Skip to content
cccskills
FreePublished on GitHub

revise-spec

実装済み機能の仕様変更。要件定義書と基本設計を先に更新してからコード修正→テスト→レビューを実行する。変更種別を自動判定し、実装はAgent(Sonnet)に委任可能、レビューは本体が直接実行する。

「アップロード上限を10MBに変えて」「この画面にフィールド追加して」「○○の仕様を変更して」 「○○を修正して」「バリデーションを変えて」などのリクエストで使用する。既に実装済みの機能を変更するときに使う。新規実装はimplement-spec。

The English summary is being prepared. Showing the original description.

Run score Not tested

See how to install

Files included (1)

  • SKILL.md11.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

<!-- オンデマンド参照(必要時に読む): - _shared/code-search-2stage.md → フェーズ1 step 2 - _shared/finish-impl.md → フェーズ「仕上げ」 - _shared/coding-quality.md → 実装フェーズ 設計情報不足時 - _shared/review-checklist.md → レビューフェーズ レビュー観点 - _shared/review-standards.md → レビューフェーズ 指摘フォーマット - _shared/review-report.md → レビューフェーズ レビューレポート構成 - _shared/impact-report.md → 実装フェーズ 影響範囲レポート - _shared/loop-protocol.md → レビューフェーズ レビューループ管理 - .claude/agents/coder/AGENT.md → 実装フェーズ Agent委任時 -->

実装済み機能の仕様変更

本スキルは親=分析・方針・レビュー / spec-writer(Sonnet)=設計書更新執筆 / integrity-checker=機械的整合性検査 / coder(Sonnet)=コード実装の四者分担で進める。

統一基盤の確認

Spec 統一基盤確認 を実施する。新しい概念が出てきた場合は glossary.md にも追記する。


フェーズ1: 分析(親エージェント、コードには触れない)

  1. 該当Specを読む
  2. 2段階探索 で現在の実装を全て把握する
  3. 依存Spec健全性チェック — spec-map.yml で以下を確認する:
    • 該当REQ-ID自体の confirmed == spec_version か(不一致なら先にコード追従が必要)
    • depends_on に列挙された依存Spec全てが confirmed == spec_version か
    • このREQ-IDに依存しているSpec(被依存先)も confirmed == spec_version か
    • 不一致がある場合:「[REQ-XXX] の実装が spec_version に追従していません。先に対応しますか?」と提案する
  4. openapi.yaml 存在確認(API変更がある場合):
    • 変更内容にAPIエンドポイントの追加・変更・削除がある場合、docs/api/openapi.yaml が存在し対象エンドポイント定義を含んでいるか確認する
    • 存在しない場合:「openapi.yaml が未作成です。detail-design を実行して API 仕様を生成しますか?」と提案する
    • 存在するがエンドポイント定義が不足の場合:ドキュメント更新フェーズで補完する
  5. 変更種別を自動判定:
    • 見た目のみ(CSS、テキスト)→ コードだけ修正。Spec更新不要
    • 動作の変更(バリデーション、ロジック)→ 要件定義書・基本設計・コード・テスト全て同期更新
    • 機能追加レベル(Specの範囲を超える)→ 新REQ-IDの追加を提案
  6. 依存グラフ影響分析(推移的閉包): a. spec-map.yml の全エントリから depends_on を読み取り、逆引きインデックスを構築する
    • 例: REQ-B が depends_on: [REQ-A] → REQ-A の被依存先に REQ-B を追加 b. 変更対象のREQ-IDから、被依存先を再帰的に辿り、推移的影響範囲を特定する
    • 直接依存(1段階): 変更対象に直接依存しているSpec
    • 推移的依存(2段階以上): 直接依存のSpecにさらに依存しているSpec
    • 循環依存を検出した場合は警告を出す c. docs/design/dependency-graph.md が存在する場合はそちらも参照し、spec-map.yml と突合する d. 影響範囲を以下の形式で整理する:
    ## 影響範囲
    ### 直接影響(変更必須)
    - REQ-XXX-001: [変更理由]
    ### 推移的影響(要確認)
    - REQ-YYY-001 → REQ-XXX-001 経由: [確認観点]
    ### コードファイル
    - [2段階探索で見つけた全ファイル]
    
  7. 影響範囲を提示して確認を求める。推移的影響がある場合は「これらのSpecも再テストが必要になる可能性があります」と明示する

