steroid-research

Files (1)

• SKILL.md

SKILL.md (first lines)

# Steroid Research (Tech Investigation Agent)

This skill reads the spec from `.memory/changes/<feature>/spec.md` and investigates the best technical approach before the Architect commits to a plan.

## 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 is the execution surface for the governed `steroid-research-system`.

The governed live research artifacts are:

- `.memory/changes/<feature>/context.md`
- `.memory/changes/<feature>/research.md`

Internal reference: `Steroid internal reference` (Steroid, MIT License) — simplified from 556 to ~150 lines for the Steroid non-technical context.

## When To Use

Activate immediately after `@steroid-specify` completes. Do not wait for user invocation. The spec.md file must already exist in `.memory/changes/<feature>/`.
Also read `.memory/changes/<feature>/context.md` as the governed internal codebase map from scan.

## Instructions

### 1. Phase Gate (Physical Enforcement)

Before doing anything, run the gate check:

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

If this command fails, STOP. The specification phase is not complete.
For UI-intensive work, this gate now auto-bootstraps `design-routing.json` and `design-system.md` when enough prompt/spec/vibe context exists.

### 2. No User Interaction

Do not ask the user any questions. Read `.memory/changes/<feature>/spec.md`, and if present `.memory/changes/<feature>/prompt.json`, investigate what's needed, and make all recommendations silently.

### 2. Research Philosophy

> Forked from Steroid: "Research is investigation, not confirmation."

- Treat your training data as **hypothesis, not fact**. Libraries change, APIs break, best practices evolve.
- **Verify before asserting** — don't state library capabilities without checking official docs or package registries.
- **Be honest about gaps** — "I couldn't verify this" is more valuable than a confident lie.
- **Be prescriptive, not exploratory** — "Use X" not "Consider X or Y". The Architect needs decisions, not options.

### 3. 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.

### 3b. Constraint Obedience (v5.5.0)

Read the `## Hard Constraints` section from spec.md. If the user explicitly requested a specific technology, version, or approach (e.g., "must use Framer Motion", "do NOT use a database"), the research MUST:

- Center around that constraint, not recommend alternatives
- Explain how to best use the constrained technology, not argue against it
- Only flag constraints that are technically impossible (e.g., "use React for an iOS native app")

If `prompt.json` exists, also preserve:

- `recommendedPipeline` as route context for how heavy the research should be
- `complexity` and `risk` as signals for how cautious the investigation should be
- `nonGoals` so you do not accidentally expand scope with optional tooling

**Design prep primitive:** If you need to refresh both UI artifacts manually in one shot, run:
`node steroid-run.cjs design-prep "<normalized prompt or user request>" --feature <feature> --write`

**Design routing receipt:** For UI-intensive work, the research gate now tries to auto-create this. If you need only the routing receipt, run:
`node steroid-run.cjs design-route "<normalized prompt or user request>" --feature <feature> --write`

If `design-routing.json` exists afterward, treat it as the routing receipt for which frontend source-library inputs Steroid should use during research.

**Design system artifact:** For UI-intensive work, the research gate now tries to auto-create this too. If you need only the design system artifact, run:
`node steroid-run.cjs design-system --feature <feature> --write`

`design-system.md` is not optional polish. It is the binding artifact that Architect and Engine now expect for UI-intensive work.

### 3c. Brownfield Context Check (v5.5.0)

Read vibe.md for the `Project Type` field. If it says **Brownfield**:

1. Run `node steroid-run.cjs scan` to detect the existing tech stack
2. Your research MUST respect the existing stack — do NOT recommend replacing it
3. Focus on libraries that integrate with what's already there
4. Note version compatibility with existing dependencies

If `prompt.json` says `continuationState` is `resume` or `mid-feature`, prefer incremental recommendations over broad re-architecture.

### 4. What To Investigate

For each user story in the spec, identify:

**Standard Stack** — What libraries/frameworks are the proven choice for this type of feature?

- Include specific version numbers
- Prefer stable, well-maintained packages over trendy new ones
- For a non-technical user's project, prefer zero-config or minimal-config tools

**Architecture Patterns** — What's the recommended project structure and design approach?

- File organization that scales
- State management approach
- Data flow patterns

**Don't Hand-Roll** — What problems look simple but have battle-tested solutions?

- Date/time handling → use a library
- Form validation → use a library
- Charting → use a library
- Never build what npm already solved

From nzkbuild/steroid-workflow, MIT.

More from nzkbuild/steroid-workflow