Get the FREE Ultimate OpenClaw Setup Guide →

spec

npx machina-cli add skill brsbl/ottonomous/spec --openclaw
Files (1)
SKILL.md
8.8 KB

Argument: $ARGUMENTS

CommandBehavior
/spec listList 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:

  1. List .otto/specs/*.md
  2. For each spec, read frontmatter (id, name, status, created)
  3. Display as table:
   | ID | Name | Status | Created |
   |----|------|--------|---------|
   | design-skill-a1b2 | Design Skill | approved | 2026-01-28 |
  1. If no specs found: "No specs found. Run /spec {idea} to create one."
  2. 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):

  1. Present the finding with its priority level
  2. If suggestion is clear: AskUserQuestion with "Accept", "Reject", "Modify"
  3. If alternatives exist: AskUserQuestion with the options
  4. If accepted: Update the spec file with the change
  5. If rejected: Skip to next finding
  6. 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):

  1. Present the finding with its priority level
  2. If suggestion is clear: AskUserQuestion with "Accept", "Reject", "Modify"
  3. If alternatives exist: AskUserQuestion with the options
  4. If accepted: Update the spec file with the change
  5. If rejected: Skip to next finding
  6. 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."

Source

git clone https://github.com/brsbl/ottonomous/blob/main/skills/spec/SKILL.mdView on GitHub

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

  1. Step 1: Run /spec {idea} to create a new spec via collaborative interview
  2. Step 2: If needed, run /spec revise {spec} to save a draft and start the review
  3. 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

Frequently Asked Questions

Add this skill to your agents
Sponsor this space

Reach thousands of developers