mcpField
T
to-spec

to-spec

github.com/pandoscope开发11.7k 次安装5 周前更新
代码仓库

关于 to-spec

将对话背景和代码库理解整理为自包含产品或功能规格的技能，适用于开发者和 Agent；起草前须确认是否有 grilling session，除非用户明确同意跳过。

主要功能

  1. 01根据上下文综合规格
  2. 02要求决策自包含
  3. 03检查 grilling session 前置条件
  4. 04梳理测试接缝
  5. 05按仓库惯例发布

适用场景

  1. 01根据讨论起草功能 PRD
  2. 02让规格便于不同实现者复现
  3. 03为仓库跟踪系统准备规格

安装

复制下面的命令，在终端中运行。

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

安装后在 Claude Code 中输入/to-spec确认已加载。

详细介绍

编写规格

根据当前对话和对代码库的了解编写规格（即 PRD）。不要采访用户——综合已有信息。

可复现性原则

规格及其后续衍生的工单必须是自包含的：任何实现者，无论是人还是 Agent，重放后都能构建出大致相同的应用。所有影响结果的决策都必须写在规格本身中，或写在规格所引用的持久文档中，例如 ADR（writing-adrs）和术语表条目（docs/glossary/）。不得依赖对话上下文、约定俗成的知识或实现者自行决定。

**检验标准：**如果两个独立的实现者可能构建出有实质差异的内容，则说明规格不够明确。将决策补充到规格中，或记录为 ADR／术语表条目并加以引用。

深入追问门槛

规格至关重要。如果上下文中没有深入追问会话（docs/glossary/grilling-session.md），则停止并询问用户：“未找到深入追问会话——确定要跳过吗？”只有在用户明确确认后才能继续，并在「后续备注」中注明已跳过。

流程

  1. 如果尚未探索代码库，则先进行探索。全程使用术语表中的词汇（uvx disambiguate <term>）；遵守涉及区域的 ADR。

  2. 为功能勾勒测试接缝。优先使用现有接缝；如需新增，尽可能放在最高层。接缝越少越好——理想情况下只有一个。

    与用户确认接缝。

  3. 按模板编写规格——如果可用，使用 writing-prose 技能编写并检查，并提供 ticket；不得牺牲精确性和易理解性。对每个部分应用检验标准，并按照使用方代码库的跟踪规范（AGENTS.md）发布。应用 ready-for-agent 标签——无需进一步分流。

规格模板：

## Problem Statement

Problem, from user's perspective.

## Solution

Solution, from user's perspective.

## User Stories

LONG numbered list: "As an <actor>, I want <feature>, so that <benefit>".
Example: "As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending."
Extremely extensive — cover all aspects.

## Implementation Decisions

Decisions made: modules built/modified, interfaces, technical clarifications, architecture, schema changes, API contracts, specific interactions.

Hard-to-reverse or surprising decisions → also record as ADR (`writing-adrs`) + reference. Decision only in conversation, not listed here → fails litmus test — write it down.

No file paths/code snippets — stale fast. Exception: prototype snippet encoding a decision more precisely than prose (state machine, reducer, schema, type shape) → inline within relevant decision, note prototype origin, trim to decision-rich parts.

## Testing Decisions

What makes a good test (external behavior only, not implementation details), which modules tested, prior art in codebase.

## Out of Scope

What this spec excludes.

## Further Notes

Anything else.

评论

支持 Markdown