تشغيل أي مهارة في Manus بنقرة واحدة

ship

النجوم٧٨

التفرعات٢٥

آخر تحديث٣ يوليو ٢٠٢٦ في ١٢:٤٣

Use to close the loop after review — verify the feature actually works, write the changelog / knowledge-base note, and open the pull request. Triggers on "ship {slug}", "open a PR for {slug}", "changelog for {slug}", "prepare {slug} for merge", "/sdd:ship {slug}", "відправ фічу {slug}", "створи PR для {slug}", "changelog для {slug}". Re-runs the gate, runs the app/feature to confirm the spec's outcomes for real (not just green tests), drafts a changelog + PR body that link spec/ AC/ADRs, and proposes the PR command for whatever forge the repo uses. Never auto-merges to main.

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

genkovich

genkovich/sdd

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·SOC 15-1252

مستكشف الملفات

3 ملفات

SKILL.md

readonly

name	ship
model	inherit
effort	medium
agents	[]
description	Use to close the loop after review — verify the feature actually works, write the changelog / knowledge-base note, and open the pull request. Triggers on "ship {slug}", "open a PR for {slug}", "changelog for {slug}", "prepare {slug} for merge", "/sdd:ship {slug}", "відправ фічу {slug}", "створи PR для {slug}", "changelog для {slug}". Re-runs the gate, runs the app/feature to confirm the spec's outcomes for real (not just green tests), drafts a changelog + PR body that link spec/ AC/ADRs, and proposes the PR command for whatever forge the repo uses. Never auto-merges to main.

Skill: ship

The closing step. review confirmed the change is correct on paper; ship confirms it works in reality and packages it for merge. The loop ends here: a reviewed, verified change with a changelog and an open PR — not a merge to main (that stays a human decision).

Forge-agnostic and stack-agnostic: the verification commands are detected the way implement detects them; the PR step targets whatever forge the remote points at (GitHub via gh, GitLab via glab, or copy-paste).

Changelog + PR-body prose follow artifact_language — commit messages, branch names and the SDD-Task/SDD-AC trailers stay English → ../_shared/artifact-language.md.

Owner

The implementer (drives) + the reviewer who signed off in review.

Inputs

<slug> — feature slug.
Gate (hard refuse): a PASS review record (docs/features/<slug>/_review/) or, at minimum, an implemented + gate-green change. No review yet → «run review <slug> first».
Read: spec.md (what to claim in the changelog), Accepted adr/ (decisions worth recording), the feature's commits (the SDD-Task history).

Protocol

Final verification — does it actually work. Re-run the detected gate (unit + integration where available + lint + vet). Then run the feature for real against its acceptance criteria — not just "tests pass": start the app / hit the endpoint / exercise the flow and observe the spec's outcomes (e.g. the default-on read returns defaults; an invalid value is rejected). Concretely: spot-check at least 3 of the most critical §5 AC outcomes (fewer only if the spec has fewer; scale the count with the feature's breadth), and for each name the AC id + the behaviour actually observed — «AC-03: posted the same apply twice → one discount row» — so the verification is checkable, not a vibe. If the app can't be run here (no runtime, no Docker), say so explicitly and record what was verified vs deferred — never claim verified-working when only tests compiled.
Write the changelog / KB note. From ./templates/changelog.md: what changed, why (link spec + the key ADRs), any migration/operational note (e.g. "adds migration 000023 — run it on deploy"), and how to use it. Partner-facing if the change is partner-facing.
Prepare the PR. Ensure the work is on a feature branch (not the default branch). Draft the PR body from ./templates/pr-body.md: summary, the AC it satisfies, links to spec/sad/ADRs, the SDD-Task commit list, the test + verification evidence, and any migration/rollback note.
Detect the forge + propose the PR command. Inspect the remote: github.com → gh pr create; gitlab.com/self-hosted GitLab → glab mr create; otherwise print the branch + body for manual creation. Propose the command — do not run a push/PR to a shared remote without the user's go-ahead, and never merge to main.
Update the roadmap. Move this feature's item to Shipped in docs/roadmap.md (via roadmap) — date + outcome + link to the feature folder + the PR/changelog — and remove it from Now. This is the anti-drift hook: delivery itself keeps the roadmap current. (No roadmap yet → skip; it's optional.)
Summary (terminal handoff). Emit the stage-handoff block per ../_shared/handoff.md (terminal variant) — What I did (verification result: verified-working / what was deferred and why; the roadmap update) + Review (the changelog path + the PR) + Run next = Done: the PR command (or URL if the user ran it) — merging to main is your call; there is no /sdd successor.

Definition of Done

The gate was re-run and the feature was exercised against its AC (or the deferral was stated explicitly with the reason).
A changelog / KB note exists, linking spec + ADRs.
A PR body is prepared and the forge-appropriate PR command proposed (work on a feature branch; main untouched).
The run-the-feature verification (real run against the ACs, not just green tests) is this skill's structural self-check (../_shared/self-check.md); its result is reported in the handoff.

Anti-patterns

