AutoGineer
Generated banner for To Spec
Generated logo for To Spec

To Spec

Matt PocockCommunityCreated by Matt Pocock

  • Skill
  • Content generator
  • Software development
  • MIT
  • No issues found
Download ZIP

From the author

Turn the current conversation into a spec and publish it to the project issue tracker: no interview, just synthesis of what you've already discussed.
— the description by Matt Pocock

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

The to-spec skill automates the creation of technical documentation by synthesizing ongoing conversation context and codebase knowledge. It eliminates the need for user interviews, instead relying on the agent's understanding of the project's domain, existing architecture, and ADRs to draft a comprehensive specification. The process includes identifying optimal testing seams, defining user stories, and outlining implementation and testing decisions, which are then published directly to the project's issue tracker with the appropriate triage labels.

What it does

  • Synthesizes current conversation and codebase context into a formal specification.
  • Identifies and proposes optimal testing seams for new features.
  • Generates an extensive list of user stories based on the project requirements.
  • Documents implementation and testing decisions without relying on brittle file paths.
  • Publishes the completed specification to the project issue tracker.
  • Applies the ready-for-agent triage label to new issues.

When to use it

  • When a feature discussion has reached a point of clarity and needs to be formalized.
  • When you need to transition from conceptual planning to actionable development tasks.
  • When you want to ensure architectural consistency by referencing existing ADRs and domain vocabulary.
  • When you need to document testing strategies and implementation boundaries for a team.

Advantages

  • Reduces manual documentation overhead by automating spec generation.
  • Ensures technical specs are aligned with existing codebase patterns and domain language.
  • Promotes high-level architectural thinking by focusing on seams rather than specific file paths.
  • Standardizes the format of project requirements across the team.

Usage examples

“We have finished discussing the new user authentication flow. Please run to-spec.”
The agent synthesizes the authentication flow discussion, drafts a spec including user stories and testing decisions, and publishes it to the issue tracker.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/mattpocock/to-spec/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip to-spec.zip -d .agents/skills

Documentation by Matt Pocock

This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user; just synthesize what you already know.

The issue tracker and triage label vocabulary should have been provided to you. If not, tell the user to run /setup-matt-pocock-skills.

Process

  1. Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.

  2. Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.

Check with the user that these seams match their expectations.

  1. Write the spec using the template below, then publish it to the project issue tracker. Apply the ready-for-agent triage label - no need for additional triage.

<spec-template>

Problem Statement

The problem that the user is facing, from the user's perspective.

Solution

The solution to the problem, from the user's perspective.

User Stories

A LONG, numbered list of user stories. Each user story should be in the format of:

  1. As an <actor>, I want a <feature>, so that <benefit>

<user-story-example> 1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending </user-story-example>

This list of user stories should be extremely extensive and cover all aspects of the feature.

Implementation Decisions

A list of implementation decisions that were made. This can include:

  • The modules that will be built/modified

  • The interfaces of those modules that will be modified

  • Technical clarifications from the developer

  • Architectural decisions

  • Schema changes

  • API contracts

  • Specific interactions

Do NOT include specific file paths or code snippets. They may end up being outdated very quickly.

Exception: if a prototype produced a snippet that encodes a decision more precisely than prose can (state machine, reducer, schema, type shape), inline it within the relevant decision and note briefly that it came from a prototype. Trim to the decision-rich parts, not a working demo, just the important bits.

Testing Decisions

A list of testing decisions that were made. Include:

  • A description of what makes a good test (only test external behavior, not implementation details)

  • Which modules will be tested

  • Prior art for the tests (i.e. similar types of tests in the codebase)

Out of Scope

A description of the things that are out of scope for this spec.

Further Notes

Any further notes about the feature.

</spec-template>

Files

agents/openai.yaml

interface:
  display_name: "To Spec"
  short_description: "Turn a conversation into a spec"
policy:
  allow_implicit_invocation: false

Requirements and compatibility

Written for: Claude Code

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Claude Code frontmatter

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Created by
Matt Pocock
Publisher
Matt Pocock (Community)
Source
mattpocock/skills · skills/engineering/to-spec · commit 4ae2317
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Matt Pocock.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download to-spec.zip