start-feature

目的

計画された機能エピックには、このスキルを使用してください。ユーザーは、正規の <slug>、正確な機能名、一意の名前の一部、または Beads ID で機能を指定できます。このスキルは、ロードマップのみの移行済みルートの範囲を限定した昇格、仕様レビュー、ワークツリーの有効化、および実装準備状況の調整を担当します。<core-dir> は、インストール済みの ../dstack-core スキルディレクトリとして解決してください。

ローカル実行の権限

/start-feature の呼び出しにより、機能ルートとライフサイクルに関する Beads の変更、ローカルワークツリーの有効化、および必要なレビュー済み設計／グラフのコミットを含む、ローカル仕様の調整が許可されます。ユーザーがローカル Git の権限を明示的に制限または保留しない限り、そのコミットについて別途承認を求めないでください。このワークフローでは、リモートへの公開、プルリクエストの作成、ブランチのプッシュは許可されていません。

一般的な bd prime の引き継ぎガイダンスは参考情報であり、この呼び出し済みワークフローやリポジトリのポリシーに優先するものではありません。

Beads の共有ネイティブ権限

選択した機能を変更する前に、../dstack-core/references/INTERACTION-BOUNDARY.md を読んでください。ネイティブのリンク済みワークツリーにおける Beads の権限は共有されています。bd -C は分離境界ではありません。機能ルートの要求、ノート、レビュー状態の更新、ライフサイクルのクローズは、beads-workflow-lock.py の配下で実行してください。リースが使用中の場合、他者のインタラクション行がある場合、またはスナップショットに競合がある場合は、処理を中断してください。生の bd 書き込みで回避してはいけません。

起動時のバージョン情報

ブランチ、ワークツリー、Beads、またはファイルを変更する前に、../dstack-core/references/SKILL-VERSION.md に従って start-feature を実行してください。読み取り専用の機能解決後、出力された正確な1行を取得し、有効化の前に選択したルートの Beads ノートに追記してください。結果が stale の場合は npx skills update で更新するよう警告します。unavailable の場合は鮮度に関する確認ができなかったことを記録し、オフライン作業は妨げません。

実行

1. 機能のコンテキストを解決する

bd prime を実行してから、Beads を通じて人間向けのセレクターを解決します。セレクターが指定されている場合：

uv run <core-dir>/scripts/resolve-feature.py "<feature-selector>" --json

ユーザーがセレクターを指定せずに /start-feature を呼び出した場合、不透明な ID を尋ねたりコピーしたりするのではなく、次に着手可能な機能エピックを選択します：

uv run <core-dir>/scripts/resolve-feature.py --next --json

Beads の変更には返された id を使用し、ブランチ、パス、メッセージ、および後続のワークフローコマンドには feature_reference を使用します：

bd show <resolved-root-id> --json

選択したイシューは、workflow:feature を持つエピックでなければなりません。最初にルートのメタデータを読み取ります。メタデータには、機能スラッグ、人間向けの名前、パス、ベースブランチ、実装リポジトリ／パス、ワークフローの種類、ライフサイクル ID が含まれている必要があります。セレクターが曖昧な場合は停止し、リゾルバーが提示する人間向けの候補を表示してください。推測したり、ID に文字を追加したりしてはいけません。セレクターが単独の task、bug、chore、spike、または feature に解決された場合、状態、ブランチ、ワークツリーを変更せず、代わりに /implement-task <human task selector> を推奨してください。このコマンドを満たすためだけに、単独のイシューを機能の計画に回してはいけません。

選択したルートがロードマップ専用で、design.md またはライフサイクルのメタデータがない場合、停止したり、別のスキルを呼び出すようユーザーに求めたりしてはいけません。/plan-features の範囲を限定した単一機能の計画フェーズを実行します。不足している成果、境界、依存関係、検証、ドキュメントへの影響、リポジトリの所有権のみを解決し、設計、ライフサイクル、範囲を限定した実装の子イシューを作成してから、このワークフローを続行してください。既存の機能スラッグとルート ID は維持してください。この呼び出しに必要な特定のレビューまたは照合用 Beads のみを照会してください。

ライフサイクル ID が不足している場合は、一度だけメタデータを修復します。molecule の場合は bd mol show <feature-root> --json を、移行済みの親子ライフサイクルの場合は bd list --parent <feature-root> --all --json を使用してください。タイトルのテキストではなく、構造化メタデータとラベルを使って子イシューを特定し、その ID をルートに保存してください。

design.md、その Documentation Impact セクションに記載された正確なページ、関連するアーキテクチャのページ、現在の実装エビデンス、関連する実装済み機能の記録を読み取ります。

2. 実装リポジトリを解決する

implementation_path が存在する場合はそれを使用します。Git ルートであること、および implementation_repository と一致することを確認してください。別のリポジトリが所有する機能について、計画リポジトリにワークツリーを作成してはいけません。メタデータが不足し、リポジトリの所有権が曖昧な場合は、作業を妨げる質問を1つ行い、その回答をルートに保存してください。

