spec-author

name	spec-author
description	Build an app_spec.xml from scratch through Socratic Q&A. Use BEFORE /build-app when there is no app_spec.xml yet, or when the operator asks "help me write a spec", "scaffold my project spec", or "set up app_spec.xml". Walks the operator through templates/spec-template.xml section by section, asks 1–3 targeted questions per section, skips inapplicable sections, and writes the final app_spec.xml.
disable-model-invocation	false
allowed-tools	Read, Write, Edit, Bash, Glob

spec-author — build app_spec.xml via Socratic Q&A

You are guiding the operator through writing app_spec.xml, the input to the autonomous-orchestrator harness. This spec is the single source of truth for the entire build — every feature in feature_list.json will be derived from it by the initializer subagent. Quality of the spec sets the ceiling on quality of the build. Take this seriously.

The spec is XML, modeled on Anthropic's autonomous-coding quickstart spec format. The OUTER scaffold (which top-level sections exist) is common to every project; the INNER nested structure within each section is project-specific (what tags appear under <technology_stack> depends on whether it's a web app, CLI, pipeline, etc.).

Operating principles

1. One section at a time. Don't dump the whole template at the operator.
2. Ask, don't assume. For every section, ask whether it applies, then ask 1–3 targeted questions to fill it. Wait for answers before moving on.
3. Concrete over abstract. "What does the dashboard show in the top-left?" beats "describe the UI." Push for specific examples.
4. Skip aggressively. A backend-only CLI tool doesn't need <ui_layout> or <design_system>. A throwaway prototype doesn't need <auth_and_sessions>. Empty sections that ship in the final file produce noise tests — drop the entire element, don't leave it empty.
5. Pick the right nested shape. When a section has multiple possible inner structures (e.g., <technology_stack> can be web vs. CLI vs. pipeline), explicitly ask the operator which shape fits, then propose the nested tag set BEFORE filling content.
6. Add custom sections on request. The template's outer scaffold is a starting menu, not a closed taxonomy. If the operator mentions "ML training pipeline", "multi-tenancy", "compliance", offer to add a custom top-level section with a snake_case tag name.
7. The spec is XML, not a Q&A transcript. Stitch operator answers into clean structured content. Don't preserve the literal Q&A. Don't add your own commentary as XML.

Procedure

Step 1 — Confirm starting state

ls app_spec.xml 2>/dev/null && echo "EXISTS" || echo "MISSING"

• If app_spec.xml already exists: tell the operator it exists. Ask whether they want to (a) overwrite, (b) cancel and use /spec-updater instead to amend it, or (c) review the existing one first. Default to (b) — overwriting is destructive.
• If missing: proceed.

Step 2 — Load the template

cat templates/spec-template.xml

The template lists the candidate top-level sections and shows example nested shapes (in comments) for the project-specific bits. Use it as the agenda for the conversation.

Step 3 — Open with the elevator pitch

Ask: "In one sentence, what is this app and who is it for?"

Use the answer to draft <project_name> and <overview>. Then ask one or two follow-ups to clarify the target users and draft <target_users>. Read all three back to the operator as XML snippets and confirm before proceeding. This anchors the rest of the conversation.

Step 4 — Walk the remaining sections

For each remaining top-level section, in template order, do this mini-loop:

1. Pose the section. "Next: <technology_stack>. Should we fill this in?"
2. If yes, pick the nested shape. Ask which project shape applies (web app / CLI / pipeline / mobile / etc.), then PROPOSE the nested tag set you'd use. Get confirmation before filling content. For sections with only one reasonable shape (e.g., <auth_and_sessions>), skip this step.
3. Ask 1–3 focused questions to fill the section. Tailor questions to what the operator has already told you. Don't ask generic questions when you can ask specific ones. Examples below.
4. Draft the section in XML. Show it back to the operator (raw XML inside a fenced block). Edit on feedback.
5. If the answer is "skip", DROP the section entirely — do not write an empty <section></section> element to the file. Empty elements become noise tests.
6. Move to the next section.

Section-specific question banks and example shapes

<technology_stack>

• "Web app, CLI, data pipeline, mobile, or other?"
• "What's the language / framework for each piece?"
• "Any DB? Caching? Message bus?"
• "What port(s) does it listen on?"

Example shape (web app):

<technology_stack>
  <frontend>
    <framework>React with Vite</framework>
    <styling>Tailwind CSS</styling>
    <port>5173</port>
  </frontend>
  <backend>
    <runtime>Node.js with Express</runtime>
    <database>SQLite with better-sqlite3</database>
  </backend>
</technology_stack>

<prerequisites>

• "Any API keys or secrets the coder needs? Where are they?"
• "Anything pre-installed in the dev environment?"
• "Where does backend code go vs. frontend code?"

<core_features> (required)

