From stv
Generates feature spec.md files via proposal, business interview, and decision gates, combining PRD and architecture in one pass. Handles update vs new specs non-linearly.
npx claudepluginhub 2lab-ai/oh-my-claude --plugin stvThis skill uses the workspace's default tool permissions.
> STV Phase 1: Feature interview → `docs/{feature}/spec.md`
Generates design tokens/docs from CSS/Tailwind/styled-components codebases, audits visual consistency across 10 dimensions, detects AI slop in UI.
Records polished WebM UI demo videos of web apps using Playwright with cursor overlay, natural pacing, and three-phase scripting. Activates for demo, walkthrough, screen recording, or tutorial requests.
Delivers idiomatic Kotlin patterns for null safety, immutability, sealed classes, coroutines, Flows, extensions, DSL builders, and Gradle DSL. Use when writing, reviewing, refactoring, or designing Kotlin code.
STV Phase 1: Feature interview →
docs/{feature}/spec.mdPRD (what to build) + Architecture (how to build) confirmed in a single pass.
Read ${CLAUDE_PLUGIN_ROOT}/prompts/decision-gate.md and apply it to every decision in this workflow.
Apply this gate to every decision. switching cost < small → autonomous judgment, == small → autonomous decision + report, >= medium → ask the user.
Before diving into the spec interview, establish the WHY in 60 seconds. This prevents direction drift on complex features.
Output a brief Proposal block (inline, not a separate file):
### Proposal
- **Why**: {1-2 sentences — the problem or opportunity that motivates this change}
- **What Changes**: {bullet list of what will be different}
- **Capabilities**: {new or modified capabilities this enables}
- **Impact**: {affected code areas, APIs, dependencies. BREAKING changes flagged}
Rules:
stv:explore firstInterpret argument:
Explore codebase (Agent:Explore):
When an existing spec is detected, decide whether to UPDATE or create NEW:
Is the intent the same problem/goal?
├── YES → Is the scope still manageable?
│ ├── YES → UPDATE existing spec
│ └── NO (scope explosion) → NEW spec (link to original)
└── NO (intent changed) → NEW spec
└── Can original spec be independently "completed"?
├── YES → Complete original, then NEW
└── NO → Deprecate original, start NEW
UPDATE mode: Modify existing spec.md in-place. Record changes in a ## Spec Changelog section.
NEW mode: Create a new docs/{feature-v2}/spec.md. Reference the original.
Interview via AskUserQuestion. Apply Decision Gate:
Bundle 2-4 related questions into a single AskUserQuestion:
Must cover:
Decision Gate applied:
Must cover:
Decision Gate applied:
DO:
### Auto-Decisions sectionDON'T:
After interview is complete (user confirmed or all dimensions covered):
docs/{feature-name}/spec.md# {Feature Name} — Spec
> STV Spec | Created: {date}
## 1. Overview
### Proposal
- **Why**: {1-2 sentences — the problem or opportunity}
- **What Changes**: {bullet list}
- **Capabilities**: {new/modified capabilities}
- **Impact**: {affected areas, BREAKING if applicable}
{1-2 paragraphs expanding on the above}
## 2. User Stories
- As a {actor}, I want {action}, so that {outcome}
- ...
## 3. Acceptance Criteria
- [ ] {criterion 1}
- [ ] {criterion 2}
- ...
## 4. Scope
### In-Scope
- ...
### Out-of-Scope
- ...
## 5. Architecture
### 5.1 Layer Structure
{Controller → Handler → Service → DB flow overview}
### 5.2 API Endpoints
| Method | Path | Handler | Description |
|--------|------|---------|-------------|
| POST | /api/... | ...Create | ... |
| GET | /api/... | ...List | ... |
| ... | ... | ... | ... |
### 5.3 DB Schema
{Entity list + key fields}
### 5.4 Integration Points
{Connection points with existing systems}
## 6. Non-Functional Requirements
- Performance: ...
- Security: ...
- Scalability: ...
## 7. Auto-Decisions
{Content autonomously decided via Decision Gate. Includes tier and rationale}
| Decision | Tier | Rationale |
|----------|------|-----------|
| ... | tiny | ... |
| ... | small | ... |
## 8. Open Questions
{Remaining unresolved items. "None" if empty}
## 9. Spec Changelog
{Change history when spec is updated. Empty on initial creation.}
## 10. Next Step
→ Proceed with Vertical Trace via `stv:trace`
STV phases (spec → trace → work) are NOT a one-way waterfall. Going back is normal and expected.
When to return to spec from later phases:
stv:trace: discovered a missing scenario or ambiguous requirement → update specstv:work: implementation reveals a spec assumption was wrong → update specstv:verify: gap detected that traces back to a spec error → update specHow to return:
stv:spec with the existing spec pathThis is not failure. This is the Feedback Loop invariant in action.
docs/{feature-name}/spec.mdSkill(skill="stv:trace") or guide user to use stv:trace docs/{feature-name}/spec.md