crew

Plugin crew from marketplace useful-claude-add-ons in mbadali25/useful-claude-add-ons. Commands read from the repo's manifest — 2 days ago.

Skills (33)

• crew-best-practices

  Community best practices for working with Claude Code - context management, planning, TDD, hooks, skills, subagents, slash commands and MCP - with what crew already does, where crew departs on purpose, and what is genuinely unsettled. Use when asked how to use Claude Code well, whether a practice is

• crew-brainstorm

  Turn a request into an approved direction before it becomes a spec - one question per message, options with the recommendation first, never implement before approval. Use at the start of any ticket that is not a known-cause one-subsystem fix.

• crew-change

  The change-request template, the ten questions a change board requires, and how each field maps onto ServiceDesk Plus, Jira and a local file. Use when filing, checking or closing a change request, when a production promotion asks for an approved change, or when the user says change request, change m

• crew-cloud

  Configure the official AWS and Azure MCP servers safely for a repo. Use when the user says set up AWS MCP, add the Azure MCP server, connect to my cloud account, look up AWS docs or pricing, or asks how to give the crew read access to cloud resources.

• crew-context

  Manage context exhaustion - warn near the limit, write handoff notes, and resume work after a clear or compact. Use when the user says set up handoff, context is filling up, wrap up the session, write a handoff note, resume where we left off, or asks how to clear the session without losing state.

• crew-debugging

  Find the cause of a defect before proposing a fix - read errors, reproduce, check recent changes, gather evidence from this repo's code map and verification map, then form one hypothesis and test it minimally. Use when encountering any bug, test failure, flaky test, performance problem or unexpected

• crew-diagrams

  Author architecture, process, sequence, ER and data-flow diagrams as Mermaid that pass a measured readability check (no crossing lines, nothing drawn through a box, at most 15 boxes), embed them in a generated Markdown and HTML page, render them to PNG or SVG, and produce Visio files when Visio is i

• crew-docs

  Keep CHANGELOG.md, README.md, SECURITY.md, TODO.md, ADRs, generated docs, and the API and feature reference current as work lands. Use when the user says update the changelog, keep the docs in sync, update the README, maintain TODO, document the API, list the endpoints or features, or asks which doc

• crew-execute

  Execute an approved plan task by task, in this session - TDD per step, a ruling instead of a silent deviation, and only four conditions that stop for a check-in. Use once a ticket has an approved plan.md and implementation is starting.

• crew-graph

  Build and query a code graph of this repository with graphify, keeping it on the filesystem as graph.json and fresh on commit. Use when the user asks to build or refresh the code graph, asks what calls what or what connects to what, or asks how a subsystem is wired. The graph lives on the filesystem

• crew-house-style

  House style for documents the crew hands to a human - palette, heading hierarchy, capitalization, and whether the artifact should be PDF, DOCX, HTML or plain markdown. Use when exporting an architecture write-up, runbook, report or handoff, when asked what a delivered document should look like, or w

• crew-lint

  Configure and run linters and formatters for PowerShell, PHP, Python, Terraform, and JavaScript, and wire them into the verification gate. Use when the user says set up linting, add a linter, format this code, run PSScriptAnalyzer, ruff, phpstan, or tflint, or asks why style keeps drifting.

• crew-memory

  Conventions for durable project memory across repos, including Obsidian vault integration. Use when the user says set up memory, wire up Obsidian, connect my vault, or when writing or reading code maps, decision notes, or cross-repo contracts.

• crew-notify

  Set up outbound notifications to Microsoft Teams or Telegram - deploy results and "Claude stopped and is waiting" questions - and explain the two-way MCP options. Use when the user says set up notifications, notify me, send to Teams, set up a Telegram bot, post updates to a channel, wire up a webhoo

• crew-plan

  Turn an approved spec into a step-by-step implementation plan - files, tests and risk per step, no placeholders, self-reviewed against the spec before it is shown. Use once a ticket has an approved spec.md and before any code is touched.

• crew-providers

  Set up, verify, and invoke external model providers - Codex, Kimi Code or GitHub Copilot for QA review, Gemini for design second opinions. Use when the user says set up codex, set up kimi, set up copilot, set up gemini, add a reviewer, add a design partner, configure providers, wire up the API key,

• crew-qa-standards

  Harness, QA-review and environment standards plus a report-only audit (parallel tests, pinned linters CI really runs, gate rules that can fail, QA environment isolation, rehearsed rollback, deploys that fail loudly) and a generated QA-process doc with diagrams. Use when setting up, onboarding or upg

• crew-runbooks

  Write, index, and maintain operational runbooks - deploys, rollbacks, alert response, recurring jobs, disaster recovery. Use when the user says write a runbook, document the deploy process, what do I do when X alerts, how do we roll this back, or asks to capture an operational procedure for later.

