make-no-mistakes

Version: 1.38.0 · CHANGELOG · Marketplace

The disciplined dev lifecycle — implement issues, review PRs, sync releases, test E2E, and manage sessions. One plugin to make no mistakes.

A Claude Code plugin by Luis Andres Pena Castillo.

Install

# Add the marketplace (one-time)
claude plugin marketplace add DojoCodingLabs/make-no-mistakes-toolkit

# Install the plugin
claude plugin install make-no-mistakes

Or clone and install locally:

git clone https://github.com/DojoCodingLabs/make-no-mistakes-toolkit.git
claude plugin marketplace add ./make-no-mistakes-toolkit
claude plugin install make-no-mistakes

Install (OpenCode)

npx @lapc506/make-no-mistakes install

CLI Commands

Start here: /make-no-mistakes:domain-driven-advisor

If you only run one command from this plugin, run this one.

/make-no-mistakes:domain-driven-advisor

The advisor is the canonical entry point for repo-health work. From its SKILL.md:

Guided entry point for repo health when you don't know which audit you need. Use when the user asks "which audit", "where do I start", wants to check "repo health", or mentions "domain driven" design. Inspects the repo, asks a few plain-language questions, recommends which audit(s) to run (or the full ordered sweep), runs them via the audit-engine, and finishes with a premortem on the remediation plan. Best first command for a new repo.

It routes you across the six audit families (all live as of 1.29.0):

After the audit(s), it runs a premortem on the aggregated remediation plan, so the plan you ship has already survived "it's 6 months later and this failed — why?". Full teaching section below.

What's Inside

Commands (37)

Deliberate actions you invoke explicitly.

Skills (10)

Auto-activate by context — you don't need to remember the command name.

Skills can also be invoked explicitly: /make-no-mistakes:spec-recommend T0-4

Agents (2)

Specialized subagents dispatched by commands/skills for heavy work.

Guided repo health: /domain-driven-advisor

New to the audit family, or not sure where to start? Run one command and let it guide you. The advisor is the front door to the whole audit-engine family.

When to use it

• You inherited a repo and want to know what's structurally wrong.
• You suspect drift (duplicated columns, FE/BE validation mismatches, tangled modules, a stalled monolith migration) but don't know which audit applies.
• You want a remediation plan that's already been stress-tested.

What it does (4 steps)

1. Inspects the repo — detects signals (a shared database, FE+backend validation, a monolith mid-migration, layered architecture, cross-module imports).
2. Asks a few plain-language questions — no jargon required. Each answer maps to one of the audits.
3. Recommends and runs the audit(s) — just the ones you need, or the full ordered sweep schema → contract → DDD → architecture → strangler → enforcement if you're unsure.
4. Runs a premortem — on the aggregated remediation plan, so you ship a plan that already survived "it's 6 months later and this failed — why?".

Quick start

/make-no-mistakes:domain-driven-advisor

Point it at a subdirectory if you only want part of the repo:

/make-no-mistakes:domain-driven-advisor src/payments

Example session

You:  /make-no-mistakes:domain-driven-advisor
Tool: Scanning… found supabase/migrations and FE+edge validation.
      Q1: ¿Varios equipos escriben en la misma base de datos? > yes
      Q2: ¿El frontend y el backend validan los mismos datos por separado? > yes
      → Recommended: /audit-schema-drift + /audit-contract-drift, then enforcement.
      Tip: fan-out is on by default; for mid-run coordination between
           verifiers, add "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
           to ~/.claude/settings.json
      Run them now? > yes
      … findings written to docs/repo-health/… + premortem report on ~/Escritorio.

What it produces

For each audit it runs: a findings doc in docs/repo-health/, an OpenSpec remediation change, Bilingual-Layer Linear issues, and 4-cure scaffold proposals — plus a single premortem report (HTML + transcript) over the combined plan.

Faster with parallel fan-out

The audits fan out one verifier per finding, so they're much faster in parallel. The parallelism itself comes from the Agent tool (name + isolation: "worktree", coordinated by SendMessage) and needs no flag — there is no TeamCreate tool in current harnesses, and its absence is expected rather than a problem.

