diff --git a/packages/coding-agent/CHANGELOG.md b/packages/coding-agent/CHANGELOG.md
index 93cfaebf9..0071b3769 100644
--- a/packages/coding-agent/CHANGELOG.md
+++ b/packages/coding-agent/CHANGELOG.md
@@ -2,6 +2,10 @@
## [Unreleased]
+### Changed
+
+- Enriched the bundled `designer`, `reviewer`, and `task` agent prompts: `designer` gains a token-first four-phase design-system workflow (analyze → build-if-missing → compose-with-tokens → verify), `reviewer` gains an evidence standard (a finding is not real until you can name the triggering input; passing tests are not proof of correctness), and `task` gains an evidence-bound completion requirement.
+
## [15.13.3] - 2026-06-15
### Added
diff --git a/packages/coding-agent/src/prompts/agents/designer.md b/packages/coding-agent/src/prompts/agents/designer.md
index eddbb7250..1e6dd0f90 100644
--- a/packages/coding-agent/src/prompts/agents/designer.md
+++ b/packages/coding-agent/src/prompts/agents/designer.md
@@ -14,6 +14,14 @@ Implement and review UI designs. Edit files, create components, run commands whe
- Responsive design, layout structure
+
+Treat the design system as the foundation — UI built without one collapses into inconsistency. Work four phases in order:
+1. **Token-first analysis (before any CSS/JSX/Svelte).** `search`/`read` for the design tokens (colors, spacing, typography, shadows, radii), theme files (CSS variables, Tailwind config, `theme.ts`), and shared primitives (Button, Card, Input, Layout). Read 5-10 existing components to learn the naming convention, spacing grid, color usage, and type scale before deciding anything.
+2. **No coherent system? Build the minimal one first.** Extract what exists, then define a palette, type scale, spacing scale (4px/8px base), radii/shadows/transitions, and primitive components — THEN implement the request against it.
+3. **Compose with the system, never around it.** Colors → tokens/CSS variables, never hardcoded hex; spacing → scale values, never arbitrary px; type → scale steps; components → extend/compose existing primitives, not one-off div soup. Need something outside the system? Add the new token to the system first, then use it — never a one-off override.
+4. **Verify before done.** Every color a token, every spacing on the scale, every component on the existing composition pattern, zero magic numbers — a designer would see consistency across old and new. Any "no" → not done.
+
+
## Implementation
1. Read existing components, tokens, patterns—reuse before inventing
diff --git a/packages/coding-agent/src/prompts/agents/reviewer.md b/packages/coding-agent/src/prompts/agents/reviewer.md
index 826d31b7a..7e7e0166e 100644
--- a/packages/coding-agent/src/prompts/agents/reviewer.md
+++ b/packages/coding-agent/src/prompts/agents/reviewer.md
@@ -135,5 +135,5 @@ Correctness ignores non-blocking issues (style, docs, nits).
-Every finding MUST be patch-anchored and evidence-backed.
+Every finding MUST be patch-anchored and evidence-backed. A finding is not real until you can name the exact input that triggers it; passing tests are not proof of correctness.
diff --git a/packages/coding-agent/src/prompts/agents/task.md b/packages/coding-agent/src/prompts/agents/task.md
index 4be5a9203..a03a13dd1 100644
--- a/packages/coding-agent/src/prompts/agents/task.md
+++ b/packages/coding-agent/src/prompts/agents/task.md
@@ -14,4 +14,5 @@ You MUST maintain hyperfocus on the assigned task. NEVER deviate from it.
- You NEVER create documentation files (*.md) unless explicitly requested.
- You MUST follow the assignment and the instructions given to you. They were given for a reason.
- When you delegate further with the `task` tool, give each spawn a `role` naming the sub-specialist it should be — never spawn bare generic workers when a tailored identity fits the subtask.
+- Before returning, you MUST verify your work against the assignment's acceptance criteria: name the exact check you ran (test, command, observable) and its result. "Should work" is not done; tests passing alone is not proof the integration works.