FreePublished on GitHub

implement-spec

Specに基づく新規機能実装。要件定義書と基本設計を読んで実装プラン作成→コード実装→テスト→レビューを実行する。実装はAgent(Sonnet)に委任可能、レビューは本体が直接実行する。

「REQ-AUTH-001を実装して」「ログイン機能を作って」「○○を実装して」「これを作って」「実装に入って」などのリクエストで使用する。要件定義書が存在する未実装機能を新規実装するときに使う。既存機能の変更はrevise-spec。

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

i-standard1/yamasaki

See how to install

Files included (1)

SKILL.md10.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Specに基づく機能実装

準備フェーズ（リーダーが実行、コードには触れない）

指定されたSpec ID（またはユーザーの意図から該当Specを特定）をdocs/requirements/から検索
- 要件定義書が見つからない場合：実装に進まない。 「先に要件定義が必要です。作成しますか？」と提案し、draft-specに誘導する
要件定義書の全セクションを読む（概要・背景・目的・受入条件・画面・技術仕様）
- 特に「背景・目的」から既存UIへの影響方針を判断する（追加 / 置換 / 削除）
- 受入条件だけを見ると設計意図を見落とす。背景にある「なぜ作るか」が実装方針を決める
要件定義書のステータスを「実装中」に更新、overview.mdも同期

必須読取リスト — 以下のファイルを優先順に読む。存在しないファイルはスキップするが、★付きが欠落している場合はユーザーに報告し続行可否を確認する：

優先度	ファイル	目的
★必須	`docs/requirements/features/[REQ-ID].md`	WHAT: 受入条件・背景・目的
★必須	`docs/design/features/[REQ-ID]-logic.md`	HOW: API・DB・バリデーション・権限
★必須	`docs/api/openapi.yaml`	API仕様の Single Source of Truth
★必須	`CLAUDE.md`	技術スタック・テスト設定・開発コマンド
推奨	`docs/design/features/[REQ-ID]-design.md`	画面構成・UIコンポーネント
推奨	`docs/design/shared-components.md`	既存共通コンポーネント（再発明防止）
推奨	`docs/design/db-schema.md`	テーブル定義・カラム制約
推奨	`docs/design/architecture.md`	システム構成・データフロー
条件付き	`interfaces/[domain]_interface.md`	orchestrate経由でドメイン間連携がある場合のみ
条件付き	`docs/design/features/[REQ-ID]-api-spec.md`	外部連携がある場合のみ
条件付き	`docs/design/security-design.md`	認証・認可に関わる場合のみ
条件付き	`docs/design/error-codes.md`	エラーハンドリングに関わる場合のみ

依存Spec健全性チェック — spec-map.yml で以下を確認する：
- 対象REQ-ID自体の confirmed == spec_version か（不一致なら先に追従が必要）
- depends_on に列挙された依存Spec全てが confirmed == spec_version か
- 不一致がある場合：「[REQ-XXX] の実装が spec_version に追従していません。先に revise-spec で対応しますか？」と提案する。ユーザーが続行を選んだ場合は影響範囲レポートの「リスク」セクションに記録する
openapi.yaml 存在チェック — 対象機能がAPIを含む場合（要件定義書にエンドポイント記載がある場合）：
- docs/api/openapi.yaml が存在し、該当エンドポイントの定義を含んでいるか確認する
- 存在しない場合: 「openapi.yaml が未作成です。detail-design を実行して API 仕様を生成しますか？」と提案する。ユーザーが続行を選んだ場合は、要件定義書のAPI記述を暫定仕様として使い、影響範囲レポートに記録する
- 存在するがエンドポイント定義が不足の場合: 不足分を補完してコミットする
2段階探索を読み、その手順に従って既存コードを把握する 7b. 画面遷移図の確認（UIを含む機能の場合）: 要件定義書に画面遷移図がある場合、新規画面の追加・既存画面の遷移先変更がないか確認する。実装後に画面遷移図ルールに従って更新が必要になる箇所を把握しておく
基本設計に不足があれば更新してコミット（API追加、テーブル追加など）
品質ゲートチェック（Gate 2: 設計→実装）: docs/quality-gates.md のGate 2項目を確認する
- 全てのSpecにREQ-IDが採番されているか
- 基本設計書（architecture.md, db-design.md, openapi.yaml）が存在し、Specと整合しているか
- 未通過項目がある場合はユーザーに提示し、続行するか確認する。ユーザーが中止を選んだ場合は要件定義書のステータスを「実装中」から元に戻す
CLAUDE.mdのブランチ戦略に従い、feature/[Spec ID] ブランチを作成
実装プランの作成 — 準備フェーズで読んだ情報を元に impl-plans/[REQ-ID].md を作成する：

