greenfield

Established rules harden into "hard truths" that design the project into corners long after their reasons died. This skill inverts the usual order: design first as if the rules didn't exist, then put only the colliding rules on trial. The best design is the primary deliverable; the rule audit is a light byproduct — never let it dominate the run's time or tokens.

Two failure modes to hold off simultaneously: anchoring (a session immersed in repo patterns produces the status quo with a new coat of paint — the greenfield frame exists to fight this) and laundering (the designer wants its design to win, so every inconvenient rule becomes "outdated" — the origin test exists to fight this).

Quick tier (default) — inline, no subagent

Run this yourself, in-session; it should work as a short detour mid-task.

1. Ground. If the session doesn't already hold the problem's context, get what it needs first — read the relevant docs/code rather than designing from guesses. Proportionate to the question; grounding is not the deliverable.
2. Greenfield design. Reframe the problem as if building fresh — same product goal, data shapes, scale, and security invariants; no inherited patterns, conventions, or "how we do it here". Sketch up to 2 genuinely distinct approaches — or 1 plus a sentence on why nothing else is close (forced second options are filler). Pick the winner on the merits.
3. Collision report. List every established rule, pattern, or convention the winner breaks. You know them; report honestly — a hidden collision defeats the whole exercise.
4. Origin test per collision (~30s each): "this rule prevents Y; Y is no longer real because Z" — the verdict must be about the rule's job, never the design's convenience. Verdicts: outdated / still load-bearing (bend the design, note the cost) / uncertain. Uncertain never stalls the run: log it as an open question and proceed on best judgment.
5. Edits. Rules judged outdated get edited where they live, in the current working tree, disclosed in the final message (and PR body if one is in flight) — but only ordinary-convention-class rules. Escalation classes (below) always stop for the operator's approval — ask the user.

Deep tier (--deep) — for architecture-level stakes

When status-quo anchoring would poison the answer, buy structural blindness (~10–15 min):

1. Sanitize. Distill a repo-agnostic problem brief — product goal, data shapes, scale, latency/cost envelope, security invariants, plus minimal code excerpts — into a pack in the session scratchpad. Banned in the brief: naming any current pattern, library choice, or architecture as a requirement; if it's load-bearing, state the underlying constraint instead.
2. Blind design. Spawn a subagent on your strongest model whose context is ONLY the pack — it never opens the repo or its instruction files. It returns 2–3 distinct candidates with trade-offs and its pick.
3. Independent adjudication. Spawn a fresh judgment agent with the winning design + the repo's rule surfaces: map collisions, and for each do real archaeology — the rule's recorded rationale, the git history that born it, whether the guarded failure still exists.
4. Propose, never auto-edit. Deliver the verdict table; every rule change waits for the user's approval, then lands where the rule lives.

Rule surfaces and escalation (repo-adaptive)

Discover at runtime: the repo's agent instruction files (CLAUDE.md / AGENTS.md and what they cite), any rules directory, and any decision registry. Respect the repo's own severity scheme where one exists (e.g. Quirk's [security]/[infra] tags and its locked-decisions registry). Always-escalate, no tier exception: security- or infra-class rules, entries in a locked/decision registry (never edit these — surface them as challenges), and anything recorded as an operator decision. In repos without a severity scheme, treat rules touching auth, secrets, data exposure, or money as escalation-class by default.

Report (turn-final, both tiers)

• Design: the winner and why; runner-up in one line.
• Collisions: table — rule → verdict → origin-test sentence.
• Edits made (quick) or proposed (deep), each with its file.
• Open questions: uncertain collisions and anything escalated.