bdfinst
@bdfinst
Public Skills
ci-debugging
by bdfinst
Systematic CI/CD failure diagnosis with hypothesis-first approach, environment delta analysis, and anti-patterns. Use when CI fails, pipelines break, or the user says "CI is failing", "build broke", "pipeline error", or "tests pass locally but fail in CI".
semantic-scan
by bdfinst
Build a computation register and detect semantic duplicates across architectural layers. Finds business logic reimplemented multiple times in different layers — the same domain calculation independently appearing in domain services, client adapters, and presentation components. Runs incrementally (git-diff-based) after the first scan. Produces a structured duplicate report with file:line references and canonical location suggestions.
domain-analysis
by bdfinst
Strategic DDD health assessment of an existing system. Use whenever someone asks to analyze their architecture, assess domain health, find coupling problems, map bounded contexts, trace event flows across services, or understand what is slowing down delivery. Trigger on phrases like "what's wrong with our architecture", "where is the coupling", "assess our domain", "event storming", "value stream", "friction report", "bounded contexts", or "why is everything so tangled". Apply to existing codebases — use domain-driven-design skill for greenfield modeling.
test-audit-disable
by bdfinst
Standalone worker. Audits the existing test suite for tests that cannot fail — no assertions, assertions on constants, expect-true, swallowed exceptions, self-equality — and disables each one by skip-and-tag (never deletes). Records each disabled test plus its reason in a JSON log under .claude/memory/<workflow>/<slug>/ so a later phase can repair them. Pairs with /coverage-baseline to produce a true baseline coverage number.
test-design-advisor
by bdfinst
Worker skill — assess testability, recommend the right test-pyramid layer and test-double strategy, and propose a behavior-preserving refactor sequence to make hard-to-test code testable. Invoked by /test-design and /test-health; not user-invocable. For a user-facing entry point use /test-design (add --advise --path <file> for forward-design on a single unit).
apply-fixes
by bdfinst
Apply correction prompts generated by /code-review. Use this whenever the user wants to apply, fix, or action the results of a code review — phrases like "apply the fixes", "fix the issues", "apply corrections", or after /code-review has run and produced a corrections/ directory.
hexagonal-architecture
by bdfinst
Design with ports and adapters to separate business logic from infrastructure. Use when designing a new service, reviewing structural compliance, or deciding how to introduce a new external dependency without coupling the domain.
semantic-duplication-scan
by bdfinst
Detect business logic reimplemented in multiple architectural layers. Builds a persistent computation-register.json by annotating non-trivial computation functions with structured semantic descriptions, then clusters entries to surface duplicate domain concepts. Runs in full-scan mode on first use, incremental (git-diff-based) mode on subsequent runs. Use when the user wants to find logical duplication that linters and diff-scoped review agents miss — the same domain calculation independently reimplemented across layers.
gherkin-public
by bdfinst
Author Gherkin scenarios for the entire public interface of a repository — every API endpoint, UI screen, batch-job entry point, library export, and event type — at the observable boundary, not internal steps. The scenarios become the executable specification of intended behavior before any test or production-code change lands. After the operator approves the scenarios at the Phase-2 gate, this skill also creates the Phase-4 and Phase-5 [Component tests] Stories that will bind their test code to specific scenario names — so the component tests are written from the approved Gherkin, not from the assessment.
systematic-debugging
by bdfinst
Four-phase debugging protocol (reproduce, investigate, root-cause, fix) that prevents guess-and-fix thrashing. Use this skill whenever a test fails, a bug is reported, an error occurs during implementation, or any unexpected behavior is encountered. Prevents the common LLM failure mode of guessing at fixes without understanding the problem.
legacy-code
by bdfinst
Safely modify code that lacks tests. Use whenever tasked with changing code without test coverage — apply characterization tests and dependency-breaking techniques before making any behavioral changes.
feature-file-validation
by bdfinst
Validate Gherkin feature files for structural quality, determinism, and implementation independence, then verify each scenario has matching test automation. Use this skill whenever reviewing test files, feature files, or BDD scenarios — including during /code-review when .feature files or step definition files appear in the changeset. Also use when a user asks to "check my feature files", "validate my Gherkin", "are my scenarios testable", or "do my feature files have tests".
review-agent
by bdfinst
Run a single named review agent against target files. Use this when the user names a specific agent (e.g. "run security-review", "check for test issues", "run js-fp-review on this file") rather than wanting the full suite. Prefer this over /code-review when only one concern is relevant or speed matters. Also used by the orchestrator for inline review checkpoints during Phase 3 implementation.
ubiquitous-language
by bdfinst
Build or refresh the project's ubiquitous language glossary — one markdown file per business concept at .plans/domain/<Concept>.md plus a _index.md. Mines grep-based signals (class names, enum values, interface names, domain-event names, BDD scenario names, validator rules) and applies a four-gate filter to keep only genuine business concepts. Optional interactive interview phase to refine definitions and capture behavior (state transitions, invariants, synonyms to avoid). Language-agnostic — works for JS/TS, C#, Java, Python, Go, or any mix. Use whenever the user says "build the glossary", "extract domain terms", "document the ubiquitous language", "what are the domain concepts", or when domain-review surfaces pervasive terminology inconsistency (3+ names for the same concept).
orchestration-benchmark
by bdfinst
Run the pre-registered solo-vs-coordinated A/B benchmark: three arms (solo session, current orchestration, delegation-only sweep) over the same task matrix at matched verification rigor, measuring dollar cost, token band shift, quality, rework, and wall-clock. Use when the user asks "is orchestration worth it", "benchmark the pipeline against a solo run", "measure delegation value", "orchestration benchmark", or wants the crossover threshold below which a solo session beats delegation.
test-design
by bdfinst
Deep test-design review and forward-design advisor. Dispatches test-review (tactical quality) and test-smell-review (xUnit smells, double selection, pyramid placement) in parallel, and runs the test-design-advisor worker to recommend how to test hard-to-test code. Use when the user says "review my tests", "how should I test this", "is this testable", "design tests for this", "what's the right test for X", "test design review", or before writing a suite for an untested module. For a single unit, pass --advise --path <file>. Advisory — it recommends, it does not edit.
apply-test-doubles
by bdfinst
Apply /cd-test-architecture's Step 4b build-vs-document decision logic against an existing, saved assessment report — or, when no valid report path is given, against a target to assess first — without re-running the full Steps 0-6 assessment each time. Use when the user wants to revisit or change a component's Build/Document choice from a saved cd-test-architecture report, says "apply the test doubles", "re-run Step 4b", "change the build-vs-document decision", or cites the /apply-test-doubles <path> command from a test-double setup guide.
report-pdf
by bdfinst
Render a dev-team Markdown report to a polished, shareable PDF. Use when the user says "make a PDF of the report", "export the code-review report as PDF", "turn .dev-team-reports/code-review.md into a PDF", or wants any .dev-team-reports or reports Markdown file as a styled document to attach to a ticket or hand to a non-terminal stakeholder.
competitive-analysis
by bdfinst
Compare this plugin against external plugins, tools, feature sets, or ideas to find gaps and weaknesses. Produces a structured gap analysis report with rough specs for closing each gap. Use this skill whenever the user references capabilities from OUTSIDE the plugin — another plugin they found, a competitor's tool, a feature list from a different project, a repo URL, or a hypothetical concept for capabilities we lack. Trigger phrases include "how do we compare to X", "what does Y have that we don't", "what are we missing", "gap analysis", "competitive analysis", "weaknesses compared to", "stack up against", "where do we fall short", and "should we add X — I saw it in another tool". Also trigger when the user pastes a feature list or describes capabilities they saw elsewhere and asks whether we should have them. Do NOT trigger for internal operations like running reviews, auditing our own agents, adding skills, threat modeling, domain analysis, or debugging — those use other skills.
triage
by bdfinst
Investigate a bug, find its root cause, and write a portable triage record to .dev-team-reports/triage/<slug>.md with a TDD fix plan. Use when the user reports a bug and wants it triaged, says "triage this", "investigate and write it up", or wants a hands-off bug investigation that produces an actionable record.
artifact-lifecycle
by bdfinst
Report on skill and agent usage data from ~/.claude/metrics/artifact-usage.json, classifying each artifact as active, stale (>= 30 days unused), or an archive candidate (>= 90 days unused). Proposes CLAUDE.md overrides for stale artifacts and exclusions for archive candidates. Pinned skills are always exempt. Use when the user asks to "review artifact lifecycle", "find stale skills", or "/artifact-lifecycle".
human-oversight-protocol
by bdfinst
Approval gates, intervention commands, and transparency requirements. Use to classify any agent action as autonomous/notify/approve, respond to override/pause/stop commands, or structure a plan review before the implementation phase begins.
explore
by bdfinst
Charter-driven exploratory testing of a running feature or endpoint. Dispatches the QA Engineer in "Chaos Specialist" mode to probe with structured heuristics (Goldilocks, Happy-Path Divergence, Telemetry Deepening, Invariant Probing, CRUD Sweep), run adversarial expansion, and auto-triage critical defects into an incremental report. Use when the user says "explore this endpoint", "poke at this feature", or wants hands-off exploratory testing of a live target.
governance-compliance
by bdfinst
Audit logging, quality gates, and ethics procedures for the agent team. Use for periodic compliance reviews, when logging task completion events, or when an ethical concern arises that requires human escalation.