skraft

Plugin skraft from marketplace skraft in SebastienDegodez/skraft-plugin. Commands read from the repo's manifest — yesterday.

Skills (43)

• acceptance-review-criteria

  Use when reviewing DISTILL artefacts (Gherkin scenarios, test plans, implementation plans) for quality, completeness, and alignment. Contains the gate definitions and scoring rubric for the acceptance-designer-reviewer lenses.

• adr-eligibility-gate

  Use when deciding WHETHER a candidate architectural choice deserves an architecture decision record, before any record is drafted: a story enters DESIGN with a list of candidate choices, a reviewer flags ADR inflation, or someone asks "should I write an ADR for X?", "how many ADRs does this story ne

• adversarial-review-lenses

  Use when reviewing a phase artifact — a discovery brief, a plan, a design, an acceptance specification, or a slice reported as delivered — and the review has to end in a defensible pass-or-block verdict rather than a list of remarks. Covers judging whether the artifact covers everything that fed int

• architecture-decisions

  Use when documenting architecture decisions as ADRs, evaluating trade-offs between alternatives, or managing the lifecycle of existing decisions. Covers ADR template, status transitions, consequence analysis, and quality criteria.

• architecture-patterns

  Use when selecting architecture patterns for a new feature, performing Event Modeling, defining bounded contexts, choosing DDD tactical patterns, evaluating pattern fitness, or understanding how patterns compose. Covers Event Modeling methodology, DDD strategic design, DDD tactical patterns, Clean A

• architecture-review-criteria

  Use when reviewing DESIGN artefacts (event models, ADRs, component diagrams, context maps, interface contracts) for quality, DDD compliance, and architectural correctness. Contains gate definitions and scoring rubric for the solution-architect-reviewer lenses.

• bdd-methodology

  Use when writing, reviewing, or structuring BDD scenarios in Gherkin format. Covers Given/When/Then conventions, scenario outline patterns, background usage, tag strategies, and domain language alignment. Load before any Gherkin authoring.

• characterize-brownfield

  Use to reverse-engineer an existing/brownfield codebase into structured, confidence-scored characterization artifacts (tech stack, feature inventory, dependency & integration map, existing API contracts, test-coverage traceability, tech debt & risks). Use before composing a PRD, or standalone to und

• characterize-with-contracts

  Use to discover or reconstruct a service's API contract and produce characterization (golden-master) tests that lock in its CURRENT behavior — including existing bugs — as a safety net before refactoring a brownfield service. Delegates stack detection and Microcks wiring to contract-testing-roster a

• clean-architecture-dotnet

  Use when laying out or extending a .NET / ASP.NET Core solution — which project a class belongs in, which project may reference which, and how an endpoint reaches a use case.

• clean-architecture-java

  Use when laying out or extending a Java / Spring Boot service built with Maven — which module a class belongs in, which module may depend on which, and how an endpoint reaches a use case.

• clean-architecture-python

  Use when laying out a Python service packaged with pyproject.toml (FastAPI or another web framework), or adding a feature, endpoint, use case, aggregate or repository to one — which package a module belongs in, which package may import which, and how an endpoint reaches a use case. Not for configura

• clean-architecture-react

  Use when laying out or extending a React / TypeScript front end — which folder a screen, component, hook, use case or API call belongs in, which folder may import which, and how a component reaches the API. Not for build, dependency, environment-variable or tooling configuration.

• clean-architecture-testing

  Use when it is unclear where a test belongs and what it is allowed to talk to — which test project and layer it goes in, whether it gets a real database, an in-memory fake, or no double at all, and whether a value object or a constructor is worth a test of its own. Also use when covering an adapter

• compose-brownfield-prd

  Use to compose a structured 17-section PRD at docs/prds/<name>.md from brownfield characterization artifacts produced by characterize-brownfield. Maps as-is features, constraints, integrations, coverage and tech debt into PRD sections with FR/NFR IDs and full traceability. Activate on 'write the PRD

• contract-testing-dotnet

  Use when the contract-testing-roster resolved a .NET stack for a provider-side contract test. Always provides the baseline WebApplicationFactory + HttpClient integration test recipe; when the Microcks opt-in is enabled, additionally provides the MicrocksContainer + TestEndpointAsync(OPEN_API_SCHEMA)

