CommunityCodierung & Entwicklunggithub.com

Ad-hoc-Umsetzungsplan

Verwandelt einen groben Plan in implementierungs- und commit-fähige Artefakte. Ermöglicht gründliche Überprüfung während der Implementierung.

Was ist Ad-hoc-Umsetzungsplan?

Diese Fähigkeit (Ad-hoc-Umsetzungsplan) beschleunigt den Weg von einer groben Idee zu implementierungs- und commit-fähigen Artefakten, indem sie die Dokumentationsvollständigkeit gegen Geschwindigkeit eintauscht. Sie eignet sich, wenn ein grober Plan mit dem Benutzer besprochen wurde, die TDD-Verifizierung von implement-commit gewünscht ist, aber die aufwändige propose-*-Kette vermieden werden soll. Der Orchestrator sammelt minimal notwendige Informationen, erstellt eine Feature-Verzeichnisstruktur, startet Unteragenten mit spezifischen Skills (Design, Testplan, Implementierungsplan) und überprüft Querverweise. Das Ergebnis ist ein minimales Design, ein minimaler Testplan und ein vollständiger Implementierungsplan, der direkt für implement-commit verwendet werden kann. Unterstützt werden Entwicklungsumgebungen, die subagent-basierte Workflows und Skill-Definitionen (z. B. Claude Code, Cursor, Codex) ermöglichen.

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

Installed? Explore more Codierung & Entwicklung skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

In Ihrer bevorzugten KI fragen

Öffnet einen neuen Chat, in dem dieser Agent-Skill bereits geladen ist.

Dokumentation

Was macht Ad-hoc-Umsetzungsplan?

Schneller Weg von einer groben Idee zu implementierungs- und commit-fähigen Artefakten. Tauscht Dokumentationsvollständigkeit gegen Geschwindigkeit.

Wann verwenden

  • Sie haben einen groben Plan oder eine Idee, die mit dem Benutzer besprochen wurde
  • Sie möchten die TDD-Verifizierung von implement-commit, ohne die vollständige propose-*-Kette zu durchlaufen
  • Die Funktion ist gut genug verstanden, um eine ausführliche Designiteration zu überspringen

Voraussetzungen

  • Vom Benutzer genehmigter grober Plan (kann im Gespräch, als Markdown oder als mentales Modell vorliegen)
  • Bekannter Workspace-Pfad
  • Bekannte zu ändernde Dateien

Orchestrator-Rolle

Sie sind ein MECHANISCHER ROUTER. Sie DENKEN NICHT über die Funktion nach. Ihre Aufgabe:

  1. Minimale erforderliche Informationen vom Benutzer sammeln
  2. Feature-Verzeichnisstruktur erstellen
  3. Unteragenten mit geeigneten Skills als Kontext starten
  4. Ausgaben zwischen den Phasen weiterleiten
  5. Querverweise überprüfen

Einrichtung

from pydantic import BaseModel
from pathlib import Path
import os

class GatherResult(BaseModel):
    feature_name: str
    feature_id: str  # NNNN-Format
    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]

# Skill-Pfade für Unteragenten-Kontext
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",
}

# Styleguides (falls vorhanden)
style_guides = [
    "docs/style/rust-design.md",
    "docs/style/rust-test.md",
    "docs/style/rust-impl.md",
]

Phase 0: Sammeln

Interaktiv aus dem groben Plan sammeln oder ableiten:

# Falls nicht bereits bekannt, Benutzer fragen:
# 1. Feature-Name -> erstellt docs/features/NNNN-name/
# 2. Zu ändernde Dateien -> commits[].files
# 3. Wichtige Randbedingungen -> CC-Tabelleneinträge
# 4. Testnamen -> test-plan + commits[].tests

# Nächste Feature-ID bestimmen
vorhanden = list(Path("docs/features").glob("[0-9][0-9][0-9][0-9]-*"))
naechste_id = f"{len(vorhanden):04d}"

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

Phase 1: Minimales Design

Unteragent mit propose-feature-design-Skill starten, aber Anweisung für MINIMALE Ausgabe.

