Macrothought skills · back to the site

Four departments, seventeen skills. Each department installs independently. Every skill describes a practice that has shipped software; none of it is aspirational.

/plugin marketplace add Tanzalastas/macrothought.org
/plugin install verification@macrothought

Verification Checks that can fail, and prove it.

verification:checks-that-cannot-fail-audit

Audits any check, gate, or metric for the defect class where it is structurally incapable of reporting failure. Use this when adding a check to a gate, when a long-green check guards something important, or when a passing result feels too convenient.

source
verification:sabotage-and-positive-controls

Proves a check works by forcing it to fail on purpose with planted defects, and confirms clean input stays quiet. Use this before trusting any new check, scanner, or gate leg, and again after refactors to the check or to the system it watches.

source
verification:chart-integrity

Detects charts that are structurally unable to disagree with their own thesis, such as many series that are one curve times fixed weights or baselines fabricated as history. Use this before plotting anything derived from a spreadsheet, a workbook export, or a pipeline you did not write.

source
verification:unknown-is-not-zero

Enforces the rule that missing data, failed measurements, and empty states stay visibly distinct from a measured zero. Use this when designing any dashboard, report, gate, or log output, and whenever a zero, a blank panel, or a clean report might actually mean nothing was measured.

source
verification:release-gate-design

Designs release gates whose every leg can independently block, with audit legs owned by a non-author and harness errors reading as failures. Use this when building or reviewing a release gate, a CI quality bar, or any go/no-go check that decides whether something ships.

source

Second brain Durable memory that stays honest.

second-brain:department-memory-design

Organizes durable agent memory into department folders with one topic per note, a single loaded index, and hub notes over atomic children. Use this when setting up long-term memory for an agent or a knowledge vault, or when an existing store has rotted into large append-only files nobody can retrieve from.

source
second-brain:evidence-gated-triage

Consumes machine-generated maintenance suggestions in bounded batches, applying only what independent evidence supports and keeping the backlog count honest. Use this when a background job drafts maintenance suggestions for a knowledge base (duplicate pairs, missing links, lint fixes, distilled facts) that an agent must review before applying.

source
second-brain:confidence-tagging

Tags every stored claim as verified, inferred, or uncertain with a date at write time, and makes recall report gaps and staleness instead of implying completeness. Use this when an agent writes durable memory, answers questions from stored knowledge, or needs a re-verification cadence for aging claims.

source
second-brain:memory-lint

Runs deterministic health checks over a knowledge base (orphan notes, oversized notes, dead index pointers, silent store shrinkage) and proves each check can still fail. Use this when building or auditing maintenance automation for an agent memory store, or when a lint report has read "all clean" for weeks.

source

Decision discipline Decisions that survive review.

decision-discipline:grilling-interview

Runs a relentless one-question-at-a-time design interview that walks the whole design tree before anything gets built. Use this when the owner asks you to grill a plan, wants a design stress-tested before building, or when a plan contains decisions nobody has actually made yet.

source
decision-discipline:doctrine-compilation

Compiles an owner's recorded decisions into a citable doctrine document with dated sources, a known-verdicts table, and an explicit gaps section. Use this when plans should be reviewed against an owner's own recorded rules rather than generic best practice, or when scattered decision records need to become one consultable document.

source
decision-discipline:verdict-first-citation

Answers review questions verdict-first, with every objection citing a dated source or carrying an explicit label as the reviewer's own read. Use this when reviewing a proposal against recorded doctrine, answering "was this already decided" questions, or in any review where line one must be a yes, a no, or an honest "no recorded position".

source
decision-discipline:settled-verdicts-register

Maintains a register of decisions already made and checks every new proposal against it before fresh analysis begins. Use this when a proposal may be relitigating a settled call, when recording the outcome of a real debate, or when someone wants to reopen a decision the owner already made.

source

Orchestration Many agents, one thread.

orchestration:requirement-ledger

Track multi-agent work against a persistent ledger of requirements where every claim of done points at a specific row and its evidence. Use this when coordinating agents or sessions on one deliverable, when finished work keeps arriving without proof, or when a project must survive across sessions.

source
orchestration:verify-audit-repair

Run worker output through mechanical verification, an audit by a party other than the author, and an evidence-carrying repair queue so a failure can never be laundered into a pass. Use this when accepting work from agents or automated workers, when building a release gate, or after any check has reported green on broken work.

source
orchestration:context-packs

Assemble the minimum context an agent needs for one task into a versioned pack instead of pointing it at everything. Use this when briefing agents on scoped work, when agents drift because they read too widely, or when stale briefings produce work built against interfaces that no longer exist.

source
orchestration:concurrent-agent-hygiene

Working rules for multiple agents sharing one repository, covering stale working trees, blanket adds, indistinguishable authors, and long-running processes that keep executing old code. Use this when more than one agent or worker commits to the same repo, or when a committed fix looks like it is not working.

source