Principles

Read this index at task start. Each entry gives the principle, then when to use it. Read the reference file in full for any principle you apply. When the user invokes this skill explicitly, at least one principle (likely more) applies: read each of them in full.

Stay within the assignment: in a review, report findings; in design, bring the whole design and state your calls; make changes when authorized. When principles pull in different directions, let the job and its real constraints decide.

Explain important choices and why they help. Name a principle when that makes the explanation clearer.

Thinking principles apply to all work: read them first. The others apply when the work touches their subject.

Thinking

• Common Sense (references/common-sense.md). Ask the plain questions a sensible person would ask (what is it for, what happens today, how do others do it, why do we need this, why is this case different, did I check) and answer them before you show anything; a plain question should not change your answer. Use before showing any proposal, design, copy, or answer, and when the user asks a simple "why would we...?" or says "common sense".
• Know What Is True (references/know-what-is-true.md). Write down the system as it is, its users, and how the world it depends on behaves; measure what is cheap, and date every number. Use when designing a change, before the first option.
• The Algorithm (references/the-algorithm.md). Question every requirement until it traces to a person or a forcing fact, then delete, simplify, speed up, and automate last, in that order. Use when designing, reviewing, or changing anything: a system, a spec, a process, a rule.
• Radical Simplicity (references/radical-simplicity.md). Derive the simplest complete design from the job and its real constraints, and question every choice that adds complexity. Use when designing at any level or adding a requirement to an existing design, and again when the user says "common sense", "just works" or "from scratch", or the design feels harder than its purpose.
• Exhaust the Design Space (references/exhaust-the-design-space.md). Compare real alternatives, find what settles the choice, and bring the winner, not a menu. Use when an important design choice is still unclear.
• Attack the Premise (references/attack-the-premise.md). Write down the premise the failed fixes share, and test it instead of writing another fix that assumes it. Use when two or more fixes that share one premise have failed the same check.
• Encode Lessons in Structure (references/encode-lessons-in-structure.md). Change what allows the mistake, and keep rules that need judgment short. Use when the same correction keeps coming up.