一键导入
next-spec-id
ブランチ間で衝突しない、次の Spec ID(SCR / DES / TASK / ADR 等任意プレフィックス)を発行する。 要件定義書・設計書・計画書・ADR(アーキテクチャ決定記録)の作成時に ID の重複を防ぐために呼び出される。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
ブランチ間で衝突しない、次の Spec ID(SCR / DES / TASK / ADR 等任意プレフィックス)を発行する。 要件定義書・設計書・計画書・ADR(アーキテクチャ決定記録)の作成時に ID の重複を防ぐために呼び出される。
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | next-spec-id |
| user-invocable | false |
| description | ブランチ間で衝突しない、次の Spec ID(SCR / DES / TASK / ADR 等任意プレフィックス)を発行する。 要件定義書・設計書・計画書・ADR(アーキテクチャ決定記録)の作成時に ID の重複を防ぐために呼び出される。 |
| argument-hint |
仕様書(要件定義書・設計書・計画書)の次の連番 ID を、全ブランチスキャンで安全に取得する。 ブランチ間での ID 重複を防止する。
forge 内の他スキルからの呼び出し専用(user-invocable: false)。
${CLAUDE_PLUGIN_ROOT}/skills/next-spec-id/scripts/scan_spec_ids.py
SCRIPT="${CLAUDE_PLUGIN_ROOT}/skills/next-spec-id/scripts/scan_spec_ids.py"
# 次の ID を取得(プレフィックス指定)
python3 "$SCRIPT" SCR
python3 "$SCRIPT" DES
python3 "$SCRIPT" TASK
python3 "$SCRIPT" ADR --share-prefixes ADR,DES # アーキテクチャ決定記録(DES と通し番号共有、設計書と同ディレクトリに配置)
# プロジェクトルート指定
python3 "$SCRIPT" --project-root /path/to/project SCR
# .doc_structure.yaml のパス指定
python3 "$SCRIPT" --doc-structure /path/to/.doc_structure.yaml SCR
# 通し番号を複数 prefix で共有する場合(例: ADR と DES が同一ディレクトリで番号を共有)
python3 "$SCRIPT" DES --share-prefixes ADR,DES
python3 "$SCRIPT" ADR --share-prefixes ADR,DES
--share-prefixes)複数の prefix(例: ADR / DES)が同一ディレクトリに配置され、番号衝突を避けるために連番を共有する運用がある。--share-prefixes にカンマ区切りで prefix を指定すると、それらすべてのファイルを横断スキャンして最大番号を計算し、位置引数で指定した prefix の次番号として返す。shared_with フィールドに共有先 prefix が記録される。
{
"status": "ok",
"next_id": "SCR-016",
"prefix": "SCR",
"max_number": 15,
"base_branch": "develop",
"branches_scanned": 7,
"ids_found": 15,
"duplicates": []
}
duplicates に報告されるのは「異なるファイルが同じ ID(共有採番モードでは同じ番号)を主張している」衝突のみ。同一パスのファイルが複数ブランチに存在するだけの同一履歴由来ケースは報告されない(Issue #181)。共有採番モード(--share-prefixes)では、ADR-032 と DES-032 のような prefix 違い・同番号も衝突として報告される。
{
"status": "ok",
"next_id": "SCR-016",
"prefix": "SCR",
"max_number": 15,
"base_branch": "develop",
"branches_scanned": 7,
"ids_found": 17,
"duplicates": [
{
"id": "SCR-013",
"ids": ["SCR-013"],
"branches": ["feature/edit_pickup", "origin/feature/print_letter"],
"paths": [
"docs/specs/pickup/requirements/SCR-013_edit_pickup.md",
"docs/specs/letter/requirements/SCR-013_print_letter.md"
]
}
]
}
id: 代表 ID(衝突に関与する ID の先頭)ids: 衝突に関与する全 ID(共有採番モードでは ["ADR-032", "DES-032"] のように複数になりうる)paths: 同じ番号を主張している異なるファイルパスbranches: 該当ファイルが存在するブランチ{
"status": "error",
"message": ".doc_structure.yaml が見つかりません"
}
スクリプトは任意のプレフィックスを引数で受け取る。ID 体系の知識は持たない。
どのプレフィックスを使うかは 呼び出し側のスキル が決定する:
spec_format.md やルールがあればそれに従う${CLAUDE_PLUGIN_ROOT}/docs/spec_format.md をフォールバック参照SCRIPT="${CLAUDE_PLUGIN_ROOT}/skills/next-spec-id/scripts/scan_spec_ids.py"
RESULT=$(python3 "$SCRIPT" SCR)
# → {"status": "ok", "next_id": "SCR-016", ...}
JSON の next_id フィールドをファイル名の先頭に使用する。
RESULT=$(python3 "$SCRIPT" DES)
# → {"status": "ok", "next_id": "DES-004", ...}
設計判断の記録として ADR を新規作成する際は、番号衝突を防ぐため必ず採番する(手動で「既存の次」と判断しない)。ADR と DES は同一ディレクトリで通し番号を共有するため --share-prefixes ADR,DES を必ず付与する:
RESULT=$(python3 "$SCRIPT" ADR --share-prefixes ADR,DES)
# → {"status": "ok", "next_id": "ADR-005", "shared_with": ["DES"], ...}
ADR は設計書と同じディレクトリに配置するため、.doc_structure.yaml に ADR 専用ディレクトリが無くても git スキャンで既存 ADR を検出できる。
.doc_structure.yaml から specs の root_dirs を取得git fetch --quiet でリモートを最新化git ls-tree で各ブランチの specs ディレクトリを走査duplicates に記録(同一パス由来の複数ブランチ出現は正常として除外)msg-sys 通信基盤(常駐 Codex セッションとの Stop フック経由の非同期往復)の上で、 Codex とのレビュー依頼・所見受領・修正・完了判定を駆動する。3モード(依頼/受信/再開)を持つ。 依頼モードのトリガー句: "msg-reviewでレビュー依頼", "Codexとレビュー往復したい", "常駐Codexにレビューを依頼", "msg-reviewを実行して", "Codexセッションにコードレビューを頼みたい"。 受信モードの起動契機(トリガー句ではなくメッセージ本文の形式で成立): Stop フックが差し戻した メッセージ本文の先頭が `[msg-review] <種別> review_id=<review_id> round=<n>` である。 再開モードのトリガー句: "msg-reviewを再開したい", "レビューの往復上限到達通知が来た、状況を確認して", "review_idの未解決所見を要約して", "msg-reviewの続きを確認したい"。
設計書から実装戦略を策定し、タスクを抽出して YAML 計画書を作成・更新する。レビュー+自動修正→commit まで一貫実行。 トリガー: "計画書作成", "計画開始", "start plan", "start planning"
計画書からタスクを選び、実装・レビュー・計画更新まで一貫して実行する。 トリガー: "実装開始", "タスク実行", "start implement"
コード・文書をレビューし、品質問題の発見から修正まで自動化できる。重大度 🔴🟡🟢 で分類。 --auto で修正まで一貫実行。code/requirement/design/plan/uxui/generic の6種別に対応。 トリガー: "レビュー", "review", "レビューして", "確認して"
GitHub Issue を軽量実装で進めるか forge の SDD フロー(start-requirements/start-design/start-plan)に委ねるかを判定するスキル。feature namespace の要否も判定する。トリガー:「このIssueをトリアージして」「Issueの進め方を判定して」「#N はどう進めるべきか判定して」
GitHub Issue の実装を準備から完了まで一貫して行う。triage の判定調査結果(仕様書・ルール・類似PR・既存コードの特定)を引き継ぎ、実装計画の策定・Issue への解決内容記載・実装・レビューまで進める。UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。 `/anvil:triage-issue` が軽量実装と判定した Issue に対して Skill ツール経由でのみ起動される(ユーザーからの直接起動は不可)。