spec
npx machina-cli add skill brsbl/ottonomous/spec --openclawArgument: $ARGUMENTS
| Command | Behavior |
|---|---|
/spec list | List all specs with id, name, status, created date |
/spec {idea} | Create new spec through collaborative interview |
/spec revise {spec} | Save spec and go straight to review with codebase exploration |
List Mode
If $ARGUMENTS is list:
- List
.otto/specs/*.md - For each spec, read frontmatter (id, name, status, created)
- Display as table:
| ID | Name | Status | Created |
|----|------|--------|---------|
| design-skill-a1b2 | Design Skill | approved | 2026-01-28 |
- If no specs found: "No specs found. Run
/spec {idea}to create one." - Stop here — do not continue to interview workflow.
Revise Mode
If $ARGUMENTS starts with revise:
Spec Content: Everything after revise  in $ARGUMENTS
If no spec content provided, ask: "Provide the spec content to save. The first line should be the product name."
Parse the provided content:
- Name: First line of the spec content
- Body: Everything after the first line
1. Gather Context
Analyze codebase:
- Use Glob to find relevant files
- Use Read to understand current architecture
- Use Grep to search for related patterns
- Note patterns and design decisions for the review
2. Draft Spec
Map the provided content to this template structure (mark missing sections as [TBD]):
Product Requirements:
- Overview - What and why, problem being solved
- Goals / Non-Goals - Explicit scope boundaries
- User Stories - User-facing behavior
Technical Design:
- Architecture - System design, component relationships
- Detailed Design - Implementation approach, key algorithms
- API / Interface - Public interfaces, contracts
- Data Model - Schema, storage, state
Planning:
- Future Considerations - Deferred features, extensibility
- Open Questions - Unresolved decisions marked as
[TBD: reason]
3. Save Draft
Generate unique ID from product name:
name=$(echo "$NAME" | head -1)
slug="${name,,}" # Convert to lowercase
slug="${slug// /-}" # Replace spaces with hyphens
slug="${slug:0:30}" # Truncate to 30 characters
hash=$(sha1sum <<< "$name$(date +%s%N)" 2>/dev/null || shasum <<< "$name$(date +%s%N)")
hash="${hash:0:4}"
id="${slug}-${hash}"
mkdir -p .otto/specs
Write to .otto/specs/{id}.md:
---
id: {id}
name: {Name}
status: draft
created: {YYYY-MM-DD}
updated: {YYYY-MM-DD}
---
{spec content mapped to template structure}
4. Clarify Ambiguities
If any sections are marked [TBD] or contain ambiguous requirements:
Use AskUserQuestion to resolve each ambiguity before proceeding to review. For each unclear item:
- Present what's missing or unclear
- Offer 2-3 options if applicable
- Update the spec file with the user's answers
Skip this step if the spec is complete with no [TBD] markers.
5. Review Spec
Launch technical-product-manager subagent with Task tool:
Handoff to technical-product-manager:
- Spec path:
.otto/specs/{id}.md - Spec ID:
{id} - Codebase context: Include relevant patterns and architecture discovered in step 1
The subagent reads the spec, reviews for completeness, consistency, feasibility, ambiguity, and technical correctness. Returns prioritized findings (P0-P2) with specific sections, issues, and suggestions.
Wait for review to complete.
6. Interview User on Findings
If no findings, skip to step 7.
For each finding (highest priority first):
- Present the finding with its priority level
- If suggestion is clear:
AskUserQuestionwith "Accept", "Reject", "Modify" - If alternatives exist:
AskUserQuestionwith the options - If accepted: Update the spec file with the change
- If rejected: Skip to next finding
- If modify: Apply user's modified version
After processing all findings, update the spec file with changes.
7. Approval
Output the full spec as rendered markdown so the user can review it inline.
Use AskUserQuestion with options:
- "Approve"
- "Request changes"
- "Open in editor" — run
open .otto/specs/{id}.md, then ask again
After each revision: Output the full updated spec as rendered markdown before asking for approval again. Revise until approved.
On approval, update status: draft to status: approved in the file.
Report: "Spec approved and saved to .otto/specs/{id}.md"
8. Next Steps
Offer task generation:
"Run
/task {id}to generate implementation tasks."
Create Mode
Product Idea: $ARGUMENTS
If no argument provided, ask: "What would you like to build?"
1. Gather Context
Check for existing specs:
ls .otto/specs/*.md 2>/dev/null
Ask about reference projects:
"Are there any reference projects or examples I should look at for inspiration?"
If provided, explore the reference project(s) to understand their approach.
Analyze codebase:
- Use Glob to find relevant files
- Use Read to understand current architecture
- Use Grep to search for related patterns
- Note patterns and design decisions to reference during interview
2. Research Best Practices
Use WebSearch to find and WebFetch to read:
- Industry best practices for the product type
- Common pitfalls and recommendations
- How popular projects solve similar problems
- Documentation and API references
For visual research (competitor products, reference implementations):
- Use browser automation (
skills/otto/lib/browser) to navigate sites and capture screenshots - Save screenshots to
.otto/research/
3. Interview
Use AskUserQuestion to gather requirements. For each decision point:
- Present 2-3 options
- Mark one as "(Recommended)" based on research
- Include pros/cons and what research suggests
Topics to cover:
- Core requirements and constraints
- Key architectural decisions
- Scope boundaries (what's in, what's out)
- Edge cases
4. Draft Spec
Write a spec covering:
Product Requirements:
- Overview - What and why, problem being solved
- Goals / Non-Goals - Explicit scope boundaries
- User Stories - User-facing behavior
Technical Design:
- Architecture - System design, component relationships
- Detailed Design - Implementation approach, key algorithms
- API / Interface - Public interfaces, contracts
- Data Model - Schema, storage, state
Planning:
- Future Considerations - Deferred features, extensibility
- Open Questions - Unresolved decisions marked as
[TBD: reason]
5. Save Draft
Generate unique ID from product idea:
slug="${ARGUMENTS,,}" # Convert to lowercase
slug="${slug// /-}" # Replace spaces with hyphens
slug="${slug:0:30}" # Truncate to 30 characters
hash=$(sha1sum <<< "$ARGUMENTS$(date +%s%N)" 2>/dev/null || shasum <<< "$ARGUMENTS$(date +%s%N)")
hash="${hash:0:4}"
id="${slug}-${hash}"
mkdir -p .otto/specs
Write to .otto/specs/{id}.md:
---
id: {id}
name: {Product Idea}
status: draft
created: {YYYY-MM-DD}
updated: {YYYY-MM-DD}
---
{spec content}
6. Review Spec
Launch technical-product-manager subagent with Task tool:
Handoff to technical-product-manager:
- Spec path:
.otto/specs/{id}.md - Spec ID:
{id}
The subagent reads the spec, reviews for completeness, consistency, feasibility, ambiguity, and technical correctness. Returns prioritized findings (P0-P2) with specific sections, issues, and suggestions.
Wait for review to complete.
7. Interview User on Findings
If no findings, skip to step 8.
For each finding (highest priority first):
- Present the finding with its priority level
- If suggestion is clear:
AskUserQuestionwith "Accept", "Reject", "Modify" - If alternatives exist:
AskUserQuestionwith the options - If accepted: Update the spec file with the change
- If rejected: Skip to next finding
- If modify: Apply user's modified version
After processing all findings, update the spec file with changes.
8. Approval
Output the full spec as rendered markdown so the user can review it inline.
Use AskUserQuestion with options:
- "Approve"
- "Request changes"
- "Open in editor" — run
open .otto/specs/{id}.md, then ask again
After each revision: Output the full updated spec as rendered markdown before asking for approval again. Revise until approved.
On approval, update status: draft to status: approved in the file.
Report: "Spec approved and saved to .otto/specs/{id}.md"
9. Next Steps
Offer task generation:
"Run
/task {id}to generate implementation tasks."
Overview
Spec writes product specifications through collaborative interviews with stakeholders and targeted web research. It helps teams plan, gather requirements, and design features by producing a structured PRD and technical design.
How This Skill Works
You provide a product idea or problem. The spec tool conducts a collaborative interview and web research, mapping findings to a template with sections like Product Requirements, Technical Design, and Planning. It saves drafts with a unique ID to .otto/specs and supports a review workflow via a dedicated subagent.
When to Use It
- Planning a new feature or product idea
- Gathering requirements from stakeholders
- Designing a feature with clear success criteria
- Creating a PRD for handoff to engineering
- Updating or revising an existing spec with new insights
Quick Start
- Step 1: Run /spec {idea} to create a new spec via collaborative interview
- Step 2: If needed, run /spec revise {spec} to save a draft and start the review
- Step 3: Review the generated spec at .otto/specs/{id}.md and iterate
Best Practices
- Define the product name and scope upfront; keep the first line as the name
- Follow the template structure: Product Requirements, Technical Design, Planning
- Capture user stories and explicit non-goals to set boundaries
- Conduct a quick codebase/context scan to inform design decisions
- Validate with stakeholders and log open questions for review
Example Use Cases
- PRD for a mobile wallet onboarding flow
- API spec for a user authentication workflow
- Feature spec for checkout optimization
- Spec for a new analytics dashboard
- Spec for an internal task management tool