implement-feature

目的

/start-feature で spec-reconcile が完了した後に、このスキルを使用します。/start-feature と同じ人間向け機能セレクターを受け付けます。Beads は実行可能な作業を選択し、design.md は意図する動作と設計上の制約を示します。<core-dir> は、インストール済みの ../dstack-core スキルディレクトリとして解決します。指定されたセレクターが、レビュー済みの workflow:feature エピックの子ではなく、単独の task、bug、chore、spike、または feature に解決される場合は、作業を請求する前に停止し、/implement-task <human task selector> を推奨します。

この呼び出しで許可されるのは、範囲を限定したローカル実装コミット、必要な場合に選択したルートに対して行う起動時のインタラクション証跡コミット、すべての子と実装コーディネーターの完了後に行うインタラクションのみの監査コミットです。プッシュ、プルリクエスト、マージ、ワークツリーの削除は許可されず、リモートへの配信も許可されません。

共有ネイティブ Beads 権限

機能を変更する前に、../dstack-core/references/INTERACTION-BOUNDARY.md を読みます。ネイティブのリンクされたワークツリーにおける Beads 権限は共有されています。bd -C は分離境界ではありません。請求／完了／証跡／最終処理の各区間は、beads-workflow-lock.py の実行下で行い、リースが使用中の場合、他者のインタラクション行がある場合、またはスナップショット競合が発生した場合は停止します。リースを回避するために bd の書き込みを直接実行したり、別の機能の監査証跡をコピーしたりしてはいけません。

起動時のバージョン証跡

子の作業を請求したり機能を変更したりする前に、implement-feature について ../dstack-core/references/SKILL-VERSION.md の手順に従います。読み取り専用で機能を解決してワークツリーをアクティブ化した後、まずセクション 1 で説明されている、クリーンな機能ワークツリーのベースラインを取得します。次に、正確に1行の出力を取得して選択したルートの Beads ノートに追記し、子を請求する前に起動時のインタラクション境界を確定します。stale の結果が出た場合は npx skills update を案内します。unavailable の場合は、鮮度に関する主張を行わなかったことを記録しますが、オフライン作業は妨げません。

実行

1. 最小限のコンテキストを読み込む

呼び出し元のディレクトリからリポジトリのルートを解決し、そのリポジトリから bd prime を実行します。指定された機能セレクターを読み取り専用で解決します。ルート ID を取得した直後、請求、ノート、その他の変更を行う前に、<core-dir>/scripts/migrate-review-topology.py guard --root-id <feature-root> --controller-topology-version 3 を実行します。より新しいマーカーがある場合、または古いレビュー種別が未移行の場合はフェイルクローズします。トポロジーの変更を行うのは、canonical-primary-worktree migrator のみです。セレクターが省略された場合は、次の優先順位を決定的に適用します。

1. 現在のブランチが feat/<slug> に一致する場合は、そのブランチを使用します。
2. それ以外の場合は、最後に成功した /start-feature が記録したリポジトリローカルの機能を使用します。
3. それ以外の場合は、無関係な準備済み作業を選ぶのではなく、セレクターを指定するよう求めて停止します。

