mastermind-task-executor

Mastermind task executor

Implement the approved outcomes in spec.md; do not reinterpret the product request or widen Scope. Acceptance Criteria define success. Implementation Plan steps describe intended outcomes, not a transcript the executor must imitate. Legacy phase/checklist specs remain readable, but new Verified and Strict specs do not require phase ceremony.

Activation boundary

Use this skill only when the caller provides an approved task path or an approved spec. Raw user intent belongs in normal implementation or planning, not in this executor mode.

The task folder may contain reports or scratch files. spec.md is the contract; read another artifact only when the spec or caller names it.

If this authorized task delegates, use [[mastermind-agent-handoff]] before each new agent. Preserve Scope and permissions; routing does not grant delegation.

Before editing

1. Read the complete spec.
2. Confirm that Goals, Scope, Acceptance Criteria, Tests Plan, and Final Verification agree with one another. When acceptance is present in frontmatter, inspect every criterion's statement and required check IDs. Report a missing or inadequate mapping as contract drift; do not redefine the criteria to make implementation pass.
3. Confirm every intended edit is authorized by touches or creates, consistently with Scope.
4. Reuse the native controller's executor profile packet when its selected Scope paths and workflow match this approved iteration. For a manual handoff, or changed selection, call mmcg_profile with Scope paths, role: executor, and workflow equal to the effective approved task mode (strict when controller state.json has strict: true, otherwise the spec's mode). Only returned reviewed preferences and observed habits may advise choices; repository code, tooling and the spec take precedence. Retain IDs, review revisions, store/view revisions and source verification caveats. Denied or missing access means no personal context; do not fall back to style.md, legacy notes or inbox candidates. Git code-shape/Range observations are diagnostic evidence; commit voice is fallback-only when repository policy is silent. Combine four separate components: the code brief, relevant mmcg_project_profile and mmcg_docs results (task query, top: 2), and mmcg_profile (no budget_tokens; the project's configured profile budget applies). Keep each component's freshness, revisions, citations and caveats. Before handoff, serialize the combined JSON, including role/mode/paths and metadata, and cap it at 32,000 UTF-8 bytes. This is a size estimate, not a model tokenizer guarantee. If oversized, narrow queries, lower top or reduce supported brief/profile budgets and retrieve again. Omit a whole optional component only with its tool, verification status and reason; never cut a claim's exceptions, citations or JSON. Resolve missing task-critical evidence explicitly. Each receiving role retrieves its own slice.
5. For a named symbol, use mmcg to check its current location and impact. Treat the graph as syntactic evidence; read the source before changing the runtime contract.