stacked PRの下位PRがマージされた後に上位branchをrestack(rebase/cherry-pick再構成)する際に使用。「restackして」「上位PRを更新して」「restack after merge」「PRのbaseを更新」「スタックを整理」という依頼でトリガーする。対象sliceの特定→rebase→変更ファイル確認と代表テスト実行→force-with-leaseでpush→PR base更新→auto-merge判定の順で進める。
kiro-spec-status
Show specification status and progress
含まれるファイル(2)
- SKILL.md2.8 KB
- LICENSE.txt1.0 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Specification Status
<background_information>
- Success Criteria:
- Show current phase and completion status
- Identify next actions and blockers
- Provide clear visibility into progress
- Surface boundary readiness, upstream/downstream context, and likely revalidation needs when available </background_information>
Step 1: Load Spec Context
- Read
docs/specs/$1/spec.jsonfor metadata and phase status - Read
docs/specs/$1/brief.mdif it exists - Read existing files:
requirements.md,design.md,tasks.md(if they exist) - Check
docs/specs/$1/directory for available files - Read
docs/steering/roadmap.mdif it exists and this spec appears in it
Step 2: Analyze Status
Parse each phase:
- Requirements: Count requirements and acceptance criteria
- Design: Check for architecture, components, diagrams, and whether boundary sections are present
- Tasks: Count completed vs total tasks (parse
- [x]vs- [ ]) - Approvals: Check approval status in spec.json
- Boundary context:
- From brief.md: note
Boundary Candidates,Upstream / Downstream, andExisting Spec Touchpointsif present - From design.md: note
Boundary Commitments,Out of Boundary,Allowed Dependencies, andRevalidation Triggersif present - From roadmap.md: note upstream dependencies and whether this spec is adjacent to
Existing Spec Updates
- From brief.md: note
- Revalidation watchlist:
- Identify downstream specs, neighboring existing-spec updates, or rollout-sensitive design notes that may need revalidation if this spec changes
- Call out when the current spec shape looks too broad and may want roadmap/design splitting instead of more local repair
Step 3: Generate Report
Create report in the language specified in spec.json covering:
- Current Phase & Progress: Where the spec is in the workflow
- Completion Status: Percentage complete for each phase
- Task Breakdown: If tasks exist, show completed/remaining counts
- Boundary Context: Upstream/downstream, out-of-boundary, and allowed dependency notes when available
- Revalidation Watchlist: Downstream or adjacent work likely affected by changes to this spec
- Next Actions: What needs to be done next
- Blockers: Any issues preventing progress
Safety & Fallback
Error Scenarios
Spec Not Found:
- Message: "No spec found for
$1. Check available specs indocs/specs/" - Action: List available spec directories
Incomplete Spec:
- Warning: Identify which files are missing
- Suggested Action: Point to next phase command
List All Specs
To see all available specs:
- Run with no argument or use wildcard
- Shows all specs in
docs/specs/with their status
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
cc-sdd実装用統合ブランチのコミット群(ベースブランチとの差分)をreview slice単位のstacked PRに再構成する際に使用。「review sliceに分割」「stacked PRを作成」「PRをスタックして」「レビュー用にPRを分けて」「review slice stack」という依頼でトリガーする。dry-run(既定)でslice計画を提示し、apply指示で実際にブランチ・PRを作成する。
CI環境で安定動作するPythonテスト(特にstructlogのログ検証)を書く際に使用。「CIで失敗する」「capture_logsが不安定」「ログアサーションがCIだけ落ちる」「caplogフォールバック」「ANSI混入」「xdistでログが取れない」という課題で起動。capture_logs→caplogフォールバック→ANSI正規化→アサーション設計の流れで堅牢なテストを書く。
GitHub Issueを作成してGitHubに投稿するスキル。「Issueを作成」「Issue作成」「Issueにして」「Issueとして投稿」「GitHubにIssue」「create issue」「open issue」「バグ報告」「機能追加をIssueに」「改善提案をIssueに」などの依頼でトリガーする。コンテキスト収集→Issue本文生成→ラベル存在確認・作成→gh issue create投稿の流れでIssueを作成する。
Dockerベースのアプリケーションのデプロイメント手順書(Markdown)を作成するスキル。「デプロイ手順書」「デプロイメント手順」「deployment guide」「本番環境への配置手順」「サーバーへの配置手順」などの依頼でトリガーする。Docker Composeビルド→イメージ転送→サーバー配置→設定→動作確認→cron設定の流れで手順書を生成する。
タスク完了後にPCを休止状態にする。Use when: ユーザーが「休止」「hibernate」「タスク完了後に休止状態」「作業後にPCをスリープ/休止」と明示的に指示した場合のみ。正常終了時だけでなく、エラーや未解決事項が残っていても、明示指示があれば最後に休止へ移行する。Windows only.