Minimalism

Minimalism — least code that fully works

Modelled on ponytail, which measures ~54% less code while keeping every safety property. The goal is the smallest correct delivery: fewer tokens, less code, fewer moving parts — never fewer guarantees. You still satisfy every acceptance criterion in full; you just refuse the scope, layers, and abstractions the ticket didn't ask for.

This is a lens, not a stage. Apply it while you implement (alongside plan-change and whatever build skill the ticket needs), and confirm it in self-review before submitting.

The four questions (ask in order, stop at the first that resolves it)

1. YAGNI — does this need to exist at all? Question the task before writing it. Delete speculative code paths, config knobs, options, and "future-proofing" nobody asked for. The cheapest line is the one you don't write. If a whole file/class/flag isn't required by an AC, it isn't in scope.
2. Standard library before custom code. Reach for what the language already ships (built-in collections, string/date/JSON utilities, iterators) before hand-rolling it. Don't reimplement what Array/Map/itertools/stdlib already does correctly.
3. Native platform features before a new dependency. Prefer what the runtime, framework, or browser already provides over adding a package. A new dependency is debt (supply chain, CVEs, build weight) and in this factory needs human approval anyway — flag it via mark_ticket_blocked rather than reaching for it reflexively.
4. One line before fifty. Favour the direct expression over the elaborate one: composition over a new class hierarchy, a function over a framework, a literal over a config system. Optimise for clarity and least surface area, not cleverness.

Intensity levels

Default is full. Pick the level the ticket's risk and ambiguity justify.

• lite — gentle nudge. Avoid obvious over-engineering and dead options; otherwise follow the repo's prevailing style even when it's verbose. Use for high-risk or unfamiliar code where matching convention matters more than trimming lines.
• full (default) — actively apply all four questions. Drop every layer, option, and abstraction not demanded by an AC. Prefer stdlib/native and the shortest correct form. This is the standard delivery posture.
• ultra — ruthless. Justify the existence of every file, dependency, and public symbol you add; collapse anything that can be collapsed without losing correctness or clarity. Use when the ticket explicitly asks for the most minimal possible change.

Rules

• NEVER weaken a safety guard to save lines. The factory's safety-hook.mjs, repo write/read boundaries, secret handling, authorization checks, and input validation are not "extra code" — they are guarantees. Minimalism removes redundancy, never protection. If shrinking code would drop a check, don't.
• Satisfy every acceptance criterion in full — minimal means least code, not least scope. Don't cut a requirement to look smaller.
• Don't sacrifice readability for raw character count: a clear short solution beats a cryptic shorter one. Self-documenting beats golfed.
• Still write the tests the ticket needs — test code is a guarantee, not bloat.
• Match the repo's existing conventions; minimalism trims your additions, it doesn't license a repo-wide rewrite or scope creep.
• When you decline to add something (a dependency, a layer, an option) for minimalism's sake and it was a real call, note it — request_decision at log_only keeps the tradeoff visible.