Claude Skills by mik2win

Learning loop over the project's own history — mine archived plans' Deviation Reports, implementation logs, handoff notes, and diagnose/arch-health reports for RECURRING patterns, then fold each confirmed lesson back into the right artifact (rules, PROJECT.md, CONTEXT.md, or a skill) with user confirmation. The kit's memory: what went wrong twice should never go wrong a third time. TRIGGER when: an epic just closed, the user says "retro", "what keeps going wrong", "learn from this", "post-mor...

Decision re-review discipline — audit past architecture/technology decisions (ADRs, select-tech picks, structural choices baked into code with no record) by extracting each decision's load-bearing assumptions and testing them against TODAY's reality, internal and external. Verdict per decision: HOLDS / STRAINED (tripwire set) / BROKEN (reopen with evidence). Guards both failure modes: drive-by relitigation and silent ossification. TRIGGER when: the user asks "is X still the right choice", "we...

Design a safe rollout/migration strategy for a risky or irreversible change — expand-contract (parallel change), strangler fig, feature flags / dark launch / canary — as a staged plan where every stage is independently deployable, verifiable, and reversible. TRIGGER when: the user asks how to ship/deploy/migrate something safely — a schema or data migration, an API contract change, a library/system replacement, a risky behavior change, or mentions zero-downtime, feature flags, canary, backfil...

Add a new module, component, command or adapter modelled on an existing one: read the canonical exemplar first, place it per the profile's Architecture, wire it into every registration point, and prove each wiring with a command rather than by reading the code. Built around the failure this task actually has — a registration that never took raises nothing, and the new thing is simply absent from the listing. TRIGGER when: the user asks to add a new module / component / command / adapter / pro...

Technology selection discipline — choose a library/gem/package/framework/external service (or decide to build it) via hard filters, an adversarial deep-dive on 2–3 finalists (issue-tracker-over-README, the hard-case probe, upgrade-path history, bus factor, escape cost), a scored matrix with one recommendation, and an adapter-seam integration contract. TRIGGER when: the user asks which library/gem/framework/service to use for X, wants to compare candidates, asks build-vs-buy, or a plan needs a...

Time-boxed throwaway experiment to validate ONE risky hypothesis before committing to the full pipeline — write a scratch experiment, run it, record works / doesn't / caveats, and explicitly do NOT integrate it into production code. TRIGGER when the user wants a quick feasibility check ("just check if X works", "spike on Y", "is this even possible", "proof of concept", "validate this assumption"). Do NOT trigger when: the approach is already known and the user wants to build it → /implement; ...

