一键在 Manus 中运行任何 Skill

fix

星标78

分支25

更新时间2026年7月3日 12:43

Use to fix a reported bug spec-first: reproduce it, trace the symptom to the owning feature's acceptance criteria, pin it with a failing (RED) test, apply the minimal GREEN fix through the same per-task gate implement uses, then patch the spec so the bug class can't silently return. Triggers on "fix {bug}", "fix the bug in {slug}", "bug in {feature}", "/sdd:fix {slug}", "regression in {slug}", "полагодь баг", "виправ багу", "регресія в {slug}", "чому зламалось". Triage is three-way: AC exists and is violated (regression) / AC is ambiguous (spec-bug — patch the wording) / no AC covers it (gap — add one, marked added-by-fix). Works on a repo with no specs at all (soft mode — code-first, recommends survey after). Writes a fix record under docs/features/{slug}/_fixes/ and commits with an SDD-Fix trailer.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

genkovich

genkovich/sdd

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

相关职业SOC

基于 SOC 职业分类

软件开发工程师计算机与数学类职业·SOC 15-1252

文件资源管理器

3 个文件

SKILL.md

readonly

同仓库更多 Skills

同仓库

glossary

genkovich/sdd

Use to capture or update domain terms in CONTEXT.md before their meaning drifts — whenever a fuzzy word shows up in an interview, spec, or review and you want one canonical definition plus a NOT-reference so a homonym can't bite you in six months. Triggers on "add term {X}", "what is {X} in our domain", "add to CONTEXT", "fix the glossary", "define {X}", "/sdd:glossary {term}", "додай термін", "онови глосарій", "що означає {X}". Two-level contract: repo-root CONTEXT.md holds project-wide terms, docs/features/{slug}/CONTEXT.md holds feature-scoped ones; readers read both and the per-feature entry wins. Lazy-bootstraps the target from a template, checks BOTH levels for a conflicting existing entry, asks for a one-sentence definition + the concept it's confused with, and appends one line to ## Glossary. Skip generic tech words (HTTP, queue, cache) — those are not domain terms. Output: created/edited CONTEXT.md. Runs anytime, no input gate; specify, clarify, design and api read its ## Glossary as the canonical so

2026-07-0378

api

genkovich/sdd

Use to derive the API contract for a feature — an OpenAPI 3.1 document at docs/features/{slug}/contracts/openapi.yaml plus a drift/sync report (and an events doc when the feature has async flows). Triggers on "api for {slug}", "openapi for {slug}", "API contract for {slug}", "lock the interface for {slug}", "events for {slug}", "/sdd:api {slug}", "контракт API для {slug}", "OpenAPI для {slug}", "опиши ендпоінти". The contract is never hand-written: it is a derived function of data-model.md (typed fields + constraints), the sad.md §6 sequence diagrams (error branches, async actors), and spec.md acceptance criteria. Runs an inline drift check (does the contract match the model and the sequences?) and a reconcile mode. Hard-refuse if data-model.md is missing AND the feature changes the schema → run `data-model {slug}` first; on a legal no-schema-change skip it derives from the existing schema instead.

2026-07-0378

clarify

genkovich/sdd

Use to run an ambiguity sweep over a written spec.md and close every under-specified point before planning or design proceeds — so two engineers can't reasonably build different things from the same spec. Triggers on "clarify {slug}", "find ambiguities in {slug}", "is the spec ready", "sharpen the spec", "/sdd:clarify {slug}", "прояснити специфікацію", "знайди неоднозначності {slug}", "чи готова специфікація". Re-reads the spec, dispatches a clean-context devil's-advocate subagent to list where the spec forks, then for each ambiguity runs AskUserQuestion to RESOLVE it (tighten §1/§5/§6 in place) or DEFER it (→ §8 Open questions with owner+due). Output: an updated docs/features/{slug}/spec.md with every ambiguity resolved or deferred — none dangling. Hard-refuse if spec.md is missing.

2026-07-0378

data-model

genkovich/sdd

Use to design the data model AND generate the actual forward + rollback migrations in one pass — shippable SQL, not a plan. Triggers on "data model for {slug}", "schema for {slug}", "generate migrations for {slug}", "DB design + migration", "/sdd:data-model {slug}", "модель даних для {slug}", "схема для {slug}", "згенеруй міграції". Reads spec.md §5 + sad.md §5 building blocks + the §6 sequence diagrams, then writes docs/features/{slug}/data-model.md plus paired *.up.sql / *.down.sql migrations STAGED under docs/features/{slug}/migrations/ (NOT the live migrations/ tree — implement promotes them when the feature is actually built) and an audit report. Greenfield-first; brownfield delta via --mode brownfield; drift-only via --drift-only. Hard-refuses if spec.md or sad.md is missing. Stack-agnostic: detects and FOLLOWS the repo's DB + migration conventions and domain layer — it imposes no DB philosophy and writes no rules file.

2026-07-0378

decide-adr

genkovich/sdd

