Prompt Craft Inside EPAV
Role + Context + Task + Format + Constraints — still the structure. It just moves into a one-line argument.
Module Overview
This is the Dev Track's equivalent of Module 3. The prompting craft doesn't go away once you have a CLI skill — it moves. Role, Context, and Format are now baked into evaluate.md, plan.md, apply.md, and validate.md themselves. What's left for you to get right is the Task — the one line you type as the skill's argument — and the Constraints you push back with when a plan or a diff misses something.
| At a glance | |
|---|---|
| Covers | What's pre-baked into each EPAV skill vs. what you still control; writing a strong /evaluate argument; correcting a wrong /plan; converting a repeated correction into a permanent rule |
| When it runs | Alongside Dev 2 — this is the craft underneath every EPAV run |
| Builds on | Core program Module 3 (Prompt Engineering Fundamentals) |
| Leads into | Dev 6, where a recurring correction becomes a committed rule, agent, or skill |
What you'll produce
A refined /evaluate argument style for your task type, at least one documented correction to a /plan output, and a candidate rule for knowledge/rules/coding-standards.md drawn from a mistake you had to correct more than once.
What's Already Baked In
Open .claude/commands/evaluate.md and you're looking at a Role + Context + Format prompt someone already wrote and tested. Role: "orient fully before writing any plan or code." Context: the priority-ordered load list (CSV → AGENTS.md → arch doc → knowledge/). Format: the exact EVALUATE SUMMARY block shape. You don't re-derive any of that per task — it's the same reason the core program has you convert a good prompt into an agent in Module 3's Drill 5. nexus ships the conversion already done for the Developer role.
| Prompt part | Where it lives now | What you still supply |
|---|---|---|
| Role | Hard-coded in each skill's .md file | Nothing — fixed per skill |
| Context | The skill's load order (CSV → AGENTS.md → arch doc → knowledge/) | Which task/CSV row to point it at |
| Task | — | The argument you type — this is Module 3's craft, still fully yours |
| Format | The EVALUATE SUMMARY / PLAN / APPLY COMPLETE / VALIDATE COMPLETE block shapes | Nothing — fixed per skill |
| Constraints | AGENTS.md, loaded automatically | Follow-up corrections when the plan misses one |
The Task Line Is Still Everything
/evaluate <task description, CSV path, or feature name> — that argument is the one part of the prompt nexus can't write for you, and it decides the quality of everything downstream, exactly the way a weak initial prompt produced a vague BRD section in the core program's Module 3.
| Weak argument | Why it fails | Stronger argument |
|---|---|---|
/evaluate fix the bug | No file, no symptom, no CSV reference — EVALUATE has nothing to load | /evaluate TASK-024 (task exists in the CSV with description + ACs) |
/evaluate make notifications better | Not a task, not scoped, no acceptance criteria to validate against | /evaluate TASK-019: seller order notifications |
/evaluate refactor the whole service layer | Violates EPAV's one-task-at-a-time scope discipline | One /evaluate per CSV row; log the refactor idea to knowledge/retros/ |
Refining a Wrong /plan
Module 3's refinement loop — change one thing at a time, don't re-roll from scratch — applies directly to a /plan that gets the blast radius wrong.
v1 /plan output: touches notification-service.ts only.
→ Missing: OrderToast.tsx also needs updating for the new event type.
Your correction (not a new /evaluate, a direct reply):
"The plan missed OrderToast.tsx — TASK-017 wired toast-service to
listen for exactly this event type. Revise the plan to include it,
and re-run the blast radius check against both files."
v2 /plan output: now includes OrderToast.tsx, blast radius updated.
→ Approve, or refine again.
Three corrections, same problem — that's a context or rule gap
If you're correcting /plan on the same category of miss for the third time this sprint, the fix isn't a better one-off correction — it's a missing entry in AGENTS.md or knowledge/rules/coding-standards.md that would have prevented the miss automatically. That's Dev 6.
Chain-of-Thought Inside /validate
When /validate reports a FAIL you don't understand, ask for the reasoning explicitly — the same chain-of-thought move from core Module 3, aimed at your own implementation instead of an architecture decision:
"Walk through why criterion 3 failed step by step: 1. What did the acceptance criterion require? 2. What does the current code actually do? 3. Where exactly do they diverge? 4. What's the minimal fix?"
Drill — Turn a Correction into a Rule Candidate
Pick a correction you've made to a /plan or /validate output more than once this week. Write it as a rule the way Module 6 of the core program specifies — specific, verifiable, scoped — and hold onto it. You'll add it to AGENTS.md or knowledge/rules/coding-standards.md in Dev 6.
Bad rule: "Be careful with notification code."
Good rule: "Any change to notification-service.ts must also check
OrderToast.tsx and PushService.ts for the same event type
— all three subscribe to the same event bus."
Self-Check
- I can explain which parts of the Role/Context/Task/Format/Constraints structure are already baked into each EPAV skill.
- I can write a task-line argument specific enough for
/evaluateto load real context. - I can correct a
/planone gap at a time instead of re-running from scratch. - I recognize when a repeated correction means a rule is missing, not that I phrased something badly.
- I've drafted one rule candidate from a real correction this week.