一键在 Manus 中运行任何 Skill

start

星标78

分支25

更新时间2026年7月2日 11:31

Use to open the SDD visual dashboard — the local read-only browser UI that shows every feature's pipeline stage, renders its artifacts (markdown, mermaid C4/sequence/ER, OpenAPI as plain YAML), and drives the pipeline by sending /sdd:<skill> commands back into this live session. Triggers on "start the dashboard", "open the SDD dashboard", "sdd dashboard", "/sdd:start", "show the pipeline UI", "відкрий дашборд", "запусти панель SDD". The sdd-dashboard MCP server auto-starts at session open (via .mcp.json), resolves the project from CLAUDE_PROJECT_DIR, binds its loopback HTTP listener, and writes the dashboard URL (with a per-session capability token) to ~/.claude/sdd-dashboard/current.url — so start's job is simply to READ that file and print the URL. No MCP tool call, no channel round-trip on the common path. Opt-in: requires dashboard_enabled: true in .claude/sdd.local.md and Bun installed; if either is missing it prints guidance and exits cleanly (pure-markdown skills are unaffected).

安装

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

在 Manus 中运行

来源

genkovich

genkovich/sdd

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

下载

在 Manus 中运行

相关职业SOC

基于 SOC 职业分类

其他计算机职业计算机与数学类职业·SOC 15-1299

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	start
model	inherit
effort	low
agents	[]
description	Use to open the SDD visual dashboard — the local read-only browser UI that shows every feature's pipeline stage, renders its artifacts (markdown, mermaid C4/sequence/ER, OpenAPI as plain YAML), and drives the pipeline by sending /sdd:<skill> commands back into this live session. Triggers on "start the dashboard", "open the SDD dashboard", "sdd dashboard", "/sdd:start", "show the pipeline UI", "відкрий дашборд", "запусти панель SDD". The sdd-dashboard MCP server auto-starts at session open (via .mcp.json), resolves the project from CLAUDE_PROJECT_DIR, binds its loopback HTTP listener, and writes the dashboard URL (with a per-session capability token) to ~/.claude/sdd-dashboard/current.url — so start's job is simply to READ that file and print the URL. No MCP tool call, no channel round-trip on the common path. Opt-in: requires dashboard_enabled: true in .claude/sdd.local.md and Bun installed; if either is missing it prints guidance and exits cleanly (pure-markdown skills are unaffected).

Skill: start

Opens the SDD visual dashboard — a local, loopback-only browser UI served by the sdd-dashboard MCP server (Bun + Bun.serve()), embedded in the same process that holds this session's MCP channel. The dashboard reads docs/features/ off disk, renders every artifact, and — the point of it — drives the pipeline back into this session: a click in the browser sends a validated /sdd:<skill> <slug> command through the channel, this Claude runs it, and progress streams back to the browser live.

start is not "start the server" — the server auto-starts when the session opens (declared in .mcp.json). On boot it resolves the project from CLAUDE_PROJECT_DIR, binds the HTTP listener, and writes the dashboard URL to ~/.claude/sdd-dashboard/current.url. So on the common path start just reads that file and prints the URL — a plain file read, no MCP tool, no channel message.

Owner

The developer running the session. No artifact is produced — this is a connection skill.

Inputs

.claude/sdd.local.md — read dashboard_enabled (must be true). Auto-created with documented defaults by specify/implement → ../implement/references/settings.md.
~/.claude/sdd-dashboard/current.url — the file the server writes when it binds: line 1 is the dashboard URL (with the capability token), line 2 is the project dir it resolved. This is the primary input — present whenever the server bound HTTP at boot.
(Fallback only) the sdd-dashboard MCP server's dashboard_handshake tool — used only when the URL file is absent (the server couldn't resolve the project at boot, e.g. CLAUDE_PROJECT_DIR unset).

Protocol

