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

Configuration

Set analysis parameters before the loop. Every parameter has a safe default; omit any to use the default.

config:
  rigor: Type 2        # Type 1 / Type 2 / Trivial
  evidence: Default    # Restricted / Default / Extended
  audit: Standard      # Standard / Full
  checks: Standard     # Minimal / Standard / Full
  confidenceFloor: Default  # Default / HighOnly / Relaxed

| Parameter | Default | Options | Effect | |-----------|---------|---------|--------| | rigor | Type 2 | Type 1 / Type 2 / Trivial | Loop depth. Type 1 forces all checks | | evidence | Default | Default / Restricted / Extended | Evidence sources. Restricted = user-provided only | | audit | Standard | Standard / Full | Output detail. Full = metadata table appended | | checks | Standard | Minimal / Standard / Full | Which checks run. Full = Fallacy + Bias + Assumption Audit | | confidenceFloor | Default | Default / HighOnly / Relaxed | Minimum confidence to recommend. HighOnly = all decisions need High |

Evidence scope

| Scope | Available sources | |-------|-------------------| | Restricted | User-provided documents, data, references only | | Default | User sources + agent training knowledge | | Extended | User + agent + web search / API tools (where available) |

Audit output

| Mode | Output | |------|--------| | Standard | [Severity] [Direction] + confidence + recommendation | | Full | Standard + Analysis Metadata table (loop count, hypotheses, claim confidence distribution, check results) |

Checks profile

| Profile | Checks run | |---------|------------| | Minimal | Formal Fallacy Check only | | Standard | Cognitive Bias Check + Formal Fallacy Check | | Full | Bias + Fallacy + Assumption Audit |

Confidence floor

| Floor | Rule | |-------|------| | Default | Type 1 → Medium+ required; Type 2/Trivial → any | | HighOnly | Every recommendation requires High confidence | | Relaxed | Type 2 accepts Low (exploratory analysis) |

All-default: Rigor: Type 2, Evidence: Default, Audit: Standard, Checks: Standard, ConfidenceFloor: Default.

To use: include a config block before the loop, or state parameters inline.

The 5-Stage Loop

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

| # | Stage | Question | |---|-------|----------| | 1 | Observation | What is present? | | 2 | Hypothesis | What could it mean? | | 3 | Evidence | What supports or refutes each candidate? | | 4 | Conclusion | What is the final judgment? | | 5 | Verification | Under what conditions is this wrong? |

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."
• If audit: Full, append the Analysis Metadata table (see Self-Audit Output below).

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).
• Run the formal fallacy check (see below).

Pass: Loop ends. Present the conclusion. Fail: Return to Observation with the new evidence. Increment the loop counter. If no new evidence is available: Exit with the current confidence level; document the limitation.

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.

| Stage | Marker label | Loop counter | Next stage | |-------|--------------|--------------|------------| | Observation | Observation | 1 (or N+5 on loop-back) | Hypothesis | | Hypothesis | Hypothesis | 2 (or N+6) | Evidence | | Evidence | Evidence | 3 (or N+7) | Conclusion | | Conclusion | Conclusion | 4 (or N+8) | Verification | | Verification (pass) | Verification | 5 (or N+9) | — (loop ends) | | Verification (fail) | Verification | 5 (or N+9) | Loop back to Observation |

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, set rigor in the config block. Rigor scales with reversibility.

Is the decision reversible at low cost?
├─ No  → config: rigor: 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 → config: rigor: Type 2 — run the loop, accept that speed matters.
│        Examples: refactoring a function, drafting a document, picking a library.
└─ Yes, with negligible cost → config: rigor: Trivial — Observation + Conclusion may suffice; document the abbreviated path.

Implications:

• Type 1: Force ≥ 2 hypotheses. Spend extra effort in Evidence. Run the bias check and fallacy 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.

Assumption Audit

Before running the loop, identify what the analysis takes for granted. Hidden assumptions cause more errors than flawed logic.

Process:

1. List assumptions the analysis framework depends on — what must be true for the framework to be valid?
2. Classify each by risk:

• High: conclusion reverses if assumption is false.
• Medium: conclusion weakens but does not reverse.
• Low: negligible impact on the conclusion.

1. Mark any assumption testable during Evidence as testable.
2. During Evidence, verify every testable assumption as a claim with its own confidence level.

| # | Assumption | Risk | Testable | |---|-----------|------|----------| | 1 | Data source is current and authoritative | High | Yes | | 2 | Stakeholder's problem description is complete | Medium | Limited | | 3 | No regulatory change pending | Low | No |

If a High-risk assumption is unverified by the end of Evidence: it counts as a load-bearing claim with Confidence: Low. The weakest-link rule applies automatically. Document it:

"Therefore, Note has been recorded (conclusion assumes [X]; this could not be verified).

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: 
# Scope: 

## Rule Group: 
- **Rule:** 
  - **Example:** 
  - **Violation indicator:** 

## Rule Group: 
...

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 indica

…

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [hyuce](https://github.com/hyuce)
- **Source:** [hyuce/master-brain](https://github.com/hyuce/master-brain)
- **License:** MIT

Install and usage instructions live in the source repository linked above.