ergebnis = spawn(
    prompt=draft_spawn_prompt(SkillDefined(
        "MINIMALE design.md gemäß Skill-Prozedur erstellen. "
            "NUR generieren: Überblick (1 Absatz), Tabelle der kritischen Randbedingungen, Modulstruktur. "
            "ÜBERSPRINGEN: Architekturdiagramme, Lösungskonzept-Prosa, Entwurfsmuster, Entwurfsentscheidungen."
    )),
    context_files=[
        skills["design"],
        *[g for g in style_guides if exists(g)],
    ],
    context_data={
        "feature_dir": feature_verz,
        "feature_name": gesammelt.feature_name,
        "constraints": gesammelt.constraints,
        "files": gesammelt.files_to_modify,
        "rough_plan": gesammelt.rough_plan_summary,
        "minimal_mode": True,
    },
    response_model=PhaseResult,
    isolate_to=Cwd(gesammelt.workspace)
)

Phase 2: Minimaler Testplan

Unteragent mit propose-feature-test-plan-Skill starten.

ergebnis = spawn(
    prompt=draft_spawn_prompt(SkillDefined(
        "MINIMALEN test-plan.md gemäß Skill-Prozedur erstellen. "
            "NUR generieren: Tabelle der Anforderungsabdeckung, Tabelle der Verifikation kritischer Randbedingungen. "
            "ÜBERSPRINGEN: Detaillierte Testimplementierungshinweise, Integrationstest-Prosa."
    )),
    context_files=[
        skills["test_plan"],
        f"{feature_verz}/design.md",  # Aus Phase 1
        *[g for g in style_guides if exists(g)],
    ],
    context_data={
        "feature_dir": feature_verz,
        "test_names": gesammelt.test_names,
        "constraints": gesammelt.constraints,
        "minimal_mode": True,
    },
    response_model=PhaseResult,
    isolate_to=Cwd(gesammelt.workspace)
)

Phase 3: Implementierungsplan

Unteragent mit propose-implementation-plan-Skill starten.

ergebnis = spawn(
    prompt=draft_spawn_prompt(SkillDefined(
        "implementation-plan.toml gemäß Skill-Prozedur erstellen. "
            "Alle Felder erforderlich - kein Minimalmodus. "
            "Sicherstellen, dass tests[] exakt den Testnamen aus test-plan.md entspricht."
    )),
    context_files=[
        skills["impl_plan"],
        f"{feature_verz}/design.md",
        f"{feature_verz}/test-plan.md",
        *[g for g in style_guides if exists(g)],
    ],
    context_data={
        "feature_dir": feature_verz,
        "workspace": gesammelt.workspace,
        "files": gesammelt.files_to_modify,
        "rough_plan": gesammelt.rough_plan_summary,
    },
    response_model=PhaseResult,
    isolate_to=Cwd(gesammelt.workspace)
)

Phase 4: Querverweise überprüfen

Prüfer starten, um Testabdeckung zu überprüfen.

class VerifyResult(BaseModel):
    valid: bool
    missing_tests: list[str]  # In test-plan, aber nicht in impl-plan
    orphan_tests: list[str]   # In impl-plan, aber nicht in test-plan
    missing_constraints: list[str]  # CC-N nicht abgedeckt

ergebnis = spawn(
    prompt=draft_spawn_prompt(AdHoc(
        intents=["Überprüfen, ob implementation-plan.toml für implement-commit gültig ist"],
        context=["Alle Querverweise zwischen Artefakten prüfen"],
        goal=Verify(constraints=[
            "Jeder Test in test-plan.md erscheint genau einmal in commits[].tests",
            "Jedes CC-N in design.md hat eine Verifikation in test-plan.md",
            "Alle commits[].files existieren oder werden erstellt",
            "TOML wird korrekt geparst",
        ])
    )),
    context_files=[
        f"{feature_verz}/design.md",
        f"{feature_verz}/test-plan.md",
        f"{feature_verz}/implementation-plan.toml",
    ],
    response_model=VerifyResult,
    read_only=True
)

if not ergebnis.parsed.valid:
    # Zurück zu Phase 3 mit Fehlern
    pass

Übergabe

Nach der Überprüfung sind die Artefakte bereit für implement-commit:

docs/features/NNNN-feature-name/
├── design.md              # Minimal: Überblick + CC-Tabelle + Modulstruktur
├── test-plan.md           # Minimal: Nur Abdeckungstabellen
└── implementation-plan.toml  # Vollständig: Alle erforderlichen Felder

Benutzer informieren:

Artefakte fertig. Führen Sie die implement-commit-Fähigkeit aus, um die TDD-Pipeline auszuführen.

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

Verwandte Skills