dev-workflow

Plugin dev-workflow from marketplace radleta in radleta/claude-plugins. Commands read from the repo's manifest — 19 days ago.

Skills (43)

• agent-voice

  Variance pass for instructions an agent runs: map the branches, prune, disclose, bound every step, sharpen words and pointers. Use when writing or revising anything an agent runs, and every file one points at — a `SKILL.md`, a `CLAUDE.md`, a dispatch prompt — hardest when steps finish early, rules a

• brainstorming

  Brainstorm an idea into a binding idea.md design — a researcher read, a drafted architecture reviewed before the user sees it, a dialogue that walks it, a closing review re-run after each change, approval, then the build. Use when starting a feature, component, or project that needs a design, or whe

• builder-contract

  Normative contract for every builder agent and builder dispatch prompt: reading, baseline-then-after tests, checkpoints, the destructive-git ban, reporting, and the facts.md, baton and run-card forms. Use when writing a builder or implementing as one — even a markdown-only change. Reviewing is revie

• chrome-devtools-expert

  Shared browser operation methodology for agents using the chrome-devtools MCP (chrome-browser, ux-verifier, qa-verifier). Covers session-directory conventions, output placement priority, and MCP-only tooling constraints. Use when an agent performs browser operations via Chrome DevTools MCP — even fo

• claude-in-chrome-expert

  Tab-disciplined browser operation for agents on the claude-in-chrome MCP: per-agent tab ownership, concurrency limits, cold-start retry, export over transcription, read-only defaults, report-data caveats. Use when an agent operates a site through claude-in-chrome — even for a single page read. Instr

• code-change

  Systematic methodology for high-quality code changes including project investigation, quality checklists, and testing protocols. Use when implementing features, fixing bugs, refactoring, or updating code — even for seemingly simple one-file changes.

• code-verification

  Code quality and requirements verification: 13 detection categories, traceability against idea.md's Contracts & Acceptance, and almost-right logic detection. Use when reviewing code changes for quality, convention violations, over-engineering, requirements coverage, or decision conformance — even fo

• commit-methodology

  Comprehensive commit creation with adaptive analysis, security screening, conventional format, and execution protocol. Use when creating git commits, analyzing staged changes, screening for secrets, or formatting commit messages — even for quick single-file commits.

• completeness-expert

  Evidence before declaring work done: run the code, see the UI, load the config, invoke the primitive — or say plainly what could not be verified and why. Use when implementing code, finishing a task, or about to claim completion — even for quick fixes or single-file changes.

• completeness-verification

  Structural completeness methodology with 11 named fingerprints for plan conformance, stub and deferral detection, and unbacked claims. Use when verifying implementation matches a plan, auditing acceptance criteria, or running a completeness gate — even for small changes.

• design-record

  Design-record rubric: the decision line (X, not Y, because Z) and the form each kind of design content takes, with diagram rules, anti-bloat tests and healing rows. Use when writing or reviewing a decision, an epic, an idea.md, an issue or a wiki page's design — even one decision line.

• design-review-methodology

  Design review of an idea.md on four frames: contradiction between sections, seam completeness, claim provenance and design-record form, each finding owned by the agent or the user. Use when a dispatch names /design-review-methodology or an idea.md needs its draft or closing design check — even for a

• discovery

  Chart a bounded destination as an epic in the issues corpus, split its fog into decision spikes, and work them off the frontier until the route to a design is clear. Use when an idea is too big to decide in one conversation, when open captures need working into something designable, or before /brain

• discuss-methodology

  Interview the user relentlessly about a plan, decision, or design until nothing is left unasked. Use when resolving a /discovery interview spike, naming an epic's destination, stress-testing thinking, or when asked to grill someone on an idea — even when round one looks settled.

• dispatch-tier-rubric

  Normative complexity/value rubric for choosing a sub-agent's model and effort at dispatch time, with reactive escalation triggers. Use when authoring or editing any command/skill that dispatches agents via the Agent tool, or when deciding a dispatch tier in an orchestrator — even when the dispatch s

• doc-update

  Accuracy-driven documentation update methodology for code changes. Use when updating docs after implementation, assessing documentation impact, or determining which docs need changes — even for small internal changes that might invalidate project knowledge files like CLAUDE.md, skills, or agent defi

