dev-workflows

Plugin dev-workflows from marketplace claude-workflows in EmmadUsmani/claude-workflows. Commands read from the repo's manifest — 5 days ago.

Skills (29)

• agent-team

  Lead a team of subagents on one effort without corrupting the repo — investigate ambiguity first, partition strictly by file ownership (contended files stay with the lead), give each agent an isolated worktree, an explicit NEVER-touch list and a mandated report format, then read every diff and re-ru

• bug-intake

  Own an incoming bug from a chat thread, a tracker ticket, an error-tracker issue or a hunch end to end — read the thread, attachments and precedent, reproduce or localize, RCA it against real production facts (warehouse-data first, then prod-script), deliver a falsifiable verdict, then the RCA artif

• cloud-agent-work

  Delegate a PR-shaped change to a cloud coding agent (`<cloud_agent>` — e.g. Niteshift via its MCP, or Claude Code on the web). Write a self-contained brief, dispatch a task in `<cloud_env>` that implements, self-verifies in its own running app, opens a ready-for-review PR with screenshots and a reco

• cloud-runtime

  Run any dev-workflows skill where the laptop's resources aren't present — a Claude Code cloud session or scheduled routine, a cloud coding agent's sandbox, a fresh VM, a container. Probes the runtime profile (local vs cloud), swaps the state directory and artifact destinations to a private `<state_r

• code-style

  The user's code-shape preferences — abstraction barriers, domain boundaries, declarative over imperative, one source of truth, sparse comments — with stack-tagged sections (any language, Rails, React, GraphQL, libraries/public APIs) so a review knows which apply. Load it while writing any non-trivia

• daily-summary

  Write the `## Summary` section of the user''s daily note for a day (default today) from what they actually did — reconstructed primarily from their Claude Code sessions (`~/.claude/projects` transcripts, via the bundled digest script) and cloud-agent tasks, cross-checked against GitHub PRs, chat thr

