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-auditAudits 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.
sourceverification:sabotage-and-positive-controlsProves 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.
sourceverification:chart-integrityDetects 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.
sourceverification:unknown-is-not-zeroEnforces 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.
sourceverification:release-gate-designDesigns 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.
sourceSecond brain Durable memory that stays honest.
second-brain:department-memory-designOrganizes 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.
sourcesecond-brain:evidence-gated-triageConsumes 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.
sourcesecond-brain:confidence-taggingTags 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.
sourcesecond-brain:memory-lintRuns 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.
sourceDecision discipline Decisions that survive review.
decision-discipline:grilling-interviewRuns 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.
sourcedecision-discipline:doctrine-compilationCompiles 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.
sourcedecision-discipline:verdict-first-citationAnswers 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".
sourcedecision-discipline:settled-verdicts-registerMaintains 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.
sourceOrchestration Many agents, one thread.
orchestration:requirement-ledgerTrack 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.
sourceorchestration:verify-audit-repairRun 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.
sourceorchestration:context-packsAssemble 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.
sourceorchestration:concurrent-agent-hygieneWorking 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