메뉴
workplan — Beads-Backlog analysieren, priorisieren und verbessern
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | workplan |
| description | workplan — Beads-Backlog analysieren, priorisieren und verbessern |
| requires_standards | ["english-only"] |
Analysiere das Beads-Backlog, erstelle einen priorisierten Arbeitsplan und schlage Verbesserungen zur Backlog-Organisation vor (Duplikate, Business-Domain-Labels, Epic-Gruppierung).
Optional: Eingabeargumente (z.B. --label billing, --epic mira-xxx, --focus P0)
Führe scripts/gather-data.sh aus, um alle Backlog-Daten zu sammeln:
scripts/gather-data.sh
Falls die Eingabeargumente Label- oder Epic-Filter enthalten, passe die Queries entsprechend an.
Aus den gesammelten Daten:
Bewerte jedes Ready-Bead nach Autonomie-Eignung:
| Signal | Score | Grund |
|---|---|---|
| Hat Akzeptanzkriterien | +2 | Agent weiß wann fertig |
| Hat Description | +1 | Agent hat Kontext |
| Hat MoC-Tabelle | +1 | Agent weiß wie zu verifizieren |
| Hat NLSpec (intent/contracts) | +1 | Vollständige Spec für Agent (feature/epic) |
| Typ bug/task | +1 | Gut abgegrenzt |
| Typ feature/epic | -1 | Braucht oft Entscheidungen |
| P0 | -1 | Zu wichtig für unbeaufsichtigt |
| Leaf-Node (keine Deps) | +1 | Kein Koordinationsrisiko |
Scoring:
cld -b <id> empfohlen (autonom) — entspricht "factory-ready"Für Autonomie-Scoring: Lade Details der Top-10 Ready-Beads via bd show <id> (parallel), um Akzeptanzkriterien, Description, MoC-Tabelle und NLSpec zu prüfen.
Detaillierte Spec-Analyse: Für einzelne Beads mit hohem Score
factory-check <id>ausführen — bewertet alle 6 factory-ready Kriterien und gibt eine klare FACTORY READY / NEEDS INTERACTIVE WORK Empfehlung.
Scanne alle offenen Beads (aus Phase 1) nach Überschneidungen:
Für verdächtige Paare: bd show <id> für beide laden und Descriptions vergleichen.
Keine externe Library nötig — der LLM-Kontext reicht für semantischen Vergleich der Titel/Descriptions.
Identifiziere übergreifende Business-Domains aus den offenen Beads. Domains sind fachliche Bereiche, keine technischen Layer:
| Beispiel-Domain | Signalwörter |
|---|---|
| billing | payment, invoice, transaction, pricing, subscription |
| auth | login, session, token, permission, role, access |
| observability | logging, monitoring, metrics, alerting, tracing |
| onboarding | setup, init, getting-started, first-run, wizard |
| workflow | pipeline, orchestrator, agent, automation, factory |
| documentation | docs, changelog, readme, standards, guide |
Nicht verwenden: frontend, backend, database, API, infrastructure — das sind technische Layer, keine Domains.
Schritte:
bd label listbd list --type=epic --status=openFormatiere das Ergebnis als:
## Workplan — [Projektname]
### Status
Open: X | Closed: Y (Z%) | Blocked: B | Ready: R
### Aktuell in Arbeit
(in_progress Beads mit Zeitstempel)
### Empfohlene nächste Aktionen
#### P0 — Jetzt
| ID | Titel | Autonomie | Grund |
#### P1 — Bald
| ID | Titel | Autonomie | Grund |
### Parallel startbar (cld -b)
```bash
cld -b <id1> & # "Titel"
cld -b <id2> & # "Titel"
| Blocker | Unblockiert | Impact |
| Epic | Done/Total | % |
| Bead A | Bead B | Ähnlichkeit | Vorschlag |
|---|---|---|---|
| "Titel" | "Titel" | Gleiche Funktion | Merge → bd close <id2> --reason="Merged into <id1>" |
| Domain | Beads | Vorschlag |
|---|---|---|
| billing | , , | bd update <id1> --add-label=billing (etc.) |
| Vorgeschlagenes Epic | Beads | Vorschlag |
|---|---|---|
| "Observability Pipeline" | , | bd create --title="[EPIC] Observability" --type=epic + bd dep add |
## Phase 5: Aktionen anbieten
Frage den User:
- Soll ich ein Bead starten? (`bd update <id> --status=in_progress`)
- Parallel-Batch launchen? (mehrere `cld -b` commands)
- Einen Blocker untersuchen?
- **Backlog aufräumen?** Duplikate mergen, Labels anwenden, Epics erstellen?
- Bei Zustimmung: die vorgeschlagenen `bd`-Commands direkt ausführen
- Bei Teilzustimmung: User wählt welche Vorschläge umgesetzt werden
Orchestrate parallel implementation of multiple beads across cmux panes in dependency-aware waves. Use when implementing a whole feature area, dispatching multiple beads at once, or running parallel cld -b sessions. MUST USE when user says "wave", "parallel beads", "implement all beads for X", "start the beads", or references implementing more than 2 beads at once. Also triggers on "cmux dispatch", "multi-bead", "wave orchestrator".
Audit a repo for ADR hoist debt and pre-trinity packages. Triggers on: adr gap, hoist debt, adr audit, pre-trinity packages, architecture drift.
Troubleshoot beads Dolt failures: `bd dolt` push/pull errors, merge conflicts, embedded/shared-server mode problems, remote auth issues, local DB recovery, re-clone, reflog restore, broken `.beads` Dolt config, and brew-services Dolt lifecycle. Use whenever beads sync or Dolt infrastructure is failing — symptoms like "beads do not sync", "cannot push issues", "no common ancestor", "not supported in embedded mode", "Dolt server unreachable", or "lost local database". Read the beads changelog first. Do not use for normal beads tracking (`bd create/ready/close`), standalone Dolt databases, or regular git push/pull.
Create and review agents (subagents). Use when creating specialized AI assistants, reviewing/auditing existing agents, deciding between agent vs skill vs command, or asking about agent best practices, multi-agent pipelines, and model selection. MUST BE USED when the user says "create agent", "new subagent", "review agent", "audit agent", "agent vs skill", or asks about multi-agent architecture.
Query per-bead token cost metrics from the local agent metrics database. Shows cost table, impl:review ratios, most expensive beads, cost trend over time. Triggers on: bead metrics, token cost report, bead costs, /bead-metrics.
Structured 4-stage retrospective for completed beads: Requirements vs Strategy, Strategy vs Execution, Iteration Review, Workflow Audit. Creates Trap/Pattern/Decision artifacts. Use when debriefing a bead, capturing session learnings, or running a compound retrospective.