3. ワークツリーを有効化する

次を使用します：

feat/<slug>

wt が利用可能な場合はそれを使用し、JSON 標準出力を正とします：

# Create when the feature branch/worktree does not exist.
wt switch --create --yes --format json feat/<slug> --base <base-branch>

# Switch when the worktree already exists.
wt switch --format json feat/<slug>

wt が利用できない場合はネイティブ Git を使用し、次の3つの状態をすべて明示的に処理します：

# Inspect existing worktrees and branches.
git worktree list --porcelain
git show-ref --verify --quiet refs/heads/feat/<slug>

# Branch and worktree both absent:
git worktree add -b feat/<slug> <worktree-path> <base-branch>

# Branch exists but has no worktree:
git worktree add <worktree-path> feat/<slug>

# Worktree already exists:
# Use the path reported by `git worktree list --porcelain`; do not add another one.

以降の Git 操作とファイル操作は、解決済みのワークツリーパスから実行するか、git -C <worktree-path> を使用してください。次の両方を確認します：

git -C <worktree-path> branch --show-current
git -C <worktree-path> rev-parse --show-toplevel

編集前に、ブランチが feat/<slug> と一致し、ルートが解決済みのワークツリーパスと一致していなければなりません。クレーム、ノート、その他の変更を行う前に、選択した機能の読み取り専用の解決済みルートを対象に、未適用またはより新しいトポロジーがないことを確認します：

python3 <core-dir>/scripts/migrate-review-topology.py \
  --repository-root <primary-worktree> guard \
  --root-id <feature-root> --controller-topology-version 3

古いレビュー種別がカットオーバーマーカーなしで残っている場合は、続行する前に、正規のプライマリワークツリーから移行を計画して適用します。移行ツールはトポロジーを変更する唯一の所有者であり、リポジトリのリースを自ら取得します。このスキルから移行ツールの書き込みを模倣してはいけません。ガードが正常に完了した後に限り、通常のリースの下で機能ルートをクレームできます。

4. 直接割り当てを導き出し、その後2つのレビューを実施する

Beads はワークフローマニフェストです。選択した機能ルート、設計／仕様の課題、実装コーディネーターと子課題、現在の検証／ドキュメント担当、および正確なレビュー課題を Beads から読み取ってください。共有エビデンスバンドル、コレクター、共有コンテキスト、または2つ目の永続的なマニフェストは作成しないでください。

起動前に、権威ある機能ワークツリーから不変の Git ソース境界を1つ固定してください。内容は review_boundary_id、reviewed_commit、reviewed_diff_base、reviewed_diff_digest、および変更パスです。各レビュー状態について、担当する review_issue_id、ソース境界、宣言済みパス、ドメイン、要件 ID、initial_active 状態を、レビュー担当者の起動前に永続化してください。固定した読み取り専用ワークツリーを、レビュー担当者が調査するソースとします。

割り当てには、固定した読み取り専用ワークツリーと、その正確なソース境界を含めてください。現在の Beads 課題と設計／ドキュメントから、役割ごとに一時的な割り当てを1つ導き出します。割り当てには、担当する Beads の課題／タイトル、説明、受け入れ基準、依存関係、検証／ドキュメントの担当、ソース境界のフィールド、宣言済みのパス／ドメイン／要件、明示的な対象外事項、および構造化レポートの契約を含めます。../dstack-core/references/PI-REVIEWER-ROSTER.md で正確な Pi 名を解決してください。論理名 specification-clarity は dstack-clarity-reviewer に、execution-readiness は dstack-readiness-reviewer に対応します。名前が存在しない、または利用できない場合は、任意のプロジェクトローカル同期後に、その旨を明示して失敗させます。暗黙の置き換えは行いません。

独立した新規レビュー担当者をちょうど2名、並行して起動してください。それぞれに渡すのは、その役割の一時的な割り当てと、固定した読み取り専用ワークツリーだけです。レビュー担当者は割り当てられたエビデンスを直接収集し、エビデンスの不足を報告します。割り当ての範囲を暗黙に広げてはいけません。

仕様の明確さ

動作、境界、互換性、担当、失敗／復旧ポリシー、ドキュメントの意図、未解決のユーザー判断をレビューしてください。ポリシーを作り出してはいけません。

実行準備状況

タスクの範囲、依存関係の方向、担当、検証、ドキュメントの担当、受け入れ基準、コミット境界をレビューしてください。作業を、意図を作り出すことなく実行できる状態にする必要があります。

../dstack-core/references/REVIEW-STATE.md と REVIEW-FINDINGS.md に従ってください。該当するライフサイクルレビュー Beads をそれぞれ取得し、起動前に現在の実行可能な状態を追記してください。レビュー状態はレビュー担当者ごとに管理し、集約状態には specification-clarity と execution-readiness をそれぞれ正確に使用します。未完了のレビュータスクと spec-reconcile は想定されたものであり、指摘事項ではありません。信頼度レビュー担当者を追加しないでください。影響を受けた元のレビュー担当者のみ再開してください。範囲に重大な変更があった場合は再設計に戻ります。タイムアウト／利用不可の扱いと、代替レビュー担当者の有限な起用方法は状態ヘルパーに従います。終端の redesign_required 状態になった後は、調整して新しい境界をコミットし、その後、ヘルパーによる上限1回の redesign 遷移を新しい境界 ID で実行してください。古い境界に対してレビュー担当者を再度起動してはいけません。

