steroid-architect

Files (1)

• SKILL.md

SKILL.md (first lines)

# Steroid Architect

This skill reads the spec and research from `.memory/changes/<feature>/` and produces a granular, test-ready implementation plan.

## Governed Baseline

The live governed authority for the planning surface is:

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

In the live repo, this skill implements the `plan_md` part of the governed `steroid-spec-system` after the specification artifact has been locked.

## When To Use

Activate immediately after `@steroid-research` completes. Do not wait for user invocation.

## Instructions

### 1. Phase Gate (Physical Enforcement)

Before doing anything, run the gate check:

```
node steroid-run.cjs gate architect <feature>
```

If this command fails, STOP. The research phase is not complete.

### 2. No User Interaction

Do not ask the user any questions. Read the following files and make all architectural decisions silently:

1. `.memory/changes/<feature>/vibe.md` — The aesthetic vision
2. `.memory/changes/<feature>/spec.md` — The acceptance criteria
3. `.memory/changes/<feature>/research.md` — The investigated tech stack and patterns
4. `.memory/changes/<feature>/prompt.json` — The normalized prompt interpretation, if present
5. `.memory/changes/<feature>/design-routing.json` — The internal frontend routing receipt, if present
6. `.memory/changes/<feature>/design-system.md` — The generated design system artifact, if present

Use the researched stack from `research.md`. Do NOT guess or pick your own tech stack — the Research skill already investigated and verified the best tools.
For UI-intensive work, `design-system.md` is the binding frontend artifact. The physical gate now blocks architect if UI work is missing `design-routing.json` or `design-system.md`.

### 2. Anti-Summarization Directive

NEVER write vague tasks like "Setup Auth", "Build Backend", or "Implement Frontend". Every task must be a 5-minute atomic step that a TDD engine can execute.

NEVER summarize existing code. If instructed to reproduce or fork a file, reproduce it line-by-line. Writing "...rest of the code here..." is a critical failure.

NEVER use "..." or truncate the checklist. Write every single task explicitly.

### 3. Schema Obedience

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

```markdown
# Implementation Plan: <Feature Name>

**Source**: .memory/changes/<feature>/spec.md + research.md
**Created**: <date>

## Tech Stack

- Frontend: [from research.md Standard Stack]
- Backend: [from research.md Standard Stack, or "None"]
- Database: [from research.md, or "None - localStorage"]
- Styling: [from research.md Standard Stack]

## Execution Checklist

- [ ] Initialize [framework] project via temp-directory scaffold (see engine scaffold safety)
- [ ] Install and configure [from research.md installation command]
- [ ] Create [Component A] with layout and placeholder content
- [ ] Write test for [Component A] core behavior (Story 1, AC 1)
- [ ] Implement [Component A] to pass test
- [ ] Create [Component B] with [specific functionality]
- [ ] Write test for [Component B] core behavior (Story 2, AC 1)
- [ ] Implement [Component B] to pass test
- [ ] Connect [Component A] and [Component B] via [routing/state]
- [ ] Write integration test for the full user flow (SC-001)
- [ ] Apply final styling polish and micro-animations
```

**Brownfield Override (v5.5.0):** If vibe.md has `Project Type: Brownfield`, do NOT include:

- `Initialize [framework] project` tasks — the project already exists
- `npm init` or framework scaffolding commands
- Tasks that would overwrite existing config files (`tsconfig.json`, `next.config.*`, etc.)

Instead, generate an _integration_ checklist that adds to the existing structure without destroying it.

Each checklist item must:

- Be specific enough that an AI sub-agent with fresh context can execute it without ambiguity
- Reference which user story / acceptance criterion it satisfies (from spec.md)
- Map to researched libraries (from research.md) — not arbitrary choices

If `prompt.json` exists, adapt the checklist shape to the approved route without breaking the structure:

- `lite-change` → keep the checklist tight and focused on the smallest viable set of files/tasks
- `resume-mode` → prefer incremental integration tasks over fresh setup tasks
- `split-work` → group tasks by sub-problem or story so execution does not blend multiple intents together
- `research-heavy` → include explicit validation or compatibility tasks before implementation

Do NOT invent new route names. Use `prompt.json` only as planning context inside the existing structure.

**UI-intensive override:** If `research.md` contains `## Design Intelligence`, the checklist MUST translate it into implementation tasks. Do not leave design direction trapped in research. Create explicit tasks for tokens, layout hierarchy, component states, responsive behavior, accessibility constraints, source-input rule application, and final anti-pattern review.
If `design-system.md` exists, the checklist MUST reference it explicitly in frontend tasks instead of inventing a separate design direction.

### 4. Task Ordering Rules

Follow this order for each component:

1. **Create** the component file with layout/structure
2. **Write test** for the component (referencing spec.md acceptance criteria)
3. **Implement** the component to pass the test
4. **Repeat** for next component

From nzkbuild/steroid-workflow, MIT.

More from nzkbuild/steroid-workflow