master-brain

master-brain

Overview

No inference without evidence. No conclusion without verification.

Every analysis passes through a mandatory 5-stage reasoning loop. Every stage is processed as a distinct, demarcated unit of work. The loop repeats from Observation if Verification fails.

Violating the letter of the rules is violating the spirit of the rules. This principle binds at every stage. No stage may be skipped or waved off as "obvious."

When to Use

Analysis, decision, or evaluation needed?
├─ No  → Don't use this skill
└─ Yes → Can it be answered in a single step?
          ├─ Yes → Don't use this skill
          └─ No  → USE this skill

Use this skill for:

• •Complex multi-step decisions with trade-offs
• •Document analysis: claims, findings, evidence, gaps
• •Quality control of structured analysis (yours or someone else's)
• •Gap analysis, benchmarking, evaluation against a standard
• •Any inference, evaluation, or judgment that must be defensible

Do not use for:

• •Simple informational queries ("where is this file?")
• •Single-step operations ("rename this variable")
• •Routine code writing or refactoring
• •Tasks with no judgment component

The 5-Stage Loop

OBSERVATION → HYPOTHESIS → EVIDENCE → CONCLUSION → VERIFICATION
   ↑________________________________________________|
              (loop back if verification fails)

Rules that bind at every stage:

• •Run the stages in order. Do not skip.
• •Process each stage as a distinct unit. Do not batch.
• •If Verification fails, return to Observation with the new evidence. Do not patch the conclusion.

Stage 1 — Observation

Collect data without interpretation. List facts, not opinions.

Do:

• •For a document: itemize claims, structure, sections, evidence cited, gaps.
• •For a decision: list current state, constraints, stakeholders, timeline, prior attempts.
• •For a claim: restate it precisely; identify what would need to be true for it to hold.
• •For QA: extract structure, numbering, headings, paragraph count.

Do not:

• •Add commentary, judgment, or "I think" statements.
• •Pre-classify findings (that is Hypothesis work).
• •Skip items because they seem irrelevant.

Stage 2 — Hypothesis

Generate candidate explanations for each observation. Force at least two hypotheses per observation — do not stop at the first plausible reading.

Do:

• •"This could mean X..."
• •"A rule could be violated if Y..."
• •"Alternatively, Z is also possible..."

Do not:

• •Settle on one hypothesis without considering alternatives.
• •Treat the first hypothesis as the conclusion.
• •Skip the stage because "it's obvious."

Stage 3 — Evidence

Gather concrete evidence. For each hypothesis, list what supports it and what contradicts it.

Do:

• •Cite the specific rule, document section, or fact.
• •Verify cross-references (does the cited section actually exist?).
• •Check statistics, dates, names — every concrete claim.
• •Match claims against any supplied domain rules.
• •Annotate each load-bearing claim with a confidence level (High / Medium / Low) and a brief source-quality note. The Evidence output feeds the weakest-link rule in Stage 4; without per-claim confidence, the rule cannot be applied.

Do not:

• •Accept a hypothesis on its own plausibility.
• •Use vague evidence ("generally accepted that...").
• •Skip the contradictions.

Stage 4 — Conclusion

State the conclusion clearly, with a severity/urgency label, a confidence level, and a concrete recommendation.

Do:

• •For findings: end with a [Urgency] [Direction] label in bold and a confidence level. Format: "Therefore, **[Major Gap]** has been identified. **Confidence: High**." See "Severity / Urgency Guidance" and "Confidence Level" below for the taxonomy.
• •For Type 1 (irreversible) decisions, see "Calibrating Rigor" — Medium-or-High confidence is required before issuing a recommendation. If confidence is Low, return to Stage 3 to gather more evidence.
• •For decisions: state the recommended action, the reason, the alternative, and the cost of not acting.
• •For QA: state pass/fail with reason.
• •Recommendations should be concrete and actionable. Use the modal form "should" or "must."

Do not:

• •Issue a conclusion without a [Urgency] [Direction] label.
• •Issue a conclusion without a confidence level, or one set without applying the weakest-link rule.
• •Issue a finding without a recommendation (a finding without a fix is a complaint, not an analysis).
• •Hedge with "I think" or "in my opinion."
• •Assign a confidence level you cannot justify with evidence.

Stage 5 — Verification

Test the conclusion adversarially. Apply intellectual honesty.

Do:

• •Ask: "What would have to be true for this conclusion to be false?"
• •Try alternative scenarios: "What if the data is wrong?"
• •Check the conclusion against every domain rule in scope.
• •Run the rule-by-rule checklist (if a domain rules file is in use).
• •Run the cognitive bias check (see below).

Pass: Loop ends. Present the conclusion. Fail: Return to Observation with the new evidence. Increment the loop counter.

Stage Markers

Each stage produces a marker — a labelled unit of work. The marker is the contract for what each stage emits; the implementation can vary.

Implementation options:

• •Step-by-step tool (e.g., sequential-thinking_sequentialthinking): one tool call per stage. Set nextThoughtNeeded=true except on Verification pass. On loop-back, set isRevision=false and needsMoreThoughts=true.
• •Prose with section headers: use ## Observation, ## Hypothesis, etc. as section dividers. One section per stage, no merging.
• •Numbered list: 1. Observation: ... 2. Hypothesis: .... Compact, useful for short analyses.

The contract is the same regardless of implementation: one stage per unit, no merging.

Calibrating Rigor

Before running the loop, classify the decision. Rigor scales with reversibility.

Is the decision reversible at low cost?
├─ No  → IRREVERSIBLE (Type 1) — run the FULL loop with high rigor.
│        Examples: choosing a database, signing a contract, hiring, deleting production data.
├─ Yes, but with non-trivial cost → REVERSIBLE (Type 2) — run the loop, accept that speed matters.
│        Examples: refactoring a function, drafting a document, picking a library.
└─ Yes, with negligible cost → TRIVIAL — Observation + Conclusion may suffice; document the abbreviated path.

Implications:

• •Type 1: Force ≥ 2 hypotheses. Spend extra effort in Evidence. Run the bias check explicitly. Do not issue a recommendation unless confidence is Medium or High.
• •Type 2: Run the standard loop. Document the reversibility so future readers know why speed was prioritized over depth.
• •Trivial: Skip Hypothesis and Evidence only if the cost of being wrong is also trivial. Otherwise run the full loop.

Worked Examples

Example 1 — Database choice

A team is choosing between PostgreSQL and MongoDB for a new application.

• •Observation: Current stack is JavaScript/TypeScript. Data model: users, orders, line items — highly relational. Team has 3 years of Postgres experience, no Mongo experience. Traffic: ~10k DAU projected. Cost ceiling: $500/mo for managed DB.
• •Hypothesis: A) Postgres fits the relational model and team experience. B) Mongo's document model could simplify some access patterns. C) A hybrid is overkill at this scale.
• •Evidence:

- A: 4 years of Postgres in production elsewhere; team velocity is high; relational queries are the hot path. - B: One access pattern (user profile + preferences) is document-shaped, but a JSONB column in Postgres covers it. - C: Hybrid adds operational cost; not justified at this scale.

• •Conclusion: Use PostgreSQL. Two findings:

- Therefore, Note has been recorded (the relational data model fits Postgres; the team has 3 years of Postgres experience). Confidence: High (multiple independent signals). - Therefore, Strength has been observed (the team's 3-year Postgres experience is a competitive capability relative to the no-Mongo experience baseline). Confidence: High (verifiable, recent). Recommendation: should adopt Postgres; must define migration plan and JSONB usage convention.

• •Verification: What if access patterns shift toward document-shaped? Postgres + JSONB covers it for the foreseeable scale. Switching cost is bounded. Decision holds.

Example 2 — Blog post accuracy review

A blog post claims: "Postgres handles 10x more concurrent connections than MySQL out of the box."

• •Observation: Claim is in paragraph 3. Source cited: a 2019 Stack Overflow answer.
• •Hypothesis: A) Claim is accurate. B) Claim is oversimplified — "out of the box" is misleading because both DBs require configuration. C) Claim is outdated.
• •Evidence:

- Postgres default max_connections=100; MySQL default max_connections=151. Numbers don't support a 10x claim. - Both DBs scale via connection pooling in practice; raw connection count is rarely the bottleneck. - Source is 7 years old.

• •Conclusion: Claim is misleading. Therefore, Major Gap has been identified (it would mislead readers). Confidence: High. Recommendation: should rephrase to "Postgres and MySQL both require pooling; their default max_connections values are similar"; or remove the claim.
• •Verification: Re-read the source — it does compare connection limits but the 10x figure is not in it. Decision holds.

Domain Rule Integration

The Evidence and Verification stages need a rule set to check against. Two ways to supply it:

Option A — User-supplied rules file. A project-specific rule document (style guide, framework, assessment standard) is provided. Evidence compares claims to the file; Verification runs a rule-by-rule checklist.

Option B — Runtime construction. No file is provided. Construct the rule set from the user's stated requirements at the start of the loop, then use it for Evidence and Verification. To elicit requirements, ask four questions during the Observation stage:

• •Success criteria — what does "done" look like for this analysis?
• •Constraints — budget, time, technical, regulatory.
• •Acceptable trade-offs — what is preferred when two requirements conflict?
• •Out of scope — what should Evidence and Verification ignore to prevent scope creep?

