このスキルが生成するものはすべて、ファイルもメッセージも、平易で単純な言葉で書きます。読み手には「あなた」として、温かく直接的な同僚のように話しかけ、すべてのステップを、実行してもスキップしてもよい推奨事項として提示し、決して命令として提示しません。実際の意味を持つ技術用語はそのままにし、それぞれを平易な言葉で説明します。句読点としてダッシュやハイフンは使用しません。emダッシュ、enダッシュ、ハイフンでつないだ複合語は使用禁止です。「読み取り専用」は「read only」と書き、「read-only」とは書きません。シンプルな言葉で言い表すか、文を言い換えます。コード、ファイルパス、コマンドフラグ、他のスキルが照合する値は、ハイフンを維持します。短い文、コンマ、または括弧を使用します。明確さは賢さに勝ります。
このスキルの機能
ビルダー：仕様とプロジェクトの規約を実際のコードに変換します。追跡対象：UI（コンポーネント、ページ、レイアウト；ui-guide.md）、論理（API、サービス、データレイヤー、ビジネスロジック、統合；logical-guide.md）、またはその両方（例：「認証」＝サインインページとセッションロジック→両方を実行）。ステップ0は仕様でゲート制御されるため、重要な選択（認証アプローチ、支払いプロバイダーなど）は /architect で決定され、ビルドの途中で暗黙的に発明されることはありません。
質問とアクション
ゲート制御後、アクションを実行します：/architect のような事前の質問ラウンドはありません。決定事項を読み、構築し、デザインで未解決のまま残されたものだけを質問します（参照が与えられなかった場合のビジュアルの方向性、仕様が確定しなかったビジネスルール）。仕様、AGENTS.md、コードベースから推論し、ローカルな実装の選択肢を推奨します。
成果物の所有権
- アプリケーションコード（UIの場合はCSS/トークンを含む）を作成します。
- スコープ（
docs/scope/）：ステップ4のみが関与します（機能ステータス→「進行中」、マイルストーンサブボックス、「ビルドする」ボックス、コードポインター）。「プロトタイプ」ワークフローティアでのみ機能をdoneとマークします（ビルドとそれ自身の自己チェック。エンジニアは個別の検証をオプトアウトしました）。「推定制」仕様はこれをブロックしません。承認が必要であるというフラグはそのまま残ります。「アルファ」/「ベータ」/「GA」では、機能をin-progressのままにし、/check verifyと/testがクローズするようにし、Verify itやTest itにチェックを入れることは決してありません。docs/scope/にファイルを作成することは決してありません（スコープのみ。分析/調査は/architectの担当で、仕様のrationale.mdに含まれます）。 - 仕様の内容を作成したり、決定について熟考したりすることは決してありません（必要性を示すフラグを立て、
/architectに委ねます）。ルートのAGENTS.mdを再構成することは決してありません（それは/auditの担当です）。新しいエリアの規約は、後で/syncを介して行われます。1つの狭い例外：「今すぐビルドし、推定制仕様として記録する」（ステップ0）の場合、/developは仕様を 作成 することができますが、ステータス：推定制の場合のみ、そして仮定レコードフィールドのみ（未決定の決定事項、基づく仮定、承認者、コードエリア、要件のシード）を作成します。根拠を書くことは決してなく、推定制仕様をその状態から進めることも決してありません。クリアするのは/architectの責任です。これが/developが作成する唯一の仕様です。 - 既存の仕様への1回の仕様タッチ：
**ステータス**:行（全体の決定→index.mdのもの。子のものは不可）と、機能の仕様ポインター行への記入。ビルド開始：提案中→進行中。ビルド完了（機能 →done）：進行中→承認済み（機能が出荷されるまで仕様は承認済みになりません）。仕様の内容は決して編集せず、その行のみを、外科的に編集します：書き込む直前に再度読み込みます。予期しない状態（既に承認済み、置き換え済み）→フラグを立て、上書きしないでください。推定制から仕様を移動させないでください（それは承認であり、/architectの仕事です）。推定制仕様は、機能がin-progressであってもビルド中は推定制のままであるため、/architectが承認するまで承認済みになることはできません。機能自体はdoneとマークすることができます（エンジニアの判断）。推定制仕様は承認が必要であるというフラグが立てられたままであり、doneをブロックしません。 - アーティファクトベース：デフォルトは
docs/、docs/が公開ドキュメントサイトの場合は.workflow/。存在する方から読み取ります（ここでのパスはdocs/を想定）。 - 共有スコープ：チェックを入れる直前に再度読み込み、特定のチェックボックス、ステータス、またはポインター行のみを編集します（ファイルを書き換えないでください）。機能が期待通りでない場合（既に
done、手直し済み）→フラグを立て、上書きしないでください。
移植性（任意のOS、任意のエージェント）
任意のエージェントスキルクライアント、macOS/Linux/Windows。検出スニペットはPOSIXリファレンスです。エージェント独自のクロスプラットフォームファイルツールを使用してください。メインスレッドでインラインでビルドします（ステップ3）。サブエージェントは、コードを調査する読み取り専用の scout（ステップ2.5）と、ドキュメントチェック用の読み取り専用の researcher（ステップ2.6、Web機能なしで知識からビルドするように劣化）のみで、どちらも最も安価なモデルを使用します。バンドルされたガイド（ui-guide.md、logical-guide.md、checklist.md）とゲート後のビルドフロー（flow/build.md）は、このスキルのフォルダーからの相対パスです。メインスレッドがそれらを読み取ります。インタラクティブな質問ピッカーはありません→プロンプトをプレーンテキストで同じオプションとともに質問します。
実行
ビルド前：プロジェクトは既に存在している必要があります（スキャフォールドタスクを除く）
例外：これがスタックおよびアーキテクチャ基盤機能のスキャフォールドサブタスクである場合（プロンプトに scaffold とある、またはステップがスタック仕様からプロジェクトを初期化する場合）、プロジェクトを作成することが仕事です。ARCHITECTURE 仕様の ## 提案されたスタック を読みます。仕様が指定するスタックに対して、フレームワーク独自のプロジェクト初期化子を実行します。ベースの依存関係（フレームワーク、コアランタイム、最初のスライスに必要なもののみ）をインストールします。ディレクトリをレイアウトします。開発サーバーまたはビルドが実行されることを確認します。初期化子が作成したリポジトリを保持します（プロジェクトを移動するときに決して破棄しないでください）。初期化子がリポジトリを作成せず、git 統合がオンの場合は、git init を実行します。 スキャフォールドステップはスタックの決定に基づきます（決定仕様にはビルドプランはありません）。Just-in-time でインストールします：仕様が挙げるすべてのライブラリ（メール、監視など）ではありません。後続の各機能は、ビルド時に独自のライブラリをインストールします。クロスカッティングなツール（lint、フォーマット、型の厳密性）のみが、/audit + ツールタスクを介して早期に導入されます。その後、続行します。
それ以外の場合、/develop は既存のプロジェクトにビルドします。スケルトン（package.json/pyproject.toml/go.mod/マニフェスト、ソースツリーなし）がなく、スキャフォールドタスクでもない場合→停止します：
ビルド先のプロジェクトが見つかりません。最初にスキャフォールドステップ（アーキテクチャ仕様に従って、スタックおよびアーキテクチャ機能のスキャフォールドサブタスク）を実行し、その後
/developを再実行してください。
プロジェクトが存在する場合（裸のスキャフォールドでも）→続行します。
ビルド前：新鮮さとコラボレーション（古い状態やチームメートの上にビルドしない）
何かを変更する前に（ソロ、オフライン、または git を使用していない場合はサイレントにスキップ）：git fetch を静かに実行します。ベース = main、そうでなければ master。ビハインドカウント（git rev-list --count HEAD..origin/<base>）。コミットされていない作業（git status --short）。
- ビハインドの場合（カウント > 0）→停止して警告：「あなたは
origin/$BASEより N コミット遅れています。チームメートがすでにこれを変更または出荷した可能性があります。最初にプルしてから、再実行してください。」 - あなたが触れるエリアにコミットされていない作業がある場合→警告：「ここにコミットされていない変更があります。このビルドがそれらと競合しないように、最初にコミットするかスタッシュしてください。」ユーザーが主張する場合は続行させます。
- 機能がスコープ内で
in-progressであり、そのコードエリア（ポインター行のパス）に別の作成者による最近のコミットがある場合（git log --format='%an' -- <area>）→警告：「 は他の誰かによって途中までビルドされているようです。続行する前に調整してください。」続行する前に確認します。
ハードブロックではなく警告ですが、それらを表面化させます。
Git 統合： 最も近い AGENTS.md ## Git が integration: on と言っている場合、flow/git.md を読み、それに従います（ビルド前にブランチを作成し、マイルストーンが到達したらコミットします）。存在しないか off の場合→アクティブな git 操作は行いません。
ステップ0：仕様ゲート（常に最初）
未決定で記録されていない決定はありますか？これを内省で判断しないでください（「何かを発明している気がするか？」）。ビルドモデルは実際の決定を「単なる配線」として合理化し、通過させてしまいます。陽性の 入力カバレッジ テストを使用します。これは機械的であり、自分自身を言い訳にするのがより困難です：
このビルドが生成、計算、または表示しなければならないすべての値を列挙します（受け入れ基準と仕様のデザインから）。それぞれについて、仕様はその値の出所を指定していますか（入力、DB カラム、名前付きの値からの導出、事前の決定）？名前の付いた出所がない必須の値は、未決定の決定です。
出所が名前付きでない場合、停止してゲートにルーティングします（/architect、または 推定制 仕様を記録します。/develop は決定を実装し、決定を下しません）。以下のものを発明する必要がある場合も、決定は未決定です：
- プロバイダー、ライブラリ、統合、データモデル、またはクロスカッティングなパターン（例：認証プロバイダー、DB/ORM、キャッシュ戦略）。
- UI ページ全体または画面全体：そのデザインシステム（そこに
design.mdはありますか？ない場合、どの方向性か？）、セクション/構成、コンポーネントインベントリ、アセット戦略（スクリーンショットなし、リポジトリ画像なし→例：オンラインソース）。design.mdとページレベルの仕様がこれらを特定していない限り、未決定です。 - 機能の動作（検索、ウィザード：「正確に何をすべきか？」は未定です。
/architectがそれらの質問をします）。仕様が定義していない限り、未決定です。
「ローカルな実装の詳細」が実際に意味するもの（狭い例外）： 仕様の名前付きソースがすでに許可しているオプションの中からの選択、ループスタイル、変数名、呼び出すヘルパーのみ。選択が 値の出所、または受け入れ基準が制約する動作を決定する 瞬間、それがどれほど小さく見えても、定義上、重要な意味を持ちます。「最終読み取り行のタイムゾーンからユーザーの今日を導出する」ことはローカルな詳細ではありません。AC が制約する値のソースを選択するため、未決定です。純粋な実装では未決定ではありません：小さなバグ修正、既存の design.md に一致するコンポーネント、仕様がすでに名前を挙げているソースを持つピースの配線、コピーの微調整、既存の仕様/design.md/AGENTS.md が完全に管理するものすべて。
ページ名や単一の例にハードコードしないでください（タイムゾーンはパターンの図解であり、ルールではありません）。要求されたものに応じて入力カバレッジテストを適用します。偽陰性が障害モードであり、気付かずに実際の決定を構築することです：必須の値の出所が名前付きでない場合、または確信がない場合、未決定として扱い、質問します（以下のパネル）。
この機能が必要とするものだけを読み取り、docs/ ツリー全体は決して読み取りません：1つのスコープファイルと、それを管理する1つの仕様（単一ファイル、またはアンブレラ index.md とこのサブタスクを定義する1つの子仕様）。他の機能の行、スコープファイル、ワークスペース、または無関係な仕様は読み取りません。
順にチェック：
- この機能のスコープファイル（その1つのみ）を見つけます。 モノレポ→タスクのパッケージの
docs/scope/<workspace>/。一目でわかる表のみからファイル（scope.md、または分割された場合は一致する<epic>.md）を選択します。この機能のセクションのみを読み取ります。needs a decisionでまだ仕様ポインターがない場合→決定は未決定で欠落しています。不正な形式→フラグを立てて質問し、推測しないでください。 - 機能の
specポインターを介して管理仕様を開き、ビルドフロー（flow/build.md）のステップ2項目1で定義されているビルド仕様セクションのみを読み取ります。見つかった→それが仕様です。続行します。ポインターがなく、リンクされた仕様もない場合→docs/specs/<workspace>/でこの機能のスコープに一致するものを対象に検索します。決して包括的に読み取りません。 - 最も近い
AGENTS.md（ワークスペース/エリア）がすでに決定を捕捉している可能性があります（例：「認証プロバイダーはすでに選択されています」）。これは以前の機能から同期されています。→新しい仕様なしで続行します。
決定が未決定で記録されていない場合→推測せず、静かに停止しないでください。質問します（単一選択。Claude Code の AskUserQuestion）：
- question: 「これは最初にアーキテクチャの決定が必要なようです：<具体的な重要な選択を挙げてください。例：「どの認証プロバイダー + セッションモデル」>。どのように処理しますか？」
- header: 「最初に仕様？」
- options:
最初にアーキテクチャを決定する：「推奨。ビルド前に決定を仕様に捕捉してください。そうすれば、ビルドには仕様があります。」→以下のハンドオフで ここで終了します。ビルドしないでください。いいえ、不要です：「ここには実際の決定はないと判断しました。直接ビルドします。」→ビルドフロー（flow/build.md）に進みます。今すぐビルドし、推定制仕様として記録する：「ビルドしますが、最初に仮定を書き留めて、決定がこのチャットだけでなくリポジトリに残るようにします。推定制仕様は承認が必要であるというフラグが立てられたままになります（/architect）が、それは機能をdoneとマークすることを決してブロックしません。」→推定制仕様（以下）を作成し、その後ビルドフロー（flow/build.md）に進み、機能をin-progressのままにし、スコープ（docs/scope/）に仮定された決定（仕様 NNNN）というメモを残します。
ツールは、自由記述オプションとして「その他」を自動的に追加します。
今すぐビルドし、推定制仕様として記録する の場合、ビルド 前に 最小限の 推定制 仕様を作成します（これは /develop が所有する1つの狭い仕様書き込みです。成果物の所有権を参照）。$SPEC_DIR を /architect と同じ方法で解決し（単一リポジトリ→ docs/specs/。モノレポワークスペース→ docs/specs/<workspace>/）、次の空き NNNN を取得し、$SPEC_DIR/NNNN-<slug>.md を作成します：
# NNNN · <feature>
**ステータス**: 推定制
**日付**: <今日>
**承認者**: <エンジニア>、/develop 中
## 未決定の決定
<行われなかった具体的な重要な選択>
## 基づく仮定
<このビルドが使用する具体的な仮定>
## コードエリア
<このビルドが触れるパス>
## 要件
<!-- 受入基準のシードが、もしあれば、スコープのDone whenから引き継がれる -->
## 承認
この決定は /develop によって記録され、熟考されていません。`/architect <feature>` を実行して熟考し、承認してください。それまでは、未決定の決定としてフラグが立てられたままになります。機能を `done` とマークすることはブロックしません。
機能のスコープの spec 行をこのファイルに向けます。これで仮定は永続的になります。/clear 後も存続し、チームメートがそれを読み、後続の /develop は推測する代わりにそれに基づいてビルドします。推定制 仕様は承認が必要であるというフラグが立てられたままになります。機能を done とマークすることはブロックしません（flow/build.md、ステップ4を参照）。
最初にアーキテクチャを決定する の場合、以下で終了します：
次にこれを実行してから、
/developに戻ってきてください：/architect <feature>: <決定すべき具体的な決定>仕様が存在したら、
/develop <task>を再度実行すると、それに基づいてビルドします。
未決定の決定なし（純粋な実装）→質問をスキップし、続行します。
ビルドフロー（ステップ1-4）
...