What "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" adds is the coordination layer on top: the teammate mailbox, shared team context, and assigning a task to a teammate. The advisor recommends enabling it in ~/.claude/settings.json (it shows the exact one-line change; it never edits your settings without consent). Decline and you still get the fan-out — you lose mid-run coordination, so each verifier is briefed self-contained and reports once at the end. Note the flag is ANDed with a server-side gate, so setting it locally doesn't guarantee the layer is live; the tool surface is what to believe.

See /make-no-mistakes:parallelize for the full capability gate.

Run a single audit directly

If you already know what you need, skip the advisor:

/make-no-mistakes:audit-schema-drift

Configuration

The plugin reads linear-setup.json at your repo root for project-specific settings:

{
  "team": {
    "key": "ALT",
    "url": "https://linear.app/your-team"
  },
  "git": {
    "baseBranch": "main",
    "branchPattern": "{type}/{issueId}-{description}"
  },
  "github": {
    "org": "your-org"
  },
  "defaults": {
    "greptileReview": true,
    "squashMerge": true,
    "slackNotify": true
  },
  "slack": {
    "statusChannel": "C09BD6W95GC"
  }
}

If no linear-setup.json exists, the plugin auto-detects settings from your environment (GitHub org from current repo, Linear team from MCP, etc.).

Toolkit behaviour (as opposed to where things go) is read from an optional make-no-mistakes.config.json, also at the repo root — see commands/make-no-mistakes.config.example.json for every key and its default. Two consumers today: language / diacritics + explain for /explain, and syncAdvisor.governedPaths for the sync-advisor skill:

{
  "syncAdvisor": {
    "governedPaths": [".claude/hooks/", "scripts/", ".github/workflows/"]
  }
}

Those are the directories where a stale checkout silently changes behaviour, so sync-advisor names them by file when they have moved on the base ref. The key has no default — unset, the skill reports distance and routing and omits that line rather than guessing at paths it cannot know.

Verify Installation

Claude Code:

claude plugin list
# should show "make-no-mistakes"

Or run /plugin inside Claude Code to see it in the plugin manager. Then invoke any command to confirm: /make-no-mistakes:summarize

OpenCode:

make-no-mistakes doctor

Requirements

• Claude Code — the CLI or IDE extension
• GitHub CLI (gh) — authenticated (gh auth login)
• Linear MCP — configured in Claude Code for issue tracking (add via Claude Code settings > MCP servers)
• Slack MCP — optional, for standup posting and Slack reporting. See slack-config.example.json at the repo root for channel configuration

Product Owner Extension (SPOPC)

make-no-mistakes is expanding from a developer lifecycle toolkit into a full product ownership layer, grounded in the Scrum Product Owner Professional Certificate (SPOPC) methodology by CertiProf.

The author holds three CertiProf certifications that inform this extension:

• Scrum Product Owner Professional (SPOPC) — backlog management, stakeholder communication, value maximization
• User Stories Foundation (USFC) — story writing, acceptance criteria, splitting strategies
• Scrum Foundation Professional (SFPC) — Scrum framework, ceremonies, roles, artifacts

Why not a separate plugin?

gstack proved that a single toolkit can serve multiple roles — CEO, designer, engineer, QA — all through slash commands. Product ownership is part of the development lifecycle, not separate from it. make-no-mistakes already has the plumbing: Linear issue tracking, Slack messaging, daily standups, spike recommendations, and session management. The PO skills are natural extensions.

Planned PO Skills and Commands

Two-Layer Architecture

SOPs (Standard Operating Procedures) define the what and why per product area — these live in your own documentation repo, not here. make-no-mistakes reads them at runtime to apply context-specific policies.

your-docs-repo/sops/{product-area}/
├── README.md              # Vision, KPIs, success metrics
├── backlog-policy.md      # Prioritization criteria, Definition of Done
├── release-checklist.md   # Pre-release gates specific to this area
└── escalation-flow.md     # When and how to escalate to stakeholders

The plugin consumes these SOPs to give context-aware recommendations. Each Product Owner creates SOPs for their area using a shared template.

SPOPC-to-Tooling Mapping

Status: The PO extension is in design phase. The existing developer lifecycle commands are stable and production-ready. PO skills will be added incrementally without breaking existing functionality.

The Name

"Make no mistakes" started as an inside joke — a mantra for disciplined execution. Like the Ralph loop, it's a reminder that process isn't optional when shipping matters.

Architecture

