skraft-plugin

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.

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.

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.

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.

Use when designing test coverage matrices, assigning tests to Clean Architecture layers, planning the outside-in implementation order, or applying the Walking Skeleton strategy. Ensures every behaviour is tested at the right level with no redundancy. Load after writing Gherkin scenarios.

Use when completing a TDD phase or before committing — self-discipline checkpoints the software-engineer runs against their own output. Not a review contract. The reviewer verifies artifacts independently.

Use when entering COMMIT & VERIFY phase, killing surviving mutants, verifying test quality via mutation score, or analyzing Stryker reports after the test baseline is green

Use when a reviewer agent must produce an adversarial verdict via 4 independent lenses and weighted synthesis (Genesis A7 pattern)

Use when the active repository is a .NET solution (`.sln` / `.csproj` present) and the software-engineer must populate the quality-gates evidence contract at the end of the COMMIT phase. Provides the concrete `dotnet` / `stryker` commands and how their outputs map onto the tech-agnostic schema.

Use to initialize and configure the repo-wide SKRAFT settings file (skraft-config.json) — chiefly the depthTier strictness dial that governs the whole codebase. Activate on 'configure skraft', 'set depth tier', 'skraft-config init', 'change strictness', or whenever a repo needs its pipeline rigor level set once. All reads and writes go through the deterministic config CLI; never hand-edit the JSON for governed keys.

Use at pipeline start to detect an upstream HVE backlog/sprint handoff (entry-point skip), and at DISCOVER exit to evaluate the depth and difficulty axes, validate immutable invariants, and persist to state.json

Use when writing tests from the outside-in, defining behavior before code, or any feature where tests should start from observable business behavior and let internal design emerge. Covers double-loop TDD, 4-phase cycle, boundary-to-boundary testing, iron rule of tests, walking skeleton, and post-GREEN wiring verification.

Use when implementing any feature or fix using TDD, before writing any implementation code

Use when deciding what to test at each Clean Architecture layer (Domain, Application, Infrastructure, API, Architecture), selecting test doubles per boundary, or enforcing layer boundaries through architecture tests. Language-agnostic principles with .NET, Java, Python, TypeScript examples.

Use BEFORE drafting any ADR when a story enters DESIGN phase, or when reviewing an ADR set that feels inflated. Runs a baseline-vs-decision gate: for each candidate architectural choice, determines whether it ratifies a genuine open question (→ ADR-worthy) or re-declares project baseline / skill-enforced convention (→ not ADR-worthy). Prevents ADR over-production by filtering out non-decisions before any draft is written. Triggers: "should I write an ADR for X?", "how many ADRs does this story need?", "ADR-INFLATION detected", "disambiguate baseline from decision".

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.

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 Architecture, CQRS, and Event Sourcing.

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) layer that replays the published contract against the running service and validates response codes, headers, and ProblemDetails shape. Emits test wiring only; the business TDD cycle stays with the software-engineer lead.

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-<stack>` adapter. Loaded by the contract-testing-worker. A baseline in-process integration test is always produced; Microcks contract verification is an additive opt-in.

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.

Use when reviewing DISCOVER artefacts (triage reports, sprint proposals) for completeness, prioritization quality, and duplicate handling. Contains gate definitions G1-G6 and scoring rubric for the backlog-discoverer-reviewer lenses.

Use when transforming raw issues or feature requests into well-structured user stories with acceptance criteria. Covers user story format, INVEST criteria, acceptance criteria patterns, story splitting techniques, DoR 8-item gate, and 8 antipatterns to detect.

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 WebApplicationFactory DI. Emits mock wiring only; the business TDD cycle stays with the software-engineer lead.

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 wiring only; the business TDD cycle stays with the software-engineer lead.

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-<strategy>-<stack>` adapter. Loaded by the mock-integration-worker. No agent hardcodes a mocking approach — it resolves it here.

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.

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 acceptance-designer and software-engineer.

Minimal fixture skill used for end-to-end tests of skraft-test-harness.

Use when building GitHub search queries, paginating through issue results, filtering by labels/milestones/assignees, or implementing artifact-driven discovery from git history. Covers GitHub search syntax, MCP tool usage patterns, and result ranking.

Use when triaging GitHub issues by assigning labels, priority, effort estimates, or detecting duplicates. Covers triage methodology, label taxonomy, priority frameworks, effort sizing, and sprint proposal construction.

Use when reviewing DISCUSS artefacts (stories, acceptance criteria, sprint plans) for INVEST quality, planning coherence, and DoR compliance. Contains gate definitions G1-G8 and scoring rubric for the backlog-planner-reviewer lenses.

Use when planning sprint content, prioritizing stories within milestones, estimating capacity, or analyzing dependency graphs between stories. Covers MoSCoW prioritization, milestone management, velocity tracking, and dependency resolution for GitHub-based workflows.

Use when refactoring tests — extracting helpers, renaming for business clarity, deduplicating fixtures, consolidating parametrized cases, or restructuring test classes after GREEN phase without changing behavior coverage