Skip to content
Development
Skill

/ask-maestro

Router for choosing the next Maestro skill or lifecycle recipe.

From plugin
maestro
22418 skills
Install
$ npx -y skills add ReinaMacCredy/maestro --skill ask-maestro --agent claude-code

How 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.md
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.

Read more
Ships withmaestro

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.

Get the whole plugin
Stats
224
Stars
23
Forks
Active
Maintenance
Rust
Language
MIT
License
17d ago
Last commit
7mo ago
Created

Repo: ReinaMacCredy/maestro

Other skills on maestro.