kiro-complete

name	kiro-complete
description	Kiro仕様駆動開発のSpec完了ワークフローを実行する。DoDゲート検証→コミット→completedフォルダ移動→spec.json更新→参照パス修正→ROADMAP更新→スキルドキュメント同期→最終コミット→PR作成→squashマージまでを中断なく完遂する。mainへの統合はこのPRが唯一の経路（直push禁止）。Use when: 実装完了を承認する, 承認してください, 完了を承認, spec承認, approve implementation, kiro承認完了。DO NOT USE when: 実装が完了したのみ（承認の明示がない場合）、タスクが終わっただけ
allowed-tools	Bash, Read, Write, Edit, Glob, Grep, AskUserQuestion
argument-hint	<feature-name>

Kiro Spec 完了ワークフロー

発動条件（必須）

⚠️ このスキルは開発者の明示的「承認」がある場合にのみ発動する。

✅ 発動する（承認の明示がある）

• 「実装完了を承認します」「承認してください」
• 「このspecを承認する」「approve」「kiro 承認完了」

❌ 発動しない（承認の明示がない）

• 「実装が完了した」「タスクが全部終わった」
• 「spec完了」「アーカイブしてほしい」などの曖昧な表現のみ
• AIが自律的に「完了したと判断」した場合

承認が不明瞭なとき

発動を迷う場合は 発動しない。必要なら開発者に確認する:

「実装完了の承認をいただけますか？承認いただいた場合、完了ワークフローを実行します。」

---

いつ使うか

• 開発者が上記「発動する」に該当する承認を明示的に宣言したとき
• tasks.md の全タスクが [x] 完了している状態で使用
• 設計文書リフレッシュが完了した後

完了基準の権威（ベースライン内蔵 + 任意の workflow.md）

このスキルはベースラインの完了基準（DoD）・コミット規約を内蔵し、単体で機能する。 完了基準（DoD）、コミット規約、ドキュメント更新判定の既定値はこのスキル内に定義する（下記）。 .kiro/steering/workflow.md が存在する場合のみ、それを追加の権威として優先し、定義されたゲートをベースラインに上乗せする。存在しなければベースラインのみで完了できる。

哲学

• 中断せず一連で完遂する — 全ステップを止めずに実行
• VSCodeの変更ファイル確定挙動を回避 — spec.json編集は移動後に行う
• ベースライン完了基準を内蔵 — DoD・コミット規約はこのスキルが既定値を持つ。.kiro/steering/workflow.md が存在すればそれを優先（任意）
• mainへの統合はPRが唯一の経路 — フィーチャーブランチはハーネスのワークツリーが供給。1 feature = 1 branch = 1 PR。{default-branch} への直接 push は一切行わない
• 繰り返し仕様は移動しない — 繰り返し実行型の仕様は常に .kiro/specs/ 直下に留まる

前提条件

• .kiro/specs/{feature}/tasks.md の全タスクが完了
• 設計文書と最終実装の整合確認済み

例外: 繰り返し仕様

リリース手順やレビュー・ループのような繰り返し実行型仕様は completed/ に移動しない。

判定基準:

• spec.json や requirements.md に「繰り返し」「repeatable」「定期実行」「ループ」等の記述がある
• /kiro-impl のたびにタスクがリセットされる設計

繰り返し仕様の場合:

1. ステップ1（DoD検証）とステップ2（コミット）のみ実行
2. ステップ3〜6（移動・パス更新・ROADMAP）をスキップ（completed/ へは移動しない）
3. ステップ8（リモート同期＝PR ベース）を実行
4. tasks.md のチェックボックスをリセット（全 [x] → [ ]）

---

手順

ステップ0: 決定的解決（portable context）

リモート操作で用いる {remote} と {default-branch} を、固定優先順序で1回だけ決定的に解決する。各値はちょうど1つの結果（または明示的なスキップ）に収束させ、推測しない。解決した値は以降のステップ（特にステップ8）で origin/main のハードコードの代わりに再利用する。この優先順序は kiro-start の「Step 0: Resolve portable context」と整合している。

1. デフォルトリモート（{remote}）: git remote を実行し、以下の固定ルールを適用する。

   • origin が存在する → {remote} = origin。
   • そうでなく、リモートがちょうど1つだけ存在する → {remote} = そのリモート。
   • それ以外（リモートなし、または origin を含まない複数リモート）→ {remote} = none。リモート操作はすべてスキップ扱いとする（一度だけ警告する）。

   $remotes = git remote
   if ($remotes -contains "origin") { $remote = "origin" }
   elseif (@($remotes).Count -eq 1) { $remote = $remotes }
   else { $remote = $null }  # none: リモート操作はスキップ
   

