CommunityProgramación y desarrollogithub.com

mattpocock/to-spec

Convierte la conversación actual en una especificación y la publica en el gestor de incidencias del proyecto: sin entrevista, solo síntesis de lo que ya has discutido.

¿Qué es to-spec?

Este skill permite a un agente de IA convertir el contexto de la conversación actual y el entendimiento del código base en una especificación técnica completa, publicándola directamente en el gestor de incidencias del proyecto (issues). La habilidad evita entrevistar al usuario, basándose únicamente en la información ya discutida. Soporta cualquier proyecto que tenga un gestor de incidencias configurado y una etiqueta de clasificación `ready-for-agent`. El proceso incluye explorar el repositorio, identificar los puntos de integración (seams) de pruebas al nivel más alto posible, y luego escribir la especificación siguiendo una plantilla detallada que cubre: problema, solución, historias de usuario extensas, decisiones de implementación (sin incluir rutas de archivo específicas), decisiones de pruebas y aspectos fuera del alcance. Es útil para desarrolladores que desean agilizar la documentación de características y la creación de incidencias basadas en discusiones previas con el agente.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/mattpocock/skills/tree/main/skills/engineering/to-spec

Installed? Explore more Programación y desarrollo skills: steipete/bluebubbles, steipete/eightctl, steipete/blucli · View all 6 →

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

Documentación

Este skill toma el contexto de la conversación actual y el entendimiento del código base y produce una especificación. NO entrevistes al usuario; simplemente sintetiza lo que ya sabes.

Se te debe haber proporcionado el gestor de incidencias y el vocabulario de etiquetas de clasificación. Si no es así, dile al usuario que ejecute /setup-matt-pocock-skills.

Proceso

  1. Explora el repositorio para entender el estado actual del código base, si aún no lo has hecho. Utiliza el vocabulario del glosario del dominio del proyecto en toda la especificación y respeta cualquier ADR en el área que estés tocando.

  2. Esboza los puntos de integración (seams) en los que vas a probar la funcionalidad. Se deben preferir los puntos existentes a los nuevos. Utiliza el punto más alto posible. Si se necesitan nuevos puntos, propónelos en el nivel más alto que puedas. Cuantos menos puntos haya en el código base, mejor; el número ideal es uno.

Consulta con el usuario si estos puntos cumplen con sus expectativas.

  1. Escribe la especificación utilizando la plantilla a continuación y luego publícala en el gestor de incidencias del proyecto. Aplica la etiqueta de clasificación ready-for-agent; no es necesario más triaje.

Declaración del Problema

El problema que enfrenta el usuario, desde la perspectiva del usuario.

Solución

La solución al problema, desde la perspectiva del usuario.

Historias de Usuario

Una lista LARGA y numerada de historias de usuario. Cada historia de usuario debe tener el formato:

  1. Como , quiero , para

Esta lista de historias de usuario debe ser extremadamente extensa y cubrir todos los aspectos de la funcionalidad.

Decisiones de Implementación

Una lista de decisiones de implementación que se tomaron. Esto puede incluir:

  • Los módulos que se construirán/modificarán
  • Las interfaces de esos módulos que se modificarán
  • Aclaraciones técnicas del desarrollador
  • Decisiones arquitectónicas
  • Cambios en el esquema
  • Contratos de API
  • Interacciones específicas

NO incluyas rutas de archivo específicas o fragmentos de código. Pueden quedar desactualizados muy rápidamente.

Excepción: si un prototipo produjo un fragmento que codifica una decisión con mayor precisión que el texto (máquina de estados, reducer, esquema, forma de tipo), intégralo dentro de la decisión relevante y menciona brevemente que provino de un prototipo. Recorta solo las partes ricas en decisiones, no una demostración funcional, solo las partes importantes.

Decisiones de Pruebas

Una lista de decisiones de pruebas que se tomaron. Incluye:

  • Una descripción de qué constituye una buena prueba (solo probar el comportamiento externo, no los detalles de implementación)
  • Qué módulos se probarán
  • Referencias previas para las pruebas (es decir, tipos similares de pruebas en el código base)

Fuera del Alcance

Una descripción de las cosas que están fuera del alcance de esta especificación.

Notas Adicionales

Cualquier nota adicional sobre la funcionalidad.

Individual skills in this repo

This repo contains 20 individual skills — each has its own dedicated page.

mattpocock/ask-matt

Ask which skill or flow fits your situation. A router over the skills in this repo.

mattpocock/caveman

Ultra-compressed communication mode. Cuts token usage ~75% by dropping filler, articles, and pleasantries while keeping full technical accuracy. Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens", "be brief", or invokes /caveman.

mattpocock/claude-handoff

Hand the current conversation off to a fresh background agent that picks up the work immediately.

mattpocock/codebase-design

Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

mattpocock/diagnose

Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.

mattpocock/diagnosing-bugs

Diagnosis loop for hard bugs and performance regressions. Use when the user says "diagnose"/"debug this", or reports something broken/throwing/failing/slow.

mattpocock/domain-modeling

Build and sharpen a project's domain model. Use when the user wants to pin down domain terminology or a ubiquitous language, record an architectural decision, or when another skill needs to maintain the domain model.

mattpocock/edit-article

Edit and improve articles by restructuring sections, improving clarity, and tightening prose. Use when user wants to edit, revise, or improve an article draft.

mattpocock/git-guardrails-claude-code

Set up Claude Code hooks to block dangerous git commands (push, reset --hard, clean, branch -D, etc.) before they execute. Use when user wants to prevent destructive git operations, add git safety hooks, or block git push/reset in Claude Code.

mattpocock/grilling

Grill the user relentlessly about a plan or design. Use when the user wants to stress-test a plan before building, or uses any 'grill' trigger phrases.

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

mattpocock/grill-with-docs

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.

mattpocock/handoff

Compact the current conversation into a handoff document for another agent to pick up.

mattpocock/implement

Implement a piece of work based on a PRD or set of issues.

mattpocock/implement-spec

Implement a specification in code.

mattpocock/improve-codebase-architecture

Scan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.

mattpocock/loop-me

Grill me about specs for the workflows I want to build, within this workspace.

mattpocock/migrate-to-shoehorn

Migrate test files from `as` type assertions to @total-typescript/shoehorn. Use when user mentions shoehorn, wants to replace `as` in tests, or needs partial test data.

mattpocock/obsidian-vault

Search, create, and manage notes in the Obsidian vault with wikilinks and index notes. Use when user wants to find, create, or organize notes in Obsidian.

Skills relacionados