autodev-core

Plugin autodev-core from marketplace autodev in djnsty23/claude-auto-dev. Commands read from the repo's manifest — yesterday.

Skills (52)

• a11y

  Accessibility audit against WCAG 2.1 AA — run the automated scan, then the manual checks tooling cannot make, and report in this project's format.

• adversarial-loop

  Run an independent-context tests-first review loop: an adversary model authors failing acceptance tests, the building agent fixes against them, and bounded review rounds end on an exact verdict token. Use for changes where a wrong fix is expensive — gates, harnesses, security paths, anything that gr

• audit

  Parallel quality audit across specialized agents. Finds bugs, violations, and quality issues. Use audit for fixes, brainstorm for features.

• auto-brain

  Run Brain's assigned mission while the user is away. Use when asked to coordinate the fleet autonomously, carrying work through implementation, verification and the authorized release boundary.

• auto

  Autonomous task execution with testing and security. Works through all tasks without stopping.

• autoreview

  Review a pull request with a cheap model before it merges, and write the review receipt merge-lock.js requires. A strict-JSON verdict (approve, request_changes or escalate) from a low-cost reviewer, checked against the story's acceptance criteria. Only an escalation reaches the expensive opus review

• brain

  Drive an authorized product mission from idea through implementation, independent review and live verification. Use when asked to run the fleet, replace manual coordination, or resume Brain.

• brainstorm

  Feature ideation, dead code cleanup, and product thinking. Proposes new features and architecture improvements — not bugs or violations (use audit for those).

• commit

  Commit, push and open a pull request to this repo standard: a conventional subject, a body saying why the change is needed, the message passed by file rather than inline, no co-author trailer, explicit paths staged rather than everything, and the gate run before the push.

• core

  The prd.json schema and task system used by every autodev workflow. Load before reading or writing prd.json, creating stories, or interpreting a task's passes field.

• cost-reconcile

  Reconcile what something costs from the bill, the usage and the quota together, before any spend number is reported or a paid run starts: charged unit, billed versus gross versus pending, invoice cadence, built-in limits, and unknown kept apart from zero.

• deploy-check

  After a merge to the production branch, wait for that exact revision to be live, run the product's smoke command against the live URL, and record PASS, FAIL or TIMEOUT with evidence per acceptance item. A failure opens one draft revert pull request and nothing else: no push to main, no merge, no pro

• design-review

  Look at the rendered screens before UI work is called done: rate or score pages and modals, bug-hunt a flow, or check a page that looks off on phones or wide screens. Judge it with real content, every state (empty, loading, error) and whether the user's task completes. Use when asked to rate all pag

• design

  Creates distinctive UI with preserved structure. Avoids generic AI aesthetics. Use when designing or refining user interfaces.

• framework-radar

  Research coding agents, agent SDKs, orchestration frameworks, harnesses, protocols, evaluations and relevant videos, then execute every selected hypothesis against the current repository. Use when asked what is new, what agent practices are worth testing, or to run the framework radar.

• heal

  Sweep every repo you are working on for vulnerabilities an attacker can actually reach, prove each one is reachable, and fix the ones that survive. One word starts the whole operation.

• isolate

  Start work in a fresh git worktree branched from the remote default branch, so parallel agents never share a tree. Use before the first edit of any feature, fix or task, and whenever a repo has more than one session working in it.

• learn-from-fixes

  Rank the failure classes this project actually ships by mining its own fix commits, then propose executable gates for the top ones. Use when the same kind of bug keeps reaching manual QA.

• marketing-radar

  Research current marketing-platform changes and practitioner videos, extract claims with incentives and boundary conditions, then safely execute every selected hypothesis. Use for recurring marketing research, campaign or funnel ideas, and supplied marketing videos.

• perf

  Web performance audit against this project's Core Web Vitals and bundle budgets, with a fixed report format.

• production-radar

  Read existing production errors, job heartbeats and deployment failures into backlog candidates with evidence. Use for production radar or when asked whether production signals reveal missing work.