フェーズ2: 執筆プラン整理(親エージェント)

  1. 「見た目のみ」変更の場合はこのフェーズをスキップして実装フェーズへ進む
  2. 変更内容に基づき、spec-writer へ渡す委任プロンプトを組み立てる:
    • 更新対象ファイルと更新箇所(セクション・項目レベルで特定)
    • 変更前後の具体的な値
    • 新REQ-IDを追加する場合は採番値と依存関係
    • 画面遷移に影響する変更がある場合は 画面遷移図ルール の適用を指示

フェーズ3: 設計書更新委任(spec-writer)

  1. Agent(subagent_type: spec-writer) に設計書更新を委任する:

    • 更新対象ファイルが複数かつ独立している場合は並列委任可

    委任プロンプト形式:

    あなたは spec-writer です。以下のドキュメントを差分更新してください。
    
    ## 更新対象
    docs/requirements/features/[REQ-ID].md
    
    ## 更新箇所
    - セクション名: [XXX]
    - 変更前: [値]
    - 変更後: [値]
    
    ## 更新方針
    - 差分更新が基本。既存文書の全面書き換えはしない
    - 変更箇所のセクションだけを更新し、周辺は触らない
    - 画面遷移に影響する変更の場合は画面遷移図も更新する
    - 不明点は「※ 要確認」マーカーを残し、推測で埋めない
    
    ## 変更内容サマリ
    [フェーズ1で整理した変更内容・影響範囲]
    
    ## 厳守事項
    - index系ファイル(overview.md / spec-map.yml / mkdocs.yml / dependency-graph.md)は触らない(親が更新)
    - コードを変更しない(コード変更は親が coder エージェントに委任する)
    - 完了時に軽量セルフチェックを実行し、結果を報告すること
    

    並列委任する対象(該当するもののみ):

    • docs/requirements/features/ の要件定義書
    • docs/design/ の基本設計(API・DB変更がある場合)
    • docs/api/openapi.yaml(API変更がある場合)

フェーズ4: index系更新(親エージェント)

spec-writer は index 系に触らないため、親が責任を持って更新する:

  1. ドキュメントを新規作成した場合は mkdocs.yml の nav に追加する
  2. spec-map.yml 操作ガイド に従い、該当 REQ-ID の spec_version をインクリメントする(「見た目のみ」変更ではインクリメント不要)
  3. docs/requirements/overview.md を更新(新REQ-IDを追加した場合)
  4. docs/design/dependency-graph.md が存在する場合、変更対象Specの依存関係を更新する

フェーズ5: ドキュメントのレビューと整合性チェック(親エージェント)

  1. spec-writer が更新したドキュメントを本体が直接レビューする(Agent委任不可)
    • 変更内容との整合性確認
    • 要確認マーカーの確認と対応(必要ならユーザーに追加ヒアリング)
  2. Agent(subagent_type: integrity-checker) を起動して機械的整合性チェック
    • 変更ファイルリスト・新規REQ-ID(あれば)を prompt で渡す
    • チェック項目: .claude/skills/_shared/doc-integrity-check.md 参照
    • FAIL があれば修正 → 再チェック(最大3ループ)
  3. ドキュメント更新をコミット(ドキュメントとコードのコミットを分ける)

フェーズ6: 実装プラン作成(親エージェント)

  1. 変更内容に基づき impl-plans/[REQ-ID].md を作成(または更新)する:
  • 変更対象ファイルと変更内容の一覧(依存関係順)
  • 流用・修正すべき既存コード(grep結果から特定)
  • 判断メモ(WHY NOT): スコープ外とした変更・仮採用した判断の理由
  • テスト計画(追加・修正するテストケース)
  • 実装プランをコミット: docs: [REQ-ID] 実装プラン作成

フェーズ7: 実装フェーズ(coder Agent または親エージェント)

  1. 実装プラン(impl-plans/[REQ-ID].md)の順序に従ってコードを修正する。 以下の基準で実装方法を自動判断する:

    • 本体が直接実装する(デフォルト): 途中判断が必要な場合は規模に関係なく本体が実行する
    • Agent に委任する: 実装プランの全ステップが明確で途中判断が不要な場合のみ。Agent(subagent_type: "coder") で起動し、実装プランのパスと設計書パスリストを prompt に渡す
  2. 実装時の共通ルール(本体/Agent 共通):

  • 更新済みの要件定義書と基本設計の通りにコード・テストを修正する
  • 共通コンポーネントが使える箇所では既存のものを使う(再発明しない)
  • spec-map.yml 操作ガイド に従い、修正ファイルの confirmed を更新
  • UIを含む変更の場合、E2Eテストも追加・修正する
  • 影響範囲レポート を docs/impact-reports/[Spec ID].md に作成(または更新)

