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

implement-commit (実装コミット)

実装計画書からTDDパイプラインを使用してコミットを実行するスキルです。

implement-commit (実装コミット) とは?

このスキルは、`implementation-plan.toml` に定義されたコミットを、機械的なTDDパイプラインに沿って順次実行します。開発者はオーケストレーターとして振る舞い、状態遷移を管理する `ic-driver.py` と連携して、デザイナー、テスター、実装者、アービターの各エージェントを適切なタイミングで起動します。各フェーズでは、コード生成、テスト作成、スタイルレビュー、スコープレビューが自動化され、障害発生時にはLLMによる介入が可能です。この仕組みにより、手順の標準化とトークン消費の最適化を両立しながら、堅牢なコード実装を実現します。Claude CodeやCursorなどのターミナルベースのAIエージェント上で動作します。

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

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

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

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

ドキュメント

Implement Commit Skill

実装計画書 implementation-plan.toml のコミットを、機械的なTDDパイプラインで実行します。

使用するタイミング

  • docs/features/NNNN-name/implementation-plan.toml に実装計画が存在する
  • コードを書き始める準備ができている

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

あなたは機械的なオーケストレーターです。ドライバー(ic-driver.py)が状態遷移を管理します。

あなたが行うのは以下のみ:

  1. ドライバーコマンドの呼び出し
  2. spawn アクションの実行
  3. 結果の報告

問題が発生しない限り関連ファイルを読んではいけません — トークンを節約し、ic-driver を信頼してください。

セットアップ

import json
from pydantic import BaseModel
from typing import Literal

# パス
feature_dir = "docs/features/NNNN-feature"
plan_path = f"{feature_dir}/implementation-plan.toml"
state_dir = ".ic"
driver = "skills/implement-commit/ic-driver.py"
workspace = "."  # 計画のメタ情報から取得

# レスポンスモデル
class PhaseResult(BaseModel):
    status: Literal["ok", "problems"]
    files_created: list[str] = []
    files_modified: list[str] = []
    notes: str | None = None

class GateDiscovery(BaseModel):
    designer_gate: str
    test_gate: str

class FormatterDiscovery(BaseModel):
    fmt_cmd: str
    lint_cmd: str

class StyleResult(BaseModel):
    status: Literal["accept", "violations"]
    violations: list[str] = []

class ArbiterResult(BaseModel):
    proceed: bool
    reasoning: str

# spawn 用のエージェントファイル
agents = {
    "designer": "skills/implement-commit/agents/designer.md",
    "tester": "skills/implement-commit/agents/tester.md",
    "implementor": "skills/implement-commit/agents/implementor.md",
    "arbiter": "skills/implement-commit/agents/arbiter.md",
}
style_guides = {
    "designer": "docs/style/rust-design.md",
    "tester": "docs/style/rust-test.md",
    "implementor": "docs/style/rust-impl.md",
}

メインループ

依存関係の順に各コミットを処理:

commit_id = 1  # 依存関係解析から取得
state_path = f"{state_dir}/commit-{commit_id}.json"

# 初期化
bash(f"python {driver} init --plan {plan_path} --commit {commit_id} --state {state_path}", on_error="raise")

# 駆動ループ
while True:
    try:
        output = bash(f"python {driver} next --state {state_path}", on_error="raise")
    except BashError as e:
        # ドライバーがLLMの支援を要求 — 以下の「障害対応」を参照
        handle_escalation(e, state_path)
        continue
    
    action = json.loads(output)
    
    if action["action"] == "done":
        break
    
    if action["action"] == "spawn":
        result = execute_spawn(action)
        bash(
            f"python {driver} report --state {state_path} --result '{json.dumps(result)}'",
            on_error="raise"
        )

spawn の実行

def execute_spawn(action: dict) -> dict:
    phase = action.get("phase")
    
    # コンテキストファイルを決定
    context_files = [f"{feature_dir}/design.md"]
    if phase and phase in agents:
        context_files.append(agents[phase])
        if phase in style_guides:
            context_files.append(style_guides[phase])
    
    # レスポンスモデルを決定
    if action.get("response_schema") == "GateDiscovery":
        model = GateDiscovery
    elif action.get("response_schema") == "FormatterDiscovery":
        model = FormatterDiscovery
    elif action.get("style_review"):
        model = StyleResult
    elif action.get("arbiter"):
        model = ArbiterResult
    else:
        model = PhaseResult
    
    # spawn を実行
    result = spawn(
        prompt=action["prompt"],
        context_files=context_files,
        response_model=model,
        read_only=action.get("style_review") or action.get("scope_review"),
        isolate_to=Cwd(workspace) if not action.get("style_review") else None,
    )
    
    result_dict = result.parsed.model_dump()
    # ドライバーの状態遷移のためにアクションフラグを保持
    if action.get("arbiter"):
        result_dict["arbiter"] = True
    return result_dict

障害対応

ドライバーが終了コード1で終了した場合、LLMの支援が必要です:

def handle_escalation(e: BashError, state_path: str):
    # stderr から障害情報を解析
    escalation = json.loads(e.stderr)
    error = escalation["error"]
    
    # LLMによる介入 — 問題を理解し修正する
    # ここで考える — ドライバーから制御が委譲された
    
    if "gate failed" in error.lower():
        # コードの誤りか、ゲートの設定ミスの可能性
        # 修正エージェントを起動するか、ゲートを調整
        spawn(
            prompt=f"このゲート障害を修正してください: {error}",
            context_files=[...],
            isolate_to=Cwd(workspace),
        )
    elif "arbiter rejected" in error.lower():
        # スタイル問題が深刻すぎる
        agent_feedback(f"スタイルレビューが不合格: {error}")
    elif "scope violations" in error.lower():
        # スコープ外の変更
        agent_feedback(f"スコープ違反: {error}")
    else:
        agent_feedback(f"不明な障害: {error}")
    
    # 修正後に再開
    bash(f"python {driver} resume --state {state_path}", on_error="raise")

ドライバーコマンド

コマンド目的
initコミットの状態ファイルを作成
next次のアクション (spawn) を取得、またはゲート/bashを直接実行
reportspawn 結果を報告し、状態を進める
resumeLLM介入後に続行
status現在の状態を表示 (デバッグ用)

状態遷移

EXPLORE_GATES -> EXPLORE_FORMATTERS ->
DESIGNER_PHASE -> DESIGNER_GATE -> DESIGNER_STYLE ->
TESTER_PHASE -> TESTER_GATE -> TESTER_STYLE ->
IMPLEMENTOR_PHASE -> IMPLEMENTOR_GATE -> IMPLEMENTOR_STYLE ->
SCOPE_REVIEW -> FORMAT -> COMMIT -> DONE
  • ゲート失敗はフェーズを再試行 (最大2回)、その後エスカレーション
  • スタイル違反はループ (最大3回)、その後アービターを呼び出し
  • ドライバーはゲート/フォーマット/コミットを直接実行 (LLMオーバーヘッドなし)
  • spawn のみオーケストレーターのアクションが必要

ファイル構成

skills/implement-commit/
├── SKILL.md           # このファイル
├── ic-driver.py       # 状態遷移ドライバー
└── agents/
    ├── designer.md    # 型とシグネチャを作成
    ├── tester.md      # テストを記述
    ├── implementor.md # ロジックを実装
    └── arbiter.md     # スタイルレビューの可否を判断

レビュアーは別スキルを使用: review-scope, review-style。

Individual skills in this repo

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

ad-hoc-implementation-plan

Transform a rough plan into implement-commit ready artifacts. Allows rigorous review while implementing.

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

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

関連スキル