mastra-ai/skills · Official

mastra-factory

Operate and supervise Mastra Factory through `mastra api factory`. Use for Factory status or queue summaries, project and work-item inspection, metrics,…

All-time #5305 Trending #1500
8-week activity

Installation

$ npx skills add https://github.com/mastra-ai/skills
Feature your product here Skill page unit · reach builders installing agent skills View pricing →

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from mastra-ai/skills.

npx skills add https://github.com/mastra-ai/skills

Browse all from mastra-ai/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 79
License LICENSE
Default branch main
Open issues 0
Status Active

History

  1. First recorded snapshot · 6 installs

SKILL.md

Mastra Factory Supervisor

Use mastra api factory as the operational control plane for Factory.

Default behavior

For status, inspection, diagnosis, queue review, or recommendation requests:

  1. Stay read-only.
  2. Select the sole or explicitly named project; report choices when ambiguous.
  3. Inspect project state, work items, metrics, thresholds, decisions, attention, and supervisor health/session.
  4. Correlate stages, revisions, sessions, decisions, and health findings.
  5. Report active/queued work, blocked or unhealthy items, running sessions, pending decisions, human attention, and one recommended next action.
  6. Execute a recommendation only when the current request or a previously granted operating scope authorizes it.

Required reference

Read [references/factory-supervisor.md](references/factory-supervisor.md) before running Factory commands. It is self-contained and includes target selection, output control, JSON envelopes, command discovery, the read-only workflow, mutation protocol, governance constraints, durable-session limitation, and error handling.

Safety boundary

  • Never read or reveal .env, bearer tokens, saved login contents, or platform/provider credentials.
  • Never invent IDs, stages, revisions, request IDs, or sessions.
  • Establish the user's operating scope before mutating. Authorization may cover one action or grant standing autonomy over named projects, resources, action types, or objectives.
  • Within a clear delegated scope, act without asking for confirmation before every mutation. Ask only when an action is ambiguous, outside scope, or materially more destructive than the granted authority.
  • Fetch current state before a write, make the smallest in-scope change, then refetch and report IDs, revisions, and final state.
  • Use transitions—not metadata updates—for stage changes, with the current revision and a fresh UUID request ID.
  • Never use private HTTP routes to bypass unsupported CLI operations.
  • If work-item start lacks a supported durable user session, report the block; never substitute the supervisor session or invent a session UUID.