フェーズ8: レビューフェーズ(本体が直接実行)

  1. レビューチェックリスト を読み、全観点を確認する
    • 指摘フォーマット・深刻度・信頼度は review-standards に従う(信頼度80以上のみ修正対象)
    • レポート構成は review-report に従う
    • 指摘があれば修正→再レビュー(最大3ループ、loop-protocol に従う)

仕上げ

  1. .claude/skills/_shared/finish-impl.md の共通仕上げ手順を実行
  2. 次のステップを提案(「他に変更する箇所はありますか?」)

コンテキスト管理

  • /cost でトークン使用量を随時確認する
  • 使用率が70%を超えたら、作業状態を impl-plans/[REQ-ID].md の末尾に追記し、新セッションでの再開を提案する

ルール

  • ドキュメントを確定させてからコードを変更すること
  • 実行前に必ず影響範囲を提示して確認を求めること
  • 変更種別の判定理由を説明すること
  • PR作成は行わない。コミットまでで完了とする

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

既存プロジェクトに新しいリポジトリを追加する。Workspaceにリポを追加した後、 CLAUDE.md・設計書・ドメイン構成を差分更新する。 「モバイルリポを追加した」「新しいリポを取り込んで」「リポを追加したので設計書を更新して」 「Workspaceにリポを足した」などのリクエストで使用する。 init-spec の移行モードではファイル存在チェックしか行わないため、 既存ドキュメントの内容を新リポに合わせて拡張するにはこのスキルを使う。

The English summary is being prepared. Showing the original description.

i-standard1/yamasaki6Updated Aug 26, 2026

既存プロジェクトをサブエージェントで並列分析し、 精度の高い overview.md を生成する。init-spec の前処理として使う。 「既存プロジェクトを分析して」「コードベースを理解して設計書を作って」 「overview.mdを作って」などのリクエストで使用する。 ファイル数が200を超えるプロジェクトで特に有効。 200以下の場合は単一エージェントで全体を読む方が精度が高いため、 init-spec をそのまま実行することを提案する。

The English summary is being prepared. Showing the original description.

i-standard1/yamasaki6Updated Aug 26, 2026

デザインの差し替え。ロジックは一切触らず見た目(HTML/CSS/テンプレート)だけを更新する。 「このデザインに差し替えて」「UIをFigmaの通りに変えて」「見た目だけ変えて」 「デザインを更新して」「CSSだけ直して」などのリクエストで使用する。 ロジック変更を伴う場合はrevise-specを使う。

The English summary is being prepared. Showing the original description.

i-standard1/yamasaki6Updated Aug 26, 2026

browse

Free

ブラウザで画面を確認する。agent-browser CLI を使って画面のスクリーンショット撮影、 アクセシビリティツリー取得、フォーム操作、画面遷移などを行う。 「画面見て」「ブラウザ確認して」「スクショ撮って」「現状把握して」「画面開いて」 「ログインして確認して」「画面の状態を教えて」「UIを確認して」などのリクエストで使用する。 E2Eテストの作成・実行には gen-tests(Playwright)を使うこと。本スキルはテスト実行ではなく 「AIの目」としてブラウザを操作し、画面状態を把握するためのもの。

The English summary is being prepared. Showing the original description.

i-standard1/yamasaki6Updated Aug 26, 2026

ClaudeDesign(claude.ai/design)とClaude Codeの連携。DesignSyncツールで デザインプロジェクトからプロトタイプHTML等を取得(インポート)、または ローカルのコンポーネントをデザインシステムプロジェクトへ同期(プッシュ)する。 「ClaudeDesignからデザインを取得して」「claude.ai/design のURLを取り込んで」 「デザインプロジェクトに同期して」「デザインシステムをプッシュして」 などのリクエスト、または claude.ai/design のURLが渡されたときに使用する。 取得したデザインのコード実装への適用は apply-design を使う。

The English summary is being prepared. Showing the original description.

i-standard1/yamasaki6Updated Aug 26, 2026

詳細設計書の一括生成。2つのモードを自動判定する: (A) コード分析モード: 既存コードから詳細設計書を逆生成する(init-spec + spec-all 完了後) (B) 設計書ファーストモード: 要件定義書から詳細設計書を新規作成する(コードなし) 「詳細設計を作って」「設計書を完成させて」「実装に必要な設計書を全部作って」 「他のエンジニアに渡せる設計書にして」などのリクエストで使用する。

The English summary is being prepared. Showing the original description.

i-standard1/yamasaki6Updated Aug 26, 2026

See all skills by i-standard1

Report a problem with this skill