"Tests pass" ≠ "it works". Run the actual feature against the spec's outcomes; green unit tests don't prove the wired system behaves.
Claiming verified when you only compiled. If the runtime/Docker wasn't available, say what was deferred — don't overstate.
Auto-merging to main / pushing to a shared remote unasked. Propose the PR; the merge is the team's call.
A changelog that restates the diff. Say what changed and why (link the spec + ADR), plus the operational note (migrations, flags) — not a file list.
Forgetting the migration/rollback note when the change includes one — the deployer needs it.

References & template

./templates/changelog.md — changelog / KB-note scaffold.
./templates/pr-body.md — PR description scaffold.

المزيد من هذا المستودع

نفس المستودع

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	ship
model	inherit
effort	medium
agents	[]
description	Use to close the loop after review — verify the feature actually works, write the changelog / knowledge-base note, and open the pull request. Triggers on "ship {slug}", "open a PR for {slug}", "changelog for {slug}", "prepare {slug} for merge", "/sdd:ship {slug}", "відправ фічу {slug}", "створи PR для {slug}", "changelog для {slug}". Re-runs the gate, runs the app/feature to confirm the spec's outcomes for real (not just green tests), drafts a changelog + PR body that link spec/ AC/ADRs, and proposes the PR command for whatever forge the repo uses. Never auto-merges to main.

Skill: ship

Changelog + PR-body prose follow artifact_language — commit messages, branch names and the SDD-Task/SDD-AC trailers stay English → ../_shared/artifact-language.md.

Owner

The implementer (drives) + the reviewer who signed off in review.

Inputs

<slug> — feature slug.
Gate (hard refuse): a PASS review record (docs/features/<slug>/_review/) or, at minimum, an implemented + gate-green change. No review yet → «run review <slug> first».
Read: spec.md (what to claim in the changelog), Accepted adr/ (decisions worth recording), the feature's commits (the SDD-Task history).

Protocol

Final verification — does it actually work. Re-run the detected gate (unit + integration where available + lint + vet). Then run the feature for real against its acceptance criteria — not just "tests pass": start the app / hit the endpoint / exercise the flow and observe the spec's outcomes (e.g. the default-on read returns defaults; an invalid value is rejected). Concretely: spot-check at least 3 of the most critical §5 AC outcomes (fewer only if the spec has fewer; scale the count with the feature's breadth), and for each name the AC id + the behaviour actually observed — «AC-03: posted the same apply twice → one discount row» — so the verification is checkable, not a vibe. If the app can't be run here (no runtime, no Docker), say so explicitly and record what was verified vs deferred — never claim verified-working when only tests compiled.
Write the changelog / KB note. From ./templates/changelog.md: what changed, why (link spec + the key ADRs), any migration/operational note (e.g. "adds migration 000023 — run it on deploy"), and how to use it. Partner-facing if the change is partner-facing.
Prepare the PR. Ensure the work is on a feature branch (not the default branch). Draft the PR body from ./templates/pr-body.md: summary, the AC it satisfies, links to spec/sad/ADRs, the SDD-Task commit list, the test + verification evidence, and any migration/rollback note.
Detect the forge + propose the PR command. Inspect the remote: github.com → gh pr create; gitlab.com/self-hosted GitLab → glab mr create; otherwise print the branch + body for manual creation. Propose the command — do not run a push/PR to a shared remote without the user's go-ahead, and never merge to main.
Update the roadmap. Move this feature's item to Shipped in docs/roadmap.md (via roadmap) — date + outcome + link to the feature folder + the PR/changelog — and remove it from Now. This is the anti-drift hook: delivery itself keeps the roadmap current. (No roadmap yet → skip; it's optional.)
Summary (terminal handoff). Emit the stage-handoff block per ../_shared/handoff.md (terminal variant) — What I did (verification result: verified-working / what was deferred and why; the roadmap update) + Review (the changelog path + the PR) + Run next = Done: the PR command (or URL if the user ran it) — merging to main is your call; there is no /sdd successor.

Definition of Done

The gate was re-run and the feature was exercised against its AC (or the deferral was stated explicitly with the reason).
A changelog / KB note exists, linking spec + ADRs.
A PR body is prepared and the forge-appropriate PR command proposed (work on a feature branch; main untouched).
The run-the-feature verification (real run against the ACs, not just green tests) is this skill's structural self-check (../_shared/self-check.md); its result is reported in the handoff.

Anti-patterns

"Tests pass" ≠ "it works". Run the actual feature against the spec's outcomes; green unit tests don't prove the wired system behaves.
Claiming verified when you only compiled. If the runtime/Docker wasn't available, say what was deferred — don't overstate.
Auto-merging to main / pushing to a shared remote unasked. Propose the PR; the merge is the team's call.
A changelog that restates the diff. Say what changed and why (link the spec + ADR), plus the operational note (migrations, flags) — not a file list.
Forgetting the migration/rollback note when the change includes one — the deployer needs it.

References & template

./templates/changelog.md — changelog / KB-note scaffold.
./templates/pr-body.md — PR description scaffold.