2. デフォルトブランチ（{default-branch}）: 以下の固定優先順序で決定的に解決する。

   • {remote} が解決済みなら、git symbolic-ref --quiet --short refs/remotes/{remote}/HEAD を読み、先頭の "{remote}/" プレフィックスを除去した名前。
   • それが空で、ローカルに main ブランチが存在する → {default-branch} = main。
   • そうでなく、ローカルに master ブランチが存在する → {default-branch} = master。
   • それ以外 → {default-branch} = 現在のブランチ。

   $defaultBranch = $null
   if ($remote) {
     $defaultBranch = git symbolic-ref --quiet --short "refs/remotes/$remote/HEAD"
     if ($defaultBranch) { $defaultBranch = $defaultBranch -replace "^$remote/", "" }
   }
   if (-not $defaultBranch) {
     if (git show-ref --verify --quiet "refs/heads/main") { $defaultBranch = "main" }
     elseif (git show-ref --verify --quiet "refs/heads/master") { $defaultBranch = "master" }
     else { $defaultBranch = git branch --show-current }
   }
   

   {default-branch} は1つの具体的なブランチ名として確定し、以降で再評価しない。

以降のステップは、origin/main のハードコードではなく、ここで解決した {remote} / {default-branch} を用いる前提とする。 {remote} が none の場合、リモート同期（ステップ8）は安全にスキップし警告する。

ステップ1: DoD（完了基準）ゲート検証

ベースラインの完了基準を順に検証する。判定ルールはこのスキルが内蔵する（下記）。.kiro/steering/workflow.md が存在する場合のみ読み込み、そこに定義された追加ゲートをベースラインに上乗せする（存在しなければベースラインのみで完了可）。

1. 任意: .kiro/steering/workflow.md が存在すれば読み込み、追加の DoD ゲートを取り込む。存在しなければスキップ。

2. ベースラインゲート（最低限・常時検証）:

   • Spec Gate: 当該 spec の tasks.md が全タスク [x] 完了であること。
   • Test Gate: テストスイートが全通過していること（下記3）。
   • License Gate: 依存グラフのライセンス健全性を検証し、配布用の第三者謝辞を最新化すること（下記4。設定ファイルを持つリポジトリのみ）。
   • workflow.md がある場合は、そこで定義された追加ゲート（例: Doc / Steering 等）も順に検証する。

3. Test Gate: ワークスペース全体のテストを実行し、全通過を確認する。

   cargo test --workspace 2>&1 | Select-String "test result:|FAILED|error\["
   

   • スキップ可: 直近のターンで cargo test --workspace が実行され test result: ok を確認済みで、その後にテスト対象コードの変更が無い場合は再実行を省略してよい。スキップ時は完了チェックリストに「(直近の実行結果により省略)」と注記する。
   • 判断に迷う場合は実行する。kiro-verify-completion スキルがある場合は、その fresh-evidence ゲートに委ねてもよい。

4. License Gate: MIT 配布を守るライセンス健全性ゲート。ルートに設定ファイルが存在する場合のみ実行し、無ければスキップする（ポータビリティ確保）。この2コマンドを回す:

   # (a) 汚染ゲート: 強コピーレフト(GPL/LGPL/AGPL/MPL 等)や許可外ライセンスの混入を検出
   #     deny.toml が存在する場合のみ実行。許可外検出＝失敗ならワークフロー中断・開発者へ報告。
   cargo deny check
   
   # (b) 第三者謝辞の再生成: 配布バイナリ同梱用の attribution を最新化
   #     about.toml が存在する場合のみ実行。生成差分はステップ2/7のコミットに含める。
   cargo about generate --workspace about.hbs -o THIRD-PARTY-NOTICES.md
   

   • ツール未導入時: cargo install cargo-deny --locked / cargo install cargo-about --features cli --locked で導入してから実行する。
   • 設定ファイル不在: deny.toml・about.toml が無いリポジトリでは License Gate 全体をスキップし、チェックリストに「(設定不在により省略)」と注記する。
   • 謝辞に差分が出た場合: 依存が変化した証跡。差分は後続のコミット（ステップ2/7）に自然に取り込まれるため、ここで個別コミットはしない。

5. いずれかのゲートが失敗した場合: ワークフローを中断し、開発者に報告。