• crew-setup

  Bootstrap and configure a repository for the crew workflow, as guided phases. Use whenever the user says any of - set up crew, set up the crew, set up the team, set up the virtual team, phase setup, phased setup, run the setup, initialize crew, init crew, configure crew, onboard this repo, get this

• crew-standards

  Build-time development standards mined from crew's QA reviews. Use at /crew:plan to name the standards each step triggers, at /crew:implement for the required pre-review self-check and its stamp, and at /crew:review for the reviewer's checklist and the findings-to-standards proposals.

• crew-terraform

  Set up and run terraform-docs and tflint for a Terraform module, including the header comment block, footer.md, and README injection. Use when the user says set up terraform-docs, generate module docs, add tflint, lint terraform, or asks why the Terraform README keeps changing or reverting.

• crew-verification

  Build the verification map, wire test credentials safely, and set up Playwright. Use when the user asks which tests should run after a change, says set up the test map, add browser tests, add visual testing, validate UI changes, or when tests need credentials from AWS Secrets Manager, Vault, Key Vau

• find-skills

  Discover and install agent skills from the open skills ecosystem via the skills CLI. Use only when the user explicitly asks to find, search for, browse, or install a skill or plugin - not for general "how do I" questions, which should be answered directly.

• stack-angular

  Angular and AngularJS pitfalls, checks and verify.json wiring - change detection, RxJS composition, subscription leaks, injector hierarchy. Use when the repo has angular.json or @angular/core, or an AngularJS 1.x app, or the user asks to write or review a component, service, RxJS pipeline, or asks w

• stack-bash

  Bash-specific pitfalls, checks and verify.json wiring - quoting, pipeline exit codes, cross-platform Git Bash surprises. Use when the repo has *.sh files, or the user asks to write or review a shell script, explain why a pipeline "passed" despite a failing command, or hits a Windows/Git Bash path-ma

