DesignAgent Guardrails (Contract Compliance)
These are hard constraints. Do NOT violate:
- Do not skip any step in contract.json entry.steps
- Do not merge or reorder output sections
- Do not invent data or hallucinate facts
- Do not execute outside the defined step order
- If input is incomplete, ask only for missing required fields
name: 07-learn
description: "Use after delivery — verify the work against the brief, audit for quality and consistency, document insights, and close the project."
07-Learn: Verify and Archive
Overview
The final step in the linear workflow. Before calling a project complete, verify that the delivered work meets the design brief, quality standards, and success criteria. Then archive what was learned so future projects benefit. This combines verification (what was formerly design-verify) with project closure and retrospectives (what was formerly finishing-a-design-project).
Non-Negotiable Rule
HARD GATE: Verify against the original design brief AND complete the phase-by-phase execution audit before declaring the project complete. "It looks good" is not verification. Every criterion must be checked. Every phase's Hard Gate must survive cross-examination.
When To Use
- After delivery is complete (06-deliver done)
- Before calling ANY project "done"
When NOT To Use
- Mid-project (verification happens at the end, not in the middle)
- When the project was abandoned (still verify what was delivered)
- "It's a small project, I'll skip it" → small projects need verification most — they hide the biggest assumptions
Process
1. Verify Against the Brief
- Review each success criterion from intake and the design brief
- Check: does the delivered work solve the stated problem?
- Check: does it respect all documented constraints?
- Check: does it meet all non-negotiables?
- Score: meets, partially meets, or does not meet — for each criterion
2. Phase-by-Phase Execution Audit
This is not a checklist. This is cross-examination — for each A-layer phase, compare what Verification claimed at the time against what the actual deliverables contain. The goal is to catch checkboxes that were ticked but hollow: the mark says done, but the work doesn't satisfy that phase's Hard Gate.
How to Audit
For each phase that was executed, fill one row (6 columns required — evidence is not optional):
| Phase |
Hard Gate |
Verification Claimed |
What the Deliverables Actually Contain |
Verdict |
Evidence (Step ID + Section + Snippet) |
| 01-intake |
Complete intake before any design phase |
e.g., ✓ Brief captured, stakeholder identified, ≥3 constraints |
e.g., Brief is one sentence, no stakeholder role named, constraints = "budget" with no number |
✓ / ⚠ / ✗ |
01-intake / section 1: "..." |
| 02-discover |
Research synthesis AND written brief before any concepts |
e.g., ✓ ≥3 pain points, ≥2 competitors mapped, brief written |
e.g., Pain points are generic, competitor section names companies with no analysis, brief missing out-of-scope |
✓ / ⚠ / ✗ |
02-discover / section 5: "..." |
| 03-strategy |
Strategy defined and approved before concept generation |
e.g., ✓ ≥3 evaluation criteria, guardrails documented, strategy approved |
e.g., Criteria are "looks premium, feels modern" — vague adjectives, no approval record |
✓ / ⚠ / ✗ |
03-strategy / section 2: "..." |
| 04-generate |
≥3 distinct directions before converging |
e.g., ✓ 3 directions generated, concept matrix completed, ≥1 prototype tested |
e.g., Directions share same concept with different colors, matrix has empty cells, no prototype evidence |
✓ / ⚠ / ✗ |
04-generate / section 1: "..." |
| 05-review |
At least one structured review against brief and criteria |
e.g., ✓ Self-review done, external reviewer gave feedback, stakeholder review conducted |
e.g., Feedback is only "looks good," no criteria-based assessment, no change documentation |
✓ / ⚠ / ✗ |
05-review / section 3: "..." |
| 06-deliver |
Delivery checklist completed before any file leaves |
e.g., ✓ Assets exported, specs written, handoff documented, receipt confirmed |
e.g., Files exported but no written specs, no naming convention, no receipt confirmation |
✓ / ⚠ / ✗ |
06-deliver / section 2: "..." |
Verdict Definitions
| Mark |
Meaning |
Action |
| ✓ |
Verification claim matches deliverable substance. Hard Gate satisfied. |
Proceed. |
| ⚠ |
Verification claimed done, but deliverable is hollow — the answer exists but lacks the substance that phase requires. |
Return to that phase and fill the gap before the project is complete. |
| ✗ |
Verification claimed done, but the Hard Gate is clearly not met. The phase was never properly executed. |
The project is blocked. Return to that phase and execute it properly. |
Audit Rules
- Scope: Only audit the phases the project actually used (Lite skips phases; don't audit skipped phases).
- Focus: Only audit the Verification items that directly relate to the Hard Gate — not every checkbox.
- Lite mode allowance: In Lite mode, a ⚠ may be acceptable if the user explicitly traded depth for speed. Document the trade-off.
- Zero-tolerance for ✗: A Hard Gate that was claimed met but clearly wasn't means the audit failed. The project is not complete.
- Document the audit: The filled table is part of the project record. Do not skip writing it down.
Evidence Binding (MANDATORY)
Every audit verdict MUST be backed by explicit evidence. Summary-only validation is not acceptable. Completion cannot be declared without traceable proof.
Each audit row must cite:
| Required Evidence |
What It Means |
Example |
| Step ID |
Which phase is being audited |
03-strategy |
| Skill section |
Where in that skill's output the evidence lives |
03-strategy / section 2: Design Criteria |
| Artifact snippet |
A concrete fragment from the actual deliverable — not a paraphrase, not a summary |
"Target audience: young urban professionals aged 25–35, prefer clean interfaces, trust premium pricing" |
Rules:
- No evidence citation → verdict is invalid. Re-audit with evidence.
- Paraphrasing "it says something about the audience" does not count as a snippet. Quote or it didn't happen.
- If the artifact doesn't exist at all → verdict is automatically ⚠ (hollow) or ✗ (missing), depending on whether some form of answer was attempted.
- Evidence comparison: the "Verification Claimed" column vs. the "Artifact Snippet" column — do they match? If the claim says "≥3 evaluation criteria defined" but the snippet shows "looks premium, feels modern" (2 vague adjectives), the verdict is ⚠.
What evidence looks like in the audit table:
| Phase |
Hard Gate |
Verification Claimed |
What the Deliverables Actually Contain |
Verdict |
Evidence |
| 03-strategy |
Strategy defined and approved before concept generation |
✓ ≥3 evaluation criteria documented |
"1. looks premium 2. feels modern" — 2 vague bullets, no source cited |
⚠ |
03-strategy / section 2: no third criterion written, no approval record in project artifacts |
The Evidence column replaces weak judgments with traceable facts. A ⚠ or ✗ without evidence is itself a hollow verdict.
Audit Conclusion
After filling the table:
- All ✓ → Audit passed. Proceed to Quality Audit.
- One or more ⚠ → Fix the gaps, re-audit the affected phases, then proceed.
- One or more ✗ → Audit failed. Go back to the failing phase. The project is not complete until all ✗ are resolved.
Conflict Resolution Audit (additional check):
Before concluding, verify that every conflict detected during the project (in 03-strategy and 05-review) was resolved with a written Conflict Resolution Block. Unresolved or undocumented conflicts = audit failure.
3. Quality Audit
- Visual consistency: colors, typography, spacing, alignment
- Technical accuracy: correct formats, resolutions, color profiles
- Accessibility: contrast, readability, inclusive language
- If brand work: check brand guidelines compliance
- If digital: check responsive behavior, states, interactions
4. Ethics and Responsibility Check
- Representation: does this design represent its audience respectfully?
- Dark patterns: no manipulative or deceptive patterns
- Cultural sensitivity: no appropriation or stereotyping
- Environmental: consider sustainability of materials, data, or production
5. Project Retrospective
- What went well? (capture for reuse)
- What could have gone better? (capture for improvement)
- What would you do differently next time?
- What reusable assets were created? (templates, prompts, patterns, components)
6. Archive and Close
- Archive: research, brief, strategy, concepts, prototypes, final files, specs
- Document: lessons learned, reusable assets, design decisions log
- Close: notify stakeholders, celebrate completion
- Update your portfolio or case study if applicable
Rationalization Prevention
| Excuse |
Reality |
| "The client approved it, so it's fine" |
Client approval is not verification. Check against the brief. |
| "I'm too tired, I'll check it tomorrow" |
Tomorrow you will be on another project. Check now. |
| "It doesn't need an audit, it's a small project" |
Small projects hide the biggest assumptions. Verify. |
| "I'll remember what I learned" |
You won't. Write it down. |
| "I ran the audit and everything looked fine — I don't need to write it down" |
Memory is not an audit trail. Write the filled audit table. The act of writing reveals hollow checkboxes. |
| "The earlier phases all marked ✓, so the audit is just confirming what I already know" |
Self-reported ✓ is exactly what the audit exists to challenge. If you trust your own marks, you've missed the point of the audit. |
Red Flags
- You skipped verification because "it's done"
- The brief is not referenced in the final review
- Lessons are not documented
- Reusable assets are sitting in a project folder no one will find
- You are moving on to the next project without closing this one
- The execution audit table is empty or was not filled
- You filled the audit table but every row is ✓ — statistically unlikely. Re-examine.
- You found a ⚠ or ✗ but rationalized it as "close enough"
- You accepted your own Verification marks without cross-checking against actual deliverables
Verification
→ Project complete. Start a new project by invoking using-designagent.
1---2name: 07-learn3description: DesignAgent Guardrails (Contract Compliance)4---5## DesignAgent Guardrails (Contract Compliance)67These are hard constraints. Do NOT violate:89- Do not skip any step in contract.json entry.steps10- Do not merge or reorder output sections11- Do not invent data or hallucinate facts12- Do not execute outside the defined step order13- If input is incomplete, ask only for missing required fields1415---16name: 07-learn17description: "Use after delivery — verify the work against the brief, audit for quality and consistency, document insights, and close the project."18---1920# 07-Learn: Verify and Archive2122## Overview23The final step in the linear workflow. Before calling a project complete, verify that the delivered work meets the design brief, quality standards, and success criteria. Then archive what was learned so future projects benefit. This combines verification (what was formerly design-verify) with project closure and retrospectives (what was formerly finishing-a-design-project).2425## Non-Negotiable Rule26**HARD GATE: Verify against the original design brief AND complete the phase-by-phase execution audit before declaring the project complete.** "It looks good" is not verification. Every criterion must be checked. Every phase's Hard Gate must survive cross-examination.2728## When To Use29- After delivery is complete (06-deliver done)30- Before calling ANY project "done"3132## When NOT To Use33- Mid-project (verification happens at the end, not in the middle)34- When the project was abandoned (still verify what was delivered)35- "It's a small project, I'll skip it" → small projects need verification most — they hide the biggest assumptions3637## Process3839### 1. Verify Against the Brief40- Review each success criterion from intake and the design brief41- Check: does the delivered work solve the stated problem?42- Check: does it respect all documented constraints?43- Check: does it meet all non-negotiables?44- Score: meets, partially meets, or does not meet — for each criterion4546### 2. Phase-by-Phase Execution Audit4748This is not a checklist. This is cross-examination — for each A-layer phase, compare what Verification claimed at the time against what the actual deliverables contain. The goal is to catch checkboxes that were ticked but hollow: the mark says done, but the work doesn't satisfy that phase's Hard Gate.4950#### How to Audit5152For each phase that was executed, fill one row (6 columns required — evidence is not optional):5354| Phase | Hard Gate | Verification Claimed | What the Deliverables Actually Contain | Verdict | Evidence (Step ID + Section + Snippet) |55|-------|-----------|---------------------|--------------------------------------|---------|----------------------------------------|56| 01-intake | Complete intake before any design phase | e.g., ✓ Brief captured, stakeholder identified, ≥3 constraints | e.g., Brief is one sentence, no stakeholder role named, constraints = "budget" with no number | ✓ / ⚠ / ✗ | 01-intake / section 1: "..." |57| 02-discover | Research synthesis AND written brief before any concepts | e.g., ✓ ≥3 pain points, ≥2 competitors mapped, brief written | e.g., Pain points are generic, competitor section names companies with no analysis, brief missing out-of-scope | ✓ / ⚠ / ✗ | 02-discover / section 5: "..." |58| 03-strategy | Strategy defined and approved before concept generation | e.g., ✓ ≥3 evaluation criteria, guardrails documented, strategy approved | e.g., Criteria are "looks premium, feels modern" — vague adjectives, no approval record | ✓ / ⚠ / ✗ | 03-strategy / section 2: "..." |59| 04-generate | ≥3 distinct directions before converging | e.g., ✓ 3 directions generated, concept matrix completed, ≥1 prototype tested | e.g., Directions share same concept with different colors, matrix has empty cells, no prototype evidence | ✓ / ⚠ / ✗ | 04-generate / section 1: "..." |60| 05-review | At least one structured review against brief and criteria | e.g., ✓ Self-review done, external reviewer gave feedback, stakeholder review conducted | e.g., Feedback is only "looks good," no criteria-based assessment, no change documentation | ✓ / ⚠ / ✗ | 05-review / section 3: "..." |61| 06-deliver | Delivery checklist completed before any file leaves | e.g., ✓ Assets exported, specs written, handoff documented, receipt confirmed | e.g., Files exported but no written specs, no naming convention, no receipt confirmation | ✓ / ⚠ / ✗ | 06-deliver / section 2: "..." |6263#### Verdict Definitions6465| Mark | Meaning | Action |66|------|---------|--------|67| ✓ | Verification claim matches deliverable substance. Hard Gate satisfied. | Proceed. |68| ⚠ | Verification claimed done, but deliverable is hollow — the answer exists but lacks the substance that phase requires. | Return to that phase and fill the gap before the project is complete. |69| ✗ | Verification claimed done, but the Hard Gate is clearly not met. The phase was never properly executed. | The project is blocked. Return to that phase and execute it properly. |7071#### Audit Rules7273- **Scope**: Only audit the phases the project actually used (Lite skips phases; don't audit skipped phases).74- **Focus**: Only audit the Verification items that directly relate to the Hard Gate — not every checkbox.75- **Lite mode allowance**: In Lite mode, a ⚠ may be acceptable if the user explicitly traded depth for speed. Document the trade-off.76- **Zero-tolerance for ✗**: A Hard Gate that was claimed met but clearly wasn't means the audit failed. The project is not complete.77- **Document the audit**: The filled table is part of the project record. Do not skip writing it down.7879#### Evidence Binding (MANDATORY)8081Every audit verdict MUST be backed by explicit evidence. Summary-only validation is not acceptable. Completion cannot be declared without traceable proof.8283Each audit row must cite:8485| Required Evidence | What It Means | Example |86|-------------------|---------------|---------|87| **Step ID** | Which phase is being audited | 03-strategy |88| **Skill section** | Where in that skill's output the evidence lives | 03-strategy / section 2: Design Criteria |89| **Artifact snippet** | A concrete fragment from the actual deliverable — not a paraphrase, not a summary | "Target audience: young urban professionals aged 25–35, prefer clean interfaces, trust premium pricing" |9091**Rules:**92- No evidence citation → verdict is invalid. Re-audit with evidence.93- Paraphrasing "it says something about the audience" does not count as a snippet. Quote or it didn't happen.94- If the artifact doesn't exist at all → verdict is automatically ⚠ (hollow) or ✗ (missing), depending on whether some form of answer was attempted.95- Evidence comparison: the "Verification Claimed" column vs. the "Artifact Snippet" column — do they match? If the claim says "≥3 evaluation criteria defined" but the snippet shows "looks premium, feels modern" (2 vague adjectives), the verdict is ⚠.9697**What evidence looks like in the audit table:**9899| Phase | Hard Gate | Verification Claimed | What the Deliverables Actually Contain | Verdict | Evidence |100|-------|-----------|---------------------|--------------------------------------|---------|----------|101| 03-strategy | Strategy defined and approved before concept generation | ✓ ≥3 evaluation criteria documented | "1. looks premium 2. feels modern" — 2 vague bullets, no source cited | ⚠ | 03-strategy / section 2: no third criterion written, no approval record in project artifacts |102103The Evidence column replaces weak judgments with traceable facts. A ⚠ or ✗ without evidence is itself a hollow verdict.104105#### Audit Conclusion106107After filling the table:108109- **All ✓** → Audit passed. Proceed to Quality Audit.110- **One or more ⚠** → Fix the gaps, re-audit the affected phases, then proceed.111- **One or more ✗** → Audit failed. Go back to the failing phase. The project is not complete until all ✗ are resolved.112113**Conflict Resolution Audit (additional check):**114115Before concluding, verify that every conflict detected during the project (in 03-strategy and 05-review) was resolved with a written Conflict Resolution Block. Unresolved or undocumented conflicts = audit failure.116117- [ ] Every conflict that surfaced in 03-strategy has a Resolution Block with Decision + Reason + Tradeoff118- [ ] Every conflict that surfaced in 05-review has a Resolution Block with Decision + Reason + Tradeoff119- [ ] No conflict was silently merged or ignored — check the 05-review "Iterate and Document" section120- [ ] Decision Log entries align with conflict resolutions (no Conflict Block says "chose A" but Decision Log says "selected B")121122### 3. Quality Audit123- Visual consistency: colors, typography, spacing, alignment124- Technical accuracy: correct formats, resolutions, color profiles125- Accessibility: contrast, readability, inclusive language126- If brand work: check brand guidelines compliance127- If digital: check responsive behavior, states, interactions128129### 4. Ethics and Responsibility Check130- Representation: does this design represent its audience respectfully?131- Dark patterns: no manipulative or deceptive patterns132- Cultural sensitivity: no appropriation or stereotyping133- Environmental: consider sustainability of materials, data, or production134135### 5. Project Retrospective136- What went well? (capture for reuse)137- What could have gone better? (capture for improvement)138- What would you do differently next time?139- What reusable assets were created? (templates, prompts, patterns, components)140141### 6. Archive and Close142- Archive: research, brief, strategy, concepts, prototypes, final files, specs143- Document: lessons learned, reusable assets, design decisions log144- Close: notify stakeholders, celebrate completion145- Update your portfolio or case study if applicable146147## Rationalization Prevention148149| Excuse | Reality |150|--------|---------|151| "The client approved it, so it's fine" | Client approval is not verification. Check against the brief. |152| "I'm too tired, I'll check it tomorrow" | Tomorrow you will be on another project. Check now. |153| "It doesn't need an audit, it's a small project" | Small projects hide the biggest assumptions. Verify. |154| "I'll remember what I learned" | You won't. Write it down. |155| "I ran the audit and everything looked fine — I don't need to write it down" | Memory is not an audit trail. Write the filled audit table. The act of writing reveals hollow checkboxes. |156| "The earlier phases all marked ✓, so the audit is just confirming what I already know" | Self-reported ✓ is exactly what the audit exists to challenge. If you trust your own marks, you've missed the point of the audit. |157158## Red Flags159- You skipped verification because "it's done"160- The brief is not referenced in the final review161- Lessons are not documented162- Reusable assets are sitting in a project folder no one will find163- You are moving on to the next project without closing this one164- The execution audit table is empty or was not filled165- You filled the audit table but every row is ✓ — statistically unlikely. Re-examine.166- You found a ⚠ or ✗ but rationalized it as "close enough"167- You accepted your own Verification marks without cross-checking against actual deliverables168169## Verification170- [ ] Each success criterion checked: meets / partially meets / does not meet171- [ ] Phase-by-phase execution audit table filled for every executed phase172- [ ] All ✗ verdicts resolved (phase re-executed and re-audited)173- [ ] All ⚠ verdicts resolved or explicitly documented as accepted trade-offs174- [ ] Quality audit completed (visual, technical, accessibility)175- [ ] Ethics and responsibility check completed176- [ ] Retrospective written (what went well, what to improve)177- [ ] Reusable assets extracted and documented178- [ ] Project materials archived179- [ ] Project formally closed with stakeholder notification180181→ Project complete. Start a new project by invoking **using-designagent**.
ahaoai