Communityコーディング&開発github.com

アドホック実装計画

大まかな計画を、実装・コミット可能な成果物に変換します。厳密なレビューを可能にしながら実装を進められます。

アドホック実装計画 とは?

このスキルは、大まかな計画やアイデアから、実装とコミットが可能なアーティファクト(設計書、テスト計画、実装計画)を迅速に生成します。ユーザーと議論した不完全な計画を、`implement-commit` スキルでそのまま利用できる最小限のドキュメント一式に変換することで、提案チェーン全体をスキップしたい場合に特に有効です。ワークフローは、情報収集(Phase 0)、最小限の設計書作成(Phase 1)、最小限のテスト計画作成(Phase 2)、完全な実装計画作成(Phase 3)、そして成果物間の相互参照検証(Phase 4)から構成されます。各フェーズでは、`propose-feature-design` や `propose-implementation-plan` といった専門スキルを持つサブエージェントが呼び出され、成果物の一貫性と品質を保ちながら、高速なパスを実現します。このスキルは、Claude Code エージェント向けに設計されており、Pydantic モデルを用いた構造化されたデータの受け渡しと、Python コードによるディレクトリ操作やサブエージェント起動を行います。

対応✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/cbgbt/bottlerocket-forest/tree/main/skills/ad-hoc-implementation-plan

Installed? Explore more コーディング&開発 skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

アドホック実装計画 (Ad-Hoc Implementation Plan)

大まかなアイデアから実装・コミット可能な成果物への高速パス。 ドキュメントの完全性よりもスピードを重視します。

使用するタイミング

  • ユーザーと大まかな計画やアイデアについて議論した後
  • implement-commit の TDD 検証機能を、完全な propose-* チェーンなしで利用したい場合
  • 機能が十分に理解されており、詳細な設計の反復を省略できる場合

前提条件

  • ユーザー承認済みの大まかな計画(会話中、マークダウン、頭の中でのモデルなど)
  • 既知のワークスペースパス
  • 変更対象の既知のファイル

オーケストレーターの役割

あなたは機械的なルーターです。機能について考えてはいけません。 あなたの仕事:

  1. ユーザーから必要最小限の情報を収集する
  2. 機能ディレクトリ構造を作成する
  3. 適切なスキルをコンテキストとしてサブエージェントを起動する
  4. フェーズ間で出力を渡す
  5. 相互参照を検証する

セットアップ

from pydantic import BaseModel
from pathlib import Path
import os

class GatherResult(BaseModel):
    feature_name: str
    feature_id: str  # NNNN 形式
    workspace: str
    files_to_modify: list[str]
    constraints: list[str]
    test_names: list[str]
    rough_plan_summary: str

class PhaseResult(BaseModel):
    success: bool
    artifact_path: str
    errors: list[str]

# サブエージェントコンテキスト用のスキルパス
skills = {
    "design": "skills/propose-feature-design/SKILL.md",
    "test_plan": "skills/propose-feature-test-plan/SKILL.md",
    "impl_plan": "skills/propose-implementation-plan/SKILL.md",
}

# スタイルガイド(利用可能な場合)
style_guides = [
    "docs/style/rust-design.md",
    "docs/style/rust-test.md",
    "docs/style/rust-impl.md",
]

Phase 0: 情報収集

大まかな計画から対話的に情報を収集または推測します:

# まだ不明な場合、ユーザーに質問:
# 1. 機能名 → docs/features/NNNN-name/ を作成
# 2. 変更するファイル → commits[].files
# 3. 主要な制約条件 → CC テーブルエントリ
# 4. テスト名 → test-plan + commits[].tests

# 次の機能IDを決定
存在的 = list(Path("docs/features").glob("[0-9][0-9][0-9][0-9]-*"))
next_id = f"{len(存在的):04d}"

feature_dir = f"docs/features/{next_id}-{feature_name}"
os.makedirs(feature_dir, exist_ok=True)

Phase 1: 最小限の設計

propose-feature-design スキルを使用してサブエージェントを起動しますが、最小限の出力を指示します。

result = spawn(
    prompt=draft_spawn_prompt(SkillDefined(
        "SKILLの手順に従ってMINIMALなdesign.mdを作成してください。"
        "生成するもの: 概要(1段落)、重要な制約条件テーブル、モジュール構造"
        "スキップするもの: アーキテクチャ図、ソリューションの仕組みの説明、デザインパターン、設計決定"
    )),
    context_files=[
        skills["design"],
        *[g for g in style_guides if exists(g)],
    ],
    context_data={
        "feature_dir": feature_dir,
        "feature_name": gathered.feature_name,
        "constraints": gathered.constraints,
        "files": gathered.files_to_modify,
        "rough_plan": gathered.rough_plan_summary,
        "minimal_mode": True,
    },
    response_model=PhaseResult,
    isolate_to=Cwd(gathered.workspace)
)

Phase 2: 最小限のテスト計画