Gate on opt-in. Read .claude/sdd.local.md.
- Absent → the dashboard is opt-in and off by default. Auto-create the file with the documented defaults per ../implement/references/settings.md (which include dashboard_enabled: false + dashboard_port: 4178), then tell the user: «The dashboard is opt-in — set dashboard_enabled: true in .claude/sdd.local.md and re-run /sdd:start.» Stop.
- Present, dashboard_enabled not true → print the same one-line enable instruction and stop. (Pure-markdown users are unaffected.)
Read the URL file (the common, channel-free path). Read ~/.claude/sdd-dashboard/current.url (e.g. cat "$HOME/.claude/sdd-dashboard/current.url").
- Present → line 1 is the live dashboard URL. Print it and go to step 5. Do NOT call any MCP tool — the server is already up and bound; nothing else is needed. (Optionally note line 2, the project dir, if it differs from the current project — that would mean another session's server is bound; tell the user rather than guessing.)
- Absent → the server is connected but idle (it couldn't resolve the project at boot). Continue to step 3.
(Fallback) check Bun + the MCP server. Run bun --version; if Bun is missing, print «The dashboard needs Bun — install from https://bun.sh, then re-run /sdd:start. The markdown skills work without it.» and stop. If the dashboard_handshake tool is unavailable, tell the user to check /mcp (the sdd-dashboard server may have failed to boot — Bun missing, or .mcp.json not picked up; re-open the session) and stop.
(Fallback) hand the project over. Determine the absolute project root — prefer git rev-parse --show-toplevel; fall back to the cwd that contains docs/ or .git. Call dashboard_handshake with project_dir set to that path. It binds HTTP, writes current.url, and returns the URL. Use the returned URL.
Print the URL + how it behaves. Show the URL prominently (http://127.0.0.1:<port>/?session=<id>&token=<cap>) and offer to open it. Then state the load-bearing UX truth so the user isn't surprised:
- The dashboard is a driver + observer, not a synchronous remote control.
- A click is consumed only while this session is idle at the prompt; mid-task it queues.
- Dashboard-driven runs default to --depth=easy (the skill self-decides reversible calls and asks far fewer questions) because the browser can't answer a blocking AskUserQuestion; if a stage genuinely needs a decision, it surfaces in this terminal — answer it here.
Handoff. Emit the stage-handoff block per ../_shared/handoff.md (utility variant) — What I did (printed the dashboard URL) + Review (open the URL; the dashboard mirrors docs/features/ and the session activity pane streams runs) + Run next (open the dashboard and click Run next stage on a feature, or run a backbone command here, e.g. /sdd:specify <slug>). /clear is optional for this utility.

Definition of Done

dashboard_enabled: true confirmed (or guidance printed + stopped).
The dashboard URL printed — read from ~/.claude/sdd-dashboard/current.url on the common path, or (fallback only, when that file is absent) obtained from dashboard_handshake after a Bun check.
The queued/busy/--depth=easy behaviour stated so the user knows the dashboard is a driver, not a remote control.
The stage-handoff block emitted (utility variant).
This skill writes no artifact — the DoD gates above (opt-in confirmed, URL only from current.url/handshake) are its structural self-check (../_shared/self-check.md).

Anti-patterns

Calling dashboard_handshake when current.url already exists. The common path is a plain file read — the server is already bound. Only hand over via the tool when the URL file is absent.
Treating start as "boot the server". The server auto-starts via .mcp.json; start only prints the URL. Never try to spawn bun yourself.
Proceeding when dashboard_enabled is not true. It is opt-in — print the enable line and stop.
Fabricating the URL. It comes only from current.url (or the dashboard_handshake result) — never invent a port or token.
Running a dashboard-triggered stage at --depth=hard. Browser-driven runs default to --depth=easy; a Socratic prompt the browser can't answer would block the queue.

References

../implement/references/settings.md — .claude/sdd.local.md, including the dashboard_enabled / dashboard_port keys this skill gates on.
../_shared/handoff.md — the stage-handoff block (utility variant) this skill emits.
../_shared/tool-adapters.md — Codex/Cursor mapping for the Claude-specific mechanisms (the dashboard channel is Claude Code-only; non-Claude hosts use the markdown skills directly).