mcpField
T
to-spec

to-spec

github.com/leandrocfeDevelopment4195 installsUpdated 12w ago
Repository

About to-spec

A skill that drafts feature specs from the current conversation and codebase understanding without interviewing the user. It identifies testing seams, confirms them, and publishes the spec to the project tracker using a defined template.

Key features

  1. 01Synthesize conversation and codebase context
  2. 02Identify and confirm testing seams
  3. 03Draft specs with a defined template
  4. 04Record implementation and testing decisions
  5. 05Publish specs with a readiness label

Use cases

  1. 01Turn known requirements into a feature spec
  2. 02Define high-level boundaries for feature tests
  3. 03Document architecture, interface, and scope decisions
  4. 04Publish a spec to the project issue tracker

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/leandrocfe/skills --skill to-spec

After installing, type/to-specin Claude Code to confirm it loaded.

Bundled filesagents/openai.yaml

Details

From the project README

Esta skill pega o contexto atual da conversa e o entendimento da codebase e produz uma spec. NÃO entreviste o usuário — apenas sintetize o que já sabe.

O issue tracker e o vocabulário de triage labels devem ter sido fornecidos a você — rode /setup-leandrocfe-skills se não.

Processo

  1. Explore o repo para entender o estado atual da codebase, se ainda não fez isso. Use o vocabulário do glossário de domínio do projeto ao longo de toda a spec, e respeite quaisquer ADRs na área que você está tocando.

  2. Esboce os seams nos quais você vai testar a feature. Seams existentes são preferíveis a novos. Use o seam mais alto possível. Se novos seams forem necessários, proponha-os no ponto mais alto que conseguir. Quanto menos seams espalhados pela codebase, melhor — o número ideal é um.

Confirme com o usuário que esses seams batem com o que ele espera.

  1. Escreva a spec usando o template abaixo e publique no issue tracker do projeto. Aplique a triage label ready-for-agent — não é preciso triage adicional.

Problem Statement

O problema que o usuário enfrenta, da perspectiva dele.

Solution

A solução para o problema, da perspectiva do usuário.

User Stories

Uma lista numerada LONGA de user stories. Cada user story deve estar no formato:

  1. Como , quero , para que <benefício>
1. Como cliente de banco mobile, quero ver o saldo das minhas contas, para que eu possa tomar decisões mais bem informadas sobre meus gastos

Esta lista de user stories deve ser extremamente extensa e cobrir todos os aspectos da feature.

Implementation Decisions

Uma lista das decisões de implementação tomadas. Pode incluir:

  • Os módulos que serão construídos/modificados
  • As interfaces desses módulos que serão modificadas
  • Esclarecimentos técnicos do desenvolvedor
  • Decisões arquiteturais
  • Mudanças de schema
  • Contratos de API
  • Interações específicas

NÃO inclua caminhos de arquivo específicos nem trechos de código. Eles podem ficar desatualizados muito rápido.

Exceção: se um prototype produziu um trecho que codifica uma decisão com mais precisão do que a prosa consegue (state machine, reducer, schema, formato de tipo), inclua-o dentro da decisão relevante e anote brevemente que veio de um prototype. Corte para as partes ricas em decisão — não é um demo funcional, só o que importa.

Testing Decisions

Uma lista das decisões de teste tomadas. Inclua:

  • Uma descrição do que faz um bom teste (teste apenas comportamento externo, não detalhes de implementação)
  • Quais módulos serão testados
  • Prior art para os testes (ou seja, tipos similares de teste já existentes na codebase)

Out of Scope

Uma descrição do que está fora do escopo desta spec.

Further Notes

Quaisquer notas adicionais sobre a feature.

Comments

Markdown supported