Study → Design → Verify

Turn "how should this work?" into a recommendation that survives scrutiny, by separating three jobs that corrupt each other when one mind does them at once: gathering facts, proposing designs, and attacking designs. Each phase is staffed by agents who only do that one job.

The output is an advisory document: problems ranked by business pain, a phased plan, explicit "do NOT do X because Y" entries, and an evidence trail a skeptic can audit.

When to invoke

"How should A convert/map/migrate/sync to B?" · "study my business, then advise" · "what's the right design for [change to an existing system]?" · "should we copy, link, or recalculate this data?" · "review this integration plan against reality" · build-vs-extend questions about an existing flow. If the answer should change when the real system contradicts the docs, this skill applies.

Principles (the why)

1. Conclusions, not raw text. One context window can't hold the wiki, two codebases, and a live schema. Fan out readers with fresh contexts; keep only their structured findings. You are the orchestrator, not the reader.
2. Structured findings beat prose. Force every reader through a JSON schema (summary, keyFindings with citations, openQuestions). Schema-shaped facts can be merged, diffed, and verified; prose can only be trusted.
3. The live system outranks the docs. Documentation states conventions; only the live system shows whether they're implemented. Real example of the failure mode: a documented "placeholder records are kept Inactive" convention where every live placeholder was Active — two of three designs built on the fiction. Always check the convention, not just the doc.
4. Usage data settles arguments. "Is bucket X dead?" / "does anyone use field Y?" are queries, not opinions. A design that maps into a never-used category, or drops a heavily-used one, is wrong in a way only live counts reveal. Every number in the study carries the query that produced it.
5. Independent designs beat one design iterated. Designers who can see each other converge on shared blind spots. Give the same study digest to designers with conflicting value systems and let the differences surface the real trade-offs.
6. Plausible-but-wrong is THE failure mode of AI advice. Designs reference fields that don't exist, assume single sources of truth that are actually duplicated, and inherit errors from the study digest. The adversarial pass is not optional polish — in practice it catches wrong field sources, misdescribed value lists, and unimplemented conventions in every run.
7. Read-only, with receipts. A study never writes to a live system — GET/SELECT only, stated as a hard rule in every agent prompt. Raw query output is saved to an evidence folder (tmp/advice-study/ or similar) so a human can audit what was looked at.