Durable quality
Load this skill before writing or modifying code. It is the default quality baseline for the session, not an optional audit mode.
Code generation is cheap. Understanding, verification, ownership, and architectural integrity are not.
One-line law: Code is cheap. Proof, structure, and ownership are the product.
Standing rules (every coding task)
Apply these on every implementation, fix, refactor, and agent-driven change. Do not wait for the user to ask.
1. Intent before edits
- Restate the goal and non-goals in one short block when the task is non-trivial.
- If requirements are ambiguous, surface assumptions explicitly before coding.
- Prefer the smallest change that satisfies the real ask. No speculative features, no drive-by refactors, no "while I'm here" rewrites.
2. Prove it works
- Run the relevant lint, typecheck, and tests for the touched surface before claiming done.
- Behavior changes need a regression that fails without the change and passes after.
- Capture evidence: commands run and outcomes. "Should work" is not done.
- Never delete, skip, or hollow out tests to obtain green.
- Never weaken CI (
|| true, drop coverage floors, skip lint) in the same change as a feature.
3. Keep the system healthy
- Every change should improve or hold code health. Reject changes that degrade structure for speed.
- Search for an existing helper before adding a new one. Reuse and extend beat clone-and-tweak.
- Match local style and patterns. Do not invent a parallel abstraction next to an existing one.
- Prefer clear names and small, bisectable diffs. One intent per commit/PR when practical.
- Do not mix pure reformat with behavior changes.
4. Respect blast radius
- Auth, payments, migrations, data deletion, permissions, and security boundaries need stronger proof and more careful review.
- Touching generated code, vendor trees, or secrets is forbidden unless the task explicitly requires it and safeguards are in place.
- Dependency and layer rules in the repo are real. Do not "just this once" import the wrong direction.
5. Own the result
- The human (or named owner) is accountable for merge and production consequences. Agents draft; they do not absorb liability.
- Prefer disclosing substantial AI assistance when the project tracks it (
Assisted-by, labels, trailers).
- If the change is unsafe to verify with available tools, say so and narrow scope rather than shipping hope.
6. Spend surplus on proof, not sprawl
When generation is fast:
- Prefer deeper tests, edge cases, and tighter structure over larger surface area.
- Prefer small lands over mega-diffs the reviewer cannot hold in their head.
- Clean structure still matters: messy code confuses agents and humans alike.
Session start checklist
At the beginning of coding work in a repo (first implementation turn):
- Note how to lint, typecheck, and test (README, package scripts,
AGENTS.md, CI).
- Note critical paths and ownership if present (
CODEOWNERS, OWNERS, MAINTAINERS).
- Note architecture or dependency checks if present.
- Work inside those constraints. If they are missing and the task is to harden the repo, use the deeper modes below.
Do not block tiny tasks on a full audit. Do block "done" claims on missing proof for the touched surface.
Explicit refusals
Do not do these unless the user explicitly overrides with eyes open:
- Ship untested user-visible behavior
- Pure cosmetic churn or mass reformat mixed into behavior work
- Break stable APIs without deprecation, flag, or design note
- Design-by-PR for substantial features (short design gate first)
- CI gaming or test theater
- Bulk low-context PR spam
- Secrets in code, logs, or agent instruction files
- Silent architecture violations
- Managing success by LOC or PR count
- Claiming done without running relevant checks
Proof ladder (quick)
| Tier |
Examples |
Minimum proof |
| T0 |
Docs, comments |
Format/lint if applicable |
| T1 |
Pure logic |
Unit tests + types |
| T2 |
APIs, service boundaries |
Contract/integration tests |
| T3 |
Parsers, state machines, money math |
Property/fuzz + units |
| T4 |
Auth, payments, migrations, data loss |
T3 + careful human review path |
| T5 |
Security / multi-tenant isolation |
T4 + threat notes; dual review when possible |
Default: match proof to blast radius. Details in references/proof-ladder.md.
Deeper modes (load files on demand)
When the user wants harness work, audits, or policy, pick a mode and read the linked files before acting.
Audit repo quality
Score C1-C10, list top risks, propose minimal fix sequence.
Read:
checklists/audit.mdreferences/constraint-packs.mdreferences/ai-failure-modes.md
Bootstrap quality harness
Install the minimum durable wall (tooling → CI → anti-gaming → arch → owners → agent docs).
Read:
playbooks/bootstrap-harness.mdreferences/proof-ladder.mdreferences/constraint-packs.md
Write laws for agents
Author lean AGENTS.md / CLAUDE.md policy with hard CI twins.
Read:
playbooks/laws-for-agents.mdexamples/AGENTS-quality-section.mdexamples/pr-template.mdchecklists/agent-pr-gate.md
Review a change (especially agent PRs)
Fast gate first, then code-health review.
Read:
checklists/agent-pr-gate.mdchecklists/code-health-review.mdreferences/oss-patterns.md
Encode architecture as code
Turn boundaries into failing tests/CI rules.
Read:
playbooks/architecture-as-code.mdreferences/constraint-packs.mdreferences/principles.md
Full file index
Load any of these when the standing rules are not enough. Paths are relative to this skill root.
References
| File |
Use when |
references/principles.md |
Need the five-loop model, code-health direction, craft vs tools |
references/oss-patterns.md |
Need flagship OSS patterns (Linux, K8s, Google, SQLite, Chromium, TS, Rust, Go) |
references/ai-failure-modes.md |
Need AI-era failure modes, empirical anchors, what works in practice |
references/proof-ladder.md |
Need risk tiers, mutation mindset, anomaly/property testing notes |
references/constraint-packs.md |
Need full C1-C10 packs (must / must-not / hard twin) |
Checklists
| File |
Use when |
checklists/audit.md |
Scoring a repo and writing an audit report |
checklists/code-health-review.md |
Reviewing design, complexity, tests, and health direction |
checklists/agent-pr-gate.md |
Fast-reject protocol before deep review of agent PRs |
Playbooks
| File |
Use when |
playbooks/bootstrap-harness.md |
Installing the quality wall in order |
playbooks/laws-for-agents.md |
Writing enforceable agent policy (soft vs hard) |
playbooks/architecture-as-code.md |
Adding dependency/layer fitness functions |
Examples
| File |
Use when |
examples/AGENTS-quality-section.md |
Pasting a quality bar into AGENTS.md |
examples/pr-template.md |
Adding an evidence-required PR template |
Five loops (memory hook)
| Loop |
Job |
| Intent |
What must be true |
| Generation |
Produce code |
| Proof |
Deterministic evidence |
| Structure |
Boundaries, deps, complexity |
| Ownership |
Named human liability over time |
Missing proof, structure, or ownership is how AI-assisted codebases slump.
Related skills
karpathy-guidelines for surgical, non-speculative edits (complementary; use together)init when bootstrapping repo agent memory- Stack-specific skills for concrete linters and test runners
Non-goals
- Clean Code aesthetics as religion
- 100% MC/DC on low-risk apps
- Banning AI generation
- Replacing product judgment
- Treating markdown rules as a security boundary without CI/hooks
Source anchors
Google eng-practices; Linux coding-assistants and submitting-patches; K8s OWNERS; SQLite testing; Chromium OWNERS/CQ; TypeScript baselines and anti bulk-agent spam; Martin (Oath, Tools are not the Answer, 2026 agent constraint notes); agents.md; Willison proof standard; Osmani agentic review; GitHub agent PR guide; empirical AI-debt and AI-slop studies.
URLs and detail live in references/ai-failure-modes.md and references/oss-patterns.md.
1---2name: durable-quality3description: Load this before writing any code to prevent vibe rot and ensure high-quality, durable output. Standing baseline for every coding session under AI-assisted development: proof before done, small bisectable changes, reuse over clones, honest tests, architecture boundaries, and human accountability. Also use for "make this last", "stop vibe rot", "quality harness", "code health audit", "laws for agents", "fitness functions", "review agent PRs", and harness setup. Progressive docs live beside this file; load them when the task needs depth.4license: MIT5---67# Durable quality89**Load this skill before writing or modifying code.** It is the default quality baseline for the session, not an optional audit mode.1011Code generation is cheap. Understanding, verification, ownership, and architectural integrity are not.1213**One-line law:** Code is cheap. Proof, structure, and ownership are the product.1415## Standing rules (every coding task)1617Apply these on every implementation, fix, refactor, and agent-driven change. Do not wait for the user to ask.1819### 1. Intent before edits2021- Restate the goal and non-goals in one short block when the task is non-trivial.22- If requirements are ambiguous, surface assumptions explicitly before coding.23- Prefer the smallest change that satisfies the real ask. No speculative features, no drive-by refactors, no "while I'm here" rewrites.2425### 2. Prove it works2627- Run the relevant lint, typecheck, and tests for the touched surface before claiming done.28- Behavior changes need a regression that **fails without the change** and passes after.29- Capture evidence: commands run and outcomes. "Should work" is not done.30- Never delete, skip, or hollow out tests to obtain green.31- Never weaken CI (`|| true`, drop coverage floors, skip lint) in the same change as a feature.3233### 3. Keep the system healthy3435- Every change should **improve or hold** code health. Reject changes that degrade structure for speed.36- Search for an existing helper before adding a new one. Reuse and extend beat clone-and-tweak.37- Match local style and patterns. Do not invent a parallel abstraction next to an existing one.38- Prefer clear names and small, bisectable diffs. One intent per commit/PR when practical.39- Do not mix pure reformat with behavior changes.4041### 4. Respect blast radius4243- Auth, payments, migrations, data deletion, permissions, and security boundaries need stronger proof and more careful review.44- Touching generated code, vendor trees, or secrets is forbidden unless the task explicitly requires it and safeguards are in place.45- Dependency and layer rules in the repo are real. Do not "just this once" import the wrong direction.4647### 5. Own the result4849- The human (or named owner) is accountable for merge and production consequences. Agents draft; they do not absorb liability.50- Prefer disclosing substantial AI assistance when the project tracks it (`Assisted-by`, labels, trailers).51- If the change is unsafe to verify with available tools, say so and narrow scope rather than shipping hope.5253### 6. Spend surplus on proof, not sprawl5455When generation is fast:5657- Prefer deeper tests, edge cases, and tighter structure over larger surface area.58- Prefer small lands over mega-diffs the reviewer cannot hold in their head.59- Clean structure still matters: messy code confuses agents and humans alike.6061## Session start checklist6263At the beginning of coding work in a repo (first implementation turn):64651. Note how to lint, typecheck, and test (README, package scripts, `AGENTS.md`, CI).662. Note critical paths and ownership if present (`CODEOWNERS`, OWNERS, MAINTAINERS).673. Note architecture or dependency checks if present.684. Work inside those constraints. If they are missing and the task is to harden the repo, use the deeper modes below.6970Do not block tiny tasks on a full audit. Do block "done" claims on missing proof for the touched surface.7172## Explicit refusals7374Do not do these unless the user explicitly overrides with eyes open:75761. Ship untested user-visible behavior772. Pure cosmetic churn or mass reformat mixed into behavior work783. Break stable APIs without deprecation, flag, or design note794. Design-by-PR for substantial features (short design gate first)805. CI gaming or test theater816. Bulk low-context PR spam827. Secrets in code, logs, or agent instruction files838. Silent architecture violations849. Managing success by LOC or PR count8510. Claiming done without running relevant checks8687## Proof ladder (quick)8889| Tier | Examples | Minimum proof |90|---|---|---|91| T0 | Docs, comments | Format/lint if applicable |92| T1 | Pure logic | Unit tests + types |93| T2 | APIs, service boundaries | Contract/integration tests |94| T3 | Parsers, state machines, money math | Property/fuzz + units |95| T4 | Auth, payments, migrations, data loss | T3 + careful human review path |96| T5 | Security / multi-tenant isolation | T4 + threat notes; dual review when possible |9798Default: match proof to blast radius. Details in `references/proof-ladder.md`.99100## Deeper modes (load files on demand)101102When the user wants harness work, audits, or policy, pick a mode and **read the linked files** before acting.103104### Audit repo quality105106Score C1-C10, list top risks, propose minimal fix sequence.107108Read:109110- `checklists/audit.md`111- `references/constraint-packs.md`112- `references/ai-failure-modes.md`113114### Bootstrap quality harness115116Install the minimum durable wall (tooling → CI → anti-gaming → arch → owners → agent docs).117118Read:119120- `playbooks/bootstrap-harness.md`121- `references/proof-ladder.md`122- `references/constraint-packs.md`123124### Write laws for agents125126Author lean `AGENTS.md` / `CLAUDE.md` policy with hard CI twins.127128Read:129130- `playbooks/laws-for-agents.md`131- `examples/AGENTS-quality-section.md`132- `examples/pr-template.md`133- `checklists/agent-pr-gate.md`134135### Review a change (especially agent PRs)136137Fast gate first, then code-health review.138139Read:140141- `checklists/agent-pr-gate.md`142- `checklists/code-health-review.md`143- `references/oss-patterns.md`144145### Encode architecture as code146147Turn boundaries into failing tests/CI rules.148149Read:150151- `playbooks/architecture-as-code.md`152- `references/constraint-packs.md`153- `references/principles.md`154155## Full file index156157Load any of these when the standing rules are not enough. Paths are relative to this skill root.158159### References160161| File | Use when |162|---|---|163| `references/principles.md` | Need the five-loop model, code-health direction, craft vs tools |164| `references/oss-patterns.md` | Need flagship OSS patterns (Linux, K8s, Google, SQLite, Chromium, TS, Rust, Go) |165| `references/ai-failure-modes.md` | Need AI-era failure modes, empirical anchors, what works in practice |166| `references/proof-ladder.md` | Need risk tiers, mutation mindset, anomaly/property testing notes |167| `references/constraint-packs.md` | Need full C1-C10 packs (must / must-not / hard twin) |168169### Checklists170171| File | Use when |172|---|---|173| `checklists/audit.md` | Scoring a repo and writing an audit report |174| `checklists/code-health-review.md` | Reviewing design, complexity, tests, and health direction |175| `checklists/agent-pr-gate.md` | Fast-reject protocol before deep review of agent PRs |176177### Playbooks178179| File | Use when |180|---|---|181| `playbooks/bootstrap-harness.md` | Installing the quality wall in order |182| `playbooks/laws-for-agents.md` | Writing enforceable agent policy (soft vs hard) |183| `playbooks/architecture-as-code.md` | Adding dependency/layer fitness functions |184185### Examples186187| File | Use when |188|---|---|189| `examples/AGENTS-quality-section.md` | Pasting a quality bar into `AGENTS.md` |190| `examples/pr-template.md` | Adding an evidence-required PR template |191192## Five loops (memory hook)193194| Loop | Job |195|---|---|196| Intent | What must be true |197| Generation | Produce code |198| Proof | Deterministic evidence |199| Structure | Boundaries, deps, complexity |200| Ownership | Named human liability over time |201202Missing proof, structure, or ownership is how AI-assisted codebases slump.203204## Related skills205206- `karpathy-guidelines` for surgical, non-speculative edits (complementary; use together)207- `init` when bootstrapping repo agent memory208- Stack-specific skills for concrete linters and test runners209210## Non-goals211212- Clean Code aesthetics as religion213- 100% MC/DC on low-risk apps214- Banning AI generation215- Replacing product judgment216- Treating markdown rules as a security boundary without CI/hooks217218## Source anchors219220Google eng-practices; Linux coding-assistants and submitting-patches; K8s OWNERS; SQLite testing; Chromium OWNERS/CQ; TypeScript baselines and anti bulk-agent spam; Martin (Oath, Tools are not the Answer, 2026 agent constraint notes); agents.md; Willison proof standard; Osmani agentic review; GitHub agent PR guide; empirical AI-debt and AI-slop studies.221222URLs and detail live in `references/ai-failure-modes.md` and `references/oss-patterns.md`.
watzon