ワンクリックでManusで任意のスキルを実行

dev-spec-kit-clarify

スター0

フォーク0

更新日2026年6月19日 21:38

Resolve ambiguity in a raw intake or draft spec by asking the user ≤5 high-value questions, each with a recommended default. Use before finalizing a full-spec route, or when `spec.onVague` is "clarify", or whenever a requirement is under-specified.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

Pratiyush

Pratiyush/dev-spec-kit

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

dev-spec-kit clarify — ≤5 questions, recommended-option, one at a time

Verification only works if the spec says something falsifiable. Before authoring criteria, find the ambiguity and resolve it with the user — cheaply. Borrowed from spec-kit's /clarify: the model pre-answers, the user mostly says "yes".

Detection passes (run all six over the intake/spec)

Ambiguity — terms with more than one reading ("fast", "secure", "soon").
Missing edge cases — unstated behavior on invalid input, empty/boundary, failure.
Contradictions — two requirements that can't both hold.
Under-specified acceptance — "works" with no observable outcome.
Hidden assumptions — implied infra, auth, scale, data shape.
Vague terms — undefined nouns the criteria will depend on.

Asking (RFC-2119)

Ask ≤5 questions total, the highest-impact first, one at a time.
Every question MUST carry a recommended answer (your best inference, marked "(recommended)") so the user can confirm with a word. Use the harness's question UI when available.
You MUST NOT ask what the intake already answers, or what a sensible default settles — make the call, note the assumption, and move on (only escalate when guessing is costlier than asking).
After each answer, fold it back into the intake/spec text immediately; don't batch.

Done

Record the resolved decisions in the intake doc (and, if the project wants it auditable, as a journaled note). Then hand to dev-spec-kit-spec-author. A clarification you didn't write down didn't happen.

このリポジトリの他の Skills

同じリポジトリ

dev-spec-kit-graph

Pratiyush/dev-spec-kit

Build, refresh, and read dev-spec-kit's Verified Traceability Graph — provider-agnostic. Keep it fresh with the build wrapper, read blast radius / implements-edges / drift to answer "what breaks if this changes?", and run the staleness re-prove dance. For choosing and configuring the code-graph engine itself, see the dev-spec-kit-revitify and dev-spec-kit-graphify skills.

2026-06-200

dev-spec-kit-graphify

Pratiyush/dev-spec-kit

dev-spec-kit's optional code-graph provider — the external Python graphify tool (multi-modal: indexes PDFs, images, and video alongside code). Opt-in only. Use to decide when graphify is worth its install over the bundled revitify default, how to install and configure it, and how dev-spec-kit verifies and falls back when it is absent. For the build/read loop itself, see dev-spec-kit-graph.

2026-06-200

dev-spec-kit-revitify

Pratiyush/dev-spec-kit

dev-spec-kit's default code-graph provider — the bundled revitify engine (native TypeScript, tree-sitter multi-language). Zero install, zero API key, always available. Use to understand when revitify is the right provider, how it is configured, what it can and cannot index, and how it feeds the Verified Traceability Graph. For the build/read loop itself, see dev-spec-kit-graph.

2026-06-200

dev-spec-kit-workflow

Pratiyush/dev-spec-kit

Drive spec-driven development with dev-spec-kit — route the request, write EARS specs with @check bindings, derive evidence-bound tasks, TDD, prove checks with real test runs, build the Verified Traceability Graph, record approvals, and generate graph-derived PR bodies. Use whenever the user asks to build/change code in a dev-spec-kit-initialized project (.dev-spec-kit/ present) or mentions rivet, specs, EARS, or traceability.

2026-06-200

dev-spec-kit-analyze

Pratiyush/dev-spec-kit

Score each requirement's complexity 1–10 and recommend a subtask breakdown, then expand the over-scoped ones into bound sub-criteria. Use after a spec is drafted and before implementation, to catch requirements that are too big to prove as a single unit.

2026-06-190

dev-spec-kit-architect

Pratiyush/dev-spec-kit

Turn approved requirements into a thin high-level design and the Architecture Decision Records (ADRs) that justify the non-obvious choices. Use after requirements are clarified and before implementation, or when a change makes a load-bearing architectural decision.

2026-06-190

name	dev-spec-kit-clarify
description	Resolve ambiguity in a raw intake or draft spec by asking the user ≤5 high-value questions, each with a recommended default. Use before finalizing a full-spec route, or when `spec.onVague` is "clarify", or whenever a requirement is under-specified.

dev-spec-kit clarify — ≤5 questions, recommended-option, one at a time

Detection passes (run all six over the intake/spec)

Ambiguity — terms with more than one reading ("fast", "secure", "soon").
Missing edge cases — unstated behavior on invalid input, empty/boundary, failure.
Contradictions — two requirements that can't both hold.
Under-specified acceptance — "works" with no observable outcome.
Hidden assumptions — implied infra, auth, scale, data shape.
Vague terms — undefined nouns the criteria will depend on.

Asking (RFC-2119)

Ask ≤5 questions total, the highest-impact first, one at a time.
Every question MUST carry a recommended answer (your best inference, marked "(recommended)") so the user can confirm with a word. Use the harness's question UI when available.
You MUST NOT ask what the intake already answers, or what a sensible default settles — make the call, note the assumption, and move on (only escalate when guessing is costlier than asking).
After each answer, fold it back into the intake/spec text immediately; don't batch.

Done

Record the resolved decisions in the intake doc (and, if the project wants it auditable, as a journaled note). Then hand to dev-spec-kit-spec-author. A clarification you didn't write down didn't happen.