Jeden Skill in Manus ausführen
mit einem Klick

Jeden Skill in Manus mit einem Klick ausführen

write-spec

Sterne1

Forks0

Aktualisiert9. Juni 2026 um 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

Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.

In Manus ausführen

Quelle

Highfivery

Highfivery/SelfOS

GitHub-Repository öffnen Creator-Repositorys ansehen

Download

In Manus ausführen

Verwandte BerufeSOC

Basierend auf der SOC-Berufsklassifikation

SoftwareentwicklerInformatik- und Mathematikberufe·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).

Mehr aus diesem Repository

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