Run any Skill in Manus with one click

write-spec

Stars1

Forks0

UpdatedJune 9, 2026 at 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

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

Highfivery

Highfivery/SelfOS

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·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).

More from this repository

same repository

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