• contract-testing-python

  Use when the contract-testing-roster resolved a Python stack for a provider-side contract test. Always provides the baseline FastAPI TestClient integration test through the app factory; when the Microcks opt-in is enabled, additionally boots the service on a real port with uvicorn and has a Microcks

• contract-testing-roster

  Use when an agent must produce a provider-side contract test for THIS service's API and needs to know the stack adapter and whether the optional Microcks verification layer is enabled. Resolves the stack and reads the Microcks opt-in (off by default), then points to the concrete `contract-testing-<s

• contract-testing

  Use when authoring OpenAPI/AsyncAPI contracts, generating Microcks samples, setting up Testcontainers mocks, verifying provider contracts, or bridging API contracts across DESIGN → DISTILL → DELIVER phases.

• craft-discipline

  Use when a change looks finished and is about to be committed, or a phase has just turned green — the self-check the software-engineer runs before claiming the work is done. Not a review contract. The reviewer verifies artifacts independently.

• github-publication

  Use when publishing already-prepared Markdown to a GitHub PR conversation or issue comment, updating that comment, or reconciling an interrupted publication. Covers MCP-first publication with host gh fallback when MCP capability is unavailable. Not for finding issues, authoring Markdown, generating

• mikado-method

  Use to refactor or restructure existing code IN PLACE when the change is likely to break things in ways that are hard to predict up front — drive the Mikado Method loop: attempt the change naively, capture what breaks as prerequisite graph nodes, revert, and implement bottom-up from the leaves, alwa

• mocking-inprocess-dotnet

  Use when the mocking-strategy-roster resolved (inprocess, .NET) — the override mocking strategy that replaces a downstream dependency with an in-process test double (FakeItEasy, NSubstitute, or Moq) instead of a Microcks container. Provides the concrete double registration swapped into the WebApplic

• mocking-inprocess-python

  Use when the mocking-strategy-roster resolved (inprocess, Python) — the override mocking strategy that replaces a downstream dependency with an in-process double (respx for httpx, responses for requests, or a hand-written fake passed to the app factory) instead of a Microcks container. Emits mock wi

• mocking-inprocess-typescript

  Use when the mocking-strategy-roster resolved (inprocess, TypeScript) — the override mocking strategy that replaces a downstream HTTP API with an in-process double (MSW answering at the network layer, or a hand-written gateway handed to the feature) in a Vitest integration test, instead of a Microck

• mocking-microcks-dotnet

  Use when the mocking-strategy-roster resolved (microcks, .NET) — the default mocking strategy for a .NET integration test. Provides the concrete Microcks Testcontainers wiring and the WebApplicationFactory scaffold that points the system-under-test's typed HttpClient at the mock URL. Emits mock wiri

• mocking-microcks-python

  Use when the mocking-strategy-roster resolved (microcks, Python) — the default mocking strategy for a Python integration test. Provides the MicrocksContainer wiring (unofficial microcks-testcontainers binding, pinned) of a Microcks container seeded from the downstream dependency's contract and the p

• mocking-microcks-typescript

  Use when the mocking-strategy-roster resolved (microcks, TypeScript) — the default mocking strategy that serves a downstream HTTP API from its OpenAPI contract in a Microcks container (@microcks/microcks-testcontainers) for a Vitest gateway integration test. Emits mock wiring only; the business TDD

