skills/skills/kvb-create-requirement/SKILL.md at 9917cccd6e2274a3419b4054009eb2aa995140d3

0 Fork 0

Files

T

Kevin Veen-BirkenbachandClaude Opus 5.5 8be453b361 feat(skills)!: add kvb-create-requirement and kvb-think-brainstorm, rename kvb-create-feature to kvb-think-gaps

kvb-create-requirement asks for the context, runs kvb-think-listen and kvb-think-brainstorm, then drafts one requirement with a user story, operator-confirmed decisions, a Mermaid approach flowchart with emoji phases, a test loop and an operator feedback checkpoint per stage, checkbox acceptance criteria grouped by area, and a Tests group with unit, integration and e2e (n/a with a reason). It writes only on the operator's Write it and stops with an offer to hand over to kvb-create-plan. kvb-think-brainstorm generates options through seven fixed lenses, scores them on value, effort and risk, and hands the best two or three over. kvb-create-feature becomes kvb-think-gaps: it still finds and ranks missing work but delegates every pick to kvb-create-requirement, so the requirement template lives in one place. Operator order 2026-11-03.

BREAKING CHANGE: /kvb-create-feature is now /kvb-think-gaps.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-11-03 13:57:14 +01:00

3.2 KiB

Raw Blame History

name, description

name	description
kvb-create-requirement	Write a requirement: user story, decisions, Mermaid approach, acceptance criteria, tests. Trigger on /kvb-create-requirement, "requirement schreiben", or a kvb-think-gaps pick.

Writes requirements, never implementations. Nothing touches disk before the operator picks Write it.

Step 1: context

Ask the operator for the context first, in one open question: what should change, for whom, and why now. A candidate handed over by the kvb-think-gaps skill already carries it. Read what the answer points to (code, issues, logs, existing requirements) before the next step.

Step 2: listen

Run the kvb-think-listen skill until scope, constraints, the definition of done and every operator-only decision are fixed. Its answers become the Decisions section.

Step 3: brainstorm

Run the kvb-think-brainstorm skill on the approach. The operator's pick becomes a decision; each rejected option stays there with its reason.

Step 4: draft

Location, filename and numbering follow the project's existing requirement documents; read them first, and ask when there are none. One feature per document: a title that needs "and" is two requirements. Sections in this order:

# <number> - <title>
## User Story: "As a , I want , so that ."
## Decisions (operator-confirmed <YYYY-MM-DD>; do not re-litigate): numbered, a bold keyword first, rejected alternatives with their reason.

## Approach: one Mermaid flowchart TD over the whole procedure, one subgraph per phase with an emoji title and an emoji in every node:

flowchart TD
    subgraph P["🧭 0 · Preparation"]
        P1["📋 Write requirement"] --> P2{"✅ Operator approves?"}
        P2 -- "✏️ corrections" --> P1
    end
    P2 -- "🤖 yes" --> A1
    subgraph A["🛠️ A · Implementation"]
        A1["🧩 Change"] --> A2{"🧪 Tests green?"}
        A2 -- "🔴 no: fix" --> A1
        A2 -- "🟢 yes" --> AF{"💬 Operator feedback?"}
        AF -- "✏️ changes" --> A1
    end
    AF -- "👍 fits" --> D1["🏁 Review, commit with operator OK, hand-over"]

Every verifiable stage gets its test loop and an operator feedback checkpoint; a user-visible change shows screenshots at that checkpoint.

## Acceptance Criteria: grouped under ### per area. Each item is a - [ ] that one check proves or disproves on its own: a command, a file:line, a test name, an observable state. No "should", no "works well".
### Tests, the last group: Unit, Integration and E2E, each with its criteria. A level that cannot apply stays with n/a: <reason>.

Step 5: confirm and write

Show the full draft, then AskUserQuestion: Write it / Revise it / Discard. Revise loops back to the step the correction touches. Write only on Write it; lint the file with the project's markdown linter on the resource chair's grant (the kvb-org-organize skill).

Step 6: hand over

Stop after writing. Offer in one line to run the kvb-create-plan skill, which hands the plan to the kvb-org-robot skill; never start the implementation without the operator's yes.

3.2 KiB Raw Blame History