Run any Skill in Manus with one click

start

Stars78

Forks25

UpdatedJuly 2, 2026 at 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).

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

genkovich

genkovich/sdd

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Computer Occupations, All OtherComputer and Mathematical Occupations·SOC 15-1299

SKILL.md

readonly

More from this repository

same repository

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).