Menu
SkillsMP has collected 28 skills from a-v-ershov/dev-skills. Open a skill to review its source and details.
Showing 28 of 28 collected skills.
Commit the current uncommitted changes: read the diff, group files by logic rather than path (a definition change split from its ripple of usage updates), write conventional-commit messages in English — with the [T###] backlog task id where one applies — and…
Produce a project's initial documentation end to end, from a raw idea to a buildable spec. Use when starting a new project or a major new initiative and you want the full guided flow rather than running each step by hand. Orchestrates gather-context,…
Define the project's development style guide once the stack is chosen: how code is organized (module/folder architecture), named, commented and documented, how errors are handled, and how tests are written. For each dimension where the chosen stack offers…
Design the system's technical architecture from the product spec: elicit measurable quality-attribute scenarios first, then co-design the components AND the concrete technologies together — researching each candidate's current capabilities, pricing and…
Design the development-time architecture — the inner loop that lets an AI agent build the product fast and verify its own work: how to run the whole product locally (Compose topology, prod-parity stand-ins, seed data), how it is tested in an AI-drivable way…
Interview the human to extract maximum context before and during spec work — a relentlessly curious discovery grill that turns a short brief into a rich, shared understanding of what to build. Two roles: as the FIRST step of create-project-spec it runs a full…
Build one backlog task's feature in the working tree. Use as the implementation stage of the build loop — normally spawned fresh per task by run-task, or standalone on a task id. It reads the task's description and acceptance criteria, builds on the current…
Improve the internal structure of the code without changing what the product does. Use in the release phase (run first by release-product, before the audits) or standalone whenever a part of the codebase has become hard to work with. It measures the rot a…
Take a built, verified product to a cut release. Use after build-tasks, as the third pipeline. A thin orchestrator: first the two steps that change the repository, strictly in order — refactor, then write-tests — then the read-only audits as fresh independent…
Turn the dev-architecture spec into a real, runnable local environment. Use after the project-spec pipeline, as the first step of the build phase: install tooling, init the repo (.gitignore, CLAUDE.md, settings.json with the permissions the loop needs), write…
Independently verify that a built feature task actually meets its acceptance criteria. Use as the verification stage of the build loop — normally spawned by run-task as a separate, fresh agent so it carries no bias from the implementer. It reads the project's…
Map where the product is NOT protected by an automated test, then close the top of that list with honest tests. Use in the release phase (run by release-product, after refactor) or standalone whenever the test net needs checking. It builds the gap map — what…
Measure the built product's performance against the spec's quality-attribute scenarios — p50/p95 on the hot paths, throughput at the target load, asset weight and client render cost, query plans, the resource and cost envelope. Use in the release phase (run…
Drive the whole running product through the spec's user flows end to end and, since it is already in the real UI, check the accessibility target on the same journeys. Use in the release phase (run by release-product) or standalone once features are built. It…
Prove with evidence whether the running system upholds the spec's STRIDE-lite threat model and trust boundaries: secrets in code and git history, authn/authz on every protected path, injection, the lethal trifecta, insecure data handling, dependency exposure,…
Audit the skills, slash commands and subagents that ran in this Claude Code session and propose numbered edits to the files that own each rule. Invoked by hand; never part of the release chain. It reads the session transcript (scan_session.py) plus the live…
Work through the development plan: take tasks from .dev-skills/build-plan/ one at a time and run each through run-task. The order is deterministic, not a judgement call — the ready task (status todo, all blocked_by done) with the lowest id; no parallel tasks,…
Map how users actually move through the product to get value — the customer journey and the step-by-step flows for each feature, informed by conventional patterns for the category and an adversarial review pass. Use after define-product-requirements (reads…
Cut a release in one gated step: check the preconditions (clean tree, no open blocker from the audits), refresh the human-facing docs and the handover README, propose the version bump (semver — proposed and confirmed, never decided silently), update the…
Decide the design direction that shapes scope and architecture: design system or none, WHICH UI kit to adopt (on component coverage against the key screens, platform fit and ubiquity), the icon set and theming approach, the inventory of key screens,…
Turn a validated idea into the product definition: who it is for, and the full set of features being built — backed by real-world research (comparable products, table-stakes features) and an adversarial review pass. The committed set holds at most 15…
Generate several stub UI variants for a screen and render them so a human can compare and choose — static pages styled against the committed root DESIGN.md. Use on demand when working a feature and you want to see options before implementing: given a task id…
Prepare the briefing a human needs in order to check the product by hand. Use as the last step of the release phase (run by release-product, after the audits) or standalone before a demo or an acceptance pass. Read-only: it proves nothing and changes nothing…
Turn the finished project spec into a buildable backlog. Use after setup-dev-environment, as the planning step of the build phase: it reads the committed feature set, the user flows, the architecture and the dev-architecture, and emits a kanban backlog under…
Drive ONE task through the full development cycle: the implementer builds it, a separate fresh verifier independently proves the acceptance criteria, its findings go back for exactly one fix round, the static gate plus this task's scoped test selection must…
Turn the spec's deployment and analytics decisions into a real production environment, and put the product live. The outward-facing sibling of setup-dev-environment: the deploy platform and release channel, the production database with migrations and backups,…
Pressure-test a raw product idea before any design or code. Use at the very start of a new project or a major new feature, when the idea is still vague — to validate demand, audience, the problem and the business model through adversarial forcing questions,…
Write or refresh the repository README as a handover document — what the project is, how another person clones it and gets the dev environment running, how a release is deployed to production, what they must bring themselves (accounts, secrets, licences), and…