a-v-ershov

@a-v-ershov source repo

28 skills
0 followers
13 hours ago last updated

▌
Commit · a-v-ershov
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 commit on the current branch, never branching, pushing, merging, amending or adding AI-attribution trailers. By default only the files this session touched are committed. Invoked by run-task for checkpoint commits and by cut-release for the release commit; otherwise use ONLY on the user's explicit request to commit — finishing a task or a review is not such a request. /commit [--dry-run] [--single] [--all] [--message <msg>]

0
installs
▌
Refactor · a-v-ershov
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 per-commit gate cannot see across the whole tree (duplication, oversized files, dead code, suppression debt) and turns the top of that list into behaviour-preserving transformations, one at a time with the full gate after each. Tests are the safety net: it refuses to work on a red suite, and a step that turns a test red is reverted rather than the test adjusted. It adds no features and fixes no bugs. Writes .dev-skills/release/refactor.md.

0
installs
▌
Run Task · a-v-ershov bundle
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 be green (the whole suite is never run here), the human accepts the work or it is auto-accepted, and a checkpoint commit carrying the task id lands. Two entry points: a task id from the backlog, or a free-form request it files itself with origin: adhoc. A small, obvious change can take the quick lane instead. Anything the single fix round leaves open escalates to needs_human. Sequential, single working tree, current branch.

0
installs
▌
Build Tasks · a-v-ershov
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, one working tree. It refuses to start when the spec has moved ahead of the plan and offers plan-development first, skips tasks another session has claimed, and never retries a needs_human task. By default it runs straight through, pausing only for a real reason; one-at-a-time and thinned acceptance are opt-in. Resumable — the backlog is the source of truth. Use after plan-development. It writes no code and duplicates no cycle.

0
installs
▌
Cut Release · a-v-ershov
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 changelog from the work since the last release, then commit, tag and open the PR through the commit skill. Use as the final step of the release phase, run by release-product once the audits are clean, or standalone. Always confirms before acting in both modes, and STOPS before any production deploy — putting the product live is setup-production-environment's job. Never edits product code.

0
installs
▌
Manual Test · a-v-ershov
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 — it answers 'what do I poke, and how do I log in?' in advance. It works out how to bring the product up, which seeded users and data exist right now, what has been built and which journeys that covers with exact steps and real texts, how to trigger rare states through the project's own mock switches, and above all what genuinely needs a person — needs_human tasks, risky surfaces, and every task accepted as review: auto.

0
installs
▌
Write Tests · a-v-ershov bundle
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 should be covered against what is covered, read from the tests' contents rather than their names, with mutation testing to expose a suite that executes lines without catching bugs — ranks it by risk, and writes the top ones at the cheapest level that proves each, keeping them fast and selectable. Red-first: a test is not accepted until it has been seen going red.

0
installs
▌
Audit Skills · a-v-ershov bundle
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 conversation and works out how each target actually behaved: steps got wrong or skipped, gates passed silently, work repeated, questions it should not have asked, needlessly slow calls, invariants of this set broken (one branch, the user's language, write scope, English commit messages), artifacts that do not match their templates. It applies nothing until the caller names numbers, and even then writes only skill, agent and command files.

0
installs
▌
Write Readme · a-v-ershov
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 how to get back to a clean seeded state. Use in the release phase (run by release-product before the manual-test briefing) or standalone whenever someone else has to run the project. Every command it writes is verified against the repo, never recalled: an unverified step is written as unknown rather than filled in with something plausible. Read-only on product code — it writes README.md and its own record, nothing else.

0
installs
▌
Audit Product · a-v-ershov
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 proves the cross-feature integration a per-task verifier could not see — state carried across steps, the seams between features, success and error states — then re-walks the core journeys with an automated axe pass plus what automation misses (keyboard operability, focus order, screen-reader semantics, contrast, reduced motion, form errors).

0
installs
▌
Validate Idea · a-v-ershov bundle
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, backed by real-world research and an adversarial review pass. Writes a source-cited .dev-skills/project-spec/idea-validation.research.md plus a short human summary; an independent reviewer returns its findings and the phase applies them in place. The first validation step of create-project-spec: it runs after gather-context and before define-product-requirements.

0
installs
▌
Audit Security · a-v-ershov
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, row-level security, rate limits on paid endpoints,. Use in the release phase (run by release-product) or standalone. Read-only: it probes, reproduces and ranks, but never edits code and never configures a provider — code holes become rework tasks, a production gap is reported as setup-production-environment's. Never prints a secret's value. Writes .dev-skills/release/security-audit.md.

0
installs
▌
Gather Context · a-v-ershov bundle
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 intake interview and writes .dev-skills/project-spec/project-brief.research.md plus a short human summary, which every later phase reads as settled intent; on demand it is a reusable grill any phase can invoke, scoped to a fork blocked on context only the human holds. Captures intent, audience, scope, constraints and developer preferences as soft priors. It does NOT validate the idea or define features.

0
installs
▌
Verify Feature · a-v-ershov
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 run/drive/prove commands from verification.md and the task's criteria, authors and runs adversarial automated tests for them (committed — the regression net), drives the real running stack and proves observable outcomes, never trusting 'it ran'. Tests go at the cheapest level that proves the criterion, at most one e2e per task. Writes only tests, never the implementation, and writes its findings into the task log as it goes.

0
installs
▌
Release Product · a-v-ershov
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 subagents in PARALLEL (audit-security, audit-performance, audit-product), then write-readme and manual-test. It ranks findings by severity, files blockers and majors as coarse rework tasks, drives ONE build-tasks fix run and re-runs the affected audits ONCE; anything still open is needs_human, never another loop.

0
installs
▌
Generate Mockups · a-v-ershov bundle
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 or a screen description it produces N variants and records the chosen one as a design-note on the task, so implement-feature follows it. It explores arrangement within the settled design system and never proposes an alternative one. Mockups are throwaway scratch under .dev-skills/build-plan/mockups/ (gitignored); it writes only mockups, task notes and temp files, never the implementation. Not auto-run by build-tasks.

0
installs
▌
Plan Development · a-v-ershov
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 .dev-skills/build-plan/ — one markdown file per task plus a derived board.md and a short plan.summary.md. Tasks are coarse on purpose: the backlog holds at most 15 open ones. When the repo already has working code it plans only the gap. Re-run after the spec changes and it amends instead — task deltas, never a regenerate; re-run with 'consolidate' and it merges the open backlog back under the ceiling. Run before build-tasks.

0
installs
▌
Audit Performance · a-v-ershov
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 by release-product) or standalone once features are built. Read-only: it measures, reproduces the slow path and ranks what it finds, but never edits product code and never installs a profiler or load tool it wishes it had — an unavailable measurement is recorded as unmeasured, and tooling is setup-dev-environment's job. Files blockers and majors as rework tasks and writes .dev-skills/release/performance-audit.md.

