develop

出力スタイル（平易な言葉、ダッシュやハイフンなし）

このスキルが作成するものは、ファイルもメッセージもすべて、平易で簡潔な言葉で書いてください。読者には you と呼びかけ、同僚に話すように温かく率直に伝えてください。各手順は、実行しても省略してもよい提案として示し、命令は避けてください。本来の意味を持つ技術用語はそのまま使い、平易な言葉で説明してください。句読点としてダッシュやハイフンは使わないでください。em dash、en dash、ハイフンでつないだ複合語も使わないでください。read only と書き、read-only は使わないでください。簡潔な言葉を使うか、文を書き換えてください。コード、ファイルパス、コマンドフラグ、ほかのスキルが照合する値に含まれるハイフンはそのまま残してください。短い文を使い、読点や括弧を活用してください。巧みさより明快さを優先してください。

このスキルの役割

ビルダーは、仕様とプロジェクトの規約を基に、動作するコードを作成します。対象は、UI（コンポーネント、ページ、レイアウト。ui-guide.md）、ロジック（API、サービス、データレイヤー、ビジネスロジック、連携。logical-guide.md）、またはその両方です（例：「auth」はサインインページとセッションロジックなので、両方を実行します）。ステップ 0 では仕様を確認します。これにより、認証方式や決済プロバイダーなど、重要な選択は /architect で決められ、ビルドの途中でひそかに決められることはありません。

質問と実行

確認してから実行します。/architect のように最初に質問をまとめてすることはありません。判断内容を読み、ビルドし、設計で決まっていないことだけを尋ねます（参照例がない場合のビジュアルの方向性や、仕様で決まっていないビジネスルールなどです）。仕様、AGENTS.md、コードベースを基に判断し、ローカルな実装上の選択肢を提案します。

成果物の所有権

• アプリのコード（UI 用の CSS／トークンを含む）を書きます。
• スコープ（docs/scope/）では Step 4 の項目だけを扱います（機能のステータス → in-progress、マイルストーンのサブボックス、Build it ボックス、コードへのポインター）。機能を done にするのは、ワークフローの Prototype ティア（ビルドと独自のセルフチェック。エンジニアが個別の検証を行わないことを選択した場合）だけです。Assumed の仕様はこれを妨げませんが、追認が必要な状態としてフラグが残ります。Alpha／Beta／GA では、機能を in-progress のままにし、完了は /check verify と /test に任せます。また、Verify it や Test it にチェックを付けることはありません。docs/scope/ にファイルを作成することは決してありません（ここはスコープのみです。分析／調査は /architect の担当であり、仕様の rationale.md に記録します）。
• 仕様の内容を書いたり、判断について検討したりすることは決してありません（必要性を示し、/architect に委ねます）。ルートの AGENTS.md を再構成することも決してありません（これは /audit の担当です）。新しい領域の規約には、その後 /sync を使用します。例外は限定的に 1 つだけです。Build now, record it as an assumed spec（Step 0）では、/develop が仕様を作成してもかまいません。ただし、ステータスは Status: Assumed に限り、記録するのも仮定の記録項目（未決の判断、根拠となる仮定、承認者、コード領域、要件の種）だけです。根拠は決して書かず、Assumed の仕様をその状態から進めることもありません。解除は /architect の担当です。/develop が作成できる仕様はこれだけです。
• 既存の仕様に対する変更は 1 か所だけです。**Status**: 行（包括的な判断 → index.md のステータス。子のステータスではありません）と、機能の仕様ポインター行への記入です。ビルド開始時は Proposed → In Progress、ビルドが完了したとき（機能 → done）は In Progress → Accepted です（機能がリリースされるまで、仕様は Accepted ではありません）。仕様の内容は編集せず、その行だけを必要最小限の変更で扱います。書き込む直前に必ず読み直し、想定外の状態（すでに Accepted、Superseded など）なら、上書きせずフラグを立てます。仕様を Assumed から進めることは決してありません（追認は /architect の担当です）。機能が in-progress でも、ビルド中は仕様を Assumed のままにします。そのため、/architect が追認するまで Accepted にはなりません。機能自体は done にできます（エンジニアの判断です）。Assumed の仕様は追認が必要な状態としてフラグが残りますが、done を妨げることはありません。
• 成果物の基点はデフォルトで docs/ です。docs/ が公開済みのドキュメントサイトの場合は .workflow/ を使用します。存在する方から読み込みます（以下のパスは docs/ を前提としています）。
• 共有スコープ：チェックを付ける直前にもう一度読み込み、該当するチェックボックス、ステータス、またはポインター行だけを編集します（ファイル全体を書き換えることはありません）。機能の状態が想定と異なる場合（すでに done、作業のやり直しなど）は、上書きせずフラグを立てます。

---

移植性（任意の OS、任意のエージェント）