• mocking-strategy-roster

  Use when an agent must mock a downstream HTTP/event dependency for an integration test and needs to know WHICH mocking strategy and stack adapter to use. Resolves the mocking strategy (Microcks by default, overridable to an in-process library) and the stack, then points to the concrete `mocking-<str

• mutation-testing

  Use when entering COMMIT & VERIFY phase, killing surviving mutants, verifying test quality via mutation score, or analyzing supported Stryker.NET, Node TAP StrykerJS, TypeScript StrykerJS with the Vitest runner or Python cosmic-ray results after the test baseline is green

• outside-in-tdd

  Use when an approved behaviour (scenario, Gherkin example, worked example, expected result) must become working software, or when a test suite is not trustworthy evidence of it — the suite is green while the real runtime behaviour is wrong or missing because fixtures or tests supply the value, or th

• playwright-evidence

  Use when capturing E2E test evidence (screenshots, videos, traces) and storing them in .copilot-tracking/skraft-plans/{projectSlug}/changes/{date}/evidence/{story}/evidence/ for agents to consume. Covers Playwright setup, on-failure capture, trace collection, and evidence manifest generation.

• qa-reporting

  Use when preparing QA forecast or outcome Markdown from approved plans and recorded delivery evidence, including DISTILL forecast handoff, blocked delivery summaries, and checking report data against its sources. Not for running tests, deciding quality gates, or publishing prepared Markdown.

• quality-gates-dotnet

  Use when the active repository is a .NET solution (`.sln` / `.csproj` present) and the software-engineer must produce falsifiable evidence for the quality gates. Most gates are captured once, after the story's last work commit; the G10 RED capture is taken **at RED**, before any production code, and

• quality-gates-evidence-contract

  Use when producing or verifying the structured evidence log that attests quality gates (tests, build, mutation, commits, RED/GREEN integrity). Tech-agnostic schema. Loaded by software-engineer (writer) at COMMIT phase and by quality-gates-lens (reader) during review.

• quality-gates-javascript

  Use in a JavaScript/Node.js project when running its existing package tests or build scripts, when running StrykerJS mutation gates after a green baseline, or when judging whether a recorded JavaScript test or mutation result is enough to call delivery verified. Owns command resolution from checked-

• quality-gates-python

  Use when the active repository is a Python project (`pyproject.toml` present) and the software-engineer must produce falsifiable evidence for the quality gates, or run the cosmic-ray mutation gates after a green baseline. Provides the cross-platform scripts (Node, no shell) that run pytest, import-l

• quality-gates-typescript

  Use when the repository holds a TypeScript project tested with Vitest — a React front end or a Node package with `vitest` in its `package.json` — and the software-engineer must produce falsifiable evidence for the quality gates, or run the StrykerJS mutation gates after a green baseline. Provides th

• resolving-stack-commands

  Use whenever an agent must run a toolchain command (build, test, mutation) and needs the concrete invocation. Resolves build/test/mutation commands from the detected stack via the `quality-gates-<tech>` adapters so no agent hardcodes `dotnet test`, `dotnet build`, or any toolchain command. Loaded by

• skraft-quality-bar

  Use before running, verifying, or reporting any quality gate. States the one permanent threshold for mutation score and line coverage, and the enforcement level of every gate. Load when about to invoke a mutation run, when deciding whether a gate blocks or merely warns, when writing or reviewing an

• strangler-fig-method

  Use to REPLACE part of an existing brownfield system incrementally — behind a routing facade, one slice at a time, verified by contract equivalence against a green safety net — rather than restructuring it in place. Loaded internally by brownfield-refactorer when the human chooses replacement over M

• test-design-mandates

  Use when planning which tests an approved set of examples actually needs before any code is written — where each test enters and what it observes, whether a rule those examples already cover deserves a test of its own, and whether a scenario reads in business terms and ends in an outcome a user coul

• test-refactoring-catalog

  Use when the tests pass but the test code itself has gone bad — the same setup copied into several tests, names that describe the method instead of the behavior, near-duplicate test methods, or a class grown too large to read. Use it to clean that up without losing a single case of coverage.

Hooks (5)

• SessionStart

  node "${CLAUDE_PLUGIN_ROOT}/src/cli/housekeeping.mjs"

• PreToolUse

  node "${CLAUDE_PLUGIN_ROOT}/src/cli/hook.mjs" PreToolUse

• SubagentStart

  node "${CLAUDE_PLUGIN_ROOT}/src/cli/hook.mjs" SubagentStart

• SubagentStop

  node "${CLAUDE_PLUGIN_ROOT}/src/cli/hook.mjs" SubagentStop

• PostToolUse

  node "${CLAUDE_PLUGIN_ROOT}/src/cli/hook.mjs" PostToolUse

Similar plugins