0
installs
▌
Create User Flows · a-v-ershov bundle
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 product-requirements.research.md) and before design-architecture. Writes a source-cited .dev-skills/project-spec/user-flows.research.md plus a short human summary; an independent reviewer returns findings and the phase applies them in place. The second product-layer step: it describes the experience (WHAT the user does), never the technical HOW and never visual UI design.

0
installs
▌
Define Code Style · a-v-ershov bundle
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 real alternatives it weighs the top 2–3 idiomatic options with trade-offs and recommends one; everything else inherits the stack's canon with a citation. Use after design-architecture and before design-dev-architecture. Writes a source-cited code-style.research.md, a short human summary, and the distilled code-style.md guide that implement-feature, verify-feature, refactor and write-tests follow on every task.

0
installs
▌
Implement Feature · a-v-ershov
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 branch following the project's CLAUDE.md and existing patterns, writes its journal into the task file as it goes, then self-verifies against .dev-skills/project-setup/verification.md and gets the static gate plus this task's scoped test selection green before handing off. It never runs the whole suite, does not run the verifier and does not commit.

0
installs
▌
Create Project Spec · a-v-ershov
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, validate-idea, define-product-requirements, create-user-flows, define-design-decisions, design-architecture, define-code-style and design-dev-architecture — each phase researching real-world facts within a fixed budget, running an adversarial review whose findings it applies in place, and emitting a research doc plus a short human summary. Works on an empty repo or one that already has code.

0
installs
▌
Design Architecture · a-v-ershov bundle
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 limits, weighing 2-3 integrated options against the scenarios, and recording significant choices as ADRs. Settles the same way WHERE the product runs (platform, environments, secrets, backups, cost, residency, the one-time manual setup) and HOW success is measured — deciding these, never configuring or deploying them. Use after create-user-flows, before define-code-style.

0
installs
▌
Setup Dev Environment · a-v-ershov bundle
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 the Compose stack, seed data and bring-up, stand up the three gate targets (make check-fast, make test-scoped, make check) with a pre-commit hook, wire the AI tooling, and scaffold the developer/test scripts and custom project skills the spec specified. For a UI project it installs the chosen kit and writes the root DESIGN.md.

0
installs
▌
Define Design Decisions · a-v-ershov bundle
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, responsive behaviour, target platforms, media-heaviness, offline expectations and the accessibility target — without pixel layouts, colours, components or mockups, which are implementation. Use after create-user-flows and before design-architecture, because these decisions feed its quality-attribute scenarios. Writes a source-cited design-decisions.research.md plus a short human summary. The bridge from the product layer to the technical one.

0
installs
▌
Design Dev Architecture · a-v-ershov bundle
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 (test levels, a selectable scoped run, developer/test scripts, an e2e harness an agent can drive), how concurrent access to the one shared local environment is coordinated, and which AI tooling and custom project-local skills to wire for the stack. Use after define-code-style, as the final step of create-project-spec. Writes dev-architecture.research.md (+ adr/*) plus a short human summary.

0
installs
▌
Define Product Requirements · a-v-ershov bundle
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 features: sub-capabilities fold into the feature they belong to, and whatever does not earn a place is cut into non-goals rather than deferred. Use after validate-idea and before create-user-flows and design-architecture. Writes a source-cited product-requirements.research.md plus a short human summary. Defines the product layer (WHAT and for WHOM) — never the technical HOW, which is design-architecture's.

0
installs
▌
Setup Production Environment · a-v-ershov bundle
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, configuration and secrets in the target environment, hard spending caps on every paid provider, the analytics and error tracking the architecture committed to, optionally CI. Every gap is sorted into three groups before anything happens — what the skill does in the repo, what an already-authorized provider CLI can do on an explicit yes, and what only the human can do in a dashboard.

0
installs

28 published skills