実装順序（ファイル単位、依存関係順に）
各ステップで作成/変更するファイルパスと概要
流用すべき既存コード（grep結果から特定したファイル:行番号）
使用するAPIエンドポイント一覧（openapi.yaml から抽出）
使用するテーブル・カラム一覧（logic.md / db-schema.md から抽出）
活用すべき共通コンポーネント一覧（shared-components.md から抽出）
判断メモ（WHY NOT）: やらないこと・スコープ外の理由・仮採用した判断
テスト計画（何をどの順でテストするか）
実装プランをコミット: docs: [REQ-ID] 実装プラン作成

設計書間の優先順位・判断ヒューリスティクス

設計書の矛盾解決 → design-priority.md を参照設計情報不足時の判断 → coding-quality.md を参照

テスト先行フェーズ（TDD: RED）

11b. docs/design/test-design.md が存在するか確認する

存在する場合: gen-tests をTDDモードで呼び出し、テストコードを先行生成する
- ユニットテスト + E2Eテスト（test.skip付き）がRED状態で生成される
- コミット: test: [REQ-ID] テストコードを先行生成（RED状態）
存在しない場合: 従来フロー（実装フェーズでテストも同時生成）にフォールバック
注: test-design.md は detail-design スキルの成果物。TDDを使いたい場合は先に detail-design を実行すること

実装フェーズ

実装プラン（impl-plans/[REQ-ID].md）の順序に従ってコードを実装する。以下の基準で実装方法を自動判断する：
- 本体が直接実装する（デフォルト）: 途中判断が必要な場合は規模に関係なく本体が実行する
- Agent に委任する: 実装プランの全ステップが明確で途中判断が不要な場合のみ。Agent(subagent_type: "coder") で起動し、実装プランのパスと設計書パスリストを prompt に渡す
実装時の共通ルール（本体/Agent 共通）：

要件に書かれていない機能は実装しない
openapi.yaml のリクエスト/レスポンス定義に忠実に実装する
共通コンポーネントが使える箇所では既存のものを使う（再発明しない）
ユニットテストが全てGREENになるまで繰り返す
E2Eテストの test.skip() を解除し、全てGREENになるまで修正する
spec-map.yml 操作ガイドに従い、実装ファイルのエントリを追加
影響範囲レポートを docs/impact-reports/[Spec ID].md に作成

実装プランの判断メモに変更が生じた場合は、実装プランを更新してコミットする

レビューフェーズ（本体が直接実行）

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

仕上げ

要件定義書のステータスを「完了」に更新、overview.mdも同期
.claude/skills/_shared/finish-impl.md を読み、共通仕上げ手順を実行する
次のステップを提案（「次の機能を実装しますか？」「テストを補強しますか？」）

コンテキスト管理

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

ルール

要件の受入条件に書かれていない機能を実装しない
レビュー→修正のループは最大3回
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.

More skills from this repository

add-repo

Free

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

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

i-standard1/yamasaki6Updated Aug 26, 2026

analyze-codebase

Free

既存プロジェクトをサブエージェントで並列分析し、精度の高い 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

apply-design

Free

デザインの差し替え。ロジックは一切触らず見た目（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

claude-design

Free

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

detail-design

Free

詳細設計書の一括生成。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

Install

Install with a command

npx skills add https://github.com/i-standard1/yamasaki --skill implement-spec

Paste it into your terminal and run it (requires Node.js). You can choose which agents to install it for, such as Claude Code or Codex.

Ask your agent

Please install the following Agent Skill.
https://github.com/i-standard1/yamasaki/tree/main/.claude/skills/implement-spec

First review SKILL.md and the bundled files and confirm there is nothing suspicious (such as sending data externally or reading credentials). Then place it in ~/.claude/skills/implement-spec/ for Claude Code, or ~/.agents/skills/implement-spec/ for Codex.

Send this text to Claude Code or Codex as is. It checks the contents before installing.

View source on GitHub

Repository: i-standard1/yamasaki
Stars: 6
Forks: 2
Category: Testing & Security
License: MIT
Original language: Japanese
Last updated: Aug 26, 2026

A skill is a set of instructions and scripts for an agent. cccskills does not guarantee that skills are safe. Review the contents before you install.