If the user does not answer, proceed with conservative defaults and note "requirements pending" as a finding in the Evidence stage.

The skill works either way. If neither is supplied, Evidence and Verification degrade to "logical consistency and stated requirements" — useful, but weaker than an explicit rules file.

Domain Rules File Format

A domain rules file is structured as:

# Domain: <name>
# Scope: <when these rules apply>

## Rule Group: <group name>
- **Rule:** <one-line statement of the rule>
  - **Example:** <concrete instance showing the rule satisfied>
  - **Violation indicator:** <how to detect a breach>

## Rule Group: <group name>
...

Excerpt example:

# Domain: Engineering Blog Standards
# Scope: technical blog posts published under our company name

## Rule Group: Claim verification
- **Rule:** Empirical claims must cite a source published within the last 5 years.
  - **Example:** "Postgres handles 10x more connections (Smith, 2024) [link]."
  - **Violation indicator:** Empirical claim with no citation, or citation older than 5 years.

## Rule Group: Severity tagging
- **Rule:** Every finding must end with a `[Urgency] [Direction]` label in bold.
  - **Example:** "...therefore **Major Gap** has been identified."
  - **Violation indicator:** Finding paragraph ends without a bold severity label, or the label lacks a direction.

The Evidence stage checks claims against each rule's example and violation indicator. The Verification stage walks the entire rules file rule-by-rule.

Severity / Urgency Guidance

A finding has two independent axes: urgency (how fast it must be addressed) and direction (deficit vs strength). Conflating them — as a single 7-level list does — produces ambiguous labels.

Urgency axis (default 4 levels)

Direction axis

Combining

The full label is [Urgency] [Direction], formatted in bold and stated with a fixed verb:

• •"Therefore, **Major Gap** has been identified."
• •"Therefore, **Strength** has been observed."
• •"Therefore, **Note** has been recorded."

Confidence Level

Confidence is the orthogonal axis to severity: severity says "how serious if true," confidence says "how well-supported is it."

Two dimensions

Breadth — how many independent sources support the claim:

• •Multiple independent sources
• •One credible source + logical inference
• •Single unverified source

Quality — how reliable the sources are:

Combined levels

The weakest-link rule

Confidence = weakest link in the chain. If any supporting claim in the Evidence stage is Low confidence, the whole conclusion is Low — unless that claim is non-critical to the main finding (e.g. an illustrative aside, not load-bearing evidence).

Walk the chain claim-by-claim. The conclusion's confidence equals the lowest confidence among the load-bearing claims.

Format

Append to the finding after the severity label. Example: "Therefore, **Major Gap** has been identified. **Confidence: Medium**."

Rules

• •For Type 1 (irreversible) decisions, do not issue a recommendation with Low confidence. Gather more evidence first.
• •Low confidence is a finding in itself: it tells the reader to verify before acting.

Combining Severity and Confidence

Severity and confidence are independent axes. The same severity with different confidences means very different things:

This table is read-only — it is the reader's decoder, not a rule the agent generates against. Use it to set reader expectations clearly when issuing a conclusion. The table shows common combinations as examples; for unlisted combinations, derive the implied action from the same axes (severity tells you how serious, confidence tells you how well-supported).

Cognitive Bias Check

Run this short protocol before issuing the Conclusion, and again during Verification.

If any check fails, return to Stage 3 (Evidence) and re-collect.

Red Flags — STOP and Restart the Loop

If any of these occur, cancel the current loop and restart from Observation:

• •A stage was skipped or waved off as "obvious" → Return to Observation.
• •Conclusion issued without a [Urgency] [Direction] label → Return to Observation, apply severity guidance.
• •Conclusion issued without a confidence level → Return to Observation, assign confidence.
• •Recommendation missing, or not in "should/must" form → Return to Observation, formulate a concrete recommendation.
• •Verification marked "passed" without running the full rule check → Return to Observation, re-run checklist item by item.
• •Verification marked "passed" without running the bias check → Return to Observation, run the bias check.
• •Personal language used ("I think," "in my opinion") → Return to Observation, rewrite in objective voice.
• •Cross-references not verified → Return to Observation, locate the referenced section and confirm it exists.
• •A single paragraph mixes a finding with its recommendation → Return to Observation, separate them.
• •A single paragraph covers more than one topic → Return to Observation, split into separate paragraphs.

All of these mean: cancel the loop, restart from Observation.

Rationalization Table

Agents will try to skip the loop. Pre-empt the common excuses:

Common Mistakes

Theoretical Foundations

Each component of this skill traces to established work in epistemology, decision theory, and cognitive science. The skill itself is an applied synthesis encoded as a procedural checklist for AI agents — it is not a peer-reviewed work, but every component has a documented source.

Quick Reference