Agent Skills 対応の任意のクライアントで使用でき、macOS／Linux／Windows に対応します。検出用スニペットは POSIX の参考例です。エージェント固有のクロスプラットフォーム対応ファイルツールを使用してください。ビルドはメインスレッド上でインライン実行します（Step 3）。サブエージェントを使うのは、コードを調査する読み取り専用の scout（Step 2.5）と、ドキュメントを確認する読み取り専用の researcher（Step 2.6。ウェブを利用できない場合は、知識に基づくビルドに切り替えます）だけです。どちらも最も低コストのモデルを使用します。同梱ガイド（ui-guide.md、logical-guide.md、checklist.md）とゲート通過後のビルドフロー（flow/build.md）は、このスキルのフォルダーからの相対パスです。メインスレッドでこれらを読み込みます。対話式の質問選択機能は使いません。同じ選択肢を示し、プロンプトをプレーンテキストで尋ねてください。

実行

ビルドを始める前に：プロジェクトがすでに存在している必要があります（スキャフォールドタスクを除く）

例外：これが Stack and architecture foundation 機能のスキャフォールドサブタスクである場合（プロンプトに scaffold と記載されているか、このステップでスタック仕様からプロジェクトを初期化する場合）、プロジェクトを作成することがこのタスクの目的です。ARCHITECTURE 仕様の ## Proposed stack を確認し、仕様で指定されたスタックのフレームワーク独自のプロジェクト初期化ツールを実行します。基本的な依存関係（フレームワーク、コアランタイム、最初のスライスに必要なものだけ）をインストールし、ディレクトリを配置して、開発サーバーまたはビルドが実行できることを確認します。**初期化ツールが作成したリポジトリはそのまま使ってください（プロジェクトを移動する際に、決して破棄しないでください）。初期化ツールが何も作成せず、git 統合が有効な場合は git init を実行します。**スキャフォールドの手順はスタックの決定に基づきます（決定仕様にはビルド計画がありません）。必要になった時点でインストールしてください。仕様に記載されたすべてのライブラリ（メール、モニタリングなど）をインストールしてはいけません。各機能の実装時に、その機能で必要なものをインストールします。早い段階で導入するのは、横断的なツール（lint、フォーマット、型の厳密性）のみです。これらは /audit とツーリングタスクを通じて導入します。その後、作業を続けます。

それ以外の場合、/develop は既存のプロジェクトに実装します。骨組みもなく（package.json／pyproject.toml／go.mod／マニフェストもソースツリーもない）、スキャフォールドタスクでもない場合は、停止します。

実装先のプロジェクトが見つかりません。まずスキャフォールドのステップ（アーキテクチャ仕様に従った Stack and architecture 機能のスキャフォールドサブタスク）を実行してから、もう一度 /develop を実行してください。

プロジェクトが存在する場合（骨組みだけでも）→ 作業を続けます。

ビルドを始める前に：最新状態と共同作業（古い状態をもとにしたり、チームメイトの作業に重ねたりしないでください）

何かを変更する前に（単独作業中、オフライン、または git を使っていない場合は何もせずスキップします）：git fetch を静かに実行します。base は main、なければ master とします。遅れているコミット数（git rev-list --count HEAD..origin/<base>）と、未コミットの作業（git status --short）を確認します。

• 遅れている（件数 > 0）→ 停止して警告します：「origin/$BASE より N コミット遅れています。チームメイトがすでに変更またはリリースしている可能性があります。先に pull してから、もう一度実行してください。」
• これから触る領域に未コミットの作業がある → 警告します：「この領域に未コミットの変更があります。このビルドと混在しないよう、先にコミットするか stash してください。」本人が続行を希望する場合は、続行を許可します。
• 対象範囲の機能が in-progress で、かつそのコード領域（ポインター行のパス）に別の作成者による最近のコミットがある（git log --format='%an' -- <area>）→ 警告します：「 は、別の人がビルドを途中まで進めているようです。続ける前に調整してください。」続行前に確認します。

警告であり、強制的なブロックではありませんが、必ず伝えてください。

**Git 統合：**最も近い AGENTS.md の ## Git に integration: on とある場合は、flow/git.md を読み、その指示に従います（ビルド前にブランチを作成し、マイルストーンの達成に合わせてコミットします）。記載がないか off の場合は、git 操作を行いません。

ステップ 0：仕様ゲート（必ず最初に実施）

未決定で、記録されていない決定事項がありますか？これを内省（「何かを自分で決めようとしている気がするか？」）で判断してはいけません。ビルドモデルは、実際の決定を「単なる配線」と合理化して通してしまいます。機械的で、自分に言い訳しにくい、肯定的な入力カバレッジテストを使います。

このビルドで生成、計算、または表示する必要がある値をすべて列挙します（受け入れ条件と仕様の設計に基づきます）。それぞれについて、仕様に値の取得元（入力、DB カラム、名前の付いた値からの導出、先行する決定）が明記されていますか？必要な値の取得元が一つでも明記されていない場合、それは未決定の事項です。

