Run any Skill in Manus with one click

spec

Stars0

Forks0

UpdatedJune 17, 2026 at 22:04

Author or revise a work item's spec at docs/spec/<id>.md before any code is written, then run it through the spec gate. Use when starting a new work item, when a spec needs revision after a spec-gate rejection, or when acceptance criteria must be defined. Produces a fully-signed spec — Goal, Non-goals, evidence-cited claims, stable spec-item IDs, and frozen executable acceptance criteria.

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

dw218192

dw218192/spec-driven-project-template

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

File Explorer

2 files

SKILL.md

readonly

name	spec
description	Author or revise a work item's spec at docs/spec/<id>.md before any code is written, then run it through the spec gate. Use when starting a new work item, when a spec needs revision after a spec-gate rejection, or when acceptance criteria must be defined. Produces a fully-signed spec — Goal, Non-goals, evidence-cited claims, stable spec-item IDs, and frozen executable acceptance criteria.

A spec is the written commitment for one work item (one branch work/<id>). It is authored before code and reviewed adversarially by the spec-gate subagent. Code does not start until the gate passes. See docs/process.md.

Author the spec

Copy this skill's references/spec-template.md to docs/spec/<id>.md and complete every section. The gate fails a spec that is missing any of them.

Goal — what this work item delivers, bounded.
Non-goals — what's explicitly out of scope. Required: without them the gate cannot distinguish an authorized deferral from a silent scope cut.
Evidence — every non-trivial claim cites a concluded spike (SPIKE-<n>), a code path (file:line), or a doc. Use the spike skill for uncertainties.
Spec items — each normative requirement gets a stable ID (<PREFIX>-<n>) so it is citable in code (an implements <PREFIX>-1 marker in a comment) and traceable.
Acceptance criteria — executable commands (prefer pixi run tasks), written verbatim in a fenced block and frozen here. Each ties to a spec item. The impl gate re-runs them itself; never author criteria that pass without exercising real behavior.

A spec is fully signed only when every item has all three of: evidence, a criterion, and spec-gate sign-off.

Run the spec gate

Invoke the spec-gate subagent to review the spec (and every ADR it depends on) adversarially. It hunts for: unauthorized scope cuts, uncited claims, open questions, and infeasibility. On a fail, address each finding by editing the spec (and/or concluding more spikes) and re-run — do not start implementation.

On a pass, present the spec to the human for sign-off. Implementation begins only after the human approves the spec — spec→impl is a human gate, not just an AI one.

Back-edge

If implementation reveals the spec is wrong, return here: edit the spec and re-run the spec gate before continuing. The spec is the contract; keep it true.

More from this repository

same repository

adr

dw218192/spec-driven-project-template

Record a new architectural decision, or supersede an existing one, as a plain-markdown ADR under docs/adr/. Use when making a significant or hard-to-reverse design decision, or when an accepted decision must change (which requires a NEW superseding ADR — accepted ADRs are immutable). Handles the frontmatter schema, numbering, and the additive supersede workflow (accepted ADRs are never edited — reverse links are derived).

2026-06-170

remote-memory

dw218192/spec-driven-project-template

Set up and operate the git-remote sync of the agent's machine-local memory directory. Use to configure the memory remote the first time, to push or pull memory manually, to onboard a new machine, or to resolve a memory merge conflict. The memory_push Stop hook handles routine per-turn pushes automatically once setup is done.

2026-06-170

spike

dw218192/spec-driven-project-template

Resolve an uncertainty during spec authoring by running a throwaway investigation and recording a concluded docs/spike/SPIKE-<n>.md evidence artifact. Use when a spec or ADR makes a design claim that is not yet backed by a concluded spike, a cited code path, or a doc — the spec gate rejects uncited claims and open questions.

2026-06-170

update-from-template

dw218192/spec-driven-project-template

Pull later framework improvements (process, gates, skills, hooks, scripts) from the upstream template into this project — without touching project content. Use when the template repo has shipped updates you want to adopt; it syncs only framework-owned paths and stages them for review.

2026-06-170

name	spec
description	Author or revise a work item's spec at docs/spec/<id>.md before any code is written, then run it through the spec gate. Use when starting a new work item, when a spec needs revision after a spec-gate rejection, or when acceptance criteria must be defined. Produces a fully-signed spec — Goal, Non-goals, evidence-cited claims, stable spec-item IDs, and frozen executable acceptance criteria.

Author the spec

Copy this skill's references/spec-template.md to docs/spec/<id>.md and complete every section. The gate fails a spec that is missing any of them.

Goal — what this work item delivers, bounded.
Non-goals — what's explicitly out of scope. Required: without them the gate cannot distinguish an authorized deferral from a silent scope cut.
Evidence — every non-trivial claim cites a concluded spike (SPIKE-<n>), a code path (file:line), or a doc. Use the spike skill for uncertainties.
Spec items — each normative requirement gets a stable ID (<PREFIX>-<n>) so it is citable in code (an implements <PREFIX>-1 marker in a comment) and traceable.
Acceptance criteria — executable commands (prefer pixi run tasks), written verbatim in a fenced block and frozen here. Each ties to a spec item. The impl gate re-runs them itself; never author criteria that pass without exercising real behavior.

A spec is fully signed only when every item has all three of: evidence, a criterion, and spec-gate sign-off.

Run the spec gate

On a pass, present the spec to the human for sign-off. Implementation begins only after the human approves the spec — spec→impl is a human gate, not just an AI one.

Back-edge

If implementation reveals the spec is wrong, return here: edit the spec and re-run the spec gate before continuing. The spec is the contract; keep it true.