Use to record a post-hoc or asynchronous architecture decision as a MADR ADR when it was NOT captured during the synchronous design pass — a choice made in code, in a chat, on a whiteboard, or one a tasks/review gate flagged as missing. Triggers on "ADR for {decision}", "adr for {slug}", "document the decision on {topic}", "lock in the decision about {X}", "MADR for {topic}", "/sdd:decide-adr {slug} {title}", "створи ADR для рішення", "задокументуй рішення", "ADR на {тему}". Confirms the decision is ADR-worthy via the blast-radius gate, picks the next 4-digit number, copies design's MADR template, and fills context / drivers / considered options / outcome / honest consequences. Supports a Proposed → Accepted review flow. Output: docs/features/{slug}/adr/NNNN-{title}.md. For decisions made live with the user, use `design` — it spawns ADRs inline (Accepted).

2026-07-0378

design

genkovich/sdd

Use to produce a Software Architecture Document for a feature — Arc42 12 sections + C4 L1/L2 inline + ADRs spawned on a blast-radius gate — once spec.md exists. Triggers on "design {slug}", "architecture for {slug}", "SAD for {slug}", "arc42 for {slug}", "C4 context+container for {slug}", "/sdd:design {slug}", "спроектуй архітектуру {slug}", "SAD для {slug}", "архітектурний документ {slug}". Drafts §1–§12 in-memory, batch-validates each section Socratically (4-state machine), spawns an ADR only when a decision crosses the blast-radius threshold (irreversible / multi-module / has legitimate alternatives), writes each resolved section + its ADRs atomically, then runs a clean-context critic before finalizing. Brownfield: dispatches an Explore subagent to map the repo first. Hard-refuse if spec.md is missing; CONTEXT.md is optional (when present its Glossary is canonical).

2026-07-0378

name	fix
model	opus
effort	high
agents	["explorer"]
description	Use to fix a reported bug spec-first: reproduce it, trace the symptom to the owning feature's acceptance criteria, pin it with a failing (RED) test, apply the minimal GREEN fix through the same per-task gate implement uses, then patch the spec so the bug class can't silently return. Triggers on "fix {bug}", "fix the bug in {slug}", "bug in {feature}", "/sdd:fix {slug}", "regression in {slug}", "полагодь баг", "виправ багу", "регресія в {slug}", "чому зламалось". Triage is three-way: AC exists and is violated (regression) / AC is ambiguous (spec-bug — patch the wording) / no AC covers it (gap — add one, marked added-by-fix). Works on a repo with no specs at all (soft mode — code-first, recommends survey after). Writes a fix record under docs/features/{slug}/_fixes/ and commits with an SDD-Fix trailer.

Skill: fix

The bugfix entry point — the backbone in miniature, sized for «it's broken», not «build a feature». A bug is treated as evidence about the spec, not only about the code: either an acceptance criterion is violated (the code regressed), the AC was ambiguous enough to permit the behaviour (the spec is the root cause), or nothing covers it (a gap). So the fix always lands in two places — the code (RED → GREEN through the same gate implement runs) and the spec (a surgical AC patch) — tied together by a small fix record.

This skill keeps only its own machinery. Question phrasing → ../_shared/ask-style.md; RED-classification semantics → ../implement/references/tdd-loop.md (reused, never duplicated); dispatch policy → ../_shared/agent-roster.md.

Fix-record prose follows artifact_language — but a spec patch matches the existing spec's language (the file wins over the setting); code, tests and commits stay English → ../_shared/artifact-language.md.

Owner

The engineer on the bug (drives). PM / Tech Lead is consulted only when triage lands on «spec-bug» or «gap» — changing an AC is a product decision, not a code one.

Inputs

<slug> — optional; pass it when you know which feature owns the bug, otherwise step 2 finds it from the symptom.
The bug report, in any form — a sentence, a stack trace, a failing request, a screenshot description.
Soft gate (never hard-refuse): docs/features/ with ≥1 spec.md. Absent (a brownfield repo that never ran the backbone) → still run, in no-spec mode: steps 1 → 3 → 4 → record, skip the spec patch, and recommend /sdd:survey in the handoff.
(Optional) .claude/sdd.local.md — gate command overrides; otherwise the commands are detected per implement's cascade.

No depth dial and no .size here — a fix is one size, and the interview is the bug report itself.

Protocol

