analyze

A read-only review of a feature specification, implementation plan, and task list. It checks whether these planning documents agree and meet the project's rules.

In plain words
What is it for?
Reviewing spec.md, plan.md, and tasks.md after the task list has been generated, then producing a structured analysis report.
Why use it?
It finds missing details, repeated work, unclear requirements, and conflicts before coding begins.

Command

Install

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.

agentmods
npx agentmods add commands/linfee/spec-kit-cn/analyze
Clone the repo
git clone --depth 1 https://github.com/Linfee/spec-kit-cn
Per session 30 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 2,004 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00030 $0.02004
Opus 5 $0.00015 $0.01002
Sonnet 5 $0.00006 $0.00401
Haiku 4.5 $0.00003 $0.00200

Measured 3d ago against content hash b312ffb02864, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

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 3d 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.

templates/commands/analyze.md · 188 lines

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. 严重性分配

Read the full file on GitHub · 188 lines

Changes

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.

  1. 3d ago First seen · 188 lines · 30 tokens per session scan A b312ffb02864

Subscribe to this mod's changes

analyze is a command published in the GitHub repository Linfee/spec-kit-cn (695 stars, last pushed 1mo ago), licensed MIT. It adds 30 tokens to every session and 2,004 once invoked, about $0.0002 per session on Opus 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.