repository_root=$(git rev-parse --show-toplevel)
bd -C "$repository_root" prime
branch=$(git -C "$repository_root" branch --show-current)
if [[ "$branch" == feat/* ]]; then
  feature_selector=${branch#feat/}
else
  feature_selector=$(git -C "$repository_root" config --get dstack.activeFeature || true)
fi
test -n "$feature_selector"
uv run <core-dir>/scripts/resolve-feature.py "$feature_selector" --root "$repository_root" --json
bd -C "$repository_root" show <resolved-root-id> --json

ここでは、次の機能を自動選択してはいけません。保存された値は、ユーザー指定のセレクターと同様にリゾルバーで検証します。状態が古い場合や曖昧な場合は、別の機能を選ぶのではなく停止します。

返されたルート ID は Beads 操作にのみ使用し、返された <slug> 参照はワークツリー、報告、継続コマンドに使用します。ルートメタデータの implementation_id から実装コーディネーターを解決します。機能の子を照会するのは、一度限りのメタデータ修復経路に限ります。これにより、通常のコンテキスト読み込みは機能全体の規模に左右されず、molecule と、移行済みの親子ライフサイクルの両方で機能します。機能ワークツリーは /start-feature によってすでにアクティブ化されている必要があります。ここで切り替えたり作成したりしてはいけません。

プロセスの CWD ではなく、ブランチから正規のワークツリーを解決します。これにより、ベースワークツリーからの呼び出しも安全になります。

feature_branch=feat/<slug>
task_worktree=
worktree_path=
while IFS= read -r line; do
  case "$line" in
    "worktree "*) worktree_path=${line#worktree } ;;
    "branch refs/heads/$feature_branch") task_worktree=$worktree_path ;;
  esac
done < <(git -C "$repository_root" worktree list --porcelain)
test -n "$task_worktree"
test "$(git -C "$task_worktree" branch --show-current)" = "$feature_branch"
test "$(git -C "$task_worktree" rev-parse --show-toplevel)" = "$task_worktree"

以降のすべての機能 Git コマンドでは git -C "$task_worktree" を使用し、すべての機能 Beads コマンドでは bd -C "$task_worktree" を使用します。ブランチまたはワークツリーを正確に解決できない場合は、変更を行う前に停止します。 指定された子タスクがある場合はそれを優先し、ない場合は Beads の原子的な次の準備完了タスクの選択を使用します。起動時のインタラクション境界が確定し、以下の子タスクのベースラインを記録するまでは、子タスクを claim しないでください。claim した子タスクは次の作業単位であり、呼び出しの終了ではありません。各子タスクをクローズして確定した後、ただちにこの選択手順に戻り、新たにクリーンなベースラインを記録して、機能の作業を続けてください。

構造化メタデータ、スコープ、受け入れ条件、ブロッカー、設計資料、ドキュメントの担当範囲、検証方法を確認してから、ほかのファイルを読み込んでください。より広いコンテキストが必要でない限り、関連する設計セクションと読者向けページのみを読んでください。

従来の tasks.md ファイルは移行用の入力に限ります。Beads へのインポート後は、ライブのタスク状態として使用しないでください。

起動時のバージョンメモやその他の機能変更を行う前に、機能の作業ツリーがクリーンであることを確認し、解決済みの機能の作業ツリーから不変のベースラインコミットを記録してください。

test -z "$(git -C "$task_worktree" status --porcelain)"
startup_base_commit=$(git -C "$task_worktree" rev-parse HEAD)
workflow_run_id=<stable workflow run id>

以下に示す、連続するすべての Beads 変更コマンド（起動時のメモ、claim、レビュー／証拠の更新、クローズ、インタラクションの確定を含む）は、正規のリポジトリルートを使って、共有の beads-workflow-lock.py リース内で実行する必要があります。bd -C "$task_worktree" は機能のコンテキストを選択しますが、分離されたロックやデータベースを作成するものではありません。リースが使用中の場合やインタラクションのスナップショットが変更されている場合は、処理をブロックしてください。生の bd 書き込みで回避してはいけません。

uv run <core-dir>/scripts/beads-workflow-lock.py exec \
  --repository-root "$repository_root" --run-id "$workflow_run_id" --timeout 0 \
  -- bash -eu -c '<contiguous Beads mutation and interaction finalization commands>'

起動時のルート、クローズするすべての子タスク、クローズする実装コーディネーターには、このフェイルクローズ手順を使用してください。verify-feature モードは、単独のクリーンベースラインとステージ済みインデックスのチェックを再利用します。子タスクとコーディネーターをクローズするには、選択した作業単位に対するインタラクションが必要です。起動時は、メモによって行が出力されない場合に --allow-clean を指定できます。このモードで許可されるのは、選択した機能の系譜に属する行のみです。それ以外の変更されたパスや安全でないインタラクション状態はすべて拒否されます。

set -euo pipefail
finalize_feature_interactions() {
  work_unit_id=$1
  baseline_commit=$2
  allow_clean=${3:-false}
  verify_args=(
    --worktree "$task_worktree" --root-id <root-id>
    --issue-id "$work_unit_id" --baseline-commit "$baseline_commit"
  )
  if test "$allow_clean" = true; then
    verify_args+=(--allow-clean)
  fi
  worktree_result=$(uv run <core-dir>/scripts/reconcile-beads-interactions.py verify-feature \
    "${verify_args[@]}")
  worktree_dirty=$(printf '%s\n' "$worktree_result" | python3 -c \
    'import json, sys; print(str(json.load(sys.stdin)["dirty"]).lower())')
  if test "$worktree_dirty" = true; then
    snapshot_sha256=$(printf '%s\n' "$worktree_result" | python3 -c \
      'import json, sys; print(json.load(sys.stdin)["snapshot_sha256"])')
    snapshot_mode=$(printf '%s\n' "$worktree_result" | python3 -c \
      'import json, sys; print(json.load(sys.stdin)["snapshot_mode"])')
    snapshot_blob=$(git -C "$task_worktree" hash-object -- .beads/interactions.jsonl)
    precommit_head=$(git -C "$task_worktree" rev-parse HEAD)
    cat > /tmp/dstack-feature-interactions-message <<EOF
chore: Record feature work evidence

Beads: ${work_unit_id}
EOF
    git -C "$task_worktree" add -- .beads/interactions.jsonl
    test "$(git -C "$task_worktree" diff --cached --name-only)" = ".beads/interactions.jsonl"
    uv run <core-dir>/scripts/reconcile-beads-interactions.py verify-feature \
      "${verify_args[@]}" \
      --expected-content-sha256 "$snapshot_sha256" --expected-mode "$snapshot_mode" --staged
    precommit_index_tree=$(git -C "$task_worktree" write-tree)
    test "$(git -C "$task_worktree" rev-parse HEAD)" = "$precommit_head"
    test "$(git -C "$task_worktree" write-tree)" = "$precommit_index_tree"
    git -C "$task_worktree" commit -F /tmp/dstack-feature-interactions-message
    interaction_commit_sha=$(git -C "$task_worktree" rev-parse HEAD)
    test "$(git -C "$task_worktree" rev-parse "$interaction_commit_sha^")" = "$precommit_head"
    test "$(git -C "$task_worktree" show -s --format=%T "$interaction_commit_sha")" = "$precommit_index_tree"
    audit_paths=$(git -C "$task_worktree" diff-tree --no-commit-id --name-only -r "$interaction_commit_sha")
    test "$audit_paths" = ".beads/interactions.jsonl"
    test "$(git -C "$task_worktree" rev-parse "$interaction_commit_sha:.beads/interactions.jsonl")" = "$snapshot_blob"
    audit_mode=$(git -C "$task_worktree" ls-tree "$interaction_commit_sha" -- .beads/interactions.jsonl | awk '{print $1}')
    test "$audit_mode" = "$snapshot_mode"
  elif test "$worktree_dirty" = false; then
    uv run <core-dir>/scripts/reconcile-beads-interactions.py verify-feature \
      "${verify_args[@]}" >/dev/null
    interaction_commit_sha="not required — no tracked interaction append"
  else
    printf 'ERROR: verify-feature returned an invalid dirty state\n' >&2
    return 1
  fi
  test -z "$(git -C "$task_worktree" status --porcelain)"
}

起動時のバージョン診断を実行し、その正確な行を bd -C "$task_worktree" で <root-id> に追記してから、finalize_feature_interactions <root-id> "$startup_base_commit" true を呼び出してください。省略可能な true は、メモによってインタラクション行が出力されなかった場合に、追跡対象の状態がクリーンな起動時区間を許可します。そのルート境界がクリーンになるまで、子タスクを claim しないでください。

skill_version_evidence=$(python3 <core-dir>/scripts/check-skill-version.py \
  --skill-name implement-feature --format line)
bd -C "$task_worktree" update <root-id> --append-notes "$skill_version_evidence"
finalize_feature_interactions <root-id> "$startup_base_commit" true

ユーザー指定の claim または自動選択のいずれかを行う直前に、子タスクの境界を記録してください。

test -z "$(git -C "$task_worktree" status --porcelain)"
task_base_commit=$(git -C "$task_worktree" rev-parse HEAD)
bd -C "$task_worktree" ready --parent <implementation-id> --claim --json
bd -C "$task_worktree" show <task-id> --json

ユーザーが特定の子タスクを選択した場合は、bd -C "$task_worktree" update <task-id> --claim と bd -C "$task_worktree" show <task-id> --json の実行前に、同じクリーンベースラインのルールを適用してください。その子タスクがクローズされ、インタラクションが確定するまで、task_base_commit を保持してください。検証で境界が拒否された場合は、ステージ、復元、コミットを一切行わないでください。機能の Beads 変更が許可された後、通常の一時停止または復帰を行う前に、現在のインタラクション区間を、選択した作業単位の ID に対して確定してください。コードまたは無関係な状態が引き続き変更されている場合は、そこで停止し、その状態を保持してください。

2. 範囲を限定した成果を実装する

コードを変更する前に、選択した子タスクとレビュー済みの設計に対して、意味上の範囲限定チェックを実施してください。子タスクでは、独立してレビュー可能な振る舞いを1つ、主要な担当者を1人、実用的なコミット境界を1つ特定する必要があります。文字数は警告の目安にすぎず、正しさの制限ではありません。子タスクに独立した成果、担当範囲、ドキュメント一式、またはコミット境界が複数含まれる場合は、コードを書かずに計画上の不備を記録し、spec-reconcile を再開して、実装中に分解方法を独自に考案するのではなく、タスクを仕様調整に戻してください。

重大な計画変更がどの時点で見つかった場合も、実装を停止してください。振る舞い、担当範囲、互換性、または受け入れ基準に関する重大な変更があれば、実装を停止し、レビュー済みのソース境界を無効にします。spec-reconcile と影響を受けるレビュー用ビーズを再開し、古くなったレビュー証拠を無効として記録し、設計とタスクの受け入れ基準を調整して、新しい仕様境界をコミットしてレビューしてください。実装を再開できるのは、そのゲートがすべて閉じた後です。重大な意図の調整をその場で済ませたり、古いレビュー証拠のまま続行したりしないでください。レビュー済みの意図、担当範囲、互換性、受け入れ基準、またはレビュー境界を変更しない場合に限り、編集上の明確化をその場で行えます。その場合は明確化の内容を記録して続行してください。

選択したタスクを満たす、最小限で完全な変更を実装してください。レビュー済みの設計と、リポジトリで確立されているパターンを維持してください。コード、テスト、設定、マイグレーション、可観測性、障害時の振る舞い、復旧は、タスクの境界内に収めてください。

タスクで指定された、読者向けのページを正確に更新してください。提供する振る舞いによって読者に継続的な情報ニーズが生じる場合に限り、他のページを追加してください。新しいページはすべて、同じ作業単位で docs/src/SUMMARY.md に登録してください。機能設計は監査記録として公開したままにしますが、製品ドキュメントは機能設計を参照しなくても単独で理解できる内容にしてください。

3. 検証とレビュー

作業を進める際は、変更した動作を対象とする最小限のチェックを実行します。Beads に記録されているタスク固有の検証コマンドと、ドキュメントを変更した場合は uv run --no-project python scripts/check-docs.py を実行します。 検証と担当レビュアー 1 名のレビューは、タスクの正確な受け入れ基準、宣言された変更パス、影響を受けるチェックの範囲内で行います。リポジトリ全体のテストスイートを自動的に実行しないでください。明示的にユーザーから依頼された場合、またはこのライフサイクルとは別のリポジトリ納品ポリシーで必須とされている場合に限り、実行します。修正後は入力が変更されたチェックだけを再実行し、無関係ですでに成功したチェックは再実行しないでください。

オプションの Pi アダプターは ../dstack-core/references/PI-REVIEWER-ROSTER.md で定義されており、論理的な task ロールを dstack-task-reviewer に割り当てます。別途コンテキストビルダーを用意する必要はありません。コントローラーは、選択した Beads イシュー、設計・ドキュメント、影響を受けるチェック、不変の Git ソース境界から、一時的な割り当てを導出します。選択した子タスクごとに、常に新規のレビュアーを 1 名だけ割り当て、2 つ目の永続的な割り当てマニフェストは作成しません。指定されたエージェントが存在しない場合は、PI-REVIEWER-ROSTER.md に記載された、プロジェクト固有の明示的な同期を提案します。同期が拒否された場合、または失敗した場合は、失敗したことを明示します。利用できない場合も、ロールの代替やレビュー人数の変更を黙って行わず、失敗したことを明示します。Pi の検出、再開、置き換え、Beads の証跡の管理については、共通のリファレンスに従ってください。

context: fresh を指定して、最初のレビュアーを必ず 1 名だけ起動し、正確性、セキュリティ、保守性、テストの妥当性、選択したタスクと設計への準拠に焦点を当てます。起動前に ../dstack-core/references/REVIEW-STATE.md と ../dstack-core/references/REVIEW-FINDINGS.md に従い、レビューを管理するイシュー、レビュアーのセッション、不変の Git ソース境界、宣言された割り当て範囲、現在の判定、現在の未解決の指摘事項を記録します。対処できていない固有のリスクがある場合、またはユーザーから明示的に依頼された場合を除き、信頼度を高めるためのレビュアーを追加しないでください。

対処可能な指摘事項を解決します。同じレビュアーと実行 ID を再開し、修正を検証します。元のレビュアーを再開できない場合に限り、新しいレビュアーに置き換えます。修正によってレビュー対象の範囲が大きく変わる場合は、上記の計画不備の手順に進み、別の境界を新しいレビュアーに承認させないでください。置き換え後のレビュアーには、同じソース境界、指摘事項の記録、解決内容、レビュー後の差分を提供します。利用できない理由または置き換えた理由と、現在の Review state: 記録を、コマンド、結果、制約、指摘事項、修正内容と併せて記録します。

bd -C "$task_worktree" update <task-id> --append-notes "Validation and review evidence: ..."

4. コミットしてクローズする

git -C "$task_worktree" status --short を実行し、既存の変更または対象範囲外の変更を特定して、タスクの範囲から除外します。

タスクによってリポジトリに変更が生じる場合：

1. 範囲内の成果をすべてコミットします；
2. コミットメッセージに Beads タスク ID を含めます；
3. git -C "$task_worktree" rev-parse HEAD で正確なコミット SHA を取得します；
4. クローズする前に、その SHA をタスクのノートに記録します。

commit_sha=$(git -C "$task_worktree" rev-parse HEAD)
bd -C "$task_worktree" update <task-id> --append-notes "Commit evidence: ${commit_sha}"
bd -C "$task_worktree" close <task-id> --reason "Acceptance criteria satisfied; commit ${commit_sha}"

タスクでリポジトリの変更が正当に不要な場合は、意図したタスクの変更に未コミットのものがないことを確認し、クローズする前に具体的な理由を記録します：

bd -C "$task_worktree" update <task-id> --append-notes "Commit evidence: no commit required — <specific reason>"
bd -C "$task_worktree" close <task-id> --reason "Acceptance criteria satisfied; no commit required — <specific reason>"

プレースホルダーの SHA、コミット欄の未記入、または説明のない no commit required という表現のままタスクをクローズしないでください。クローズするすべての実装タスクには、実際のコミット SHA、または具体的なコミット不要の理由が必要です。子タスクのクローズは、最後の Beads 変更です。その後、子タスクのノートを追加しないでください。クローズ直後に finalize_feature_interactions <task-id> "$task_base_commit" を呼び出してください。これにより、追跡対象の行がある場合は各子タスクの後にインタラクションのみの監査コミットが記録され、凝集チェックポイントまたは次の選択の前にフィーチャーのワークツリーがクリーンであることが確認されます。interaction_commit_sha を保持して報告してください。クローズ済みの子タスクには書き戻さないでください。

対象範囲外の作業が見つかった場合は、その子タスクの検証済み境界内に選択された系譜のインタラクション行が含まれるよう、最終的な子タスクの証拠とクローズの前に、出所情報とともに記録します：

bd -C "$task_worktree" create "<discovered work>" \
  --type <bug|spike|chore|task> \
  --deps discovered-from:<task-id> \
  --json

不具合には bug、終了条件を定めた範囲限定の事実調査には spike、保守作業には chore、それ以外には task を使用します。未解決のプロダクトポリシーを先送りするための実装上の decision は作成しないでください。その未解決事項は仕様の調整に戻します。安全な完了に真に必要な前提条件である場合にのみ、ブロッキングエッジを追加してください。

5. 機能を余すことなく実装し続ける

タスクの境界やコミットの境界は、作業を止めるタイミングではありません。子タスクが正常にコミットされて完了するたびに、次の子タスクを引き受ける前に、実装、レビュー、検証から得られた新たな根拠に照らして一貫性チェックを行ってください。新たな所有権の境界、マイグレーション、外部依存関係、リスクの高い副作用クラスがないか、特に確認します。独立した価値やレビューの境界が見つからなければ、同じ機能のもとで続行してください。付随的な複雑さだけを分割の根拠にしてはいけません。

根拠から、残る成果に独立した価値があり、個別にレビュー可能だと判断された場合は、クリーンな対話のベースラインを記録し、実装コーディネーターを一時停止して、そのコーディネーター上に一貫性の欠陥とその発生元を記録してください。戻る前に、そのコーディネーターとの対話区間を終了します。実装ループから置き換えの子タスクや新しいエピックを作成してはならず、一貫性のないコーディネーターのもとで残りの作業を引き受け続けてもいけません。通常の機能計画権限を通じて戻り、依存する機能エピックを定義し、ユーザーの権限と既存の Beads の依存関係セマンティクスを維持したうえで、実装再開前に必須の設計／レビューゲートを実施してください。完了済みの作業は維持し、実際の前提条件に対してのみ blocks エッジを追加してください。

チェックで一貫性が確認された場合は、次の手順に従ってください。

1. クリーンな機能ワークツリーを必須とし、タスクを引き受ける前に新しい task_base_commit=$(git -C "$task_worktree" rev-parse HEAD) を記録します。
2. 同じ実装コーディネーターのもとで、次に実行可能な子タスクを照会し、アトミックに引き受けます。
3. その子タスクを実装、検証、レビュー、コミット、完了し、対話の境界を確定します。
4. 実装の子タスクがすべて完了するまで繰り返します。

実行可能な子タスクがない場合は、未完了の子タスクとそのブロック関係をすべて確認してください。判断を必要としないブロッカー、古くなった依存関係の状態、またはグラフの欠陥を解消して続行します。外部で実行中の前提条件については、重複や放棄をせず、調整して待ちます。一時的な外部障害については、ほかの実行可能な機能作業を進めながら再試行します。必須の検証を利用できず、免除が必要な場合に限り、ユーザーの判断を仰ぎます。あるタスクがブロックされているという理由だけで、別のタスクが実行可能なのに停止してはいけません。

残る未完了の子タスクがすべてユーザーの判断待ちでブロックされている場合に限り、ユーザーに確認してください。一度に一つの判断事項だけを質問し、回答を受けたら直ちに再開します。この状態が有効なのは移行された作業に限られます。ネイティブの /plan-features の出力には、実装に関するすべての判断がすでに含まれていなければなりません。

実装によって、動作、所有権、互換性、受け入れ条件、または新たな独立境界に関わる重大な計画上の欠陥が明らかになった場合は、作業を停止し、第 2 節の計画欠陥の無効化手順に従ってください。古い仕様やレビュー根拠のもとで続行してはいけません。発見されたのが、レビュー済みの意図を変えない編集上の明確化にすぎない場合は、記録して続行します。ネイティブの /plan-features の出力でどちらのケースも防げるはずですが、このゲートは実装中に見つかったずれから保護します。

6. 実装コーディネーターを完了する

必要な子タスクがすべてクローズされるか、明示的に延期されたら、クリーンな機能用ワークツリーを必須とし、コーディネーターの境界を記録し、提供された動作を design.md と比較し、実装レベルの受け入れチェックを実行して証拠を記録し、実装コーディネーターをクローズします：

test -z "$(git -C "$task_worktree" status --porcelain)"
coordinator_base_commit=$(git -C "$task_worktree" rev-parse HEAD)
bd -C "$task_worktree" update <implementation-id> --append-notes "Implementation acceptance evidence: ..."
bd -C "$task_worktree" close <implementation-id> --reason "Required implementation work complete; acceptance verified"
finalize_feature_interactions <implementation-id> "$coordinator_base_commit"

コーディネーターのクローズは、その境界における最後の Beads の変更です。その後にコーディネーターのメモを追加しないでください。クローズ前に、インタラクションのみのコミットと最終的なクリーン状態が必須です。これらの機能ブランチの監査コミットは /close-feature のために履歴を保持するものであり、クローズアウトまたはデリバリー中に作成される行に対する、その後の prepare、finalize、およびマージ後の系譜検証に代わるものではありません。

コーディネーターのクローズ後、デフォルトの選択がまだこの機能を指している場合に限り、古い選択をクリアします：

test "$(git -C "$task_worktree" config --get dstack.activeFeature || true)" != "<slug>" || \
  git -C "$task_worktree" config --unset-all dstack.activeFeature

実装コーディネーターがクローズされるか、残りの子タスクがすべて、明示的なユーザーの判断待ちで同時にブロックされている場合にのみ、処理を終了します。正規の機能参照と人間が読む名称、完了したすべてのタスク ID とコミット、ワークツリー、変更、ドキュメント、検証、レビュー、発見された作業、実装およびインタラクションの監査コミット、コーディネーターの状態、次のライフサイクル項目を報告します。必ず Recommended next step の行を含めます：

• 実装コーディネーターが正常にクローズされた場合は、/close-feature <slug> を推奨します；
• 判断待ちで一時停止している場合は、実装がブロックされていることとブロッカーのカテゴリーを示し、次に必要な判断についてのみ質問します；
• 検証、レビュー、環境、依存関係、またはリポジトリの状態が原因でブロックされている場合は、/implement-feature <slug> を再開する前に必要な具体的な助言または承認を示します。

ステータスの要約だけで終わらせないでください。機能がクローズアウト可能な状態なのか、それとも先にユーザーの助言が必要なのかを、推奨内容で明確にしてください。