Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

write-spec

Étoiles1

Forks0

Mis à jour9 juin 2026 à 21:14

Scaffold or revise a SelfOS feature-set spec in docs/specs/. Use when starting a new feature set, when the user asks to "write/draft a spec", or before writing any feature code (spec-driven workflow). Produces a doc that follows _TEMPLATE.md.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

Highfivery

Highfivery/SelfOS

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

SKILL.md

readonly

name	write-spec
description	Scaffold or revise a SelfOS feature-set spec in docs/specs/. Use when starting a new feature set, when the user asks to "write/draft a spec", or before writing any feature code (spec-driven workflow). Produces a doc that follows _TEMPLATE.md.

write-spec

SelfOS is spec-driven: no feature code without an approved spec. This skill creates or revises a spec so it's consistent, complete, and ready for review.

Steps

Confirm scope. Restate the feature set in one sentence and confirm with the user. Never guess at intent — ask focused questions about anything ambiguous.
Pick the number. Specs are ordered NN-name.md in docs/specs/. Read the directory, choose the next free NN, and use a short kebab-case name.
Start from the template. Copy docs/specs/_TEMPLATE.md. Fill every section. Do not leave placeholders — if a section doesn't apply, say why.
Honor the architecture. The spec must fit the feature-module registry, schema-driven settings, the vault storage model, and the IPC/security boundaries in docs/specs/00-architecture.md. Reference, don't restate.
Wellness safety. If the feature touches user wellbeing or conversation, include a Safety subsection: the not-medical boundary and crisis-routing behavior.
List open questions explicitly at the bottom rather than assuming answers.
Hand off for review. Specs are perfected with the user before any code. Use the spec-writer agent for heavy drafting when useful.

Definition of a good spec

Unambiguous, testable, internally consistent, and detailed enough that implementation needs no guesswork — but it references shared architecture instead of duplicating it (DRY).

Plus depuis ce dépôt

même dépôt

ship-slice

Highfivery/SelfOS

Run the full end-to-end cadence to finish a slice of SelfOS work — quality gate, self code-review, doc sync, and a Conventional Commit. Use when the user says "ship it", "finish this slice", "wrap up", or when an implementation slice is code-complete and ready to land.

2026-06-221

capture-feedback

Highfivery/SelfOS

Persist user feedback, corrections, or durable preferences into the project's config so they aren't forgotten. Use whenever the user corrects your approach, states a standing preference ("from now on…", "always/never…"), or makes a decision that should outlive this session. The reactive half of SelfOS's living-docs loop.

2026-06-091

commit

Highfivery/SelfOS

Create a Conventional Commit for SelfOS with the required co-author trailer, after verifying the quality gate passes. Use when the user asks to "commit", or as the final step of shipping a slice. Refuses to commit on main or when checks are failing.

2026-06-091

quality-gate

Highfivery/SelfOS

Run the automatable subset of SelfOS's Definition of Done (typecheck, lint, format check, unit tests, and E2E when present) and report pass/fail. Use before committing, before declaring a slice done, or when the user asks to "run the checks / quality gate / verify it's clean".

2026-06-091

sync-docs

Highfivery/SelfOS

After code changes, detect drift between the code and the docs (docs/specs/, CLAUDE.md, skills) and propose the concrete edits to bring them back in lockstep. Use as part of finishing a slice, before committing, or when the user asks to "update the docs / sync the spec / check the docs are current". The proactive half of SelfOS's living-docs loop.

2026-06-091

name	write-spec
description	Scaffold or revise a SelfOS feature-set spec in docs/specs/. Use when starting a new feature set, when the user asks to "write/draft a spec", or before writing any feature code (spec-driven workflow). Produces a doc that follows _TEMPLATE.md.

write-spec

SelfOS is spec-driven: no feature code without an approved spec. This skill creates or revises a spec so it's consistent, complete, and ready for review.

Steps

Confirm scope. Restate the feature set in one sentence and confirm with the user. Never guess at intent — ask focused questions about anything ambiguous.
Pick the number. Specs are ordered NN-name.md in docs/specs/. Read the directory, choose the next free NN, and use a short kebab-case name.
Start from the template. Copy docs/specs/_TEMPLATE.md. Fill every section. Do not leave placeholders — if a section doesn't apply, say why.
Honor the architecture. The spec must fit the feature-module registry, schema-driven settings, the vault storage model, and the IPC/security boundaries in docs/specs/00-architecture.md. Reference, don't restate.
Wellness safety. If the feature touches user wellbeing or conversation, include a Safety subsection: the not-medical boundary and crisis-routing behavior.
List open questions explicitly at the bottom rather than assuming answers.
Hand off for review. Specs are perfected with the user before any code. Use the spec-writer agent for heavy drafting when useful.

Definition of a good spec

Unambiguous, testable, internally consistent, and detailed enough that implementation needs no guesswork — but it references shared architecture instead of duplicating it (DRY).