• prove

  Capture the evidence a change actually works: the BEFORE state while the defect still reproduces, the AFTER state once it passes, both put where a reviewer sees them, so no completion claim rests on the author saying so.

• reflect

  Review the current session for user corrections, retries, wrong assumptions and slow paths, and turn each lasting lesson into a concrete edit to an existing skill, rule or check. Use at the end of a session or when asked to reflect.

• review

  Review changed code for correctness and quality, then apply the project-specific checks Claude Code's built-in reviewer does not know about.

• role-chain

  Run one story through standing role sessions, PM to Spec to Eng to QA to Copy, each with its own model, worktree and skills, handing the next a typed handoff file instead of sharing a context window.

• rule-ab-testing

  Every proposal gets measured against the current approach and at least one variant before it is adopted, and the measurement is reported. Load before recommending a change, writing a detector, or claiming something is cheap, fast, or better.

• rule-agent-concurrency

  How many agents to spawn, at which model and effort, so a fan-out does not burn the session's limits. Load before spawning subagents, running a workflow, or dispatching background sessions.

• rule-design-system

  Design-token rules: semantic tokens over inline colors, where tokens are defined, and the one case hardcoded colors are allowed. Load before writing or editing component styles.

• rule-diagnosis

  A wrong fix costs one cycle; a wrong diagnosis costs every cycle until someone questions the premise. Reproduce before explaining, suspect the frame before inventing a mechanism, and attribute a failure before repairing it. Load before proposing any cause, fix, or explanation.

• rule-file-organization

  Choose recoverable paths for generated artifacts. Keep scratch state private, and preserve shared PRD archives, project rules and verification evidence in tracked locations. Load before writing an artifact.

• rule-gate-integrity

  Ways a gate or test proves nothing while looking decisive: grading a copy of itself, passing on emptiness, a canary firing for the wrong reason, a summary read as a verdict, a probe pointed at the wrong invocation. Load before writing a gate, a mutation harness, or any check guarding generated outpu

• rule-local-first

  Verification happens on this machine, in a browser you drive, before anything is pushed. Covers the local gate, the batched publish cadence, why GitHub Actions is not the gate, and why a restored browser session fakes a pass. Load before verifying, before pushing, and before any visual check.

• rule-options-protocol

  How a decision panel looks when one is shown: a clickable AskUserQuestion panel of vetted, complementary options with a recommendation in every block. Whether to show one is the operator's decision policy.

• rule-own-the-loop

  A coordinator carries a task to done itself and pings the owner only for an owner decision, a PR ready to merge with both receipts, or a deploy outcome. Everything else goes to the daily digest. Steer the worker you have, pick the cheapest capable model tier. Load before notifying the owner or spawn

• rule-ramifications

  The eight ways a change passes typecheck, build, and a clean console and is still wrong. Derived from 3,127 fix commits across three production repos. Load before implementing a feature and again before calling it done.

• rule-report-shell

  The house shell for any HTML report, audit, or findings page an agent publishes: summary-first cards that expand on click with staggered detail, themed scrollbars, and a token system that survives both themes. Load before writing or editing an HTML page a person will read.

• rule-security

  Security rules this project always applies: secret handling, input validation, parameterized queries, and Supabase RLS. Load before writing code that touches credentials, user input, queries, or auth.

• rule-thumb-first

  Interface design starts from where the hand is and what each element MEANS, not from a palette. Reach zones, progressive density, and the rule that unearned signal destroys real signal. Load before designing a screen, choosing a theme, or adding colour, motion, or output.

• rule-verification

  What counts as done for each kind of change: the required verification per task type, and the cross-cutting checks that apply to every task. Load before marking any task complete.

• rule-windows

  Windows host traps for commands and scripts: Git Bash versus PowerShell syntax, heredoc and inline-script mangling, Python cp1252 file I/O, native exit status, MSYS path rewriting, killing a process tree, supervised servers. Load on a win32 host before writing a shell command, script or .ps1.