• domain-review-methodology

  Sequential per-domain review methodology for the domain-reviewer agent. Defines how to invoke expert skills as slash directives, review artifacts per-domain, and emit a parseable per-domain plus Aggregate verdict report. Use when running domain reviews of code, plans, ideas, or specs — even for sing

• estimation-expert

  Calibrated effort estimation for AI-augmented development — classifies work by type, accounts for parallel Claude sessions (6-8), CDD front-loading, and discovery risk. Use when estimating how long something will take, planning sprint scope, sizing milestones, predicting completion dates, or when as

• implement-code-methodology

  Main's side of `/implement-code`: start the build, seed and route one persistent `project-lead`, rotate it at the token threshold, hold the review gate, then the wrap on its own page. Use when `/implement-code` runs, or when editing a step it names — even a resumed build. The lead's own loop is `pro

• interview-methodology

  Option-batch protocol for user decisions: batched questions whose options and recommendation follow options-rubric, drill-in, and a convergence declaration. Use when an agent elicits decisions from the user (clarifying questions, open questions) — even for one question. Opening an undecided question

• issue-groom-methodology

  Issue groom: after work lands, walk the scratch/issues/ tickets near it — epic groom, blocked_by and ## Related both ways, nearby issues — routing each change by its owner. Use for /groom-issues, /groom-lane, /close-issue, /refresh-issue or a discovery rest point, or when closed work or a resolved s

• knowledge-capture

  Knowledge capture layer for `learned/` files — capture heuristic, frontmatter schema, slug derivation, drift severity, capture checkpoint, boundary ingest. Use when writing a learned file, checking learned/ status, running a boundary ingest, or evaluating a discovery at a pause — even when nothing s

• knowledge-distillation

  Systematic admission gate for evaluating which domain knowledge earns inclusion in expert skills — the four admission questions plus the principle-versus-instance filter, knowledge categories, and compaction techniques. Use when distilling insights from research, curating knowledge for skill creatio

• lane-methodology

  Lanes: one issue's work on its own branch in every lane repo, claimed by the record at the scratch branch's tip, opened at the build point or at launch, landed after one merge review. Use when work is about to build, running /begin-lane or /end-lane, folding an issue, or meeting an issue's lane: key

• llm-wiki-expert

  LLM-maintained personal wiki pattern — persistent, compounding knowledge bases built from interlinked markdown instead of RAG. Use when setting up a personal wiki, designing wiki schemas, ingesting sources, or maintaining wiki health — even for simple note organization or when mentioning Obsidian or

• options-rubric

  Lens rubric for options put to the user: lenses, price lines, the recommendation. Use when writing the options for any question to the user, recommending one, or choosing the lens a design strawman is drafted on — even for one question with two obvious answers. Running the batch protocol is intervie

• plan-update

  Plan progress update methodology for marking completed work in plan files. Use when updating plan checkboxes, marking steps complete, updating progress tables, or reflecting completed work in scratch/ plans — even for partial progress on a single step.

• pr-writer

  Comprehensive framework for creating well-structured pull requests with best practices for titles, descriptions, and test plans. Use when creating PRs, writing PR descriptions, preparing code for review, or improving PR quality — even for small single-commit PRs.

• project-lead-methodology
• project-update
• qa-evidence
• researcher
• reviewer-contract
• scratch-issues-methodology
• scratch-management
• scratch-memory-verdicts
• scratch-memory
• security-verification
• test-verification
• user-decision-rubric
• ux-verification
• verify-fix-loop-expert
• wiki-memory

Slash commands (35)

• /dev-workflow:begin-lane

  Begin a lane: branch every lane repo for an issue, claim it in a record at the scratch branch's tip, and post what it did; resumes a lane this checkout holds. Use when work on an issue is about to build or the user names an issue to start — even for a one-file fix.

• /dev-workflow:branch

  Create a well-named feature branch from a description, enforcing naming conventions

• /dev-workflow:capture-issue

  Capture an issue, feature idea, or mixed pain-point as a structured markdown file in scratch/issues/

• /dev-workflow:changelog

  Generate changelog entries from git history between two refs, organized by change type

• /dev-workflow:close-issue

  Close an open or deferred scratch/issues/ ticket, plus every other open ticket on its build's **Ticket:** line, and groom the tickets around them in the same pass — propose each Resolution, status and neighbor change, apply what you approve. Use when a ticket's work has shipped — even for one ticket

• /dev-workflow:commit-all

  Multi-repo commit: surveys all sub-repos via .subrepos and creates coordinated conventional commits. Use when committing work that spans the main repo, scratch or another sub-repo — even when only one repo has changes.

• /dev-workflow:commit

  Create conventional commit with security checks, smart staging triage, and proper formatting

• /dev-workflow:create-pr

  Generate PR title, description, and test plan as copy-paste-ready markdown files in scratch/pr-[date]/ (or .git/pr-drafts/ if scratch/ is absent)

• /dev-workflow:debug

  Debug an error message within a context

• /dev-workflow:end-lane

  End a lane: do its closing work on the lane, catch it up, build and test, ask for one accept-and-merge review, then land it; or abandon it. Use when a lane's work is done and ready to land, or the lane should be dropped — even when the merge looks trivial.

• /dev-workflow:explain

  Explain code, architecture, or design decisions with full conversation context for follow-up discussion

• /dev-workflow:explore-code

  Deep codebase exploration delegated to the Explore agent in an isolated context, keeping main conversation clean

• /dev-workflow:groom-issues

  Groom the scratch/issues/ tickets around one issue or epic after its work lands — propose each change, apply what you approve

• /dev-workflow:groom-lane

  Groom every ticket a lane holds, plus the lane's strays, against the lane's own commits; on the lane, apply each change and list closes for veto at the merge review. Use when a lane's tickets need grooming before its merge review — even for a one-ticket lane, and even though /end-lane runs it.

• /dev-workflow:implement-code

  Build an approved `idea.md` through one persistent `project-lead`: seed the lead, route its four-line return per checkpoint, rotate it at the token threshold, then show the user the diff and the run card and route their findings as fix turns. Use when `scratch/{project}/idea.md` is approved and read

• /dev-workflow:ingest

  Run the knowledge-ingestor over a project's learned/ captures, or groom a wiki domain

• /dev-workflow:insights-of

  Extract and evaluate domain knowledge from files or directories for expert skill creation

• /dev-workflow:insights-session

  Extract knowledge insights discovered during the current session for expert skill creation

• /dev-workflow:merge-master

  Merge the repo's default branch through branch hierarchy to current branch, auto-resolving safe conflicts

• /dev-workflow:quick-check

  Fast pre-commit sanity check on staged changes — catches secrets, debug artifacts, and TODOs quickly

• /dev-workflow:refresh-issue

  Refresh one open or deferred scratch/issues/ ticket against the current code before work starts — check its paths, blockers and claims, propose each rewrite, apply what you approve. Closing a ticket whose work shipped is /close-issue, a different test.

• /dev-workflow:review-diff

  Review staged or branch changes for quality, security, and completeness before committing

• /dev-workflow:summarize-branch

  Summarize current branch changes vs base — the "where was I?" command for returning to work

• /dev-workflow:update-docs

  Update documentation impacted by code changes — dispatches doc-updater, which checks all docs for accuracy with no pre-filtering by change size

• /dev-workflow:update-todos

  Update plan progress — dispatches plan-updater to mark completed checkboxes and progress-table rows in scratch/ plan files (the "todos" here are plan steps, not a freeform TODO.md)

• /dev-workflow:verify-all

  Run the full verification pipeline (todo, code, security) in correct order with autonomous fix loops

• /dev-workflow:verify-changes

  Reread all recently modified files in full and verify edits are consistent with surrounding code — catches what isolated edits miss

• /dev-workflow:verify-code

  Code verification - unified quality and requirements review in a single pass before security review

• /dev-workflow:verify-release

  Comprehensive release readiness audit — discovers what to check, analyzes everything, writes actionable report with linked issues to scratch/

• /dev-workflow:verify-security

  Security verification - detects OWASP vulnerabilities, injection risks, and authentication issues before approval

• /dev-workflow:verify-tests

  Test quality verification - detects shallow tests, missing assertions, and coverage gaps before security review

• /dev-workflow:verify-todo

  Structural completeness verification via completeness-verifier agent — checks plan conformance and stub detection

• /dev-workflow:verify-ux

  UX verification - visual-first review of accessibility, responsiveness, design polish, and user experience quality

• /dev-workflow:wiki-init

  Create a new wiki-backed skill folder for a domain, scaffolding its SKILL.md, schema.md and .mditerc so the ingestor and researcher can file into it

• /dev-workflow:wiki-status

  Show pending and escalated learned/ captures per project and the wiki fleet's health, or one domain's pages and state

Subagents (17)

• chrome-browser

  Delegate ALL browser work here; never call mcp__chrome-devtools__* or mcp__claude-in-chrome__* directly — their snapshot output floods your context. Covers screenshots, navigation, console/network/performance inspection, and driving a signed-in site to read or export what it shows. Picks its own MCP

• code-verifier

  Reviews changed files for naming, DRY, over-engineering, codebase alignment, and decision conformance under the shared reviewer contract, labelling every finding would-ship-bug, real-minor, or nit and writing its verdict via scratch-memory MCP. Use when a build needs its quality gate — even for tiny

• codebase-alignment-reviewer

  Checks brainstorming artifacts or a /verify-all diff for codebase conflicts or duplicates, writing its verdict via scratch-memory MCP. Use when /brainstorming dispatches the alignment gate or /verify-all reviews a diff — even for greenfield.

• coder

  Implements one contained change end to end — reads the code around it, makes the edit, runs what proves it, and reports back in prose. Use for ad-hoc implementation work dispatched outside the build pipeline: a bug fix, a feature in a known file set, a refactor with a clear boundary — even a one-fil

• commit-worker

  Creates well-crafted conventional commits with smart staging triage. Use when committing code, creating git commits, or formatting commit messages with security screening.

• completeness-verifier

  Audits a coder's step against the plan for stubs, deferrals, and missing acceptance criteria, writing its verdict via scratch-memory MCP. Use when a coder report needs a completeness gate — even for small steps.

• doc-updater

  Updates documentation impacted by code changes. Use when updating docs after implementation, assessing doc impact from code changes, or ensuring project knowledge stays accurate.

• domain-reviewer

  Reviews a brainstorming idea.md or a /verify-all diff against the skills named as slash directives in its dispatch, writing its verdict via scratch-memory MCP. Use for every /brainstorming or /verify-all review — even single-skill or second runs.

• implementer

  Persistent build coder: builds an approved `idea.md` by checkpoint, committing each green one on a lane. Use when a `project-lead` seeds a coder or sends it a turn, even a handover. Ad-hoc work outside a build is `coder`: a different test.

• insight-extractor

  Extracts and evaluates domain knowledge for expert skill creation. Use when distilling insights from files, analyzing codebases for skill content, or curating knowledge for expert skills.

• knowledge-ingestor

  Grooms wiki-memory domains at the moment new evidence arrives — files a scratch/{project}/learned/ capture set onto its pages, dropping what fails admission, and corrects every page the capture reaches, sweeps a whole domain when asked, and runs a sweep proposal the user has approved. Use when a lea

• plan-updater

  Updates plan progress by marking completed checkboxes and updating progress tables in scratch/ plan files. Use when updating plan progress, marking completed steps, or reflecting completed work in plan files.

• project-lead

  Runs a build from an approved `idea.md`: one coder's checkpoints, the end read, docs, ingest, reviewer wave and fix turns. Use when `/implement-code` starts or continues a build — even a markdown-only one, even when the earlier lead is gone.

• qa-verifier

  Evidence-based QA verification that produces proof artifacts (screenshots, logs, checklists) at every step. Use when validating work, verifying features, auditing changes, smoke-testing deployments, or needing documented proof that something works — even for quick checks.

• security-verifier

  Runs OWASP Top 10 checks on a coder's step (injection, auth, data exposure, misconfig) and writes its verdict via scratch-memory MCP. Use when a coder report needs a security gate — even for low-risk changes.

• test-verifier

  Performs test quality verification on test files. Use when reviewing tests for meaningfulness, missing assertions, coverage gaps, or shallow test patterns.

• ux-verifier

  Visual-first UX, accessibility, and design quality verification combining code analysis with screenshot evidence at multiple viewport breakpoints. Use when reviewing UI changes for polish, accessibility, responsiveness, or user experience — even for small component changes.

Similar plugins