• deep-pr-review

  Deep, context-gathered review of a pull request (often someone else's) that writes a numbered local review doc to `<review_dir>` and posts nothing to GitHub. Gathers issue-tracker, chat and repo context and maps subsystems with parallel Explore agents *before* reading the diff, reviews against the P

• demo-video

  Make an edited, narrated, high-production demo video of a feature, PR or branch with the narrated demo-video engine at `<demo_engine>` (default `~/projects/demo-reel`) — real footage of the running app, camera moves, callouts and a synthesized voiceover, rendered to MP4. Runs locally by default; dis

• dev-doctor

  Diagnose and recover a broken local dev stack before blaming your diff — blank page, "stuck loading", a page that times out, the wrong app answering on your port, specs that can't reach the database, generated output that never appears, backed-up job queues. Walks a symptom-first tree (who owns the

• firefighter-loop

  Watch your chat channels (plus your @-mentions and an optional on-call rotation channel) for incoming issues in the area you own, decide what is actionable, and hand each one to an Opus agent that runs bug-intake end to end unattended — so by the time you are online each issue has a hypothesis, RCA

• gh-stack

  Manage stacked branches and pull requests with the gh-stack GitHub CLI extension. Use when the user wants to create, push, rebase, sync, navigate, or view stacks of dependent PRs. Triggers on tasks involving stacked diffs, dependent pull requests, branch chains, or incremental code review workflows.

• mine-sessions

  Mine past Claude Code sessions (~/.claude/projects/*/*.jsonl) for recurring workflows, corrections, and hard-won domain facts, and turn them into new SKILL.md skills or improvements to existing ones. Use for "look through my past sessions and find skills to create", "what should I turn into a skill"

• one-pager

  Condense a technical plan into ONE full-screen spec sheet — a minimalist engineering-drawing-style page (six numbered panels, revision or status block, title block) a reviewer takes in at a glance. Default panels are a data model ERD, boundary diagram with real class names, numbered trace paths, API

• pr-review-graph

  Build an interactive review graph of a pull request — one dark, pannable page where every code unit the PR adds, changes or removes is a node in left-to-right lanes (entry points → logic → data/external), every dependency is a typed edge (renders, calls, uses, network, resolves, reads/writes, async,

• pr-triage

  Watch an open PR (or a whole stack) for CI results and automated review findings (Cursor Bugbot, CodeRabbit, cubic, Graphite, Socket), verify every claim against the real code before agreeing OR refuting, then fix and reply in-thread with the fixing SHA and resolve the thread — autonomously by defau

• prod-script

  Make guarded production repairs — and, as the LAST resort, get production facts — through a script the user pastes into their production console (`<prod_console_cmd>`; a Rails console is the worked example). Prod reads go to the warehouse first (warehouse-data), then the `<ops_bot>` if your team run

• render-pipeline-debug

  Debug a multi-stage media render pipeline — in-process (ActiveStorage, Shrine, Sharp/libvips) or via an external renderer (imgproxy, a headless-Chrome PDF service) — when an output looks raw/untreated, a thumbnail or PDF preview is stale, a transform "isn't working", or a page waiting on a render sp

• research-doc

  Turn a code investigation, an end-to-end trace, or a pre-implementation design into a durable personal document — a Markdown/Obsidian note under `<notes_dir>`, a page in a static docs site (`<docs_site>` — Astro, Docusaurus, MkDocs…), or an interactive HTML explainer in `<sandbox_dir>` (delegated to

• sandbox-tool

  Build a durable local tool in `<sandbox_dir>` instead of a throwaway — a reusable dev-ops script in scripts/, a per-ticket fixture toolkit with MODE=report|apply|revert|break|restore, or an exploration/preview sampler that renders every candidate through the real pipeline into a browsable HTML page.

• ship-pr

  End-to-end workflow for opening a well-formed PR. If `<cloud_agent>` is set (not `none`) the work is delegated to it via cloud-agent-work; otherwise (the default) it runs locally — branch off the right base (or a stacked base), implement, self-review the diff's shape against code-style, verify the c

• slack-message

  Draft the messages the user posts about technical work, in their voice, with every fact verified, and see them through: replies to teammates who raised an issue (ack, "it should be fixed now", a plain-language explanation, a hand-off round-up, a decision to ask for), replies to open-source reporters

• stack-surgery

  Advanced stacked-PR operations that `gh stack`'s happy path doesn't cover and that are easy to get catastrophically wrong — split an over-large branch into a stack losslessly, restack past a squash-merged or concurrently-rewritten base, cascade a fix up a live stack, adopt branches built with plain

• status-update

  Draft the user''s periodic status update for `<status_channel>` (cadence `<status_cadence>`) from whatever notes they give — none, loose lines, or full daily-note Summaries — using them as the base and filling every gap by researching the window since the last post: their Claude Code sessions (`~/.c

• vendor-api-probe

  Settle a claim about a third-party API empirically by driving the live API — preferably through the app's own API client from a local runner (`bin/rails runner`, `python manage.py shell`, a node script), else plain HTTP — instead of trusting docs or a vendor's word. Break the claim into testable ass

• verify-in-app

  Prove a change works by driving the real running app and asserting on captured payloads, measured numbers and persisted DB rows — sign in with the app's dev login, reach the surface the real way, patch window.fetch to capture API/GraphQL requests and responses, measure with getBoundingClientRect/get

• visual-explainer

  Build a self-contained, highly visual HTML page in <sandbox_dir> that makes one thing understandable at a glance — mode `explain` for a bug / RCA / mechanism handed to a triager or reviewer, mode `explore` for a solution space or a grid of candidate treatments rendered through the real pipeline — pl

• warehouse-data

  The first place to get any production data fact — query your read-only warehouse or replica (`<warehouse>` — a Snowflake/BigQuery MCP tool, `bq`, `psql` on a replica) yourself, no human round trip. Owns the prod-data hierarchy every other skill defers to — 1. `<warehouse>`, 2. the `<ops_bot>` if you

• worktree-create

  Create an isolated git worktree for a project and provision it so it can actually run — plain `git worktree add` under `<worktrees_dir>`, then a per-project checklist (ignore rules, env-file symlinks verified rather than assumed, a collision-free port, an isolated Docker Compose project, an optional

• worktree-dev-server

  Run the project's dev server (`<dev_cmd>` — `npm run dev`, `bin/dev`, `docker compose up`…) from a git worktree, detached so it survives, on the port the app's pinned URLs expect (derived from `<dev_url>`), with readiness polling that watches the process and can't be fooled by someone else's listene

Similar plugins