make-no-mistakes-toolkit/
├── .claude-plugin/     # Claude Code plugin metadata
│   ├── plugin.json
│   └── marketplace.json
├── src/                # OpenCode npm distribution (TypeScript CLI)
│   ├── cli.ts
│   ├── index.ts
│   └── lib/
├── commands/           # 30 explicit commands
├── agents/             # 2 specialized subagents
├── skills/             # 10 auto-activating skills
│   └── */SKILL.md
├── hooks/              # Manifest-driven PreToolUse + PostToolUse hooks (v1.5.0+)
│   ├── hooks.json      # Claude Code wiring (thin)
│   ├── pre-bash.sh     # Bash dispatcher
│   ├── pre-edit.sh     # Edit/Write/MultiEdit dispatcher
│   ├── post-slack.sh   # Slack message dispatcher (warn-only)
│   ├── test-hooks.sh   # Parametrized test runner
│   ├── lib/            # Generic helpers (parse-input, eval-rule)
│   └── rules/
│       ├── rules.yaml  # Rules SSoT — humans edit
│       ├── rules.json  # Build artifact — runtime reads
│       └── README.md   # Contributor guide
├── scripts/            # Shared bash + node utilities
│   └── build-rules.mjs # rules.yaml -> rules.json compiler
├── package.json
└── README.md

Design principle: Commands for destructive/token-intensive actions (you decide when). Skills for read-only analysis (context-aware, auto-activate). Agents for heavy orchestration (own context window). Hooks for deterministic guardrails on every tool call (no human in the loop).

Hooks (v1.5.0+)

When this plugin is enabled, every tool call you make in any repo runs through the manifest-driven hooks in hooks/rules/rules.yaml. The Tier 1 ruleset ships 10 rules:

PreToolUse on Bash (block by default):

• ssh-db-mutation — blocks gcloud compute ssh ... --command="...php -r/mysql/set_config..." (Moodle-flavoured SSH payloads)
• inline-db-mutation-mysql / -psql / -sqlite / -mongo / -redis / -gcloud-sql — blocks inline DB mutations across any CLI (mysql -e "UPDATE...", psql -c "INSERT...", sqlite3 path "DROP...", mongo --eval "db.x.update(...)", redis-cli SET/DEL/FLUSHALL, gcloud sql import/export). Forces use of a versioned script under scripts/ or bin/. SELECT-only reads are never blocked. Per-rule bypass via # hook-bypass: db-mutation-rule; per-repo opt-out via touch .no-make-no-mistakes-db-mutation at the root (memory: feedback_scripts_not_db.md).
• prod-ops-no-approval — blocks --project=*-prod operations without explicit acknowledgement
• destructive-db-ops — blocks supabase db reset|push|repair and inline DROP/TRUNCATE/DELETE FROM
• manual-edge-fn-deploy — blocks supabase functions deploy (forces CI-only deploys)
• gcloud-missing-project — warns when a gcloud subcommand is missing --project=
• discard-stderr (v1.36.0) — blocks a command that routes stderr to /dev/null (2>/dev/null, &>/dev/null, >/dev/null 2>&1). A failing command with its stderr discarded is indistinguishable from a succeeding one that printed nothing, so the empty result reads as "none found" rather than "it errored". cmd >/dev/null alone is untouched — stderr still reaches you — and so is cmd 2>&1 >/dev/null, where stderr is duplicated to the original stdout before stdout is redirected and therefore survives. Same tokens, opposite outcomes; the rule matches on order. No bypass marker — see below.

PreToolUse on Edit | Write | MultiEdit (block):

