rigorous

The engineering counterpart of impeccable.One skill, 13 commands, 3 standards files.

Disciplined code, low-ceremony, opinionated. Setup writes your team's standards once. Every sub-command after that follows them. Push back against AI cargo, premature abstraction, and defensive ceremony.

$npx skills add CoRLab-Tech/skills@rigorous
Or run directly inside Claude Code:/rigorous teach
The 13 commands

Five categories. One coherent toolkit.

Setup once, then run any command from any project. Each follows your team's posture in PRINCIPLES.md, STACK.md, and TESTING.md.

Setup
teach

Interactive walkthrough. Writes PRINCIPLES.md, STACK.md, TESTING.md once per project.

document

Reverse-engineer the three standards files from existing code.

Build
shape

Plan a feature before you write any code. Returns a one-page brief.

craft

Implement the approved shape end-to-end. Typecheck and verify each layer.

tdd

Strict red, green, refactor cycle. One failing test at a time.

Evaluate
critique

Acid review. What's complicated, what can be cut, what doesn't earn its place.

audit

Technical audit. Performance, security, dependency health, races, observability.

architect

System design review. Modules, coupling, abstraction lines, failure model.

Refine
simplify

Strip ceremony. Dead code, premature abstractions, unnecessary indirection.

harden

Boundary validation, edge cases, idempotency. Only where they earn their place.

refactor

Restructure without changing behavior. Small steps, tests after each.

Fix
debug

Systematic root cause investigation. Reproduce, hypothesize, trace upstream.

optimize

Profile-driven performance work. Measure, target, fix, re-measure.

The three standards files

Set up once. Every command follows them.

`teach` writes these files at the root of your repo through 15 questions. After that, every command reads them before doing work, so the output never drifts from your team's posture.

PRINCIPLES.mdmd
## Abstractions
 
- **Rule of three.** Don't extract a helper until the third duplication.
- **No interfaces with one impl.** Concrete classes until ≥2 implementations.
 
## Comments
 
- Default to zero. Code is the documentation.
- WHY-comments only — workarounds, invariants, hidden constraints.
Engineering posture. Required.
STACK.mdmd
## Languages
 
- TypeScript 5.6 — strict mode, no implicit any.
- Node 22 LTS — runtime baseline.
 
## Anti-choices
 
- No GraphQL — REST is sufficient at our scale.
- No ORM — `pg` driver direct, schemas under our control.
- No Redis — `pg-boss` for queues, Postgres for everything.
Tech choices and their why.
TESTING.mdmd
## Coverage policy
 
- Real DB integration tests for SQL boundaries.
- Pure unit tests for business logic.
- Skip framework code — don't re-test `Array.map`.
 
## Mocking
 
- Mock at boundaries already mocked elsewhere.
- Never mock the DB — burned us in production.
What's worth testing, and how.

The files are markdown, version-controlled, edited by you whenever the rules drift. They're the durable engineering policy of the project.

The flow

From idea to shipped.

One representative path through the toolkit. The five categories cover everything else, but most features go through these in order.

  1. 01
    /teach
    Setup

    Answer 15 questions about how your team writes code. Get three standards files at the repo root.

  2. 02
    /shape
    Plan

    Describe the feature. Get a one-page brief: goal, files, schema, test plan, tradeoffs. Confirm before any code.

  3. 03
    /craft
    Build

    Implement after the plan is approved. Each layer typechecks and verifies before the next starts.

  4. 04
    /critique
    Review

    Acid review of the diff. What's complicated, what can be cut, what abstractions don't earn their place.

  5. 05
    /harden
    Ship

    Add boundary validation, idempotency, observability. Only where they earn their place. Then it's ready.

Engineering laws

Always apply. Override taste and inertia.

Six rules every command honors, regardless of what's in your standards files. The product of years of code review distilled to what survives when defaults fail.

  • Match the change to the task.

    A bug fix changes the buggy line and nothing else. No surrounding cleanup. Three similar lines beat a premature abstraction.

  • Trust internal code, validate boundaries.

    No defensive null checks for arguments the type system already validated. Validate at HTTP request bodies, env vars, third-party API responses, user uploads.

  • Default to zero comments.

    The code is the documentation. Write a comment only when the WHY is non-obvious: a hidden constraint, a workaround, a subtle invariant. Never WHAT-comments.

  • No half-finished work.

    No feature flags or backwards-compat shims if the change can be made directly. No TODO without an issue link. No function with one branch returning null.

  • The slop test.

    If a senior engineer reading this PR could say "AI wrote that" without doubt, it has failed. Over-commented code, defensive cargo, suffix-disease class names — rework until it reads like a deliberate human authored it.

  • Reversibility before risk.

    Editing files is free. Deleting files, dropping tables, force-pushing, modifying CI — confirm with the user first.

Compared to

What's different from the alternatives.

The skill ecosystem already has good code-quality tools. rigorous picks a specific bet: one cohesive skill, durable standards, gates instead of suggestions.

FeaturerigorousOther code skills
Single skill, multiple commands13 commands, one installfragmented across N packages
Setup that asks the right questionsteach writes 3 durable filesglobal system prompts only
Standards drive every commandPRINCIPLES.md is loaded on every runagent re-asks each time
Plan-before-code as a hard gateshape required for craft / tddoptional or absent
Engineering laws baked insix rules apply to every outputdepends on which skill you invoke

Honest take: obra/superpowers and mattpocock/skills have brilliant individual skills. Use them too. rigorous is for teams that want one cohesive frame instead of 14 separate packages.