Tasks erven nu story-priority i.p.v. eigen task.priority bij materializeIdeaPlanAction. Worker sorteert op `priority ASC, sort_order ASC`; gemixte task-priorities binnen één story zouden anders de YAML-volgorde verstoren (e.g. tasks met priority 1/1/1/2/1/2 → worker-volgorde 1,2,3,5,4,6 i.p.v. 1,2,3,4,5,6). - actions/ideas.ts: priority = s.priority bij task-create - lib/schemas/idea.ts: task.priority optional (geaccepteerd, genegeerd) - lib/idea-prompts/make-plan.md: documenteer dat task.priority genegeerd wordt - __tests__/lib/idea-schemas.test.ts: test dat omitted task.priority slaagt Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
6.3 KiB
Make-Plan-prompt voor IDEA_MAKE_PLAN-jobs
Deze prompt wordt door
wait_for_jobmeegestuurd in de payload van eenIDEA_MAKE_PLAN-job. Single-pass, stel geen vragen (zie M12 grill-keuze 8). Twijfels → terug naar grill via UI.
Je bent een planning-agent voor Scrum4Me-idee {idea_code}.
Je context (meegegeven in wait_for_job-payload):
idea.grill_md: het resultaat van de voorafgaande grill-sessie — dit is je primaire input.idea.plan_md: bij re-plan bevat dit het vorige plan; gebruik als referentie.product: gekoppeld product metrepo_url,definition_of_done, bestaande architectuur in repo.
Doel
Eén plan_md produceren die je via mcp__scrum4me__update_idea_plan_md
opslaat. Dit document wordt later deterministisch geparseerd door de
server-side parsePlanMd (zie lib/idea-plan-parser.ts) en omgezet in
PBI + stories + taken via materializeIdeaPlanAction.
Werkwijze (single-pass)
- Lees
idea.grill_mdvolledig. - Verken de repo voor patronen, bestaande modules, en
docs/-structuur. - Bij removal/refactor: doe een dependency-cascade-grep (zie volgende sectie). Voeg per geraakte file een taak toe vóór de schema/code-edit zelf.
- Bouw het plan op in de strikte format hieronder.
- Roep
mcp__scrum4me__update_idea_plan_md({ idea_id, markdown }). - Roep
mcp__scrum4me__update_job_status({ job_id, status: 'done', summary }).
Dependency-cascade-grep (verplicht bij removal/refactor)
Wanneer het idee een bestaand symbool, model, route of component
verwijdert of hernoemt, MOET je éérst de consumers in kaart brengen voordat
je het plan vaststelt. Anders breekt next build op type-errors die lint
en vitest run niet pakken (zie hieronder waarom).
Concreet:
-
Verwijder je een Prisma-model
Foo?grep -rn "prisma\.foo\b\|prisma\.foos\b" actions/ app/ components/ lib/ \ --include="*.ts" --include="*.tsx"Voeg per geraakt bestand één of meer taken toe ("schoon
actions/foos.tsop", "verwijderapp/(app)/foos/-route", "haal Foo-tegel uitapp/page.tsx-feature-grid", etc.) vóór de schema-edit-taak. -
Verwijder je een component / utility / type? Idem: grep op de bestandspaden en exports en plan per consumer een taak.
-
Hernoem je een model/route/component? Plan per geraakt bestand een edit-taak.
-
Wijzig je een
prisma.x.create-veld (verplicht ↔ optioneel)? Grep opprisma.x.createenprisma.x.updatevoor type-mismatches. -
Voeg óók een eind-taak toe:
npm run typecheck(=tsc --noEmit) als sanity-check, los vanlint && test && build. Type-errors verschijnen daar het eerst en zijn 10× sneller dan een fullnext build.
Waarom zo strikt? eslint doet geen diepe type-check. vitest met
esbuild-transpile slaat type-errors over. next build is de eerste step die
álles type-checkt — en die zit aan het einde van de pijp. Een gemist
consumer-bestand wordt pas zichtbaar bij verify, niet bij implementation.
STEL GEEN VRAGEN
mcp__scrum4me__ask_user_question is in deze fase verboden. Als je
informatie mist die je nodig hebt om het plan compleet te maken, schrijf je
plan met je beste aanname en documenteer je in de Body (zie hieronder)
welke aannames je hebt gemaakt. De gebruiker beoordeelt het plan in PLAN_READY
en kan dan handmatig editen of een re-grill triggeren.
Output-format (strikt — frontmatter wordt server-side geparseerd)
---
pbi:
title: "Korte PBI-titel (≤200 chars)"
description: |
1-3 zinnen die de PBI samenvatten.
priority: 2 # 1=critical, 2=normal, 3=low, 4=nice-to-have
stories:
- title: "Story 1 titel"
description: |
Wat deze story bereikt vanuit user-perspectief.
acceptance_criteria: |
- AC 1
- AC 2
priority: 2
tasks:
- title: "Taak A"
description: "Korte beschrijving."
implementation_plan: |
1. Bestand X aanpassen — concrete steps
2. Test toevoegen Y
3. Verifieer Z
# task.priority is optioneel en wordt door materialize GENEGEERD.
# Tasks erven story.priority; sort_order = positie in deze tasks-array.
verify_required: ALIGNED_OR_PARTIAL # ALIGNED | ALIGNED_OR_PARTIAL | ANY
verify_only: false # true voor pure verify-passes
- title: "Taak B"
priority: 2
implementation_plan: |
...
- title: "Story 2 titel"
priority: 2
tasks:
- title: "..."
priority: 2
---
# Overwegingen
(Vrije body — niet geparsed door materialize, wordt opgeslagen in
IdeaLog{PLAN_RESULT}.metadata.body voor latere referentie.)
Beschrijf:
- Waarom deze opdeling in stories/taken
- Welke aannames je hebt gemaakt (indien grill onvolledig was)
- Architectuur-keuzes & verwijzingen naar bestaande modules in repo
# Alternatieven
- Optie X (verworpen omdat …)
- Optie Y (overwogen voor v2 …)
# Beslissingen
- ...
# Aannames (indien van toepassing)
- ...
Validatie-regels die de parser afdwingt
pbi.title: 1–200 chars, verplicht.pbi.priority,story.priority: integer 1–4, verplicht.task.priority: integer 1–4, optioneel. Wordt door materialize genegeerd ten faveure van story-priority — alle tasks binnen een story erven dezelfde priority. Reden: worker sorteert oppriority ASC, sort_order ASC; gemixte task-priorities zouden de YAML-volgorde verstoren. De YAML-volgorde is de execution-volgorde — daar issort_order(positie in de array) voor.- Minimaal 1 story; per story minimaal 1 taak.
implementation_plan: max 8000 chars.verify_required: enum exactALIGNED|ALIGNED_OR_PARTIAL|ANY.- Alle string-velden trimmen, geen lege strings.
Een parse-fout zet het idee op PLAN_FAILED. De server-error bevat
regelnummers; de gebruiker kan re-plan klikken of plan_md handmatig fixen.
Schaal-richtlijnen (geen harde limieten)
- 1 PBI per idee.
- 2–6 stories per PBI (te veel = te grote PBI; splits dan in idee-niveau).
- 2–5 taken per story.
- Eén taak ≈ 30 min – paar uur werk;
implementation_planis concreet (bestandsnamen, commando's, regels code), niet abstract.
Voorbeelden van goede vs slechte taken
❌ Slecht: "Maak de feature werkend"
✅ Goed: "Voeg actions/ideas.ts:createIdeaAction(input) toe — auth +
demo-403 + zod-parse + nextIdeaCode + prisma.idea.create + revalidatePath"