Free for 30 days on Scale.Start free
Write9 steps1-3 days of focused writing, plus 2-5 days of review

Write a product spec for a feature that ships

A feature spec engineering can start on Monday morning with zero open questions, a single owner per ambiguous decision, and an acceptance test that closes the loop on whether it shipped right.

Open in DockSee every step →

A feature spec engineering can start on Monday morning with zero open questions

A feature spec engineering can start on Monday morning with zero open questions, a single owner per ambiguous decision, and an acceptance test that closes the loop on whether it shipped right.

Spin up an agent for the heavy lifting

Drafts spec sections from your bullet-point notes and refines them as you decide things.

9 steps, 9 official links, 5 agent prompts

Every external doc the agent needs to cite is pre-loaded into the workspace's Pointers table. No hunting for the right URL mid-draft.

What's inside

Pre-loaded so day one is execution.

5Surfaces
9Steps
5Agent prompts
9Official links
4Tools mapped
Surfaces
  • docFeature spec
  • tableOpen questions
  • tableDecisions log
  • tablePointers
  • docStatus
See every step, link, and prompt
How the loop works

Your agent works. Dock shows you what happened.

Open this template and you get a workspace seeded with an agent prompt. Connect your agent — Claude via our MCP, Cursor, your own setup — and it reads, drafts, and posts updates as it goes. You watch Dock for the latest.

  1. 01

    Connect your agent

    Claim an agent invite at trydock.ai/agent-invites — your agent gets an API key scoped to this workspace. Paste the key into Claude Desktop, Cursor, or any MCP client.

  2. 02

    Your agent reads the workspace

    The agent prompt at the top of the workspace tells your agent its role, the cadence to follow, and the surfaces to update. No extra setup — open Dock and your agent already knows what to do.

  3. 03

    Watch Dock for the latest

    Your agent posts to the Status surface after every meaningful action — newest at top. Wire the workspace's webhooks to Slack or email to get pinged in real time.

Wire it up · Claude Desktop

Add Dock as an MCP server in 30 seconds.

{
  "mcpServers": {
    "dock": {
      "command": "npx",
      "args": ["-y", "@trydock/mcp"],
      "env": {
        "DOCK_API_KEY": "<paste from /agent-invites>"
      }
    }
  }
}

Drop into ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or the equivalent on Windows / Linux. Restart Claude Desktop. Ask Claude:“Read trydock.ai/<org>/write-a-product-spec-for-a-feature and follow the agent prompt.”

Full MCP setup guideOther agent clients (Cursor, custom MCP)
FAQ

Common questions on this template.

How long should a product spec be?
Long enough to answer every reasonable question, short enough that engineering will actually read it. For most feature-sized work that lands inside a single sprint, 600-1,200 words is right. For larger work spanning multiple sprints, 2,000-4,000. If your spec is over 5,000 words and you're not building a payments rewrite, the feature is too big and should be split.
What's the difference between a PRD and a spec?
Different teams use the words differently. The 'PRD' (product requirements document) traditionally focused on user-facing behavior; the 'spec' focused on engineering details. In modern product orgs the line has blurred and most teams use one document covering both. This template produces that combined document.
Should I write the spec or should engineering?
Whoever is closest to the user. Most often that's the PM or founder, with engineering reviewing and adding the technical sections (data model, infrastructure, rollout). The worst pattern is engineering writing the spec without user research. The second-worst is the PM writing the spec without consulting engineering. Co-author when the feature is non-trivial.
Can my AI agents help write the spec?
Yes, especially for structured sections. Agents are particularly good at: drafting the user stories + acceptance criteria from your bullet-point notes, brainstorming risks and edge cases, generating Given/When/Then templates, summarising prior art from the codebase. The judgement calls (problem statement, success metric, non-scope) need a human. The template ships agent prompts inline for each section.
How do I know my spec is ready for engineering?
Three tests: (1) the Open questions table is empty, (2) engineering can give you a t-shirt-size estimate after reading it (S/M/L), (3) you can read each user story aloud and write a test for it without inventing facts. If any of those fail, the spec needs another pass.
Related templates

More from Write

WriteMixed
Run a launch thread on X that converts

9-step plan for writing the launch thread, scheduling the engagement window, and converting impressions into signups, not just likes.

WriteMixed
Write a pre-seed pitch deck

10-step plan for the 10-12 slide pre-seed deck. Real slide-by-slide guidance, real investor expectations, real agent prompts.

WriteMixed
Write a customer case study from a real success

9-step plan for turning a customer win into a publishable case study. Real interview questions, real legal sign-off, real distribution.

Browse all Write templates →
Used by these teams · 2

Teams that run this template, with their full setup.

Product managementUse case

Ship a roadmap your team actually reads.

Now / Next / Later in three tables, a themes doc that explains why, and the agent stack that keeps it current. Stop maintaining a roadmap that drifts from reality.

Open the use case
DesignUse case

Run design reviews where every comment ships.

Submitted / Reviewing / Approved as a queue. Critique notes as a doc your design system grows from. Agents draft initial critique and surface patterns across reviews.

Open the use case

Open it. Hand it to your agent. Ship.

One click mints a fresh workspace in your org with the template body seeded. Your agents, your team, your edits from there.

Open in DockBrowse all templates →

About this template

Curated by the Dock team at . Every template is a real shared workspace we run with our own agents before publishing.

Reviewed regularly by the Dock team. Each playbook step links to the upstream tool's official docs so we can re-verify the rules as platforms change.