ステップ2: 未コミットファイルのコミット

実装中の変更をすべてコミットする。コミットメッセージ形式は下記のベースライン規約（<type>({feature-name}): <要約>）に従う。.kiro/steering/workflow.md が存在すればその規約を優先する。

git add -A
git commit -m "<type>({feature-name}): 実装完了

- 変更の要約（箇条書き）"

ステップ3: completedフォルダへの移動

specディレクトリをcompleted配下へ移動する。

New-Item -ItemType Directory -Path ".kiro/specs/completed" -Force | Out-Null
Move-Item ".kiro/specs/{feature-name}" ".kiro/specs/completed/"

重要: この時点ではspec.jsonを編集しない。VSCodeが編集中のファイルを追跡しており、移動前に編集すると移動操作と競合してファイルが元の場所に復活する。

ステップ4: spec.jsonのステータス更新

移動完了後に spec.json を更新する。areka の spec.json スキーマ（.kiro/steering/kiro-spec-schema.md）に従い、以下を変更:

{
  "phase": "completed",
  "updated_at": "YYYY-MM-DDTHH:MM:SSZ"
}

• スキーマ規約: phase 変更時は必ず updated_at も更新する。
• 任意で approvals.implementation を更新してよい（completed: true, completed_at: "YYYY-MM-DDTHH:MM:SSZ"）。
• "status" フィールドは使用しない。"phase": "completed" で完了を表す。

ステップ5: 参照パスの更新

他のspecファイルや親仕様がこのspecを参照している場合、パスを更新する。

1. 参照箇所の検索:

Get-ChildItem ".kiro/specs" -Filter "*.md" -Recurse |
  Where-Object { $_.FullName -notlike "*completed*" } |
  Select-String -Pattern "{feature-name}" |
  Select-Object -ExpandProperty Path | Sort-Object -Unique

2. パスの一括置換: .kiro/specs/{feature-name}/ → .kiro/specs/completed/{feature-name}/

3. 親仕様への完了マーク: 親仕様のdesign.mdに完了ステータス（✅）を反映する（該当する場合）

ステップ6: 追加更新チェック

以下を実施する。.kiro/steering/workflow.md が存在すれば、その「実装完了時アクション」「ドキュメント保守」セクションの指示も併せて適用する。

6-1. ROADMAP更新

doc/ROADMAP.md を確認し、完了したSpecが記載されているか判定する（参照タイミングは .kiro/steering/focus.md）。

スコープ判定（優先順位）:

1. requirements.md に明示的なROADMAP項目との紐付け記述がある場合
2. 開発者が直接指示した場合
3. doc/ROADMAP.md の仕様テーブルにこの feature-name が含まれる場合
4. 判断に迷う場合は開発者に確認

スコープ内の場合（doc/ROADMAP.md の areka 形式に従う）:

• 6-1-1. 仕様テーブルの状態列を更新: 該当行のパスを completed/{feature-name} に、状態列を ⚪ 未着手 / 🔵 進行中 → ✅ 完了 に更新。
• 6-1-2. プログレスサマリーを更新: 「完了済み仕様」を +1、該当すれば「アクティブ仕様(P0)」を −1。
• 6-1-3. フェーズ進捗率を更新: Phase内の完了状況に応じて進捗バーとパーセンテージを更新（必要な場合）。

スコープ外の場合: スキップ。

6-2. スキルドキュメント更新

変更領域に関連するスキルドキュメント（.claude/skills/ 配下で当該機能を解説するもの）が存在すれば、整合性を確認・更新する。該当がなければスキップ。.kiro/steering/workflow.md に「スキルドキュメント更新検討」の指示があればそれに従う。

6-3. ステアリング・ドキュメント更新

