10.2 Stable "house rules" prompts for coding projects

Why “house rules” work

House rules are a stable prompt layer that encode your engineering norms. They work because they:

• reduce repeated instruction overhead,
• make behavior consistent across tasks,
• prevent common failure modes (rewrites, surprise dependencies, missing tests),
• keep your iteration loop fast without losing control.

What belongs in house rules

High-leverage rule categories:

• Process: plan-first, ask questions, stop-and-confirm assumptions.
• Change discipline: diff-only changes, small steps, line budget.
• Dependencies: allowlists/forbidden deps.
• Verification: tests, commands, acceptance criteria mapping.
• Safety: no secrets, no unsafe dynamic execution, safe logging.
• Output format: how you want patches and file outputs presented.

Keep rules generic. Task-specific requirements belong in the task prompt, not in house rules.

How to keep house rules short and effective

House rules degrade when they become:

• too long (the model ignores parts),
• too vague (“use best practices”),
• contradictory (“be concise” + “be extremely detailed always”),
• overly prescriptive (forcing patterns that don’t fit every task).

A good target is 8–20 bullet rules.

A reusable house rules template

House rules for this project:

Behavior:
- Be concise and explicit.
- If information is missing, ask clarifying questions before coding.
- If there are multiple approaches, propose tradeoffs and recommend one.

Change discipline:
- For existing code: output diff-only changes (no full rewrites).
- Keep diffs small and reviewable; prefer incremental steps.
- Do not introduce new dependencies unless explicitly allowed.

Verification:
- Define/confirm acceptance criteria before implementing.
- Add/update tests for new behavior; keep existing tests passing.
- After changes, provide commands to verify.

Safety:
- Never include secrets in prompts/outputs/logs.
- Avoid unsafe dynamic execution (eval/exec) on untrusted input.
- Prefer metadata logs over raw user content.

Output:
- Use clear file paths and unified diffs for patches.

Versioning and evolving house rules

As soon as house rules affect output quality, treat them like artifacts:

• store them in a file,
• change them deliberately,
• review diffs like code,
• tie rule versions to major project milestones.

If a rule causes problems, adjust it and note why.

Common pitfalls (and fixes)

Pitfall: house rules include every possible rule

Fix: cut to the rules that prevent your most frequent failures.

Pitfall: contradictory rules

Fix: pick the priority explicitly: “Prefer correctness over concision” or “Prefer small diffs over perfect style.”

Pitfall: the model ignores a rule repeatedly

Fix: move the rule to a more stable layer, tighten with a line budget, and enforce via review (don’t accept violating outputs).

Where to go next

• 10.3 Using checklists inside prompts
• 10.4 Separating spec from conversation