• minified-build-output — blocks writing minified content to amd/build/*.min.js or dist/*.min.{js,css}
• secrets-hardcoded — blocks hardcoded password|secret|token|api_key|... patterns in source files (env.example/test/spec/README/fixtures/mocks paths exempted)

PostToolUse on Slack messages (warn-only):

• slack-unicode-bullets — warns when •◦▪▫ bullets are used (use - instead)
• slack-tables-no-codeblock — warns when markdown tables ship outside ``` fences (Slack mrkdwn doesn't render bare tables)
• slack-spanish-tildes — warns on common Spanish words missing tildes (migracion → migración, etc.)

Bypassing a rule

Each blocking rule has a bypass_marker. Add the literal string // hook-bypass: <marker> (or # hook-bypass: <marker>) anywhere in the command or content to acknowledge the rule and proceed:

# Bypass markers shipped in Tier 1:
# // hook-bypass: ssh-db-rule
# // hook-bypass: prod-ops
# // hook-bypass: db-destructive
# // hook-bypass: edge-fn-manual
# // hook-bypass: minified-build
# // hook-bypass: secret-leak

# Bypass marker shipped in v1.17.0 inline-db-mutation family:
# // hook-bypass: db-mutation-rule

Some rules (e.g., the v1.17.0 inline-DB-mutation family) also support a per-repo escape hatch: drop a sentinel file at the repo root and the rule becomes a no-op in that repo. The current sentinel filenames are:

• .no-make-no-mistakes-db-mutation — disables all six inline-db-mutation-* rules in the repo

Bypasses are explicit acknowledgements — they sit inside the command/content itself, not as silent flags.

Not every rule has one, on purpose. discard-stderr (v1.36.0) ships with bypass_marker: null, because the legitimate cases it might otherwise need a bypass for are already allowed by the rule itself: cmd >/dev/null for noisy stdout, cmd 2>&1 >/dev/null when stderr must survive, command -v x >/dev/null for existence probes, and cmd 2>>"$log" to keep stderr somewhere readable. With no case left over, a marker would only buy a way past a rule nobody needs to get past.

The general shape matters beyond this one rule: a gate whose refusal message prints the way around it is not a gate. pre-bash-block-main-target.sh in dojo-os accepted DOJO_HOTFIX_TO_MAIN=1 and quoted that literal in its own refusal, so typing the string it handed you WAS the authorization; two agents filed false P0-hotfix claims that way on 2026-07-28 (DOJ-6247). A bypass is worth its cost when it names a real case the rule cannot express. When it does not, it is a password printed on the lock.

And as of v1.37.0, no refusal prints its own marker. The markers still work, exactly as before — a human who knows one exists can type it deliberately, and the allows-bypass-marker test on every rule that has one pins that mechanic in place. What changed is that the hook no longer announces it. Measured on origin/main @ ee0ba47: of 40 rules, 35 carried a bypass_marker and 26 quoted that marker inside their own refusal text — including prod-ops-no-approval, destructive-db-ops, secrets-hardcoded and block-git-force-push-no-lease.

jq '[.[] | select((.bypass_marker // "") != "")
         | select(.bypass_marker as $m | (.message // "") | contains($m))] | length' \
  hooks/rules/rules.json

That is the DOJ-6247 shape reproduced 26 times: reading the refusal is the authorization, and typing the marker becomes a reflex rather than a decision. A refusal now says what was blocked and why, and closes with a block is a finding — report it upward rather than routing around it. The markers are documented here, in a file you open on purpose, which is a different act from being handed one at the moment you are trying to get past something.

Held in place by three generic assertions in hooks/test-hooks.sh (run by CI on every PR touching hooks/**), which hold over the whole manifest rather than rule by rule — because rule by rule is what drifted the first time:

• a message may not contain its own bypass_marker
• a message may not contain its own disable_if_repo_file (the per-repo escape hatch is the same door, one level up)
• no message may contain the literal hook-bypass, which catches the template form even when the marker is renamed

Ordinary prose is untouched: ds-deep-ui-import still says deep imports "bypass the barrel", and discard-stderr still says outright that it has no bypass marker.

Adding your own rules

Edit hooks/rules/rules.yaml, run npm run build-rules, run npm run test-hooks to verify, and commit. See hooks/rules/README.md for the schema and Tier 2 decomposition techniques.

Disabling all hooks

Remove the plugin from ~/.claude/settings.json enabledPlugins, or set CLAUDE_DISABLE_PLUGIN_HOOKS=1 in your shell.

Bilingual Format

Implementation briefs produced by spec-recommend and spike-recommend follow the Bilingual Format — a two-layer structure:

• Human Layer — User story, background, analogy, pitfalls (readable by non-engineers)
• Agent Layer — Objective, context files, acceptance criteria, verification commands (executable by AI)

See skills/spec-recommend/references/bilingual-format.md for the full template.

License

Business Source License 1.1 — you may use, modify, and redistribute for non-competitive purposes. Converts to Non-Profit OSL 3.0 after 5 years.