From architecture-toolkit
新機能・機能追加を、まずコードベース全体を理解して変更箇所を漏れなく特定し、既存アーキテクチャに整合する 設計を立ててから、衝突しない wave に分けて Workflow で並列実装+段階検証+グループコミットするスキル。 「この機能を追加して」「〜を実装して/作って」「新しいエンドポイント/画面/CLI コマンド/ジョブを足して」 「〜できるようにして」「機能を設計して実装まで」など、複数ファイルにまたがる新しい振る舞いをゼロから作る 開発フェーズで使う。既存コードの評価・改善(リファクタ)ではない——構造を評価するなら architecture-review、 出した所見を適用するなら architecture-fix、収束まで反復改善するなら architecture-loop。 単一ファイル・数行で明白な追加(引数1個・ログ1行)だけなら本スキルは不要。
How this skill is triggered — by the user, by Claude, or both
Slash command
/architecture-toolkit:feature-buildThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
新しい機能を「いきなり書き始めず、まず設計し」、その設計を基準に実装を**衝突しないタスク(wave)へ分割して
新しい機能を「いきなり書き始めず、まず設計し」、その設計を基準に実装を衝突しないタスク(wave)へ分割して 並列実装+段階検証するスキル。ゴールは 速さ(並列)と安全(設計先行+既存整合+検証)の両立。
review/fix が「既存コードを直す」のに対し、本スキルは「新しい振る舞いをゼロから足す」開発フェーズを担う。 ただし基本思想は共通: 構造化して理解し、衝突しない単位に分け、並列で進め、段階的に検証する。
単一ファイル・数行で明白な追加だけなら本スキルは不要(普通に書く)。既存コードの構造改善が主目的なら
architecture-review / architecture-fix を使う。
feat/<name>)。references/verify.md)。最初から赤なら先に切り分け。最重要の原則: コードベース全体を理解し「どこを変えればいいか」を漏れなく把握してから、初めて実装に入る。
1ファイルだけ見て書き始めない。新機能は既存設計の上に乗るので、関係する経路・配線・規約を先に押さえる。
詳細手順は references/design.md を読む。Phase 1 は次の 1A→1B→1C の順で進める。
新機能が触れる「機能の道筋」を端から端まで追って、頭の中に地図を作る。最低限これを押さえる:
大きい機能では理解を並列探索でファンアウトしてよい(既存パターン/データモデル/I/O境界/配線箇所を別エージェントで 調べ、構造化要約を集約)。推測で断定しない——「ここを変えれば足りる」は grep / 参照追跡 / 型・ビルドで裏を取る。
理解した道筋をもとに、手が入る場所を1つ残らずリスト化する。新規作成だけでなく既存編集を取りこぼさない
(配線漏れは「動かない」の最大要因)。各項目は パス + 新規/編集 + 何のため で書く。最低限この観点を当てる:
このチェンジマップ(影響を受ける全ファイル)が Phase 2 の wave 分割の入力になる。漏れていると配線 wave が 不完全になり機能が繋がらないので、ここの網羅性を最優先する。確信が持てない接続点は「(要確認)」と明示する。
理解とチェンジマップを基準に設計を確定する:
設計を実装タスクの DAG に落とす。アルゴリズムは fix の発想を流用、詳細は references/planning.md を読む。要点:
[wave0, wave1, ...]。wave 内は並列、wave 間は逐次(前段の検証 PASS 後に次段)。テスト同伴: 各 task は実装と一緒にテストを書く(受け入れ条件→テストケース)。重要パスは**テスト先行(TDD)**を明記。
Workflow ツールで wave 列を実行する。スクリプト雛形は references/workflow-template.md を読んで埋める。
構造(wave 単位の barrier: 次 wave は前 wave 統合後に開始):
parallel(wave.map(t => () => agent(buildPrompt(t), {schema: RESULT})))。
title / 設計仕様(契約) / 触れてよいファイル / 依存先で確定した型・IF / 受け入れ条件 / verify を渡す。{id, status: done|failed|blocked, files_changed[], tests_added[], verify_passed, verify_output, notes} を返す。references/verify.md: ビルド/型/リンタ/テスト/起動スモーク)を main 側で実行し、
PASS したら その wave をグループコミットする。feat: <要約> (task: a,b,…) 形式。references/design.md — 既存パターン調査・配置/レイヤ判断・インターフェース設計・影響範囲洗い出しの手順。Phase 1 で読む。references/planning.md — 実装タスク分割、wave 化(ファイル集合・依存順・基盤先行・配線集約)、テスト計画。Phase 2 で読む。references/workflow-template.md — Workflow スクリプト雛形(wave barrier・実装プロンプト・RESULT スキーマ)。Phase 3 で読む。references/verify.md — 言語別の検証コマンドと成功条件(ビルド/型/リンタ/テスト/起動スモーク)。Phase 0/各 wave 後で読む。Provides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub ootsuka-repos/architecture-toolkit --plugin architecture-toolkit