/ask-maestro
Router for choosing the next Maestro skill or lifecycle recipe.
$ npx -y skills add ReinaMacCredy/maestro --skill ask-maestro --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/ask-maestro
Context preview
The summary Claude sees to decide when to auto-load this skill.
Router for choosing the next Maestro skill or lifecycle recipe.
SKILL.md
ask-maestro.SKILL.mdname: ask-maestro
version: 1.0.5
description: "Router for choosing the next Maestro skill or lifecycle recipe."
disable-model-invocation: true
Ask Maestro
You do not remember every Maestro route, so ask.
This skill is a router. It chooses the next Maestro skill or lifecycle recipe; it does not replace the chosen skill. After routing, follow that skill and the repo harness.
Quick Start
Run `maestro status` before routing. If implementation might overlap another session, run `maestro active` and respect any conflict-handoff hard stop.
If the next move is still unclear, run `maestro loop next`. It is read-only and routes from local artifacts. Read the selected recipe with `maestro loop show <recipe>`.
Rule: loop next recommends; outcome/proof/memory verbs write. Use `maestro loop next --chain` to explain current chain position without writing, `maestro loop outcome` to record structured attempt outcomes and transition receipts after native work, `maestro loop trace <card>` to audit card-scoped receipts, and `maestro loop improve` for read-only improvement proposals. Do not use hidden stores, hidden schedulers, silent recipe mutation, or proof/QA bypass.
The Main Flow: Idea To Ship
Most Maestro work moves through this path:
1. `maestro-design` - use for unsettled behavior, brainstorm, workflow design, specs, PRD synthesis, domain modeling, grilling, UX shape, or skill/harness design. Stay here until material forks are locked and the feature handoff is finalized. "lock all", "all rec", and all-recommendations batches must be a DecisionSet or separate child decisions, not one compressed summary lock. 2. `maestro-card` - use after design approval or for already-scoped executable work: implement, bugfix, verify, QA, close, release, archive, or continue active work. Behavior-changing implementation defaults to test-first work unless the task is explicitly docs/config/mechanical/light/spike. 3. `maestro-card` ship path - use `maestro loop show ship` for close, release, local install, archive, and proof-backed handoff boundaries.
Do not route approved build work back into design just because more discussion is possible. Do route back to design when the requested outcome depends on an unsettled product, lifecycle, schema, command, or UX decision.
On-Ramps
- Setup, sync, install, hooks, global skills, doctor, or harness initialization:
use `maestro-setup`.
- Repo-wide improvement, architecture review, code review, harness backlog, or
read-only deepening proposals: use `maestro-audit`.
- Raw incoming bug report with an obvious reproduction target: use
`maestro-card` and the bugfix loop: reproduce, root cause, smallest correct fix, regression coverage, verification, scoped commit.
- Raw incoming feature request with open questions: use `maestro-design`.
- External PRD or plan that is already approved enough to execute: use
`maestro-card` intake.
- Small same-session work: use the Progress task surface through
`maestro task setup` or `maestro task add/start/done`; proof is still required on completion.
Cross-Session Continuation
Use Maestro artifacts instead of chat memory:
- Design continuation: `maestro feature reconcile <id>` writes or refreshes the
pre-finalize receipt, then `maestro feature finalize <id>` writes the handoff; the next session starts from that handoff.
- Active work continuation: `maestro status`, `maestro task show <id>`, and
`maestro card show <id>` reveal the current task, locked acceptance, and proof state.
- Shared-store coordination: use `maestro active`, links, messages, and the
`conflict-handoff` recipe when sessions may overlap.
Quick Router
- "What should I use?" -> this skill, then the closest row below.
- "Set up Maestro here" -> `maestro-setup`.
- "Brainstorm/design/grill/spec/PRD/domain model this" -> `maestro-design`.
- "Go build/implement/fix/verify/close/archive/release" -> `maestro-card`.
- "Review/audit/find improvements/propose backlog" -> `maestro-audit`.
- "Work while away/asleep/keep looping" -> `maestro-card`, then
`maestro loop show unattended`.
- "Record a reusable lesson" -> `maestro-card`, then
`maestro loop show learning`.
- "There are active sessions or possible overlap" -> `maestro loop show
conflict-handoff`.
Completion criterion: one route is chosen with the exact next skill, recipe, or command; if no route fits, the missing fact is explicit before fallback.
Stop
If no route fits, say what is missing and use `maestro loop next` before inventing a custom flow. Custom flows still use Maestro verbs, proof, QA, authority gates, hard stops, and the loop grammar: perceive -> choose -> act -> observe -> learn -> continue.
Read more
name: ask-maestro version: 1.0.5 description: "Router for choosing the next Maestro skill or lifecycle recipe." disable-model-invocation: true
Ask Maestro
You do not remember every Maestro route, so ask.
This skill is a router. It chooses the next Maestro skill or lifecycle recipe; it does not replace the chosen skill. After routing, follow that skill and the repo harness.
Quick Start
Run `maestro status` before routing. If implementation might overlap another session, run `maestro active` and respect any conflict-handoff hard stop.
If the next move is still unclear, run `maestro loop next`. It is read-only and routes from local artifacts. Read the selected recipe with `maestro loop show <recipe>`.
Rule: loop next recommends; outcome/proof/memory verbs write. Use `maestro loop next --chain` to explain current chain position without writing, `maestro loop outcome` to record structured attempt outcomes and transition receipts after native work, `maestro loop trace <card>` to audit card-scoped receipts, and `maestro loop improve` for read-only improvement proposals. Do not use hidden stores, hidden schedulers, silent recipe mutation, or proof/QA bypass.
The Main Flow: Idea To Ship
Most Maestro work moves through this path:
1. `maestro-design` - use for unsettled behavior, brainstorm, workflow design, specs, PRD synthesis, domain modeling, grilling, UX shape, or skill/harness design. Stay here until material forks are locked and the feature handoff is finalized. "lock all", "all rec", and all-recommendations batches must be a DecisionSet or separate child decisions, not one compressed summary lock. 2. `maestro-card` - use after design approval or for already-scoped executable work: implement, bugfix, verify, QA, close, release, archive, or continue active work. Behavior-changing implementation defaults to test-first work unless the task is explicitly docs/config/mechanical/light/spike. 3. `maestro-card` ship path - use `maestro loop show ship` for close, release, local install, archive, and proof-backed handoff boundaries.
Do not route approved build work back into design just because more discussion is possible. Do route back to design when the requested outcome depends on an unsettled product, lifecycle, schema, command, or UX decision.
On-Ramps
- Setup, sync, install, hooks, global skills, doctor, or harness initialization:
use `maestro-setup`.
- Repo-wide improvement, architecture review, code review, harness backlog, or
read-only deepening proposals: use `maestro-audit`.
- Raw incoming bug report with an obvious reproduction target: use
`maestro-card` and the bugfix loop: reproduce, root cause, smallest correct fix, regression coverage, verification, scoped commit.
- Raw incoming feature request with open questions: use `maestro-design`.
- External PRD or plan that is already approved enough to execute: use
`maestro-card` intake.
- Small same-session work: use the Progress task surface through
`maestro task setup` or `maestro task add/start/done`; proof is still required on completion.
Cross-Session Continuation
Use Maestro artifacts instead of chat memory:
- Design continuation: `maestro feature reconcile <id>` writes or refreshes the
pre-finalize receipt, then `maestro feature finalize <id>` writes the handoff; the next session starts from that handoff.
- Active work continuation: `maestro status`, `maestro task show <id>`, and
`maestro card show <id>` reveal the current task, locked acceptance, and proof state.
- Shared-store coordination: use `maestro active`, links, messages, and the
`conflict-handoff` recipe when sessions may overlap.
Quick Router
- "What should I use?" -> this skill, then the closest row below.
- "Set up Maestro here" -> `maestro-setup`.
- "Brainstorm/design/grill/spec/PRD/domain model this" -> `maestro-design`.
- "Go build/implement/fix/verify/close/archive/release" -> `maestro-card`.
- "Review/audit/find improvements/propose backlog" -> `maestro-audit`.
- "Work while away/asleep/keep looping" -> `maestro-card`, then
`maestro loop show unattended`.
- "Record a reusable lesson" -> `maestro-card`, then
`maestro loop show learning`.
- "There are active sessions or possible overlap" -> `maestro loop show
conflict-handoff`.
Completion criterion: one route is chosen with the exact next skill, recipe, or command; if no route fits, the missing fact is explicit before fallback.
Stop
If no route fits, say what is missing and use `maestro loop next` before inventing a custom flow. Custom flows still use Maestro verbs, proof, QA, authority gates, hard stops, and the loop grammar: perceive -> choose -> act -> observe -> learn -> continue.
Local-first harness for agent-built codebases. Humans steer, agents execute, maestro is the substrate. maestro is a single Rust binary that gives a coding agent a durable place to work.
Repo: ReinaMacCredy/maestro
Other skills on maestro.
- /cli-for-agent
Designs or reviews CLIs so coding agents can run them reliably: non-interactive flags, layered --help with examples, stdin/pipelines, fast actionable errors, idempotency, dry-run, and predictable structure. Use when building a CLI, adding commands, writing --help, or when the
Open skill - /docs
Update repository documentation to match the current state of the codebase. Local replacement for the remote /docs command (which needs the Claude GitHub app). Use when the user says /docs, "update the docs", "sync the README", "document this feature", or asks you to refresh
Open skill - /gitnexus-cli
Use when the user needs to run GitNexus CLI commands like analyze/index a repo, check status, clean the index, generate a wiki, or list indexed repos. Examples: \"Index this repo\", \"Reanalyze the codebase\", \"Generate a wiki\"
Open skill - /gitnexus-debugging
Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: \"Why is X failing?\", \"Where does this error come from?\", \"Trace this bug\"
Open skill - /gitnexus-exploring
Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: \"How does X work?\", \"What calls this function?\", \"Show me the auth flow\"
Open skill - /gitnexus-guide
Use when the user asks about GitNexus itself — available tools, how to query the knowledge graph, MCP resources, graph schema, or workflow reference. Examples: \"What GitNexus tools are available?\", \"How do I use GitNexus?\"
Open skill

