crew

Plugin crew in pixeloven/crew. Commands read from the repo's manifest — 7 days ago.

Skills (21)

• activation-contracts

  Use when a role must run without an interactive request, when wiring CI or a scheduler to an agent, or when choosing triggered versus interactive dispatch. Defines the event → dispatch → output contract.

• agent-platform-design

  Use when designing an agent capability, choosing MCP vs AXI vs CLI, deciding skill vs agent, or placing a surface at operator or autonomous-runtime scope. Covers naming and federation boundaries.

• autonomous-agent-design

  Use when designing or evaluating an autonomous agent workflow. Covers task decomposition, tool scoping, result contracts, failure modes, and the shadow → draft → autonomous maturity sequence.

• decision-records

  Use when a change settles an architectural or hard-to-reverse choice, or when writing, reviewing or superseding an ADR. Covers when to record a decision, required content, and superseding.

• delta-handling

  Use when a worker proposes deviating from an active plan, when deciding whether a change needs sign-off, or when recording a mid-execution change. Defines auto-approvable vs human-escalated deltas.

• doctor

  Use when asked to run Crew Doctor, verify installation or onboarding, debug missing roles/skills, or report what this session can reach. Separates installed, enabled, runtime-loaded, granted, degraded, and untested evidence.

• github-repo-workflow

  Use when editing a GitHub repository, opening or reviewing a PR, or operating on issues. Covers clone → branch → edit → commit → push → PR using pre-wired GH_TOKEN and git credentials.

• incident-runbook-template

  Use when writing an incident report, diagnosis brief, degradation issue, health sweep, or repeatable runbook. Structures what broke, where, why, blast radius, recommended action, and confidence.

• intake-process

  Use when triaging issues or PRs, labeling an unsorted backlog, choosing a handler, or defining intake conventions. Classifies domain, work type, complexity, and routing decision.

• learn

  Use when asked to learn a CLI, MCP server or vendor tool this project uses, to learn from this session's corrections, failures, denials or review findings, or to turn a Crew inventory gap into a lesson. Drafts one proposal per lesson and never applies it. Not for teaching a topic.

• mcp-server-design

  Use when building MCP tools or servers in any framework (FastMCP is the worked example). Covers tool boundaries, discovery descriptions, structured errors, failure semantics, registration, and the MCP vs AXI vs CLI decision.

• onboarding

  Use when onboarding or re-auditing a project against Crew. Defaults to a read-only report; edits require explicit apply authorization. Preserves mature entry files, safety tripwires, delivery contracts, and runbook pointers.

• orchestration-patterns

  Use when planning multi-agent work, dispatching workers, or splitting and reconverging a task. Covers sequential, parallel, and mixed execution, dispatch packets, convergence, writer isolation, and harness bindings.

• plan-execution

  Use when executing an approved plan, dispatching a worker or review, or driving phased work to done. Covers phase order, test-first phases, acceptance criteria, validation gates, loop-back budgets, delta routing, and completion evidence.

• plan-generation

  Use when developing a plan with the operator before execution. Covers when planning is warranted, checklist → detailed-spec progression, phases, dependencies, success criteria, and execution handoff.

• plan-validation

  Use when deciding whether a phase can advance, whether work is complete, or what evidence “done” requires. Defines acceptance evaluation, validation-gate promotion, invalid completion signals, and the closing retro that hands lessons to learn.

• platform-glossary

  Use when naming a platform concept, locating a workload, or writing docs/manifests with shared terms. Resolves app, surface, consumer, tenant, gateway, workload, deployment, project, skill, operator, and Crew vocabulary.

• pr-review-checklist

  Use when reviewing code/manifests for merge, approving a PR, or requesting changes. Applies scope, secrets, seam, load-bearing-assumption and AI dark-pattern checks, then each touched stack's own review checks.

• release-and-versioning

  Use when adding a release workflow, cutting a release, changing tag rules, or reviewing artifact publication. Requires one semver line, file-owned versions, changelog notes, checksums, and verified provenance.

• seam-alert-routing

  Use when a protected change needs sign-off or a risky finding must be surfaced. Defines who decides, the host escalation channel, waiting behavior, and formats for PR comments, pauses, or filed issues.

• seam-detection

  Use when scanning a diff for protected changes or reviewing widened permissions, secrets, storage, or runtime contracts. Detects registered seam crossings and agent-runtime exit-code changes, and defines the finding format.

Subagents (6)

• implementer

  Privileged write path. Executes one scoped task end-to-end in whatever stack the project uses — application code, infrastructure as code, configuration, CI. Parallel-capable under Lead's orchestration; stays strictly within the dispatched scope. Use for any write work: code, manifests, configs, PRs.

• investigator

  Read-first diagnosis. Investigates a failing test, CI run, bug report, alert or incident, traces flows across components, and detects drift between declared and actual state. Produces findings, not fixes. Use by dispatch or on a trigger for any failure, plus live-infrastructure health where the proj

• lead

  Planning and orchestration, run as the session agent rather than dispatched (e.g. claude --agent crew:lead). Owns multi-step work end-to-end: develops the plan with the operator, dispatches worker agents, mediates deltas, escalates blockers. Writes plans and dispatches — does not mutate code directl

• researcher

  Answers from the record and option analysis. Answers a question briefly from what the project has written down — repo, docs, git history, corpus — or weighs alternatives, adding the web, and recommends one. Replies are drafts, never sent; recommends, never decides or implements. Use for project ques

• reviewer

  Adversarial pre-merge review. Hard-coded skeptical posture — assumes problems exist until the diff proves otherwise. Use for code review, manifest review, design review, and seam detection on any PR or proposed change.

• triage

  Lightweight intake filter. Classifies incoming issues and PRs by domain and work type, applies labels, and routes to the right handler. Makes no execution decisions. Use on a trigger or by dispatch to process incoming work or a backlog without engaging Lead or more expensive roles.