propose-feature-test-plan スキルを使用してサブエージェントを起動します。

result = spawn(
    prompt=draft_spawn_prompt(SkillDefined(
        "SKILLの手順に従ってMINIMALなtest-plan.mdを作成してください。"
        "生成するもの: 要件カバレッジテーブル、重要な制約条件検証テーブル"
        "スキップするもの: 詳細なテスト実装ノート、統合テストの説明文"
    )),
    context_files=[
        skills["test_plan"],
        f"{feature_dir}/design.md",  # Phase 1 から
        *[g for g in style_guides if exists(g)],
    ],
    context_data={
        "feature_dir": feature_dir,
        "test_names": gathered.test_names,
        "constraints": gathered.constraints,
        "minimal_mode": True,
    },
    response_model=PhaseResult,
    isolate_to=Cwd(gathered.workspace)
)

Phase 3: 実装計画

propose-implementation-plan スキルを使用してサブエージェントを起動します。

result = spawn(
    prompt=draft_spawn_prompt(SkillDefined(
        "SKILLの手順に従ってimplementation-plan.tomlを作成してください。"
        "すべてのフィールドが必要です - 最小モードはありません。"
        "tests[] が test-plan.md のテスト名と完全に一致することを確認してください。"
    )),
    context_files=[
        skills["impl_plan"],
        f"{feature_dir}/design.md",
        f"{feature_dir}/test-plan.md",
        *[g for g in style_guides if exists(g)],
    ],
    context_data={
        "feature_dir": feature_dir,
        "workspace": gathered.workspace,
        "files": gathered.files_to_modify,
        "rough_plan": gathered.rough_plan_summary,
    },
    response_model=PhaseResult,
    isolate_to=Cwd(gathered.workspace)
)

Phase 4: 相互参照の検証

検証エージェントを起動してテストカバレッジを確認します。

class VerifyResult(BaseModel):
    valid: bool
    missing_tests: list[str]  # test-plan にあるが impl-plan にないテスト
    orphan_tests: list[str]   # impl-plan にあるが test-plan にないテスト
    missing_constraints: list[str]  # カバーされていない CC-N

result = spawn(
    prompt=draft_spawn_prompt(AdHoc(
        intents=["implementation-plan.toml が implement-commit に対して有効か検証する"],
        context=["アーティファクト間のすべての相互参照をチェックする"],
        goal=Verify(constraints=[
            "test-plan.md のすべてのテストが commits[].tests に正確に1回出現する",
            "design.md のすべての CC-N が test-plan.md で検証されている",
            "すべての commits[].files が存在するか、作成予定である",
            "TOML が正しくパースできる",
        ])
    )),
    context_files=[
        f"{feature_dir}/design.md",
        f"{feature_dir}/test-plan.md",
        f"{feature_dir}/implementation-plan.toml",
    ],
    response_model=VerifyResult,
    read_only=True
)

if not result.parsed.valid:
    # エラーと共に Phase 3 に戻る
    pass

引き渡し

検証後、アーティファクトは implement-commit で使用可能になります:

docs/features/NNNN-feature-name/
├── design.md              # 最小限: 概要 + CC テーブル + モジュール構造
├── test-plan.md           # 最小限: カバレッジテーブルのみ
└── implementation-plan.toml  # 完全版: すべての必須フィールド

ユーザーに通知:

アーティファクトの準備ができました。implement-commit スキルを実行して TDD パイプラインを開始してください。

Individual skills in this repo

This repo contains 19 individual skills — each has its own dedicated page.

build-kit-locally

Build a kit and publish it to a locally hosted registry for development testing

build-variant-from-local-kits

Build a variant using locally published kits for development validation

deep-research

Create educational documents that build understanding progressively with citations

edit-spec-file

Edit Bottlerocket RPM spec files following project style conventions

fact-find

Quick lookup of specific facts about Bottlerocket with citations

idea-honing

Clarify feature ideas through iterative Q&A, recording insights to guide concept development

implement-commit

Implement commits from an implementation plan using a TDD pipeline

local-registry

Start and manage a local OCI registry for Bottlerocket kit development

prepare-core-kit-release

Prepare bottlerocket-core-kit for release by bumping version and updating changelog

propose-feature-concept

Create a new feature concept document to pitch the idea and explain the problem/solution

propose-feature-design

Create or update feature technical design document with architecture and implementation guidance

propose-feature-requirements

Create or update feature requirements specification using EARS notation with examples and appendices

propose-feature-test-plan

Create a test plan mapping EARS requirements and Critical Constraints to specific tests

propose-implementation-plan

Create an implementation plan with atomic commits that build toward a complete feature

review-code

Deep code review generating PR comments via principled question-driven analysis

review-scope

Verify code changes match intended scope and requirements without exceeding boundaries

review-style

Verify code follows project style guides without providing improvement suggestions

test-local-twoliter

Build and test local changes to twoliter before releasing

update-twoliter

Update all Bottlerocket repositories to a new Twoliter version

関連スキル