base

ベーススキルの概要

ベーススキルでできること

base スキルは、コーディング作業の土台になるレイヤーです。シンプルな構成、TDD先行の習慣、そして細かく切り出したタスクを優先し、過度な設計に流れ込む前にブレーキをかけます。エージェントに小さな設計判断をさせたい、ファイルの可読性を保ちたい、リライトのリスクを減らしたい、という目的なら、この base スキルはまさにそのためのものです。

向いているユーザー

base スキルは、日々の実装に実用的なガードレールがほしいときに向いています。特に、新規リポジトリ、リファクタリング、またはスコープがすぐ広がりがちな AI 支援コーディングの場面で効果的です。巧妙さよりも保守性を重視するチームに、いちばん役立ちます。

何が違うのか

この base ガイドで最も強く出ているのは、派手なフレームワークではなく、厳しい制限とその徹底です。リポジトリ全体で、シンプルさのルール、行数制限、ファイルの境界、TDD ワークフローが強調されており、エージェントが自由に動ける余地を意図的に狭めています。そのため、base for Code Editing は、行き当たりばったりのブレインストーミングよりも、一貫した編集作業に向いています。

base スキルの使い方

正しくインストールして読み込む

このディレクトリエントリでは、想定されているインストールパスは npx skills add alinaqi/claude-bootstrap --skill base です。元の説明ではこのスキルは常時ロード前提になっているため、base のインストールは「編集を始める前から有効にしておきたい土台」として扱い、一度きりのプロンプト断片のようには考えないでください。

雑な依頼を、よいプロンプトに変える

base がもっとも活きるのは、プロンプトに対象ファイル、変更の目的、そして制約の種類が入っているときです。「これをきれいにして」は広範囲な書き換えを招きやすい弱い依頼です。より強い base の使い方の例は次のようになります: “Refactor src/auth/session.ts to separate validation from persistence, keep each function under 20 lines, preserve current tests, and add tests first for the new error cases.”

先に読むべきファイル

まず SKILL.md を読んでルールを把握し、そのあとで編集前にリポジトリ全体の隣接する規約を確認してください。このリポジトリには rules/ や resources/ のような補助フォルダはないため、主な判断材料はスキルファイル本体と、対象コードベース内の関連ファイルです。

スキルに合ったワークフロー

base は、最小の変更点を特定する → テストを追加または更新する → コンパクトな関数で実装する → 終了前に行数と依存関係の上限を確認する、という流れで使うのが基本です。タスクを小さくできない場合は、無理に大きなパッチを一度で通そうとせず、複数の原子的な todo に分割してください。

base スキル FAQ

base スキルは単体でも役立つ？

はい。ドメイン特化ツールではなく、コーディングの基準線がほしいなら十分役立ちます。base スキルは広く使えるよう設計されていますが、明確なプロジェクト指示と既存リポジトリの文脈がそろうと、いっそう強みが出ます。

どんなときに base を使わないべき？

探索的な作業、ビジュアル要素が強い作業、あるいは試作を前提にしていて、まだ構造を気にしなくてよい場面では使わないでください。とにかくスピード最優先なら、base スキルの制約は窮屈に感じるはずです。

普通のプロンプトより優れている？

コード編集では、たいていはそうです。base ガイドは、曖昧なスタイル指示ではなく具体的な境界をエージェントに与えるからです。通常のプロンプトは「きれいなコードを書いて」と言うだけかもしれませんが、base では関数サイズ、ネストの深さ、ファイル範囲といった測定しやすい制約が加わります。

base は初心者向け？

はい。ルールが明示的で、確認もしやすいからです。ただし初心者にありがちなリスクは、問題を十分に理解しないまま制限を当てはめすぎることです。最初は、全部を一気にリファクタリングするのではなく、最小限で有用な変更から始めてください。

base スキルを改善するには

スキルにもっと明確な入力を与える

base の結果をよくする一番の方法は、ファイル名、期待する動作、編集範囲をはっきり指定することです。「ログインフローを直して」は弱い依頼ですが、「login.ts を更新して、トークンの解析を分離し、期限切れトークンのテストを追加し、公開 API は変更しないで」と書けば、スキルの狙いが明確になります。

取るべきトレードオフを指定する

可読性を最小差分より優先したいなら、その旨を明記してください。実装より先にテスト更新が必要なら、それもはっきり伝えてください。base スキルは、何が譲れない条件なのかをこちらが示したほうがうまく反応します。優先順位を勝手に読み取ってくれると期待しないでください。

よくある失敗パターンをレビューする

細かく分けすぎていないか、見えにくい結合が増えていないか、行数制限は満たしていても命名やモジュール境界が弱くなっていないかを確認してください。最初のパスが抽象的すぎる、または断片的すぎる場合は、二回目の見直しを依頼し、些細なヘルパーを統合し、冗長性を हटし、処理の流れが一目で追えるようにしてください。