• stack-dotnet

  .NET-specific pitfalls, checks and verify.json wiring - DI lifetimes, async model, EF Core change tracking, plus a short .NET Framework 4.8 section for Web Forms/WCF legacy hosts. Use when the repo has *.csproj/*.sln files, or the user asks to write or review C#, wire up dependency injection, fix an

• stack-node

  Server-side and CLI Node.js and TypeScript pitfalls, checks and verify.json wiring - child processes, fetch status handling, paging that says when it stopped, unhandled rejections, module format, dates and big integers - and the Node candidate standards. Use when the repo has a package.json with ser

• stack-php

  PHP 8 pitfalls, checks and verify.json wiring - loose comparison, array key behaviour, bound SQL parameters, output escaping, unserialize, time zones - and PHP's candidate standards. Use when the repo has *.php files or a composer.json, or the user asks to write or review PHP, a PDO/mysqli query, a

• stack-powershell

  Windows PowerShell 5.1 and PowerShell 7 pitfalls, checks and verify.json wiring - encoding defaults, TLS, module compatibility, and security hardening. Use when the repo has *.ps1 or *.psm1 files, or the user asks to write or review a PowerShell script, decide between 5.1 and 7 for a target host, or

• stack-python

  Python-specific pitfalls, checks and verify.json wiring - mutable defaults, exception widening, the async model, text/bytes encoding - and a pointer to the gated PYTHON standards set and its candidates. Use when the repo has pyproject.toml, setup.py or requirements.txt, or the user asks to write or

• stack-sql

  SQL Server, MySQL and PostgreSQL pitfalls, checks and verify.json wiring - sargability, NULL semantics, per-engine locking and isolation defaults. Use when the repo has a migrations directory or *.sql files, or the user asks to write or review a query, an index change, or a migration, or asks why a

• stack-terraform

  Terraform-specific pitfalls, checks and verify.json wiring - state, plan replacements, count/for_each re-indexing, module interfaces. Use when the repo has *.tf files, a change touches a backend block or provider version, or the user asks to write, refactor or review HCL, run `terraform plan`, or ex

• stack-web

  Playwright web UI testing pitfalls, checks and verify.json wiring - role/testid locators, web-first assertions, trace and visual-baseline discipline, accessibility via axe. Use when the repo has playwright.config.* or @playwright/test, an Angular e2e suite, or the user asks to write, review or debug

Slash commands (41)

• /crew:approve-mass

  Approve ONE blocked mass delete, create or change - only you can, by typing this

• /crew:approve

  Approve a ticket's plan - only you can, by typing this; the prompt hook records the receipt

• /crew:autopilot

  Report a ticket (status), drive it until a human is needed (run), or run an approved set as parallel lanes (wave)

• /crew:brainstorm

  Brainstorm a request into an approved direction, before it becomes a spec

• /crew:change

  File, check and close a change request — SDP, Jira or local

• /crew:config-setup

  Set up crew config from a menu - machine or repo layer, dry run then apply, or delete the repo config

• /crew:config

  Show where every crew setting comes from, and set machine or repo config from a menu

• /crew:confirm-config

  Confirm a sensitive crew config change - only you can, by typing this twice

• /crew:debug

  Find the cause of a defect before anyone proposes a fix

• /crew:diagram

  Create or refresh diagrams from the actual code

• /crew:docs

  Update the documents this change should touch — and only those

• /crew:done

  Close a ticket - needs an accepted review receipt, a clean gate, a passing completion audit, current artifacts and docs

• /crew:emergency

  Declare an incident - stand the gates down, spin up parallel investigation lanes, and record what was skipped

• /crew:fix

  The light path - every lifecycle phase present, each compressed to one step

• /crew:gate

  Take a repository's merge gate down and put it back, from the export

• /crew:graph

  The code graph - one-line status, the repo's sanctioned refresh with the pair check, and queries

• /crew:handoff

  Write the handoff note for the next session

• /crew:help

  What to do next, and what any crew command is for

• /crew:implement

  Implement an approved plan for a ticket, then tests, docs and review

• /crew:init

  Guided phased setup for this repo — resumable, one phase at a time

• /crew:jira-sync

  Sync a ticket between Jira (via MCP) and the local cache

• /crew:migrate

  One-time move of a 0.20 crew setup to the 1.0 layout - preview, backup, atomic apply, rollback

• /crew:model

  Show or change which model backs each crew role, and probe that it actually answers

• /crew:obsidian-sync

  Sync a ticket between an Obsidian Kanban board and the local cache

• /crew:onboard

  Learn this codebase once and write a durable, verifiable code map

• /crew:plan

  Turn an approved spec into a step-by-step plan, then get it approved

• /crew:promote

  Promote a build to the next environment, with the full post-deploy proof

• /crew:reference

  Generate the API, feature and integrations reference from the code, with anchors

• /crew:review

  Independent QA review of the current diff (Codex, Kimi, Copilot, or Claude - first that probes clean)

• /crew:runbook

  Write, update, or audit operational runbooks

• /crew:sdp-sync

  Sync a ticket between ServiceDesk Plus (via MCP) and the local cache

• /crew:spec

  Fill the ticket contract from an approved direction - Intent, Exclusions, Evidence, Unknowns, Touch, Acceptance checks

• /crew:split

  Split an oversized ticket into 2-5 children, with evidence and one confirmation, in any tracker but SDP

• /crew:status

  Read-only crew status for this repo - config, roster, tickets, review budget, gate, codemap, gitignore, handoff

• /crew:survey

  Research the app for real gaps and propose options with tradeoffs

• /crew:ticket

  Removed in crew 1.0 - use /crew:spec

• /crew:upgrade

  Removed - use /crew:migrate, which upgrades a pre-0.20 config itself

• /crew:verify

  Build or refresh the verification map from evidence

• /crew:webtest

  Drive Playwright's Test Agents inside the ticket lifecycle - a healer skip is a finding, never accepted

• /crew:work

  Removed in crew 1.0 - use /crew:implement

• /crew:worktrees

  Where worktrees go (worktrees.root), a read-only survey of them, and owner-confirmed removal

Subagents (5)

• explorer

  Read-only codebase investigator. Use proactively for any question about where code lives, how a flow works, or what depends on what. Returns a short map, never file contents. Examples: <example> Context: The user needs to know where something lives before changing it. user: "Where is the rate limiti

• researcher

  External research only - library and framework docs, API and SDK behaviour, version and migration questions, vendor pricing and limits, standards, RFCs, prior art. Use when the answer lives outside this repository. Read-only; every claim carries its source. Examples: <example> Context: The answer li

• reviewer

  Hostile reviewer for one change's diff, and the Claude fallback when Codex and Copilot are unavailable. The crew 1.0 successor of qa-reviewer. Never runs in the session that wrote the code. Not for a broad quality pass over unchanged code. Examples: <example> Context: A diff is ready for review and

• security

  Read-only security reviewer. Use before merging any change touching authentication, authorization, user input, uploads, SQL, secrets, PII, infrastructure permissions, the CI/CD pipeline, or the dependency tree. Do NOT use this for actively exploiting a running system; crew ships no agent for that. E

• session-relay

  Transport-only relay for messages between sessions, pinned to the full id `claude-haiku-5-5` (Haiku 5.5). The main session hands it what to send and to whom; it formats and sends, and condenses inbound peer messages. One per session. It is not a review or investigation role and never acts on message

Hooks (8)

• SessionStart

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/crew-hook.sh" SessionStart

• UserPromptSubmit

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/crew-hook.sh" UserPromptSubmit

• PreToolUse

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/crew-hook.sh" PreToolUse

• PostToolUse

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/crew-hook.sh" PostToolUse

• SubagentStart

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/crew-hook.sh" SubagentStart

• PreCompact

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/crew-hook.sh" PreCompact

• Notification

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/crew-hook.sh" Notification

• Stop

  bash "${CLAUDE_PLUGIN_ROOT}/hooks/scripts/crew-hook.sh" Stop

Similar plugins