Intake — reproduce before touching anything. At most 1–2 AskUserQuestion (phrasing per ../_shared/ask-style.md), only for what the report doesn't already say: expected vs actual, the steps, the scope (one user? all? since when?). Outcome: a one-line reproduction statement — «doing X, expected Y, got Z». A bug you can't state this way isn't ready to fix.
Trace to spec (triage). Grep docs/features/*/spec.md (+ the candidate slug's _fixes/ for a recurrence) for the reproduction's domain terms; locate the owning slug and the closest §5 AC. In parallel, dispatch explorer — subagent_type: "sdd:explorer" (fallback Explore / inline per ../_shared/agent-roster.md) — to localize the code path. Three outcomes (decision table → ./references/triage.md):
- (a) Regression — an AC describes the expected behaviour and the code violates it. The spec is right; only the code changes.
- (b) Spec-bug — the AC exists but a reasonable implementer could read it and produce the observed behaviour. The wording is the root cause — the AC gets patched (with the user, step 5).
- (c) Gap — no AC covers the behaviour. A new AC is added to §5, marked .
- No-spec mode — no docs/features/ (or no spec plausibly owns the symptom): skip the spec patch, say so in the record, recommend survey.
RED — pin the bug with a failing test. Write the minimal test that reproduces the bug at the level the behaviour implies (unit for a rule, integration for a dependency behaviour, e2e for a flow). Run it and classify the first run per ../implement/references/tdd-loop.md — it must be a GOOD red (fails on the assertion that encodes the expected behaviour); quote the failing line. A bug that can't be pinned by a test → STOP and say so — an unverifiable fix is a guess.
GREEN + GATE — minimal fix. Make the RED test pass with the smallest change; no drive-by refactors (anything the fix exposes goes to the record's follow-ups). Then the same per-task gate implement runs: unit + lint + vet (+ integration when available), via the detected commands (detection cascade → ../implement/references/command-detection.md). Red gate → fix it, never commit around it.
Spec patch + fix record. Apply the step-2 branch — (a) nothing to patch, re-verify the AC; (b) patch the AC wording; (c) add the new AC with the marker. Any spec change is confirmed with the user in one AskUserQuestion (before/after wording shown). Then write docs/features/<slug>/_fixes/<date>-<short-slug>.md from ./templates/fix-record.md: symptom → root cause → the pinning test → the spec patch (or why there is none).
Commit + handoff. Propose commit fix: <slug> <short summary> with trailers SDD-Fix: <date>-<short-slug> and SDD-AC: <id> (when an AC was traced). Then emit the stage-handoff block per ../_shared/handoff.md (utility variant — /clear optional): What I did + Review (the diff, _fixes/<date>-<short-slug>.md, the spec patch if any) + Run next: resume what you were doing; when the fix touched >5 files or crossed a module boundary, recommend /sdd:review <slug> — a recommendation, not a gate.

Definition of Done

The bug is reproduced by a test that failed before the fix and passes after — GOOD red proven, failing line quoted.
The gate is clean: unit + lint + vet (+ integration where available).
The triage outcome is explicit — regression / spec-bug / gap / no-spec — and the matching spec patch is applied (or its absence explained in the record).
docs/features/<slug>/_fixes/<date>-<short-slug>.md exists: symptom, root cause, the test, the spec patch, follow-ups.
The commit carries the SDD-Fix: trailer (+ SDD-AC: when traced); any spec change was user-confirmed.
The RED-pin (failing test first) + the per-task GATE are this skill's structural self-check (../_shared/self-check.md); its result is reported in the handoff.

Anti-patterns

Fixing without a pinning test. «It works now» with no RED proof is a guess that re-breaks silently — the exact failure mode this skill exists to stop.
Patching code when the spec was the bug. If the AC permitted the behaviour, the wording is the root cause; leave it unpatched and the next implementation reintroduces the bug legally.
Silent spec edits. Every AC patch/addition is confirmed with the user — the spec is a contract, not a scratchpad.
Drive-by refactoring. The fix commit is minimal; refactors the fix exposed go to the record's follow-ups, not into the same diff.
Skipping the gate because the change is «one line». One-line fixes break suites just fine.
Hard-refusing on a repo without specs. A brownfield bug is this skill's front door — degrade to no-spec mode and recommend survey, never block.
Writing a parallel test when _fixes/ shows the same symptom was fixed before. That's a recurrence — read the old record and strengthen its test instead.

References & template

./references/triage.md — the symptom→spec trace: grep strategy, the regression / spec-bug / gap decision table, the added-by-fix marker, no-spec mode, the recurrence check.
./templates/fix-record.md — the fix-record scaffold (symptom → root cause → pinning test → spec patch → follow-ups).
../implement/references/tdd-loop.md — RED classification (GOOD red / BAD red / false-pass) — the semantics step 3 reuses.
../implement/references/command-detection.md — how the step-4 gate commands are resolved (settings override → Makefile → package scripts → language manifests).
../_shared/ask-style.md · ../_shared/agent-roster.md · ../_shared/handoff.md.

Example invocation

User: «/sdd:fix — discounts are applied twice when the user clicks pay twice fast» Skill: intake confirms: expected one discount per order, got two on a double-click (all users, since the checkout-discounts release). Trace: docs/features/checkout-discounts/spec.md AC-04 says «a discount is applied to an order at most once» → the code violates it → regression. explorer localizes the apply-discount handler (no idempotency check). RED: an integration test posting the same apply twice asserts one discount row — fails with got 2, want 1 (GOOD red). GREEN: guard on the existing uniqueness key; gate clean. Spec: nothing to patch (AC-04 was right). Record _fixes/2026-06-12-double-discount.md; commit fix: checkout-discounts double-applied discount + SDD-Fix: / SDD-AC: AC-04 trailers. Handoff: 2 files touched → no review push; resume.