AI-Assisted Development with /apply
The task CSV is the prompt. /apply is two words: "Plan approved."
Module Overview
This is the Dev Track's equivalent of Module 5 — where the artifact chain becomes working software. Everything in Dev 2 through Dev 4 exists to make this module boring: by the time you type /apply, the plan is approved, the context is loaded, and the acceptance criteria are already sitting in the CSV waiting for /validate to walk through them one at a time.
| At a glance | |
|---|---|
| Covers | Running EPAV against a real Dev Task; reading /apply's output; using reviewer skills as a Stage 3 pass; contributing patterns back to knowledge/ |
| When it runs | Every task, every sprint — the bulk of Day 1 |
| Builds on | Dev 1 (the scaffold), Dev 2 (the cycle), Dev 4 (context) |
| Leads into | Dev 6 — encoding what you learn as a rule, agent, or skill |
What you'll produce
Merged code implementing your Dev Tasks, with tests derived from acceptance criteria, a clean read-only reviewer pass, and at least one contribution to knowledge/patterns/ or knowledge/rules/ from something you learned while implementing.
The Loop Doesn't Change — the Effort Does
Core Module 5's central point was that a well-loaded APPLY prompt is two lines: "Plan approved. Implement TASK-XXX. Follow AGENTS.md." nexus makes that literal — /apply takes no argument at all. Everything it needs (the approved plan from /plan, the coding standards from AGENTS.md, the task's acceptance criteria from the CSV) is already in context.
| Step | What you type | Where the substance comes from |
|---|---|---|
| EVALUATE | /evaluate TASK-011 | CSV row, AGENTS.md, arch doc, knowledge/, the graph |
| PLAN | /plan | The EVALUATE summary + blast-radius check |
| APPLY | /apply | The approved plan — nothing else to say |
| VALIDATE | /validate | The CSV's acceptance_criteria field, checked one by one |
If you're typing a lot at /apply, something upstream was thin
Same diagnostic as the core program: if you find yourself re-explaining requirements at the APPLY step, the CSV's acceptance criteria were incomplete, or /plan didn't actually get approved before you moved on. Fix the upstream artifact, don't compensate at APPLY.
TASK-011 is a real row
It's the leave-request submission task from the Dev Track's sample project Dev Tasks (introduced in Dev 1, walked through with TASK-014 in Dev 2), three acceptance criteria — a valid submission, a rejected bad date range, and an over-balance warning that doesn't block submission. Run /evaluate TASK-011 against your own copy of the sample project to see this for real.
Stage 3 — The Reviewer Skills
Beyond the four EPAV skills, nexus init installs five read-only reviewer skills and matching subagents — the built-in equivalent of the core program's Module 5 "Code Review" recurring pattern, already scoped and formatted.
| Skill / agent | Reviews for |
|---|---|
| /code-review, @code-reviewer | Bugs, security, error handling, complexity, duplication, type safety, performance, maintainability |
| /database-review, @database-reviewer | Schema design, migrations, query/index issues, transaction safety |
| /deployment-review, @deployment-reviewer | CI/CD, Docker/Kubernetes config, infrastructure risk |
| /monitoring-review, @monitoring-reviewer | Observability gaps, logging, alerting, error tracking |
| /performance-review, @performance-reviewer | Response time, caching, bundle size, query performance |
The code reviewer's output format is fixed and machine-checkable: a Repo Context block, then a JSON findings block with a blocked flag that flips true the moment any finding is critical severity — a mechanical version of the core program's "no unresolved Critical or High findings" Sprint 1 Readiness gate criterion.
{
"blocked": false,
"overall_severity": "medium",
"summary": "TASK-011 endpoint logic is correct; one date-range validation gap.",
"findings": [
{ "id": "CR-001", "severity": "medium", "category": "error-handling",
"file": "src/app/api/leave-requests/route.ts", "line": 28,
"title": "end_date before start_date not rejected before the insert",
"description": "PRD US-01 AC2 requires this to be a validation error with no row created; currently the DB insert runs first, then fails on a check constraint.",
"suggestion": "Validate the date range in the route handler before calling the DB, per AC2." }
]
}
Reviewers are read-only
These agents discover repo context, run the checklist, and report — they never edit files themselves. That's the same "read and report" autonomy level Module 6 of the core program teaches for audit-type agents: full autonomy to analyze, none to act.
Contributing Back
The core program's knowledge-contribution habit is built into /validate's own steps — step 5 explicitly prompts you to append a discovered pattern to knowledge/patterns/ or a rule to knowledge/rules/coding-standards.md before the task is marked complete. This repo's own knowledge/patterns/ holds real examples worth reading before writing your own: cli-doctor-checks.md, rich-markup-escaping.md, and version-check-banner.md — each a specific implementation pattern captured the first time it was needed, so the second time is faster.
| What you discovered | Where it goes |
|---|---|
| A reusable implementation pattern | knowledge/patterns/ |
| A coding rule learned the hard way | knowledge/rules/ |
| A task-specific prompt refinement | knowledge/prompts/dev/ |
| A backlog item surfaced mid-task | knowledge/retros/ |
Self-Check
- I can run a full EPAV cycle on a real Dev Task with a two-word APPLY prompt.
- I know which reviewer skill to reach for and that none of them edit files.
- I understand the
blockedflag and what severity triggers it. - I've read at least one existing file in
knowledge/patterns/before writing my own. - I've contributed one pattern or rule back after finishing a task.