Mass mechanical migration across many files — rename an API, swap a library, apply a codemod pattern: build a COMPLETE site inventory first, prove the recipe on a pilot batch, then transform in verified batches until a re-scan finds zero leftovers. Coverage is explicit — every site transformed, deferred with a reason, or flagged for judgment; nothing silently skipped. TRIGGER when: the user wants the same change applied everywhere ("rename X to Y across the repo", "migrate all call sites", "r...

Drive a feature or bug fix TEST-FIRST with a red-green-refactor loop in vertical slices — one failing test → minimal code to pass → refactor → repeat. Tests verify behaviour through public interfaces, not implementation details, so they survive refactors. Distinct from /test (which authors/audits a suite) and /implement (which executes a prepared plan as written). TRIGGER when: the user wants to build or fix something test-first, mentions "red-green-refactor" / "TDD" / "write the test first",...

Remove or roll back the feature-flow kit from THIS project, safely and reversibly. Two scopes: "clean up leftovers" deletes build-time material (_kit/, *.template.*, CLAUDE.snippet.md, old .bootstrap-backup snapshots) while keeping the working config; "uninstall" returns the project to its pre-kit state from a backup (or git). Trigger when the user says "remove the kit", "uninstall the kit", "clean up the kit leftovers", "roll back bootstrap", or "/teardown". DO NOT TRIGGER to INSTALL/adapt t...

Spec-first testing — derive tests from a plan/spec file WITHOUT reading the implementation, so the spec is the source of truth: a failing test means the CODE is wrong, not the test. For pure-logic units (calculations, transforms, validators, parsers, state reducers, filters). Enforces verbatim spec-quoting, one-test-per-spec-case coverage, and a deviation report. TRIGGER when: a plan/spec (a /prepare plan file, or an inline `f(1.3) → ~1.0` contract) defines pure-logic behaviour to verify — ei...

Author new tests or refactor existing ones — layer classification, inventory & gap analysis, test-design table, AAA/naming/mock discipline, async safety, antipattern cleanup, and coverage verification. Covers both writing tests from scratch and improving the quality of tests that already exist. TRIGGER when: the user wants to write/add/generate tests for a file, directory, or feature, OR to audit/refactor/clean up existing tests. DO NOT TRIGGER when: the user wants to build NEW code test-firs...

Design-time threat modeling (STRIDE-lite) for a feature BEFORE it's built — map the new surface and trust boundaries, walk spoofing/tampering/disclosure/DoS/elevation per entry point, add abuse cases (IDOR, mass assignment, rate abuse), and land every accepted threat as a spec AC or plan step — not a wish. TRIGGER when: a spec/plan adds or changes external surface — a new endpoint/form/webhook, file upload, auth/authz change, a new integration or tenant boundary — and code hasn't been written...

Break a plan, spec, or PRD into independently-grabbable issues using TRACER-BULLET vertical slices — each slice cuts end-to-end through every layer (schema→logic→API→UI→tests), is demoable on its own, and declares what blocks it. Writes the issues as local markdown files in the project's backlog (the local issue tracker), in dependency order. TRIGGER when: the user wants to split a plan/PRD/spec into work items, "make issues/tickets out of this", "break this down into slices", or set up grabb...

Synthesize the CURRENT conversation into a Product Requirements Document and save it to the project's plans location — no fresh interview, it crystallizes what's already been discussed. Quizzes only about which modules the change touches (a design-first nudge) before writing. TRIGGER when: the user says "turn this into a PRD", "write this up", "document what we decided", or wants a durable doc out of a discussion that's already happened. DO NOT TRIGGER when: requirements are still unclear and...

Move local backlog issues through a triage state machine — read each open issue, sort it into the next canonical status (needs-triage → ready → blocked/done…), set its status frontmatter, and report the board. The triage roles/labels come from PROJECT.md. Operates on the local markdown issue tracker written by /to-issues. TRIGGER when: the user wants to triage the backlog, "what should I work on next", sort/label issues, groom the backlog, or move an issue to a new state. TRIGGER ALSO on the ...

Update or re-adapt the feature-flow kit in a project that was ALREADY bootstrapped, without clobbering your local adaptations — the safe path for both a newer kit version and a plain re-adapt after structural changes. Does a 3-way merge (manifest baseline vs your files vs the staged version), asks only on real conflicts, never touches project-owned files (PROJECT.md, CONTEXT.md, docs/adr/, backlog), then re-runs the bootstrap re-adapt inline so settings/hooks/rules refresh in the same pass. B...

Router over the feature-flow kit — given a situation in plain words, recommend which kit skill (or short chain of skills) fits, and why. The map of the kit and the discover→analyst→prepare→implement flow, so you don't have to remember 20+ skills. TRIGGER when: the user asks "which skill should I use for…", "what's the right flow for…", "where do I start", "is there a skill for X", or describes a situation without naming a skill. TRIGGER ALSO (silent match) when the user states a concrete task...

Authoring reference for writing and editing the kit's own skills well — the frontmatter shape, description triggers, user- vs model-invoked split, the rule-vs-skill altitude call, and the house conventions every skill follows (Phase-0 profile load, facts-from-PROJECT.md, cross-refs, hard rules). A maintenance aid for developing THIS kit, not a project-runtime skill. TRIGGER when: someone is adding or editing a skill in this kit, asks "how should this skill be structured", whether something sh...