取得元が一つでも明記されていない場合は、停止してゲートに進みます（/architect を実行するか、Assumed 仕様を記録します。/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>/ を確認します。At a glance テーブルだけを使ってファイル（scope.md、または分割されている場合は対応する <epic>.md）を選び、この機能のセクションだけを読みます。仕様へのポインターがまだない状態で needs a decision となっている場合 → 決定が必要で、未記録です。形式が不正な場合 → 推測せず、指摘して質問します。
2. 機能の spec ポインターを使って、規定する仕様を開きます。ビルドフロー（flow/build.md）のステップ2、項目1で定義されているビルド仕様のセクションのみを読みます。見つかった場合 → それが仕様です。続行します。ポインターがなく、リンクされた仕様もない場合 → docs/specs/<workspace>/ から、この機能のスコープに合致するものを対象を絞って探します。全体を一括して読み込んではいけません。
3. 最も近い AGENTS.md（ワークスペース／領域）に、以前の機能から同期された決定がすでに記録されている場合（例：「認証プロバイダーはすでに選定済み」）→ 新しい仕様を作成せずに続行します。

決定が必要で未記録の場合 → 推測したり、何も言わずに止めたりしないでください。次の選択式の質問をしてください（Claude Code では AskUserQuestion）。

• question: "これは、先にアーキテクチャ上の決定が必要なようです：<重要な選択を具体的に記入。例：「どの認証プロバイダー＋セッションモデルにするか」>。どのように進めますか？"
• header: "先に仕様を作成しますか？"
• options:
  1. Architect it first: "推奨。構築前に仕様に決定を記録し、仕様に基づいて構築できるようにします。" → 下記の引き継ぎを行い、ここで終了します。構築してはいけません。
  2. No, not needed: "ここには実際の決定事項はないと判断しました。直接構築します。" → ビルドフロー（flow/build.md）に進みます。
  3. Build now, record it as an assumed spec: "構築しますが、まず前提を記録し、決定をこのチャットだけでなくリポジトリにも残します。Assumed 仕様には、承認待ち（/architect）のフラグが残りますが、それによって機能を done にすることが妨げられることはありません。" → Assumed 仕様（下記）を作成してから、ビルドフロー（flow/build.md）に進みます。スコープ（docs/scope/）に assumed decision (spec NNNN) という注記を残し、機能は in-progress のままにします。 このツールは「その他」を自由記述の選択肢として自動的に追加します。

Build now, record it as an assumed spec の場合は、ビルドする前に最小限の Assumed 仕様を書きます（これは /develop が担当する、限定的な仕様書の作成です。「成果物の所有権」を参照）。/architect と同じ方法で $SPEC_DIR を解決し（単一リポジトリ → docs/specs/、モノレポのワークスペース → docs/specs/<workspace>/）、次に利用可能な NNNN を割り当て、$SPEC_DIR/NNNN-<slug>.md を作成します。

# NNNN · <feature>

**Status**: Assumed
**Date**: <today>
**Authorized by**: <engineer>, during /develop

## Owed decision
<the specific load bearing choice that was not made>

## Assumption built on
<the concrete assumption this build will use>

## Code area
<the paths this build will touch>

## Requirements
<acceptance criteria seeds carried from the scope Done when, if any>

## Ratify
This decision was recorded by /develop, not deliberated. Run `/architect <feature>`
to deliberate and ratify it. Until then it stays flagged as an owed decision; it does not block marking the feature `done`.

機能のスコープにある spec 行を、このファイルを指すようにします。これで仮定が永続化されます。/clear の後も保持され、チームメイトが参照でき、後続の /develop は再び推測するのではなく、この仕様に基づいてビルドできます。Assumed 仕様には承認が必要であることを示すフラグが残りますが、機能を done にする妨げにはなりません（flow/build.md のステップ 4 を参照）。

Architect it first の場合は、次のように締めくくります。

まずこれを実行してから、/develop に戻ってください：

/architect <feature>: <決めるべき具体的な内容>

仕様ができたら、もう一度 /develop <task> を実行してください。仕様に沿ってビルドします。

決めるべきことがない場合（実装のみ）→質問を省略して続行します。

ビルドの流れ（ステップ 1～4）

ゲートを通過したら（決めるべきことがない場合、またはエンジニアが No, not needed / Build now, record it as an assumed spec を選択した場合）、flow/build.md を読み、そのステップ 1～4 に従います。トラックを分類し、決定事項と規約を読み込み、調査し、必要に応じてドキュメントを確認し、ビルドしてから、スコープを更新して報告します。ゲートで実行が終了する場合（Architect it first、ビルドなし）は、flow/build.md を読まないでください。

---

参照ファイル

• ゲート通過後のビルドの流れ（ステップ 1～4）：flow/build.md
• UI ビルドトラック：ui-guide.md
• ロジカルビルドトラック：logical-guide.md
• アクセシビリティチェックリスト（UI トラック、フェーズ 5）：checklist.md
• プロジェクトのデザインシステム（UI トラック）：./design.md