devkit-core

Plugin devkit-core from marketplace devkit in chacal88/devkit. Commands read from the repo's manifest — today.

Skills (8)

• commit-message-guidelines

  Format for git commit messages and PR titles, taken from the project itself - its ticket key convention when it uses tickets (from branch names, CONTRIBUTING, git log), conventional commits otherwise - with an imperative subject and a "why" body. Load before writing or staging any commit message or

• plan-readiness-review

  Reviews a planned change package (proposal, design, specs, tasks) for implementation readiness and emits APPROVED, NEEDS-REVISION or BLOCKED, stopping ambiguous work before coding starts. Works on OpenSpec changes or docs/changes/<id>/. Use when the user says "is it ready to implement?", "review the

• requirements-grill

  Adversarial requirements interview before any spec or code. Classifies the change, then grills the owner one question at a time on scope, end effect, edges and conflict with project rules, and returns assumptions plus observable acceptance criteria. Default-on; skipped when the owner says so. Use at

• retro

  Short retrospective after a phase or a whole change. Answers three questions (what went wrong, how to do it better, what to remember), classifies each learning and proposes doc or rule updates as diffs for the owner to approve, never writing them blindly. Use at the end of a change or phase, or when

• review-change

  Pre-ship review gate. Picks the reviewer agents a change needs from what its diff touches, runs them in parallel, verifies each blocking or important finding with three refuting agents, and decides by consensus (any open blocking finding rejects). Use after writing a plan, before committing or openi

• systematic-debugging

  Four-phase root-cause debugging (investigate, analyze patterns, test one hypothesis, fix with a failing test first). Use when encountering any bug, test failure, flaky test or unexpected behavior, before proposing a fix, or when the user says "debug this", "why is this failing", "it broke".

• test-and-coverage

  Discovers the repo's test surfaces and their commands, runs them per surface with coverage, reports PASS/WARN/FAIL against the coverage target, and analyzes gaps with prioritized test suggestions. Use when validating an implementation, before a commit or PR, or when the user says "run the tests", "t

• test-driven-development

  Red-green-refactor discipline - write the failing test first, watch it fail, write the minimal code to pass, then refactor. Use when implementing any feature or bugfix, before writing implementation code, or when the user says "TDD", "test first", "write the test before the code".

Subagents (14)

• adr-reviewer

  Reviews a plan, design doc, spec change or diff against the project's locked ADRs (Architecture Decision Records) and returns one verdict with each violation tied to an ADR section and a file:line. Use when a change touches architecture, stack, conventions, infrastructure or process, or someone asks

• architecture-reviewer

  Reviews the design of a diff, not its style: right owner, layer boundaries, contracts and their consumers, and a deletion test on every new module. Returns one verdict with severity-tagged findings at file:line. Use when a diff creates a module/package, touches a contract (route, event, shared schem

• change-planner

  Authors the plan for a change — proposal.md, design.md, tasks.md and spec deltas when a capability changes — without writing product code. Uses openspec/changes/<id>/ when OpenSpec is present, else docs/changes/<id>/. Use when the user asks to "plan a change", "write a proposal", "draft the design a

• code-quality-reviewer

  Reviews the code quality of a diff in four phases (context, architecture, line-by-line, summary) and returns one verdict with severity-tagged findings at file:line. Use when delivered code needs a quality verdict before approval or merge, or when someone asks for "code review", "review this diff/PR"

• codebase-researcher

  Read-only investigator that answers specific questions about a codebase, or maps a module/service, with every claim cited by file:line or commit. Use when you or another agent need facts before deciding — "where is X defined", "which convention is used for Y", "find prior examples of Z", "how does t

• commit-and-pr

  Ships reviewed work mechanically — stages files by name, writes a conventional commit, pushes the branch and opens the PR with gh — then stops; never merges. Refuses secrets, never skips hooks or amends. Use after review passed, when the user says "commit and open the PR", "ship it", "push this and

• finding-verifier

  Tries to refute one review finding from the code, the tests and the plan, and returns whether it holds, with evidence. Read-only; writes no file. Use when a review round needs an independent check of a single blocking or important finding before any verdict file is written.

• plan-readiness-reviewer

  Independent reviewer that decides whether a change plan is ready to implement, using the plan-readiness-review method, and writes the change's readiness.md with \"- Status: APPROVED | NEEDS-REVISION | BLOCKED\". It is not the plan's author and ignores any verdict the caller suggests. Use when a chan

• plan-reality-auditor

  Checks that a change plan's claims about the current code — the "current behavior", "context" or "what exists" statements in proposal.md/design.md — are still true today, citing file:line, and returns an ACCURATE/OUTDATED verdict. Read-only. Use before a plan review or before implementing an older p

• pr-verifier

  Runs what a pull request delivers and gathers proof for each acceptance criterion — check output, API responses, screenshots, logs — then records it in the change's evidence.md and can comment on the PR. Reports defects, fixes nothing. Use when a PR is ready and someone needs evidence before approvi

• security-reviewer

  Audits a diff for exploitable vulnerabilities across six categories (injection, authn/authz/IDOR, data exposure, weak crypto, hardcoded secrets, insecure config), runs a mandatory false-positive filter, and returns one verdict. Use when a change touches auth, sensitive data, credentials, per-tenant

• spec-reviewer

  Reviews a plan or implementation against the project's canonical requirement specs (openspec/specs/ or docs/specs/) and returns one verdict with a per-requirement coverage table, flagging scope creep (work no requirement asks for) and gaps (required scenarios not delivered). Use when a change implem

• tdd-implementer

  Implements an approved change plan with strict TDD (red → green → refactor), one phase at a time, stopping at each phase gate; re-inspects the repo before coding and returns a parseable outcome. Never commits or opens PRs. Use when a change has an approved tasks.md and it's time to write the code —

• test-coverage-reviewer

  Analyzes a diff's test coverage behaviorally, not by line %: maps each new or changed behavior to a test that would go red, scores gaps 1-10 and flags tests that only test the mock. Returns one verdict. Use when someone asks \"are tests missing?\", \"is coverage enough?\", \"what regression would sl

Similar plugins