/maestro-companion

name: maestro-companion
disable-model-invocation: false
description: "Quick execution for small tasks — minimal run lifecycle (start + done) with evidence recording. Full LLM capability, scoped to mechanically clear tasks."
argument-hint: "<intent> [-y]"
allowed-tools:
  - Read
  - Write
  - Edit
  - Bash
  - Glob
  - Grep
  - Agent
  - AskUserQuestion
session-mode: run
contract:
  discovery: self-described
  consumes: []
  produces: []

<required_reading> @~/.maestro/workflows/run-mode.md @~/.maestro/ref/knowledge-closeout.md </required_reading>

If any required file above was not expanded into context by the host, or its content is no longer in context, Read every required file explicitly before executing any step; for knowledge closeout, Read @~/.maestro/ref/knowledge-closeout.md explicitly before closeout.

<purpose> Minimal-run execution channel. Full LLM capability with one bounded Run and evidence appended to `{run_dir}/evidence/companion-log.md`.

Use when:

• Intent is mechanically clear (no design decisions needed; file count irrelevant)
• No typed artifact consumed by downstream steps
• No gate/verdict needed for lifecycle tracking

Lightweight self-check (all must hold):

• Intent specifies a concrete, bounded action with named target (file, function, error message)
• No typed artifact consumed by downstream steps
• No gate/verdict for lifecycle tracking
• Single concern, no multi-phase span

If self-check fails mid-execution, stop and suggest `/maestro-next` for re-routing. </purpose>

<context> $ARGUMENTS — intent text + optional flags.

| Flag | Effect | |------|--------| | `-y` | Skip bounded task confirmation; never grants knowledge publication approval |

Mode detection: intent → execute | empty → [@ask] AskUserQuestion: request intent text; if still empty → display usage hint and exit

Knowledge utilities (note/log/promote) are available via `/maestro-knowledge`. </context>

<invariants> 1. Execute mode follows the exact Session identity -> bounded Run lifecycle in `run-mode.md`. 2. Evidence is append-only, non-formal (never enters gates or artifact registry) 3. No automatic multi-step orchestration — the command owns exactly one explicit single-step Session chain </invariants>

<flow>

Execute (default)

Linear: resolve Session identity -> dispatch Run -> explore -> confirm -> do -> check -> complete Run -> complete Session when the chain is terminal.

1. Create

Follow the self-start flow in `run-mode.md`. Negotiate capabilities, then execute the three receipt-chained mutations below. `--actor` carries the authorized identity (`--participant` defaults to it); use the exact `session_id` and `orchestration_revision` returned by each preceding receipt.

maestro session open "<intent>" --id <slug> --actor {actor_id} --json
maestro session chain insert --session {session_id} --step-id {step_id} --command companion --arg "<intent>" --actor {actor_id} --expected-orchestration-revision {open_orchestration_revision} --json
maestro run next --session {session_id} --actor {actor_id} --expected-orchestration-revision {insert_orchestration_revision} --json

The Session objective is metadata; `session chain insert --arg "<intent>"` supplies Companion's positional domain text. Never pass task prose through `--input`; that option accepts only sealed same-Session Artifact IDs. Consume the `run next` birth packet's `task` and structured `continuation`, and retain its exact Run locator and revisions.

Init `{run_dir}/evidence/companion-log.md`:

# Companion Log: {intent}
> run_id: {run_id} | session: {session_id}

## Evidence

2. Explore

Locate targets and gather evidence before touching anything. Methods (pick what fits):

• `maestro explore "FIND: ...\nSCOPE: ..."` — codebase search
• `maestro search "<keywords>" --type spec --type knowhow` — knowledge recall
• Agent (subagent) — multi-file analysis, cross-reference, pattern discovery
• Direct Read/Grep/Glob — known targets, quick lookups

Record findings under `## Evidence`:

## Evidence
- {file:line — what was found}
- {spec/knowhow entries loaded, or "none"}
- {subagent conclusions if used}

3. Confirm

Before executing, verify evidence is sufficient:

• Target files/locations identified?
• Change scope clear (what to modify, what to leave alone)?
• No ambiguity requiring design decisions?

If insufficient → continue exploring or ask user. If `-y` → skip user confirmation interaction, but still perform evidence sufficiency self-check. If critical targets are unlocated, continue exploring (without asking user); only the 'ask user' branch is skipped.

4. Do

Execute the task. After each meaningful action, append under `## Work Log`:

### {HH:MM} — {summary}
{outcome, files touched if any}

Rules: batch trivial reads; 1-5 lines per entry; focus on outcome not process.

5. Seal

Append outcome:

## Outcome
**Status:** done | partial
**Summary:** {1-2 sentences}
**Files:** {modified/created, or "none"}

Before completion, put accepted decisions/locked constraints in `report.md`. If a reusable recipe or pitfall emerged, stage it now:

maestro knowledge stage knowhow "<title>" --content-file <path|-> --run <run_id>
# Then use fenced `maestro run complete ... --advance` from run-mode.md.
# At terminal closeout, the completion owner executes knowledge-closeout.md,
# then `maestro session complete` with the current locator/revision/identity.

Display: `Companion done. Run: {run_id} | Evidence: {path}`

As completion owner, execute `@~/.maestro/ref/knowledge-closeout.md` (Review → Refresh → Present → Authorize → Execute → Verify) at terminal overall-task closeout; displaying only the receipt's `review_command` is insufficient. Zero candidates, rejection, or deferral allow completion with any backlog reported. If dispatched, return candidate IDs/warnings to the orchestrator instead of repeating its approval question. Do not persist