• rule-workflow-spine

  The order the other skills run in. Four steps: isolate, build, prove, ship. Each carries the condition that ends it. Load before starting any feature, fix or task, and whenever you are about to pick a skill and cannot tell which one comes first.

• security

  Find the security defect in code before it ships: secrets in source or in schema files, Supabase RLS and access policies, session and sign-out scope, a user id read from the payload or a header instead of the verified session, and unvalidated external input.

• seo

  Audit a page or a site for search and AI-answer visibility: metadata and Open Graph tags in the SERVED html, JSON-LD that actually parses, canonical, sitemap and robots correctness, and which AI crawlers are allowed to read or to cite the site.

• sessions

  Sweep Claude Code Desktop sessions — classify which are finished, check their worktrees are safe to discard, write resume stubs, and archive the safe ones. Use for "archive finished sessions", "session cleanup", "how many sessions do I have open".

• setup-project

  Scaffolds new projects or onboards existing ones. Detects stack, creates monorepo/single-app, configures strict tooling. Use for greenfield or first-time setup.

• ship

  Deploy, release or promote a change and prove the served version is the one that was tested: gates, security, target identity, then the live check on every entry point. Use whenever a change is about to reach staging or production, or before saying it is live.

• spec

  Turns a one-line product idea into a spec, a data model and a prd.json backlog, so setup-project and auto can run without a manual planning hop. Use when the user describes something to build rather than a change to make, and as step 2 of the new-app chain it owns.

• standards

  The conventions this project holds code to — UI state completeness, design tokens, type-safety boundaries, query-key shape, and the anti-patterns to flag on sight.

• thrift

  Find the best value before recommending or running anything paid: state the job, survey every credible provider and host, check each one can do the job, normalise prices to the unit of work, then test the cheapest viable option once on the exact inputs before scaling up.

• unslop

  Sweep a product's routes at phone and desktop widths for layout slop (mismatched control rows, glued controls, double borders, short stripes, missing gutters, small tap targets, truncated text, broken rhythm, overflow), turn what is measured into fix stories by component, hand them to auto, and prov

• verifier

  Build a project-local verify skill and driver script that starts the app, drives its real controls through its main user flows and reports pass or fail with evidence. Use when a product repo has no scripted way to exercise the app the way a user does.

• writing-for-agents

  Writing a document another agent will execute: a SKILL.md, a CLAUDE.md or AGENTS.md line, a subagent brief, a scheduled-task prompt, a doc reached by a pointer. Use when creating or editing any of those.

Subagents (4)

• code-reviewer

  Reviews code changes for quality, patterns, and potential issues. Use before commits or PRs.

• plan-reviewer

  Reviews a plan, a design, or a finished change for what it got wrong — before it ships. Use for architecture decisions, risky migrations, and anything a domain expert would wince at. Read-only.

• researcher

  Deep codebase and web research. Traces code flows, investigates bugs, researches libraries.

• security-scanner

  Scans for vulnerabilities, secrets, and security misconfigurations. Cross-project learning.

Hooks (30)

• SessionStart

  node

• SessionStart

  node

• SessionStart

  node

• SessionStart

  node

• SessionStart

  node

• UserPromptSubmit

  node

• UserPromptSubmit

  node

• PreToolUse

  node

• PreToolUse

  node

• PreToolUse

  node

• PreToolUse

  node

• PreToolUse

  node

• PreToolUse

  node

• PreToolUse

  node

• PostToolUse

  node

• PostToolUse

  node

• PostToolUse

  node

• PostToolUseFailure

  node

• Stop

  node

• Stop

  node

• Stop

  node

• Stop

  node

• Stop

  node

• Stop

  node

• StopFailure

  node

• PreCompact

  node

• PreCompact

  node

• PostCompact

  node

• InstructionsLoaded

  node

• SessionEnd

  node

Similar plugins