mcpField
T
to-spec

to-spec

github.com/pandoscope開発11.7k 回インストール5 週間前に更新
リポジトリ

to-spec について

会話の文脈とコードベースの理解から、自己完結した製品・機能仕様を作成するスキルです。開発者やエージェント向けで、ユーザーが明示的に省略を承認しない限り、起草前にグリリングセッションの有無を確認します。

主な機能

  1. 01文脈から仕様を統合
  2. 02判断の自己完結性を徹底
  3. 03グリリングセッション要件の確認
  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 とも呼ばれます）を作成します。ユーザーに質問してはいけません。すでに把握している情報をまとめてください。

再現性の不変条件

仕様書と、そこから後で作成されるチケットは自己完結型でなければなりません。人間またはエージェントを問わず、誰が再現しても、おおむね同じアプリケーションを構築できる必要があります。結果を左右するすべての判断は、仕様書自体、または仕様書が参照する永続的なドキュメント（ADR（writing-adrs）、用語集の用語（docs/glossary/））に記載してください。会話の文脈や、実装者の裁量に委ねてはいけません。

リトマス試験： 独立した 2 人の実装者が、実質的に異なるものを構築できてしまう場合、仕様が不十分です。判断を仕様書に追加するか、ADR／用語集の用語として記録して参照してください。

要件確認のゲート

仕様書は重要な土台です。コンテキストに要件確認セッション（docs/glossary/grilling-session.md）がない場合は、作業を止めてユーザーに「要件確認セッションが見つかりません。省略してもよいですか？」と尋ねてください。明示的な確認を得てから進め、補足事項に省略したことを記載してください。

手順

  1. まだリポジトリを調査していない場合は調査します。全体を通して用語集の語彙（uvx disambiguate <term>）を使用し、対象領域の ADR を遵守してください。

  2. 機能をテストするための接続点を概略化します。既存の接続点を優先し、新しい接続点は可能な限り上位の階層に設けてください。接続点の数は少ないほどよく、理想は 1 つです。

    接続点をユーザーと確認してください。

  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 対応