doodledood User request: $ARGUMENTS
Systematically harden a /define task guidance file until manifests built from it produce deliverables that don't need iteration.
If no arguments, ask which task file to harden.
Context
Task files come in two parallel, decoupled sets, each keyed by task type and hardened for one-shot quality. Harden whichever set the target file belongs to:
/define's task files (claude-plugins/manifest-dev/skills/define/tasks/) carry encoder data:- Quality Gates — Verifiable output properties. Can split into baselines (always enforced) and selectable (meaningful rigor choices)
- Defaults — process practices always worth doing, carried into the manifest without probing;
/definedecides the encoding, and routes one whose violation would be unsafe or irreversible to a binding invariant rather than advice
- figure-out's task files (
claude-plugins/manifest-dev/skills/figure-out/tasks/) carry probing fuel:- Blind-spot probes — Non-natural angles the model skips by default (failure modes, pre-mortem fuel), phrased as the question that opens a branch
- Forced trade-offs — Competing tensions the model must drive to a decision
New items must match the depth and structural conventions of the owning skill (define/SKILL.md or figure-out/SKILL.md) and its existing sibling task files.
Goal
The task file should be comprehensive enough that a manifest built with it surfaces all criteria needed for one-shot quality — figure-out's probes surface the non-natural angles during understanding; /define's gates and Defaults encode the verifiable bar. "One-shot" = the deliverable passes review without iteration.
Log
Write findings to /tmp/harden-{timestamp}.md after each round. Read full log before each new round — prevents re-proposing rejected items and losing dimension context.
Per-round log structure:
## Round N
### Dimension Map
[dimension → items mapping]
### Gaps Found
[uncovered dimensions]
### Proposals
[item: accepted/rejected by user]
### Reviewer Findings
[finding: agree/disagree, applied/skipped]
Orthogonality Analysis
The core discipline. Map every item in the file to a dimension — an independent axis of concern. A dimension is a top-level concern like "evidence quality" or "audience fit"; items are specific checks within a dimension like "source credibility" or "cross-referencing". Two items share a dimension if improving one naturally helps the other.
User validates the dimension map before gap-filling begins. Gaps = dimensions with no coverage.
Examples of dimension sources: deliverable lifecycle (creation → review → use → maintenance), rejection triggers, wrongness vs incompleteness, base-rate failures for this task class, user interaction points.
If the first analysis finds no gaps, invoke the reviewer once and exit if clean — not every task file needs hardening.
Iteration Loop
Each iteration achieves:
- Gaps identified via orthogonality analysis
- Additions designed — invoke the prompt-engineering skill before proposing changes
- User-approved additions applied (all additions via AskUserQuestion)
- Quality validated — invoke the review-prompt skill on the task file after applying changes
- Reviewer findings evaluated critically — not all are valid. Present assessment with rationale; user decides
- Log updated after each round
Converged when criteria in Convergence section met.
Section Placement
Each item belongs in exactly one section, and a safety rule whose violation would be unsafe or irreversible is a Default even when verifiable — that clause wins over the Quality Gate (baseline) row below, which every safety rule also matches. A file holds only its own set's sections — a /define file never carries probes/trade-offs, a figure-out file never carries gates/Defaults:
| Section | Set | What it checks | Test |
|---|---|---|---|
| Quality Gate (baseline) | /define | Output property that should always be true | Would omitting this ever be acceptable? No → baseline, unless violating it would be unsafe or irreversible → Default |
| Quality Gate (selectable) | /define | Output property representing a meaningful rigor choice | Reasonable to skip for some tasks? Yes → selectable |
| Default | /define | Process practice always worth doing | Can't verify from output, or a safety rule whose violation would be unsafe or irreversible? → Default |
| Blind-spot probe | figure-out | A non-natural failure mode / pre-mortem angle the model skips by default | "Imagine this was rejected because..." AND a capable model wouldn't raise it unprompted? → probe |
| Forced trade-off | figure-out | Competing tension with no universal right answer | Both sides have legitimate merit? → trade-off |
A concern appears once, in its most natural section. When the same concern appears in multiple sections, keep the stronger version.
Principles
| Principle | Enforcement |
|---|---|
| Orthogonality over volume | Cover all dimensions, not all possible items within a dimension |
| User approves all changes | Propose via AskUserQuestion, never auto-add |
| Critical reviewer evaluation | Evaluate each finding independently — push back with rationale when wrong. When reviewer suggests items in already-covered dimensions, orthogonality wins |
| No redundancy across sections | Same concern in both risks and scenarios = pick one |
| Principles over thresholds | "Corroborated across independent sources" not "verified across 2+ sources" |
| No capability instructions | Don't prescribe verification methods — parent skill handles that |
| Match complexity to domain | Not every task file needs 17 quality gates — match depth to the diversity of ways the deliverable can fail |
Never
- Auto-add items without user approval
- Blindly apply all reviewer suggestions
- Add arbitrary numerical thresholds
- Prescribe verification methods (parent skill handles this)
- Re-propose items the user already rejected (check log)
Convergence
Done when:
- Orthogonality analysis finds no new uncovered dimensions
- Prompt reviewer finds no MEDIUM+ issues
- User confirms satisfaction