scaffold-design-spec

Sterne14

Forks5

Aktualisiert10. Juli 2026 um 06:01

Create template stub files for newly enabled catalog entries, including user-facing documentation

Installation

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

Quelle

sohei56

sohei56/maul-team

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·SOC 15-1252

SKILL.md

readonly

Mehr aus diesem Repository

gleiches Repository

codebase-audit

sohei56/maul-team

Whole-repo, multi-agent audit that IS the Sprint-end cross-review ceremony (product-wide integrity): 4 axes — spec-conformance, logic/defect hunt, redundancy, and product-security — over the ACCUMULATED codebase at HEAD, not the Sprint diff. Findings are swept to zero per defect class — one class = one PBI covering every occurrence, documentation drift batched into a single DOCS PBI — and non-blocking: Critical/High become draft PBIs for the NEXT Sprint, Medium/Low at PO discretion. At Integration-Sprint entry a thin re-check confirms the latest audit is fresh and no open Critical/High audit PBIs remain before testing proceeds.

2026-07-2014

cross-review

sohei56/maul-team

Sprint-end product-wide integrity gate. The five per-aspect reviews (requirement conformance, functional quality, security, maintainability, docs consistency) now run PER-PBI inside the pipeline before a PBI reaches awaiting_cross_review. Sprint-end cross-review is the whole-repo codebase-audit ONLY: static analysis + 4 audit axes (spec-conformance, logic-defect, redundancy, product-security) over the accumulated codebase at HEAD. The audit is non-blocking — Critical/High findings become draft PBIs for the next Sprint; it never reverts a PBI.

2026-07-2014

pbi-escalation-handler

sohei56/maul-team

Handles PBI pipeline escalation notifications from Developer. Reads escalation context, applies response matrix (retry / split / hold / human), and routes to user when human intervention is needed.

2026-07-1914

pbi-merge

sohei56/maul-team

SM-side merge orchestration for a single PBI. Triggered when the Developer notifies `[<pbi-id>] PBI_READY_TO_MERGE`. Drives `.scrum/scripts/merge-pbi.sh` and handles the failure / retry cycle through SendMessage to the assigned Developer.

2026-07-1914

pbi-pipeline

sohei56/maul-team

PBI development pipeline — orchestrates design, impl+UT, PBI review, and UT-run stages with sub-agent fan-out, file-based handoff, and deterministic termination gates (Anthropic + Ralph + GAN-derived). Used by Developer per assigned PBI. Replaces former design + implementation skills.

2026-07-1914

po-acceptance

sohei56/maul-team

PO acceptance verification — launches and operates the app to verify acceptance criteria by command execution. Used in Sprint Review (demo mode) and Integration Sprint (UAT mode) when .scrum/config.json po_mode is "agent".

2026-07-1514

name	scaffold-design-spec
description	Create template stub files for newly enabled catalog entries, including user-facing documentation
disable-model-invocation	false

Inputs

docs/design/catalog.md (doc type reference)
docs/design/catalog-config.json (enabled spec IDs)
sprint.json → id
backlog.json → PBI IDs for related_pbis

Outputs

docs/design/specs/{category}/{id}-{slug}.md stub files
YAML frontmatter: catalog_id, created_sprint, last_updated_sprint, related_pbis, frozen: false, revision_history

Preconditions

state.json phase: "sprint_planning"
catalog.md, catalog-config.json, sprint.json, backlog.json exist

Steps

Read catalog-config.json→enabled IDs. Cross-reference catalog.md→get category/name/granularity
Each enabled entry without existing file: a. Create docs/design/specs/{category}/{id}-{slug}.md (auto-create dirs) b. YAML frontmatter: catalog_id, created_sprint, last_updated_sprint (same), related_pbis, frozen: false, revision_history (initial entry: sprint, author: "scrum-master", date, summary: "Initial stub created", pbis) c. Placeholder sections: Overview, Design Details, Constraints, References d. Category docs/→doc placeholders: Overview, Usage, API Reference, Examples e. Category technology/→library-spec placeholders: Library & Version, Verified API Surface, Gotchas, Sources (source URL per claim)
Skip existing stubs (idempotent)
Report: count created, new file paths

Multi-instance types (D-001, S-022, S-070)

D-001 (one file per decision), S-022 (one per external service), and S-070 (one per third-party library) are multi-instance. Scaffold the single name-slug base stub as for any enabled ID; additional instances are created on demand by their owning agent — e.g. pbi-designer writes technology/S-070-<lib-slug>.md per library during the Design stage. All files sharing an enabled ID's prefix satisfy Governance Rules 1–2 (keyed on spec ID, not exact slug); do not delete extra instances as "non-enabled".

Ref: FR-004

Exit Criteria

Every enabled catalog entry has stub file
All stubs: valid YAML frontmatter with all required fields
docs/ category→doc-oriented placeholders
No duplicate stubs

Handoff (commit before base freeze)

This skill only writes stubs to the working tree. The caller (sprint-planning Step 13) MUST commit docs/design/ to main before spawn-teammates runs freeze-sprint-base.sh — worktrees fork from committed HEAD, so an uncommitted stub reaches no PBI worktree. freeze-sprint-base.sh refuses while docs/design/ is dirty.