spec-work
Use when implementing a feature against repository specs, finding requirements before coding, or turning a Git or Brain spec into an implementation plan and acceptance checks. Also handles /memhub:spec work. Do not use merely because an unrelated document is called a spec.
ソース情報
- リポジトリ
- XTraceAI/agent-plugins
- ソースの最終更新活動
- 2026年10月8日 05:52
- 検出された SKILL.md の言語
- 英語
- スター
- 2
- フォーク
- 0
インストール方法
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
ソースファイルを確認
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
SKILL.md を表示中
SKILL.md
ソースの指示 · 読み取り専用プレビュー- name
- spec-work
- description
- Use when implementing a feature against repository specs, finding requirements before coding, or turning a Git or Brain spec into an implementation plan and acceptance checks. Also handles /memhub:spec work. Do not use merely because an unrelated document is called a spec.
- argument-hint
- <feature|task|files>
# Work with specs
Read [shared context](../../references/spec-workflow.md). Resolve the configured
source and requested scope before planning changes.
1. Find governing requirements. For Git, read active ownership specs for the
proposed files and relevant feature specs for new files. For Brain, retrieve
relevant documents within the selected governing brain and read the sections
being relied on. Include cross-cutting requirements such as authorization
where they apply; don't load unrelated documents merely to fill the context.
2. Inspect the implementation and tests. Separate existing behavior, required
behavior, and proposals. A statement in code is evidence of implementation,
not proof the team intended it.
3. Give a concise work brief: source/document and revision, requirements that
constrain this task, files likely to change, acceptance checks, and unresolved
decisions. Cite the source section and relevant code. An uncovered new file
is a proposed ownership addition, not silently owned by a nearby spec.
4. If the task contradicts a governing requirement, identify the exact conflict.
Reuse an explicit user decision to change intended behavior; otherwise ask
which behavior should govern before implementing the conflicting part.
Continue independent work. Don't ask again about decisions already made.
5. Carry out the user's requested scope. A planning request produces a plan;
an implementation request proceeds with code and meaningful acceptance
checks. Keep necessary Git spec edits in the same change. In Brain mode,
prepare a revision proposal if requirements change; don't mark it published.
6. Follow [Check specs](../spec-check/SKILL.md) on the actual resulting diff.
Summarize implemented requirements, validation, proposed spec changes, and
remaining gaps. Do not set verification markers merely because tests pass.
If no relevant requirement is found, say what was searched and which code is
uncovered. Offer or perform `spec init` when it is within the user's requested
scope; never manufacture a governing requirement from an old audit summary.
GitHubで見る