steroid-specify

Files (1)

• SKILL.md

SKILL.md (first lines)

# Steroid Specify (Specification Generator)

This skill reads the user's vibe from `.memory/changes/<feature>/vibe.md` and, when available, `.memory/changes/<feature>/prompt.json`, then produces a formal specification with testable acceptance criteria.

## Governed Baseline

The live governed authority for this phase is:

- `Steroid runtime contract`
- `Steroid runtime contract`
- `Steroid runtime contract`
- `Steroid runtime contract`

In the live repo, this skill implements the `spec_md` part of the governed `steroid-spec-system`. The downstream `plan_md` part is implemented by `skills/steroid-architect/SKILL.md`.

Internal reference: `Steroid internal reference` (GitHub Steroid, MIT License)

## When To Use

Activate immediately after `@steroid-vibe-capture` completes. Do not wait for user invocation. The vibe.md file must already exist in `.memory/changes/<feature>/`.

## Instructions

### 1. Phase Gate (Physical Enforcement)

Before doing anything, run the gate check:
```
node steroid-run.cjs gate specify <feature>
```
If this command fails, STOP. The vibe capture phase is not complete.

### 2. No User Interaction

Do not ask the user any questions. Read `.memory/changes/<feature>/vibe.md` and translate the vibe into a formal spec. If `.memory/changes/<feature>/prompt.json` exists, use it to preserve prompt intelligence fields like assumptions, non-goals, complexity, and recommended route. Make all decisions silently.

### 3. Anti-Summarization Directive

NEVER write vague acceptance criteria like "it should work" or "the app looks good". Every criterion must be a binary pass/fail test that a TDD engine can validate.

NEVER summarize existing code. Writing "...rest of the code here..." is a critical failure.

### 4. Circuit Breaker Mandate

If at any point you need to run a terminal command, you MUST use:
`node steroid-run.cjs '<command>'`
Direct terminal execution is strictly forbidden.

### 5. Schema Obedience

Write the output to `.memory/changes/<feature>/spec.md` using this exact format:

```markdown
# Specification: <Feature Name>

**Created**: <date>
**Source**: .memory/changes/<feature>/vibe.md
**Status**: Ready for Research

## Scope Boundary

### In Scope (v1)
- [explicit feature 1]
- [explicit feature 2]

### Out of Scope (not v1)
- [explicitly excluded thing 1]
- [explicitly excluded thing 2]

## User Stories

### Story 1: [Brief Title] (Priority: P1)

[Describe this user journey in plain, non-technical language]

**Acceptance Criteria:**

1. **Given** [initial state], **When** [user action], **Then** [expected outcome]
2. **Given** [initial state], **When** [user action], **Then** [expected outcome]

---

### Story 2: [Brief Title] (Priority: P2)

[Describe this user journey in plain, non-technical language]

**Acceptance Criteria:**

1. **Given** [initial state], **When** [user action], **Then** [expected outcome]

---

### Story 3: [Brief Title] (Priority: P3)

[Continue for all stories derived from the vibe]

---

## Edge Cases

- What happens when [boundary condition]?
- How does the system handle [error scenario]?

## Success Criteria

- **SC-001**: [Measurable outcome, e.g., "User can complete primary flow in under 30 seconds"]
- **SC-002**: [Measurable outcome]
- **SC-003**: [Measurable outcome]

## Hard Constraints (from vibe.md)
- [Copy ALL hard constraints from vibe.md verbatim]
- [These are non-negotiable requirements that override all other decisions]

## Prompt Intelligence Notes
- **Primary Intent**: [Copy from prompt.json or vibe.md]
- **Complexity / Risk**: [Copy from prompt.json or vibe.md]
- **Recommended Route**: [Copy from prompt.json or vibe.md]
- **Assumptions Carried Forward**:
  - [Copy assumptions from vibe.md / prompt.json that shape scope]
- **Non-Goals Carried Forward**:

From nzkbuild/steroid-workflow, MIT.

More from nzkbuild/steroid-workflow