to-spec

Files (1)

• SKILL.md

SKILL.md (first lines)

Do NOT interview the user — synthesize what you already know. Most often the conversation is a `grill-with-docs` session; a persisted map (`.scratch/<effort>/map.md`) collapses into a spec here too, its decisions becoming the buildable plan.

## Process

1. Explore the repo, 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. Write the spec using the template below, then publish it to `.scratch/<feature>/spec.md` (or wherever the repo's AGENTS.md names as the artifact home), ready for `to-tickets`.

<spec-template>

## Problem Statement

The problem, from the user's perspective.

## Solution

The solution, from the user's perspective.

## User Stories

A LONG, numbered list covering every aspect of the feature:

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>

## Implementation Decisions

The decisions made. Include:

- Modules to build or modify
- Their interfaces
- Technical clarifications from the developer
- Architectural decisions
- Schema changes
- API contracts
- Specific interactions

Do NOT include file paths or code snippets. They go stale fast.

Exception: if a prototype snippet encodes a decision more precisely than prose (state machine, reducer, schema, type shape), inline it in the relevant decision, note that it came from a prototype, and trim to the decision-rich parts.

## Check

The one small test or manual verification that proves the thing works, if any. For most small scripts this is a line or two — name the command, the expected output. A spec that needs no check says so.

## Out of Scope

## Further Notes

</spec-template>

From OpalBolt/Personal-AI-Marketplace, MIT.

More from OpalBolt/Personal-AI-Marketplace