@xcraftmind/mastermind 0.24.0 → 0.26.0

package/share/skills/mastermind-incident-response/references/investigation-playbook.md

@@ -0,0 +1,173 @@
+# Investigation playbook — find root cause via mmcg + git + .mastermind/tasks/
+
+Reference for the [`mastermind-incident-response`](../SKILL.md) skill, Phase 3. After symptoms have stopped, find what actually broke.
+
+The patterns below are concrete recipes. Use them when the corresponding question comes up — don't run all of them speculatively (wastes context).
+
+---
+
+## Question 1 — "What changed recently?"
+
+Most production incidents trace to a recent change. Start here.
+
+```bash
+# What was committed in the window when the incident started?
+git log --since='2 hours ago' --until='now' --oneline
+
+# What was committed in the file/dir we suspect?
+git log -20 --oneline -- <suspected/path/>
+
+# What did the most recent commits actually change?
+git log -5 -p --stat -- <suspected/path/>
+```
+
+Then for any candidate commit:
+```bash
+git show <commit-sha> --stat       # what files
+git show <commit-sha>              # full diff
+```
+
+**Heuristic for ranking suspect commits:**
+- Most recent first
+- Bigger diffs first (more surface to have bugs)
+- Commits to "interesting" paths (hot paths, recently-incident-prone dirs)
+- Commits that touch the symptom's component (grep error message in commit diff)
+
+---
+
+## Question 2 — "What's the blast radius of the change?"
+
+If you have a suspect commit, what does it touch that could explain the symptom?
+
+```bash
+# What symbols changed in the suspect commit?
+git show <commit-sha> --name-only
+
+# For each changed function/method, what calls it?
+mmcg_callers <symbol> --language <lang>
+
+# Transitive — what else depends on it?
+mmcg_impact <symbol> --depth 3 --language <lang>
+```
+
+If the blast radius doesn't include the symptom's component → the suspect commit probably isn't the cause. Move to the next candidate.
+
+If the blast radius DOES include the symptom's component → strong candidate. Read the code change.
+
+---
+
+## Question 3 — "Were the relevant specs supposed to catch this?"
+
+Spec for any recent change should have had Tests Plan + Observability Plan + Performance Considerations sections (per spec template).
+
+```bash
+# Find the spec for this work (look in .mastermind/tasks/ for matching name or timestamp)
+ls -lt .mastermind/tasks/
+
+# Read its Tests Plan
+grep -A 20 "Tests Plan" .mastermind/tasks/<NNN>-<name>.md
+
+# Read its Observability Plan
+grep -A 10 "Observability Plan" .mastermind/tasks/<NNN>-<name>.md
+
+# Read its Performance Considerations
+grep -A 10 "Performance Considerations" .mastermind/tasks/<NNN>-<name>.md
+```
+
+Then ask:
+
+- **Did the Tests Plan cover this failure mode?** If no, that's a gap in spec quality. Action item: "harden Tests Plan for similar work."
+- **Did Observability fire for this failure?** If no, was it instrumented? If yes, did it page? Detection time is its own failure to root-cause.
+- **Did Performance Considerations anticipate this load?** If the issue is scale-related, the spec should have predicted it.
+
+These answers feed the postmortem's "Why detection took N minutes" and "Workflow improvements" sections.
+
+---
+
+## Question 4 — "Has this happened before?"
+
+```bash
+# Check known gotchas
+grep -B 2 -A 4 -i "<symptom keywords>" CONTEXT.md
+
+# Check don't-touch list
+grep -B 2 -A 4 "<file or path>" CONTEXT.md
+
+# Check past postmortems (if you keep them)
+ls postmortems/ 2>/dev/null || ls docs/postmortems/ 2>/dev/null
+grep -ri "<symptom>" postmortems/ 2>/dev/null
+```
+
+If yes → this is a **recurrence**. That's a MUCH bigger finding than a first-time incident:
+- The previous fix didn't stick
+- The prevention didn't transfer
+- The CONTEXT.md entry was either missing or ignored
+
+A recurrence postmortem should focus heavily on Phase 5 (feed forward) and propose a STRUCTURAL fix, not just a code fix.
+
+---
+
+## Question 5 — "What's the failure mode?"
+
+Classify the failure into a category. This guides both immediate response and what kind of structural improvement to propose:
+
+| Category | Examples | Typical fix |
+|---|---|---|
+| **Code bug** | null-pointer, off-by-one, wrong condition | Code change + test |
+| **Configuration bug** | wrong env var, bad timeout, missing flag | Config change + config validation in CI |
+| **Schema / migration** | column missing, type mismatch, FK violation | Migration + pre-flight schema check |
+| **Capacity / scale** | OOM, connection pool exhausted, CPU pegged | Scaling + capacity model in spec template |
+| **External dependency** | upstream API down, vendor SLA breach | Degraded-mode fallback + dep health probe |
+| **Race / concurrency** | lost write, deadlock, double-spend | Concurrency model documented + tests |
+| **Data quality** | bad input from upstream, encoding issue | Validation at boundary + schema for inputs |
+| **Process** | bad deploy, wrong branch, missed code review | Pipeline / process improvement |
+
+The category determines whether the postmortem proposes a CODE fix, a PROCESS fix, or a SYSTEM fix (architectural).
+
+---
+
+## Question 6 — "What's the smallest reproducer?"
+
+Before declaring root cause found, get a reproducer:
+
+- **Unit test** — fastest; if you can write one that fails, you understand the bug
+- **Integration test** — if behavior depends on multiple components
+- **Manual reproduction** — if neither possible, document the exact steps
+
+A bug without a reproducer is a bug not understood. Don't ship the fix until you can reproduce.
+
+The reproducer becomes Test 1 in the fix spec's Tests Plan.
+
+---
+
+## Five-whys discipline
+
+For the postmortem's "What went wrong" section, apply five-whys:
+
+1. **Why** did the symptom happen? → because <proximate cause>
+2. **Why** did that happen? → because <one level deeper>
+3. **Why** did THAT happen? → because <one more>
+4. **Why**?
+5. **Why**?
+
+Stop when:
+- The answer is a system property (e.g., "the deploy pipeline is asynchronous, so we ran without rollback safety")
+- The answer would require changing fundamental architecture (escalate, don't propose in postmortem)
+- You've gone 5 levels — at some point further whys are speculation
+
+Document the chain in the postmortem. The deepest "why" you can credibly answer is the **systemic** root cause; that's what the action items should address.
+
+---
+
+## When to stop investigating
+
+You have enough when:
+
+1. ✓ You can name the proximate cause (the code/config/data thing that broke)
+2. ✓ You can name a systemic cause (the why that goes deeper than "engineer X did Y")
+3. ✓ You have a reproducer (or explicit decision that one is not feasible)
+4. ✓ You know what would have prevented this (a test? a check? a config? a process?)
+
+Then go to Phase 4 — write the postmortem.
+
+If after 1-2 hours you can't answer #1-2 → escalate or accept "we couldn't determine root cause" honestly in the postmortem. **Don't fabricate a cause to look complete.** Unknown root causes are themselves a finding.

package/share/skills/mastermind-incident-response/references/postmortem-template.md

@@ -0,0 +1,184 @@
+<!--
+  Mastermind blameless postmortem template.
+
+  HOW TO USE
+  - Copy this file to postmortems/<YYYY-MM-DD>-<short-name>.md (or docs/postmortems/, whichever convention your repo uses)
+  - Fill in every <placeholder> with concrete content
+  - Delete sections that genuinely don't apply (e.g., if a sev3 had no user impact)
+  - Keep the file short — a postmortem nobody reads is worse than no postmortem
+  - Action items get linked back here from the .mastermind/tasks/ specs they spawn
+
+  BLAMELESS PRINCIPLE
+  Write about systems, not people. If a person made a judgment call, frame it as:
+  "given the information available, the action was reasonable; the lesson is that
+  information X needs to be more accessible / surfaced earlier."
+
+  Anti-pattern: "Engineer X deployed without testing."
+  Better: "The deploy pipeline allowed merging with failing tests because the
+  test job was marked non-blocking three weeks ago."
+
+  TONE
+  - Past tense (this happened, this was tried)
+  - Concrete (timestamps, error messages, file paths)
+  - Honest about unknowns ("we don't yet know why X" is better than fabricating)
+-->
+
+# Postmortem: <short title>
+
+## Summary
+
+**Date:** <YYYY-MM-DD>
+**Severity:** <sev0 | sev1 | sev2 | sev3>
+**Duration:** <N minutes from start to mitigation, M minutes to full resolution>
+**Impact:** <one sentence — what users / systems were affected, magnitude>
+
+<One to three sentences: what happened, what was the user impact, what was the resolution. Anyone reading should know what this is about in 30 seconds.>
+
+---
+
+## Timeline (UTC)
+
+| Time | Event |
+|---|---|
+| <HH:MM> | First failure observed (per <source — log, monitor, user report>) |
+| <HH:MM> | Detection (paged / reported in #ops / noticed by …) |
+| <HH:MM> | Incident response engaged |
+| <HH:MM> | Triage complete; severity declared as <sev>; <initial hypothesis> |
+| <HH:MM> | Mitigation: <what was done> |
+| <HH:MM> | Symptoms stopped |
+| <HH:MM> | Root cause identified |
+| <HH:MM> | Full resolution (fix deployed / patch applied / dependency restored) |
+| <HH:MM> | Postmortem started |
+
+---
+
+## What happened
+
+<2-4 paragraphs of narrative. Lead with the proximate cause. Then walk through how the symptom manifested, what was tried, what worked, what didn't.>
+
+<If multiple things went wrong in sequence (cascading failure), name each component and how they interacted.>
+
+---
+
+## Root cause analysis
+
+### Proximate cause
+<The specific code change / config / dependency that triggered the symptom. Cite file:line, commit SHA, or external system.>
+
+### Systemic causes (five-whys chain)
+1. **Why** did the symptom happen? <because…>
+2. **Why** did that happen? <because…>
+3. **Why** did that happen? <because…>
+4. **Why** did that happen? <because…>
+5. **Why** did that happen? <because…>
+
+The deepest "why" we can credibly answer is the **systemic root cause** — that's what the action items should address.
+
+### Failure category
+
+<Pick one from the investigation-playbook.md table: code bug / configuration bug / schema / capacity / external dependency / race or concurrency / data quality / process.>
+
+---
+
+## Detection
+
+**Why did detection take <N> minutes?**
+<Why didn't this fire earlier? Was there a monitor for this failure mode? Did the monitor fire but not page? Did it page someone who couldn't act?>
+
+**What detection improvements would have caught this <K> minutes sooner?**
+<Specific: "a P99 latency alert on /api/messages would have fired at 14:33 instead of 14:38 when users reported.">
+
+---
+
+## Mitigation
+
+**Why did mitigation take <M> minutes?**
+<Was the rollback path clear? Was someone with deploy access available? Was the on-call runbook accurate?>
+
+**What mitigation improvements would have stopped the bleed sooner?**
+<Specific: "a feature flag for the new code path would have let us disable in seconds instead of waiting for a rollback deploy.">
+
+---
+
+## What went well
+
+<Yes, name what worked. Reinforces good patterns and supports psychological safety. Be specific.>
+
+- <Thing 1 — e.g., "The Datadog dashboard for /api/messages clearly showed the regression once someone looked at it">
+- <Thing 2 — e.g., "On-call rotation was clear; <person> was immediately available">
+- <Thing 3>
+
+---
+
+## What didn't go well
+
+<The hard part — be honest, but blameless. Focus on systems, gaps, processes.>
+
+- <Thing 1 — e.g., "The spec for this change didn't include an Observability Plan, so the new code path had no metrics">
+- <Thing 2 — e.g., "The deploy pipeline reported success even though the smoke test failed">
+- <Thing 3>
+
+---
+
+## Where the mastermind workflow gates failed (if applicable)
+
+*Only relevant if this incident came from a change shipped through the mastermind workflow. If it came from a hot-fix, manual ops, or pre-mastermind code, skip this section.*
+
+- **Critic dimension(s) that should have caught this:** <e.g., "dimension #3 Observability — the design didn't include any metric / log on the failure path, and the critic missed flagging it">
+- **Spec template section(s) that were empty or weak:** <e.g., "Observability Plan was 'n/a — no production runtime' but this code DOES run in production">
+- **Auditor checks that passed when they shouldn't have:** <e.g., "auditor verified tests ran, but spec didn't include a load test, so capacity issue wasn't tested for">
+
+→ Each of these maps to a workflow-improvement action item (see Action Items below).
+
+---
+
+## Action items
+
+Each action item gets owned, dated, and either (a) becomes a `.mastermind/tasks/` spec or (b) becomes a CONTEXT.md update.
+
+| # | Action | Type | Owner | Due | Spec / CONTEXT entry |
+|---|---|---|---|---|---|
+| 1 | <Specific change — code, config, process, doc> | <code-fix \| context-md \| workflow-improvement \| process> | <person> | <YYYY-MM-DD> | <`.mastermind/tasks/NNN-…md` or "CONTEXT.md → Known gotchas">|
+| 2 | <…> | <…> | <…> | <…> | <…> |
+
+**Avoid action items like:**
+- ❌ "Be more careful when deploying" — not actionable
+- ❌ "Add monitoring" — too vague
+- ❌ "Train the team on X" — training without process change rarely sticks
+
+**Prefer action items like:**
+- ✓ "Add P99 latency alert on /api/messages at 200ms threshold via Datadog monitor — `.mastermind/tasks/NNN-add-messages-latency-alert.md`"
+- ✓ "Add 'capacity test' as mandatory line in Performance Considerations section of spec-template — `.mastermind/tasks/NNN-spec-template-capacity.md`"
+- ✓ "Add CONTEXT.md known-gotcha: 'Redis cluster mode silently drops MULTI on key migrations during rebalance'"
+
+---
+
+## Feed forward to CONTEXT.md
+
+The following entries get appended to project `CONTEXT.md`:
+
+### Known gotchas (append)
+- **<one-line summary of the failure pattern>** — <bite scenario>. See `postmortems/<this file>`.
+
+### Don't-touch list (if applicable, append)
+- **`<path or symbol>`** — <constraint that emerged from this incident>
+
+### Decision log (if architecture changed, append)
+- **<YYYY-MM-DD> — <decision name>** — <one-sentence decision, why, alternatives rejected, source: postmortems/<this file>>
+
+---
+
+## Unknowns
+
+*If root cause is partially or fully unknown, name what's unknown. This is honest — fabricating a cause is worse than admitting uncertainty.*
+
+- <Unknown 1 — e.g., "We don't yet know why the Redis client closed the connection at 14:32 specifically; logs are too sparse to tell">
+- <What would we need to know it: a debug log, a packet capture, a repro environment>
+
+---
+
+## Sign-off
+
+- **Author:** <name>
+- **Reviewers:** <names who read this before publishing>
+- **Distribution:** <team / org / wider>

package/share/skills/mastermind-incident-response/references/triage-checklist.md

@@ -0,0 +1,117 @@
+# Triage checklist — first 5 minutes
+
+Reference for the [`mastermind-incident-response`](../SKILL.md) skill, Phase 1. Run through these questions / commands in parallel with talking to the user. Goal: enough information to choose a mitigation in Phase 2.
+
+---
+
+## What to ask the user (priority order)
+
+1. **Symptom — what's observable?**
+   - "What error are you / users seeing?"
+   - Paste actual error message, not a paraphrase
+   - Single sentence, ideally
+   - Example: `❌ "the app is slow"` → `✓ "/api/messages returning 500 with 'connection refused' since 14:32"`
+
+2. **Scope**
+   - "How many users / what % of traffic / which surfaces?"
+   - Distinguish: 1 user vs 1 region vs everyone
+   - If unclear → ask: do we know yet?
+
+3. **Severity classification** (pick one; if unclear, default to one level higher):
+   - **sev0** — total outage / safety / data loss; immediate
+   - **sev1** — major surface broken; act within minutes
+   - **sev2** — partial degradation; act within hours
+   - **sev3** — cosmetic / single user; act within days
+   - Severity drives whether to ask "should we page?" before doing anything else
+
+4. **Timeline — when did this start?**
+   - "What's the first timestamp you have?"
+   - Convert to UTC immediately, write it down
+   - This is what you'll correlate against deploys / git log
+
+5. **What's been tried?**
+   - Avoid duplicate effort
+   - If user already rolled back / restarted / flipped a flag — note it
+   - **Critical:** if a previous action made things WORSE, the next action shouldn't be the same kind
+
+---
+
+## What to gather in parallel (mmcg / git / files)
+
+Run these via `mastermind-researcher` subagent or directly — should take < 1 minute:
+
+```bash
+# What committed recently (might have shipped the issue)
+git log --since='2 hours ago' --oneline
+
+# What's deployed (if there's a deploy marker file or git tag)
+git tag --sort=-creatordate | head -5
+git log -10 --oneline
+
+# What specs were finished recently
+ls -lt .mastermind/tasks/ | head -10
+
+# Are there in-progress specs that might be related?
+git status -s
+
+# Is the index reachable (am I working from stale info?)
+mmcg_status
+
+# Quick scan for the symptom — has this been seen before?
+grep -i "<error string>" CONTEXT.md 2>/dev/null
+```
+
+---
+
+## Severity-driven branching
+
+After triage, the severity determines what comes next:
+
+| Severity | What you do next |
+|---|---|
+| **sev0** | Ask user: "should we page on-call before continuing?" Then go to Phase 2 with the most conservative mitigation. |
+| **sev1** | Go directly to Phase 2. Watch the clock — if no improvement in 10 min, escalate. |
+| **sev2** | Phase 2 with more deliberation — rollback is still preferred if available. |
+| **sev3** | Skip Phase 2's "stop bleeding" urgency. Go to Phase 3 investigation. The postmortem (Phase 4) may even be lightweight (a CONTEXT.md gotcha entry, not a full doc). |
+
+---
+
+## What to write down (timeline starts now)
+
+For the postmortem later, you'll need a timeline. Start it during triage:
+
+```
+14:32 UTC — first failure observed (per <source>)
+14:36 UTC — user reported in #ops
+14:38 UTC — incident response engaged
+14:39 UTC — triage complete; sev1 declared; investigating recent deploys
+...
+```
+
+Even rough timestamps are useful. The postmortem can refine them from logs later, but having any timeline beats reconstructing from memory.
+
+---
+
+## Anti-patterns during triage
+
+- **Don't speculate about root cause yet.** Triage answers WHAT and WHEN, not WHY. WHY comes in Phase 3.
+- **Don't write a fix yet.** Even if you're sure you know what's wrong, Phase 2 prefers rollback over hot patches.
+- **Don't change scope unilaterally.** "While I'm here let me also fix X" is exactly the wrong instinct under time pressure.
+- **Don't blame the deploy author** — the system allowed the bad deploy; that's the systemic issue, not the human.
+
+---
+
+## When to call this phase done
+
+You're done with triage when you can answer all five:
+1. ✓ What's the symptom? (concrete)
+2. ✓ Who/what is affected? (scope)
+3. ✓ Severity?
+4. ✓ When did it start?
+5. ✓ What's been tried?
+
+…and you have either:
+- A candidate mitigation in mind, OR
+- An explicit "I don't know yet, going to Phase 3 first" decision
+
+Move to Phase 2.

package/share/skills/mastermind-prompt-refiner/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: mastermind-prompt-refiner
+description: Refines a user's rough, vague, or under-specified prompt into a clean, executable one before handing it off to another agent or skill. Use as a front-stage filter in delegation workflows, or when the user says "improve this prompt", "rewrite this prompt for an agent", "make this clearer".
+metadata:
+  version: 0.1.0
+  authors:
+    - mastermind
+  tags:
+    - prompt-engineering
+    - workflow
+  model: sonnet
+---
+
+# Prompt Refiner
+
+Sits between the user and a downstream agent (planner, executor, reviewer, …) and rewrites the raw user input into a refined prompt. The downstream agent sees the refined version, not the user's brain dump.
+
+This is a **one-pass** skill: input goes in, refined prompt comes out. Not a tutorial on prompt engineering, not a general-purpose advisor. If the user wants to learn prompt engineering, point them at [`references/techniques.md`](references/techniques.md) instead.
+
+## When to use
+
+- User's request is rough, vague, missing context, or bundles multiple intents
+- About to spawn a subagent and you want the input to be a clean prompt, not a raw idea
+- User explicitly asks "improve this prompt", "rewrite this prompt", "make this clearer for an agent"
+- Do NOT use to refine prompts that the user wants *you* to answer right now — only when the next step is another agent/skill. If they want an answer, just answer.
+
+## Process
+
+### 1. Read the input. Identify three things.
+- **Goal** — what does the user actually want to accomplish?
+- **Next consumer** — who reads the refined prompt next? (planner / executor / reviewer / unspecified)
+- **Gaps** — what's vague, missing, or contradictory?
+
+### 2. Decide: refine inline, or ask first?
+
+| Situation | What to do |
+|---|---|
+| Goal is clear, 1-3 small gaps (format, length, edge case) | Refine inline. Mark unresolvable gaps with `<NEEDS: …>` placeholders. |
+| Goal itself is ambiguous (multiple plausible interpretations → different prompts) | Ask 1-3 targeted questions. Stop. Do not guess. |
+| Prompt is already tight | Return the original with a one-line "no changes needed". |
+
+Do not stack: max 3 clarifying questions, max one refinement pass per call.
+
+### 3. Apply the refinement.
+
+Walk the [refining checklist](references/refining-checklist.md) and pick the smallest set of fixes that close the gaps. Common fixes (full list in the checklist):
+
+- Lead with a specific verb tied to a deliverable
+- State the output shape (length, structure, format)
+- Surface 1-2 constraints (what NOT to do)
+- Add a success criterion
+- Replace hardcoded values with `{{PLACEHOLDERS}}` if the prompt will be reused
+
+For technique-level decisions (when to add CoT, few-shot, XML structure, role framing), see [`references/techniques.md`](references/techniques.md). Pick the smallest set — don't stack techniques to show off.
+
+### 4. Hand off.
+
+Output in this exact shape. The spawner copies the `## Refined prompt` block into the next agent's input:
+
+```markdown
+## Refined prompt
+
+<the rewritten prompt, ready to paste verbatim into the next agent>
+
+## What I changed and why
+
+- <change 1> — <reason>
+- <change 2> — <reason>
+
+## Gaps the user still needs to fill
+
+- <NEEDS: gap 1>
+- <NEEDS: gap 2>
+```
+
+Omit the "Gaps" section entirely if there are none.
+
+## What you do NOT do
+
+- Add scope or features the user didn't ask for
+- Invent details (deadlines, file paths, names, numbers) — mark with `<NEEDS:>`
+- Refine prompts that are already tight ("no changes needed" is a valid output)
+- Stack multiple refinement passes in one call
+- Execute the prompt — that's the next agent's job
+- Critique the user's writing style — only fix what affects machine consumption
+
+## Output examples
+
+### Vague request → refined
+
+**Input:** "help me write a better prompt for analyzing customer feedback"
+
+**Output:**
+```markdown
+## Refined prompt
+
+You are analyzing customer feedback messages. For each message:
+1. Classify sentiment as `positive`, `negative`, or `neutral`.
+2. Extract up to 3 themes (1-3 words each).
+3. Extract up to 3 actionable issues (short imperative phrases).
+
+Output JSON:
+{"sentiment": "...", "themes": [...], "actions": [...]}
+
+Constraints: handle 50-500 word messages. If the message is empty or off-topic, return {"sentiment": "neutral", "themes": [], "actions": []}.
+
+Feedback message:
+<NEEDS: actual message text>
+
+## What I changed and why
+
+- Added concrete classification labels — original "analyze" was undefined
+- Added JSON output shape — downstream tools need parseable output
+- Added empty-input handling — production prompts must define edge behavior
+
+## Gaps the user still needs to fill
+
+- <NEEDS: actual feedback message to analyze>
+```
+
+### Already-tight prompt → passthrough
+
+**Input:** A 200-word prompt with role, format, constraints, and success criterion already in place.
+
+**Output:**
+```markdown
+## Refined prompt
+
+<original prompt verbatim>
+
+## What I changed and why
+
+No changes needed — prompt has clear role, format, constraints, and success criterion.
+```
+
+### Ambiguous goal → ask
+
+**Input:** "improve my onboarding"
+
+**Output:**
+```markdown
+I need 2 clarifications before I can refine this:
+
+1. Improve onboarding for whom — end users, new employees, API consumers, something else?
+2. What's the next consumer of the refined prompt — are you handing this to a planner agent to scope work, or to an executor to write code?
+
+(Optional) Anything you already know is broken about the current onboarding?
+```
+
+## References
+
+- [`references/techniques.md`](references/techniques.md) — when to apply CoT, few-shot, XML, role-based, prefilling, chaining
+- [`references/refining-checklist.md`](references/refining-checklist.md) — anti-patterns to fix + before/after examples
+
+## Pair pieces
+
+The runtime companion is the `mastermind-prompt-refiner` subagent. Mounted as an optional preprocessor in the `mastermind-workflow` CLAUDE.md.