All authors
Claude Skills by SebastienDegodez
github.com/SebastienDegodez44 skills0 installs45 views
- Create Skraft EvalUse when creating, refreshing, expanding, or reviewing a SKRAFT Vally skill evaluation at tests/skills/<skill>/eval.yaml in the skraft-plugin repository. Covers behavior coverage, baseline-versus-isolated-treatment discrimination, natural prompts, outcome rubrics, non-activation cases, regression guards, fixtures, static Vally validation, trial budgeting for statistical power, staged live spend, and optional paired measurement. Do not use for dotnet/skills evals, generic skill-test scaffoldin...Votes: 0GitHub stars: 8
- GenesisUse this skill BEFORE drafting any agentic primitive module (skill, persona scoping file, scope-attached rule file, orchestrator workflow) or when refactoring an existing one. Activate whenever the task asks to design, restructure, or critique an agentic module across any agent harness (Claude Code, Copilot, Cursor, OpenCode, Codex), or when the task asks to make a workflow cost-effective, route model calls by capability, design for cache discipline, prune token spend, or pick a model class. ...Votes: 0GitHub stars: 8
- Examples> **Operator prompt (verbatim):** > > "Draft release notes from CHANGELOG entries for the next version of an open-source library. The library follows Keep-a-Changelog and SemVer; the release notes should land as a GitHub Release on tag push." > > **Regime:** single-skill > **Key pattern decisions:** A9 SUPERVISED EXECUTION + S7 BRIDGE + S4 SCHEMA GATE. A1 PANEL considered and rejected (lens-count gate did not fire). > > Output below is the verbatim response of a fresh agent session that > loa...Votes: 0GitHub stars: 8
- Agentic WorkflowsRoute gh-aw workflow design/create/debug/upgrade requests to the right prompts.Votes: 0GitHub stars: 8
- PlansDate: 2026-09-19. Status: approved design; source extraction in progress, integration validation pending. Audience: maintainers, not runtime instructions. This packet supersedes earlier company-override, profile, resolver and configuration proposals. The [earlier reporting plan](2026-09-17-pr-markdown-reporting.md) remains historical context for the unchanged publication lifecycle, not QA ownership.Votes: 0GitHub stars: 8
- Acceptance Review CriteriaUse 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.Votes: 0GitHub stars: 8
- Adr Eligibility GateUse 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 need?", "is this ADR-worthy?", "this feels like too many ADRs", "disambiguate baseline from decision". Runs a baseline-vs-decision gate over each candidate and returns ELIGIBLE or NOT ELIGIBLE with t...Votes: 0GitHub stars: 8
- Adversarial Review LensesUse 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 into it, whether it matches the business intent, whether it holds together internally, and what it puts at risk downstream, then weighing those into a single call. Not for routine code review of an or...Votes: 0GitHub stars: 8
- Architecture DecisionsUse 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.Votes: 0GitHub stars: 8
- Architecture PatternsUse 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.Votes: 0GitHub stars: 8
- Architecture Review CriteriaUse 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.Votes: 0GitHub stars: 8
- Bdd MethodologyUse 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.Votes: 0GitHub stars: 8
- Characterize BrownfieldUse 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 understand a legacy system with no docs. Activate on 'characterize this codebase', 'what does this system do', 'map the architecture', 'find existing contracts', 'assess tech debt', 'reverse-engineer ...Votes: 0GitHub stars: 8
- Characterize With ContractsUse 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 and mocking-strategy-roster; adds nothing new to the toolchain, only the characterization intent. Activate on 'characterize this API', 'lock in current behavior', 'build a contract-based safety net'.Votes: 0GitHub stars: 8
- Clean Architecture TestingUse 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 that calls an external API, a database or the file system, and when layer dependencies must be enforced by the build instead of by review.Votes: 0GitHub stars: 8
- Compose Brownfield PrdUse 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', 'compose PRD from characterization', 'produce a PRD for this system'.Votes: 0GitHub stars: 8
- Contract Testing DotnetUse 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...Votes: 0GitHub stars: 8
- Contract Testing RosterUse 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.Votes: 0GitHub stars: 8
- Contract TestingUse when authoring OpenAPI/AsyncAPI contracts, generating Microcks samples, setting up Testcontainers mocks, verifying provider contracts, or bridging API contracts across DESIGN → DISTILL → DELIVER phases.Votes: 0GitHub stars: 8
- Craft DisciplineUse 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.Votes: 0GitHub stars: 8
- Discovery Review CriteriaUse 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.Votes: 0GitHub stars: 8
- Github Search ProtocolUse when finding GitHub issues to work on, exploring a backlog by labels, milestones or assignees, finding issues related to changed files, or publishing already-prepared Markdown to PR conversation or issue comments, including updates and interrupted-publication retries. Covers issue discovery queries, pagination and ranking, plus MCP-first publication with host gh fallback when MCP capability is unavailable. Not for authoring Markdown, generating reports or judging their content.Votes: 0GitHub stars: 8
- Issue RefinementUse 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.Votes: 0GitHub stars: 8
- Issue TriageUse 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.Votes: 0GitHub stars: 8
- Mikado MethodUse 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, always keeping the codebase green. Loaded internally by brownfield-refactorer when the human chooses in-place restructuring over Strangler Fig.Votes: 0GitHub stars: 8
- Mocking Inprocess DotnetUse 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.Votes: 0GitHub stars: 8
- Mocking Microcks DotnetUse 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.Votes: 0GitHub stars: 8
- Mocking Strategy RosterUse 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.Votes: 0GitHub stars: 8
- Mutation TestingUse when entering COMMIT & VERIFY phase, killing surviving mutants, verifying test quality via mutation score, or analyzing supported Stryker.NET or Node TAP StrykerJS reports after the test baseline is greenVotes: 0GitHub stars: 8
- Outside In TddUse 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 the suite already fails but that failure may not prove the missing approved outcome. Drives outside-in / double-loop TDD with an acceptance or application-boundary test first, a trustworthy RED befor...Votes: 0GitHub stars: 8
- Planning Review CriteriaUse 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.Votes: 0GitHub stars: 8
- Playwright EvidenceUse 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.Votes: 0GitHub stars: 8
- Qa ReportingUse 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.Votes: 0GitHub stars: 8
- Quality Gates DotnetUse 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 cannot be reconstructed later. Provides the concrete `dotnet` / `stryker` commands and how their outputs map onto the tech-agnostic schema.Votes: 0GitHub stars: 8
- Quality Gates Evidence ContractUse 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.Votes: 0GitHub stars: 8
- Quality Gates JavascriptUse 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-in package scripts, sequential core/boundary StrykerJS 9.6.1 TAP execution and fresh evidence. Not for explaining test code, frontend, TypeScript compilation, coverage enforcement, or other mutatio...Votes: 0GitHub stars: 8
- Resolving Stack CommandsUse 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.Votes: 0GitHub stars: 8
- Skraft Quality BarUse 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 evidence record, when a skill or descriptor appears to state a threshold of its own, and whenever a number would otherwise be copied from memory or from an older document. There are no tiers, no ad...Votes: 0GitHub stars: 8
- Sprint PlanningUse 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.Votes: 0GitHub stars: 8
- Strangler Fig MethodUse 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 Mikado in-place restructuring.Votes: 0GitHub stars: 8
- Test Design MandatesUse 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 could observe.Votes: 0GitHub stars: 8
- Test Refactoring CatalogUse 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.Votes: 0GitHub stars: 8
- Clean Architecture DotnetUse 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.Votes: 0GitHub stars: 8
- Clean Architecture JavaUse 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.Votes: 0GitHub stars: 8