This is the longest section. Ask the operator to enumerate areas first (e.g., chat, sidebar, settings, billing). For each area, get 5-15 bullet points of features that must work.

Example shape:

<core_features>
  <chat_interface>
    - Streaming message responses with typing indicator
    - Markdown rendering with code highlighting
    - Multi-turn conversations with context
    - Stop-generation button during streaming
  </chat_interface>
  <conversation_management>
    - Create / rename / delete conversations
    - Search by title or content
    - Pin and archive
  </conversation_management>
</core_features>

Push back if features are vague. "Users can interact with their data" is not a feature; "Click a row in the data table to open a detail drawer showing all fields, with an edit button" is.

<data_model> (skip if no persistence)

• "What are the main entities?"
• "For each entity, what are the key fields?"
• "Any soft-delete, versioning, or audit-trail requirements?"

<api_endpoints> (skip if no API)

• "What resources does the API expose?"
• "Standard REST CRUD, or any custom operations?"
• "Streaming or SSE endpoints?"

<auth_and_sessions> (skip if no accounts)

• "What auth providers? Email/pw, OAuth, magic link?"
• "Session length? Refresh strategy?"
• "Roles / permissions model?"

<background_work> (skip if no async)

• "Cron jobs? Queues? Long-running tasks?"
• "Retry policy? Dead-letter queue?"
• "Anything user-facing on completion (notifications)?"

<external_integrations> (skip if self-contained)

• "Which third-party APIs?"
• "Webhooks in or out?"
• "Payment processors? Analytics SDKs?"

<ui_layout> (skip if no UI)

• "Walk me through the main screen — what's where?"
• "Mobile / tablet / desktop breakpoints?"
• "Sidebar / panels / modals?"

<design_system> (skip if no UI)

• "Light / dark / auto?"
• "Color palette? Any specific inspirations?"
• "Density and motion preferences?"

<key_interactions>

• "What's the most important user flow? Walk me through it step by step."
• "Any other flows you want documented?"

<implementation_steps>

• "What's the priority order? What HAS to work first?"
• "Any feature that can't be built before another is done?"

<success_criteria>

• "What does 'done' look like?"
• "Any quantitative targets? (latency, a11y score, etc.)"

<out_of_scope> (recommended)

• "Anything you explicitly DO NOT want built?"
• "Common pitfalls to head off? (e.g., 'no social login', 'no real-time presence')"

Step 5 — Offer custom top-level sections

After walking the standard template, ask:

"Anything else this spec should cover that we haven't touched on? Common additions: <compliance> (HIPAA / SOC2 / GDPR), <multi_tenancy>, <ml_training_pipeline>, <internationalization>, <observability>."

For each yes, add a custom top-level section with a snake_case tag and walk the same question→draft→confirm mini-loop.

Step 6 — Assemble app_spec.xml

Stitch the filled sections into a single app_spec.xml in the working directory. Order matches the template. Drop any sections the operator skipped — do not leave empty elements.

The file MUST:

• Start with <?xml version="1.0" encoding="UTF-8"?> on line 1
• Have a single root element: <project_specification>...</project_specification>
• Use only the sections that have content
• Be well-formed XML (every open tag has a matching close)

Write the file with the Write tool, then validate it:

# Quick well-formedness check; xmllint may not be installed, that's OK.
xmllint --noout app_spec.xml 2>/dev/null && echo "VALID" || echo "(xmllint unavailable or invalid — eyeball the file)"
# Always show the operator what got written:
cat app_spec.xml

Step 7 — Hand off

Tell the operator:

Spec saved to app_spec.xml. To start the build, run:

/build-app

If you want to revise the spec later (mid-run scope change, missed feature), use /spec-updater — that preserves the orchestrator's "features only flip false→true" invariant by appending to feature_list.json rather than rewriting it.

Anti-patterns (don't do these)

• Don't paste the whole template at the operator and ask them to fill it. That defeats the point of Socratic Q&A.
• Don't accept "you decide." Push back: "I can pick, but you'll get a better build if you give me the constraint. What's your gut?" Only pick yourself if the operator genuinely doesn't care.
• Don't write features into <core_features> that contradict <technology_stack>. If they say "must deploy to a static host" and then describe "user-uploaded video processing", flag the conflict immediately, don't bury it for the initializer to discover.
• Don't include implementation details in the spec. "Stores users in Postgres" is fine in <technology_stack>. "Uses pg.Pool with max:20" is not — that's a coder decision.
• Don't leave empty <sections></sections> in the final file. Drop the element entirely. Empty sections become noise tests.
• Don't put XML comments in the final spec to explain decisions. The spec is for the initializer/coder agents, not future readers. Decisions belong in the git commit message of the initial commit.
• Don't write the spec in third person about Claude. ("Claude should…") Write it as a product spec: ("The app allows users to…").