当該変更で陳腐化する steering（.kiro/steering/*.md）やドキュメントがあれば更新する。.kiro/steering/workflow.md に「ドキュメント保守 > 更新チェックリスト」があればそれに従う。

ステップ7: 完了最終コミット

移動・ステータス更新・参照パス修正・追加更新をコミットする。

git add -A
git commit -m "chore({feature-name}): spec完了・アーカイブ"

ステップ8: リモート同期（PR ベース）

手順実体: リモート同期は PR（Pull Request）ベースであり、本セクションがその手順実体である。.kiro/steering/workflow.md に同等のブランチ戦略が定義されていればそれを優先する。

前提: 本ステップは origin/main をハードコードせず、ステップ0で解決した {remote} / {default-branch} を用いる。フィーチャーブランチ／ワークツリーは Claude Code（ハーネス）が供給しており、このスキルは自前でブランチ／ワークツリーを作成・削除しない。1つの feature = 1つのブランチ = 1つの PR とし、完了時に1回だけ PR を作成して squash マージする。{default-branch} への直接 push は一切行わない。

確認不要。現在のブランチを判定し、以下を中断なく実行する。

$branch = git rev-parse --abbrev-ref HEAD   # 現在の作業ブランチ（ハーネス供給）

PR 可否判定

以下をすべて満たすときのみ PR を作成・マージする（PR 可）:

1. 現在ブランチが {default-branch} 以外（非デフォルトブランチ）。
2. ステップ0で解決した {remote} が none でない（リモートあり）。
3. gh が認証済み（gh auth status が成功）。

いずれかが欠ける場合は PR 不可 とし、下記「フォールバック（PR 不可時）」へ進む。

PR 可: PR 作成 → squash マージ → リモートブランチ削除

# 1. 現在ブランチを push して PR を作成（base = {default-branch}, head = 現在ブランチ）
gh pr create --base {default-branch} --head $branch --title "<subject>" --body "<body>"

# 2. squash マージ（--squash 固定、--delete-branch でリモートブランチを API 削除）
#    --subject / --body は下記「squash メッセージ生成」に従って供給する
gh pr merge --squash --delete-branch --subject "<subject>" --body "<body>"

• マージ成否はマージ API の結果のみで判定する。 gh pr merge の成否がマージ成否であり、それ以外の警告でマージ成功を覆さない。
• リモートブランチ削除: gh pr merge --delete-branch が PR マージ成功後に API でリモート feature ブランチを削除する。
• ローカル後始末警告は非致命: --delete-branch のローカル削除試行は、カレントワークツリーでブランチがチェックアウト中のためブロックされ警告を出すことがある。これは非致命でありマージ成功（API 結果）を覆さない。リモートブランチは API により削除済みである。
• ローカルブランチ／ワークツリーの後始末はハーネスへ委譲: このスキルは自分のワークツリー／カレントブランチを削除しない（構造的に不可）。ローカルブランチ・ワークツリーの teardown はハーネスがセッション/タスク境界で実施する。

squash メッセージ生成（gh pr merge --squash の --subject / --body）:

• 固定文言にせず、分岐点以降のコミット履歴を要約して作成する。
• 手順:
  1. git log --no-merges --pretty=format:"%h %s%n%b" {default-branch}..HEAD（= merge-base..HEAD）で分岐点以降の全コミットを取得
  2. 対象 spec の requirements.md / design.md のタイトル・概要も参照し意図を補強
  3. 以下の形へ再構成:
     • subject（--subject）: <type>({feature-name}): <機能全体を1文で表す要約>
     • body（--body）: 主な開発仕様・変更内容を箇条書き（3〜7項目目安）。関連コミットは統合し、fixup/typo/WIP 等の些末な履歴は集約・省略。個々のコミット羅列ではなく「何を・なぜ作ったか」の開発単位で再構成する。

フォールバック（PR 不可時）

現在ブランチが {default-branch} である / {remote} が none（リモートなし・オフライン）/ gh 未認証 のいずれかの場合:

• 警告を出力し、PR 作成・push をスキップする。
• ローカルコミットはそのまま保持して継続する。
• {default-branch} への直接 push は一切行わない。

中断条件

PR の作成またはマージ（API）が失敗した場合（コンフリクト / mergeable でない / 権限不足等）は、ブランチを削除せず処理を中断し開発者へ報告する（復旧可能性を確保するため）。中断するのはマージ API が失敗したときのみであり、--delete-branch のローカル削除警告（非致命）とは区別する。

---

完了チェックリスト

- [ ] DoD ベースラインゲート通過（Spec / Test / License。workflow.md が存在すれば追加ゲートも）
- [ ] cargo test --workspace 成功（または直近の実行結果により省略）
- [ ] License Gate: `cargo deny check` 成功 + `cargo about generate --workspace about.hbs -o THIRD-PARTY-NOTICES.md` で謝辞再生成（deny.toml/about.toml があるリポジトリ。無ければ「設定不在により省略」）
- [ ] 未コミットファイルをコミット済み（ステップ2）
- [ ] completedフォルダへ移動済み（ステップ3）※繰り返し仕様はスキップ
- [ ] spec.json の phase を "completed" に更新済み + updated_at 更新（ステップ4）※繰り返し仕様はスキップ
- [ ] 参照パス更新済み（ステップ5）※繰り返し仕様はスキップ
- [ ] doc/ROADMAP.md 更新済み（スコープ内の場合: 状態列✅ + 完了数インクリメント）
- [ ] スキルドキュメント同期済み（該当する場合）
- [ ] 完了コミット済み（ステップ7）
- [ ] ステップ0で `{remote}` / `{default-branch}` を決定的解決済み
- [ ] リモート同期完了（ステップ8、PR ベース。解決した `{remote}`/`{default-branch}` を使用）
      - PR 可（非デフォルトブランチ かつ `{remote}` あり かつ `gh` 認証あり）: `gh pr create --base {default-branch} --head <current>` → `gh pr merge --squash --delete-branch --subject … --body …`（メッセージは `merge-base..HEAD` 履歴を要約）。マージ成否は API 結果のみで判定し、`--delete-branch` のローカル削除警告は非致命として継続。リモートブランチは API 削除、ローカルブランチ／ワークツリーはハーネス teardown へ委譲
      - PR 不可（`{default-branch}` 上 / `{remote}` none / `gh` 未認証）: 警告して PR・push スキップ、ローカルコミット保持（`{default-branch}` への直接 push なし）
      - PR 作成／マージ（API）失敗: ブランチを残し中断・報告

---

エラー回避

VSCode変更確定問題

• 症状: 移動したファイルが元の場所に復活する
• 対策: spec.jsonは必ずステップ4（移動後）で編集。移動前に編集しない

参照パス更新漏れ

• 症状: 後続specが旧パスで参照しファイルが見つからない
• 対策: ステップ5で Select-String による網羅的検索を実施

コミット漏れ

• 症状: pushしたが変更が反映されていない
• 対策: 各コミット前に git status --short で確認

テスト失敗時

• 症状: cargo test --workspace が失敗
• 対策: ワークフローを中断し開発者に報告。テスト修正後に再実行

License Gate 失敗時

• 症状: cargo deny check が失敗（許可外ライセンス・強コピーレフト混入を検出）
• 対策: ワークフローを中断し開発者に報告。混入 crate と経路を提示し、依存の差し替え／除外か allowlist 妥当性の再検討を仰ぐ。安易に allow を広げて通さない（MIT 配布の前提が崩れる）
• 症状: cargo deny / cargo about が未導入（no such command）
• 対策: cargo install cargo-deny --locked / cargo install cargo-about --features cli --locked で導入後に再実行
• 症状: cargo about generate が failed to satisfy license requirements で失敗
• 対策: 出荷対象外の dev-dependency が混入していないか確認（about.toml の ignore-dev-dependencies = true）。真に出荷される新規ライセンスなら permissive 性を確認のうえ about.toml の accepted と deny.toml の allow を揃えて追記

リモート同期関連（ステップ8 PR ベース）

PR 作成失敗

• 症状: gh pr create が失敗（既存 PR との衝突 / push 権限不足 / ネットワーク等）
• 対策: ブランチを削除せず中断して開発者へ報告。既存 PR がある場合はその PR を確認して再マージを検討

マージ不可（mergeable でない / API 失敗）

• 症状: gh pr merge --squash が失敗（コンフリクトで mergeable=false / 必須チェック未通過 / 権限不足等）
• 対策: ブランチを削除せず中断して開発者へ報告。コンフリクトは GitHub 上または別途解決のうえ再実行。中断判定はマージ API の結果のみで行い、--delete-branch のローカル削除警告とは混同しない

gh 未認証 / リモートなし（PR 不可）

• 症状: gh auth status が失敗、または {remote} が none
• 対策: 警告を出力し PR・push をスキップ。ローカルコミットは保持して継続する。{default-branch} への直接 push は行わない

{default-branch} 上で承認された

• 症状: 現在ブランチが {default-branch}（PR の head に使えない）
• 対策: 警告を出力し PR・push をスキップ、ローカルコミット保持。通常はハーネス供給の非デフォルトブランチ上で完了する想定

--delete-branch のローカル削除警告

• 症状: gh pr merge --delete-branch がローカルブランチ削除を試みてブロックされ警告を出す（カレントワークツリーでチェックアウト中のため）
• 対策: 非致命として無視し継続。リモートブランチは API で削除済み。ローカルブランチ／ワークツリーの後始末はハーネスのワークツリー teardown に委ねる（このスキルは自分のワークツリーを削除しない／できない）