Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →reinamaccredy/maestro-card
Card work in a project using Maestro after design approval: use for implement, fix, verify, QA, close, release, continue, or unattended prompts like use loop, keep looping, work while away/asleep.
Passed 13 of 18 test cases with the skill, and 2 of 18 without it.
and 16 more in the full report
13 fixed3 passed either way6 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 13 test cases the skill fixed. Same model, same prompt, with and without the skill.
I am unsure which lifecycle recipe to execute next for card-987. I am tempted to run a write verb to force state transition or guess the next step. What read-only command explains chain position and recommends the next recipe without mutating state?
| Checked | Without skill | With skill |
|---|---|---|
| Uses `maestro loop next` as the read-only router to obtain lifecycle recommendations. | Missed | Passed |
| Treats loop next recommendations as read-only guidance without mutating underlying card state. | Missed | Passed |
The instructions your model reads when the skill loads.
Maestro uses three work levels: High = Card, Mid = CardKind / workflow kind,
and Low = Task. Feature, Bug, Chore, Custom, Decision, Idea, and Progress are
CardKinds, not separate high-level objects. Progress is a lightweight CardKind
that stores many low Tasks in progress.yml; legacy type: task cards remain
readable for compatibility. This skill covers the active-work cluster: the task
work loop, card/feature lifecycle, proof, and QA gates. Design
(maestro-design), audit (maestro-audit), and setup (maestro-setup) have
their own skills.
Activate with a known session id:
maestro hook record --event skill_activation --skill maestro-card --session <session_id>
First step in a session: run maestro active (pull-only) to see what other
live sessions are working on before you claim. If a peer is on a related card,
connect yours with maestro link add <your-card> <their-card>; maestro never
auto-links. Once linked, coordinate through the channel: maestro msg send <their-card> "<text>" and maestro msg read. An [inbox] N new (...) -> maestro msg read line on STDERR before any command means a linked peer is
waiting -- clear it with maestro msg read (see reference/work.md).
Inbox messages are advisory coordination only: they can suggest an ordering
relationship, but they do not block work. Record an explicit Task blocker when
execution order matters. Reply when the message poses a question or needs a
decision; an FYI needs no reply.
Phase 0: design-to-card gate. Before task setup, feature prepare, source
edits, implementation tests, or other work verbs, ask:
If the answer starts in design and the owning card/feature or fresh handoff is
missing, stop. Bind chat-only or standalone Decision records to a Feature/card
contract and refresh/finalize the handoff through the supported feature
lifecycle path first. Progress rows cannot be used to implicitly end design.
If the design approval included "lock all", "all rec", or all-recommendations
decisions, confirm they landed as a DecisionSet or separate child decisions. Do
not build on a compressed summary lock; run maestro decision audit --compressed
test cases passed, vs 2 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.