CONCEPTS
Design philosophy
Understand the task well enough to implement safely. Write the smallest clear change at the right boundary. Prove it works with fresh evidence. Make the docs match the facts.
Three failure modes this corrects
Ceremony everywhere
General workflow packages force every task through planning, TDD, worktrees, subagents, and release rituals. Hard tasks improve slightly while ordinary work gets slower and more fragile. Here, simple tasks are handled directly and full workflows load only on explicit request.
Lost multi-turn context
Answers, approvals, corrections, and reports of omitted acceptance items stay inside the same task context. There is no need to invoke the entry point again halfway through.
Clarification mistaken for approval
Independent questions are asked in one batch, dependent ones follow in order, and answering a question never authorizes code. Approval is a separate, explicit act.
Two layers, on purpose
Cost and control are separated. The always-on layer is small enough to be free; the expensive layer is opt-in.
Minimal Engineering Core
A minimal set of engineering, completion, and safety rules is injected at session boundaries — start, resume, and compaction. No planning, TDD, worktree, or release ceremony is included.
Five full workflows
A full workflow changes the shape and cost of the whole session, so it loads only when you name it — and then stays active at task level until the task ends.
The develop lifecycle
Develop is the only workflow with a human gate in the middle. Alignment happens before approval; implementation and verification happen after it. A material scope change returns to alignment; an omitted accepted behavior reopens implementation.
Why nothing triggers automatically
Auto-triggering was built, measured, and removed. Both experiments are recorded in the project’s benchmark log.
The auto-loaded design skill
Loading code-design automatically scored 100% trigger precision, but produced no outcome benefit: duration +34.6%, tool calls +75%, input tokens +76.9%. The cost was real and the benefit was not, so it became user-invoked.
The auto-triggered diagnosis
Even after narrowing the description, the model still routed an unrelated policy change into diagnosis. Negative wording is not a deterministic boundary, so every workflow became explicit and only a minimal core stays automatic.
The maintainable-code standard
The objective is minimum necessary complexity — not minimum syntax, and not minimum line count. Every workflow that touches design applies the same list.
- Familiar
- Established in the repository or idiomatic in the language and framework.
- Explicit
- Control flow, state changes, failures, and external effects are visible.
- Local
- A maintainer can change behavior without tracing unrelated modules.
- Named
- Intermediate concepts carry domain meaning instead of being compressed into expressions.
- Debuggable
- Meaningful steps can be inspected, logged, and given breakpoints.
- Change-resilient
- One rule has one authoritative owner; related behavior changes together.
- Boring
- It avoids novelty that exists only to reduce lines or show off language cleverness.
Explicit non-goals
- Owning issue tracking, branching, pull requests, or release management.
- Requiring worktrees, subagents, saved plans, or commits for every task.
- Replacing an established project documentation layout.
- Enforcing a universal language style guide.
- Optimizing for minimum lines of code.
- Requiring unit tests where they provide no useful feedback.