5. 仕様を調整する

design.md、Beads の説明、受け入れ基準、依存関係、メタデータ、検証、ドキュメントへの影響を明確に修正します。レビュアーの状態遷移と集約状態には、../dstack-core/scripts/review-state.py を使用してください。 いずれかのレビュアーまたは集約状態に decision_required、changes_required、未完了のレビュー、waiver_required、または redesign_required が含まれている間は、spec-reconcile をクローズできません。

レビュアーが、ユーザーポリシーまたは意図について真に未解決の事項を特定した場合は、その決定記録を保持して処理を停止します。以下のラベル付き項目を含む決定概要を 1 つ提示します。

• Issue: 何が決定できないのか、および安全な推測を妨げる証拠や明示的な不確実性。
• Affected requirements/tasks: 記録されているすべての要件 ID とタスク ID。
• Recommendation: 1 つの選択肢と、それがレビュー済みの境界を最もよく保つ理由。
• Alternatives and consequences: 実行可能な各代替案と、それに伴う具体的なトレードオフ。
• Question: 記録された決定を解決できる、正確な質問を 1 つだけ。

質問の背後に問題の詳細を隠したり、複数の質問をしたり、回答を捏造したりしないでください。ユーザーから回答を得たら、review-state.py transition をイベント reconcile で呼び出す前に、その回答の author、正確な value、現在の reviewed_diff_digest を boundary_digest として、永続的な決定記録に追記します。このヘルパーは、そのダイジェストを現在のソース境界に対して検証し、解決済みの決定に関する証拠を保持します。検証の前に、次の追記専用 Review state: レコードとして、返された状態を保存します。ヘルパーの結果が正式な状態です。遷移では、すべての複合保留条件と、該当する検出事項 ID をまとめて解決する必要があります。この遷移で唯一の検証パスを消費します。

調整後、必須のすべてのレビュアー状態と、変更されたパス、ドメイン、要件 ID の完全な各セットを指定して、review-state.py aggregate を呼び出します。Git ソース境界が変更された場合は、完全な reconciliation_boundary を 1 つ指定します。一時的な割り当て ID は保存しません。集約処理は、兄弟レビューの承認無効化より先に、共通の境界をアトミックに適用します。再開する影響対象の元レビュアーに戻る前に、兄弟レビューの承認無効化を含む、集約処理から返されたすべてのレビュアー状態を保存します。検証後に集約状態を再確認し、返された can_close が正確に true の場合に限り、レビューと仕様のゲートをクローズします。レビュアーの不足、未解決の複合条件、未完了／免除／再設計の状態、または検証後の重複する変更がある場合は、クローズできません。

移行済みの機能では、仕様または終了処理を妨げる migration:reconciliation Bead を解決します。現在の設計と Beads グラフを正式な情報源としつつ、レガシーの証拠はノートに保持します。

レビュー済みの設計とグラフの境界をコミットします。コミットメッセージには機能ルート ID を含めます。コミット SHA を spec-reconcile タスクに記録します。

レビュータスクは、検出事項を解決した後にのみクローズし、その後で spec-reconcile をクローズします。

bd close <review-task-id> --reason "Review complete; findings reconciled"
bd close <spec-reconcile-id> --reason "Reviewed design and execution graph committed at <sha>"

これらのライフサイクル変更後に、機能のワークツリーがクリーンであることを確認します。続行する前に、スコープ内に残っているワークフロー状態をローカルでコミットします。2 回目のコミット承認を求めないでください。機能のワークツリーに未コミットの変更がある場合は、/implement-feature <slug> を推奨しないでください。

test -z "$(git -C <worktree-path> status --porcelain)"

6. 実装準備状況を確認する

次を実行します。

bd ready --parent <implementation-id> --json

設計にゲートのみ、または保留中の作業のみが意図的に含まれている場合を除き、少なくとも1つの実装子タスクが準備完了になっているはずです。正常に準備された機能を、このリポジトリの実装デフォルトとして保存します。

git -C <worktree-path> config dstack.activeFeature <slug>

仕様の整合性確認と実装準備状況のチェックに合格した後にのみ、これを設定してください。この値はリポジトリローカルの Git の状態であるため、後で /implement-feature を呼び出したときに、ベースのワークツリーから呼び出した場合でも、その機能を再開できます。

正規の機能参照と人間が読める名前を最初に返し、その後に監査可能性のためのルート ID、ワークツリー、レビュー済み設計のコミット、レビュー結果、下された判断、残っているブロッカー、次に実装準備が整っているタスクを続けてください。推奨する続行方法では、Beads のハッシュだけを使うのではなく、/implement-feature <slug> を使用してください。