Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/Linfee/spec-kit-cnWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/commands/linfee/spec-kit-cn/analyze)<a href="https://agentmods.dev/commands/linfee/spec-kit-cn/analyze"><img src="https://agentmods.dev/badge/commands/linfee/spec-kit-cn/analyze/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/commands/linfee/spec-kit-cn/analyze"><img src="https://agentmods.dev/badge/commands/linfee/spec-kit-cn/analyze.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00030 | $0.02004 |
| Opus 5.5 | $0.00012 | $0.00802 |
| Sonnet 5.5 | $0.00006 | $0.00401 |
| Haiku 4.5 | $0.00003 | $0.00200 |
Grade A, and why
analyze scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 188 lines — stays where its author put it; the contents beside it link to each section on GitHub.
用户输入
$ARGUMENTS
在继续之前, 你必须考虑用户输入(如果不为空).
目标
在实施之前, 识别三个核心制品(spec.md, plan.md, tasks.md)之间的不一致, 重复, 模糊和规范不足的项目. 此命令必须在 /speckit.tasks 成功生成完整的 tasks.md 后运行.
操作约束
严格只读: 不要修改任何文件. 输出结构化分析报告. 提供可选的修复计划(用户必须明确批准后才能手动调用任何后续编辑命令).
章程权威: 项目章程(/memory/constitution.md)在此分析范围内是不可协商的. 章程冲突自动为严重问题, 需要调整规范, 计划或任务——而不是稀释, 重新解释或默默忽略原则. 如果原则本身需要更改, 那必须在 /speckit.analyze 之外的单独, 明确的章程更新中进行.
执行步骤
1. 初始化分析上下文
从仓库根目录运行一次 {SCRIPT} 并解析 JSON 以获取 FEATURE_DIR 和 AVAILABLE_DOCS. 推导绝对路径:
- SPEC = FEATURE_DIR/spec.md
- PLAN = FEATURE_DIR/plan.md
- TASKS = FEATURE_DIR/tasks.md
如果任何必需文件缺失, 则以错误消息中止(指示用户运行缺失的先决条件命令). 对于参数中的单引号, 如 "I'm Groot", 使用转义语法: 例如 'I'''m Groot'(或尽可能使用双引号: "I'm Groot").
2. 加载制品(渐进式展示)
仅从每个制品加载最小必需的上下文:
从 spec.md:
- 概述/上下文
- 功能需求
- 成功标准(可衡量的结果——例如, 性能, 安全性, 可用性, 用户成功率, 业务影响)
- 用户故事
- 边缘情况(如果存在)
从 plan.md:
- 架构/技术栈选择
- 数据模型引用
- 阶段
- 技术约束
从 tasks.md:
- 任务 ID
- 描述
- 阶段分组
- 并行标记 [P]
- 引用的文件路径
从章程:
- 加载
/memory/constitution.md进行原则验证
3. 构建语义模型
创建内部表示(输出中不包含原始制品):
- 需求清单: 为每个功能需求(FR-###)和成功标准(SC-###)记录一个稳定键. 当存在显式 FR-/SC- 标识符时, 使用该标识符作为主键, 并可选择推导一个祈使短语 slug 以提高可读性(例如, "User can upload file" →
user-can-upload-file). 仅包含需要构建工作的成功标准项(例如, 负载测试基础设施, 安全审计工具), 排除发布后的结果指标和业务 KPI(例如, "将支持工单减少 50%"). - 用户故事/操作清单: 带有验收标准的离散用户操作
- 任务覆盖映射: 将每个任务映射到一个或多个需求或故事(通过关键词/显式引用模式推断, 如 ID 或关键短语)
- 章程规则集: 提取原则名称和 MUST/SHOULD 规范性声明
4. 检测过程(高效令牌分析)
专注于高信号发现. 限制总共 50 个发现; 在溢出摘要中聚合其余部分.
A. 重复检测
- 识别近似重复的需求
- 标记较低质量的表述以进行合并
B. 模糊性检测
- 标记缺乏可测量标准的模糊形容词(快速, 可扩展, 安全, 直观, 稳健)
- 标记未解决的占位符(TODO, TKTK, ???,
<placeholder>等)
C. 规范不足
- 有动词但缺少对象或可测量结果的需求
- 缺少验收标准对齐的用户故事
- 引用规范/计划中未定义的文件或组件的任务
D. 章程对齐
- 与 MUST 原则冲突的任何需求或计划元素
- 章程中缺失的强制部分或质量门控
E. 覆盖缺口
- 没有关联任务的需求
- 没有映射需求/故事的任务
- 需要构建工作的成功标准(性能, 安全性, 可用性)未在任务中反映
F. 不一致性
- 术语漂移(相同概念在不同文件中命名不同)
- 计划中引用但在规范中缺失的数据实体(反之亦然)
- 任务排序矛盾(例如, 集成任务在基础设置任务之前而没有依赖说明)
- 冲突需求(例如, 一个要求 Next.js 而另一个指定 Vue)
5. 严重性分配
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 188 lines · 30 tokens per session scan A b312ffb02864
analyze is a command published in the GitHub repository Linfee/spec-kit-cn (708 stars, last pushed 2mo ago), licensed MIT. It adds 30 tokens to every session and 2,004 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other commands, from other repositories
review-branch
Review the current branch's diff against base by dispatching atomic-reviewer. No orchestration loop, no spec required — pre-flight before /commit pr or /commit merge.
refactor
Systematic code refactoring with smart scope detection.
init
Install the formatters this repository needs, with every command visible before it runs.
spec-trace-requirements
You are verifying that implementation changes trace back to specification requirements.
merge-conflict-analysis
You are analyzing merge conflicts for PR #${{ pr-number }}.
boot
Start a new PromptKit prompt assembly session (alias for /bootstrap).