checklist

A command that creates a tailored checklist for reviewing whether written requirements are complete, clear, consistent, and ready to implement. It checks the specification itself, not the code.

In plain words
What is it for?
Use it to review requirements for areas such as visual design, accessibility, interactions, edge cases, and measurable details. It can ask focused questions based on the feature and documents in the repository.
Why use it?
It helps find vague, missing, or contradictory requirements before development begins. This is like unit testing a specification: checking its quality instead of testing software behavior.

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/checklist
Clone the repo
git clone --depth 1 https://github.com/Linfee/spec-kit-cn
Per session 14 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 4,225 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.00014 $0.04225
Opus 5 $0.00007 $0.02112
Sonnet 5 $0.00003 $0.00845
Haiku 4.5 $0.00001 $0.00422

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

Security

Grade A, and why

checklist 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 2d 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/checklist.md · 291 lines

How it starts

The opening of the file, as written. The whole thing — 291 lines — stays where its author put it; the contents beside it link to each section on GitHub.

清单目的: "需求编写的单元测试"

CRITICAL CONCEPT: 清单是需求编写的单元测试 - 它们验证特定领域中需求的质量, 清晰度和完整性.

不用于验证/测试:

  • ❌ 不是"验证按钮点击正确"
  • ❌ 不是"测试错误处理有效"
  • ❌ 不是"确认 API 返回 200"
  • ❌ 不是检查代码/实现是否符合规范

用于需求质量验证:

  • ✅ "是否为所有卡片类型定义了视觉层次需求? "(完整性)
  • ✅ "'突出显示'是否通过具体尺寸/位置进行了量化? "(清晰度)
  • ✅ "所有交互元素的悬停状态需求是否一致? "(一致性)
  • ✅ "是否为键盘导航定义了可访问性需求? "(覆盖度)
  • ✅ "规范是否定义了 logo 图像加载失败时的处理? "(边缘情况)

比喻: 如果你的规范是用英文编写的代码, 那么清单就是它的单元测试套件. 你测试的是需求是否编写良好, 完整, 明确并准备好实施 - 而不是实现是否有效.

用户输入

$ARGUMENTS

在继续之前, 你必须考虑用户输入(如果不为空).

执行步骤

  1. 设置: 从仓库根目录运行 {SCRIPT} 并解析JSON以获取FEATURE_DIR和AVAILABLE_DOCS列表.

    • 所有文件路径必须是绝对路径.
    • 对于参数中的单引号如"I'm Groot", 使用转义语法: 例如 'I'''m Groot'(或者尽可能使用双引号: "I'm Groot").
  2. 澄清意图(动态): 推导最多三个初始上下文澄清问题(无预编目录). 它们必须:

    • 从用户的表述 + 从规范/计划/任务中提取的信号生成
    • 只询问实质上改变清单内容的信息
    • 如果在$ARGUMENTS中已经明确, 则单独跳过
    • 优先考虑精确性而非广度

    Generation algorithm:

    1. Extract signals: feature domain keywords (e.g., auth, latency, UX, API), risk indicators ("critical", "must", "compliance"), stakeholder hints ("QA", "review", "security team"), and explicit deliverables ("a11y", "rollback", "contracts").
    2. Cluster signals into candidate focus areas (max 4) ranked by relevance.
    3. Identify probable audience & timing (author, reviewer, QA, release) if not explicit.
    4. Detect missing dimensions: scope breadth, depth/rigor, risk emphasis, exclusion boundaries, measurable acceptance criteria.
    5. Formulate questions chosen from these archetypes:
      • Scope refinement (e.g., "Should this include integration touchpoints with X and Y or stay limited to local module correctness?")
      • Risk prioritization (e.g., "Which of these potential risk areas should receive mandatory gating checks?")
      • Depth calibration (e.g., "Is this a lightweight pre-commit sanity list or a formal release gate?")
      • Audience framing (e.g., "Will this be used by the author only or peers during PR review?")
      • Boundary exclusion (e.g., "Should we explicitly exclude performance tuning items this round?")
      • Scenario class gap (e.g., "No recovery flows detected—are rollback / partial failure paths in scope?")

Read the full file on GitHub · 291 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. 2d ago First seen · 291 lines · 14 tokens per session scan A 24eb2d338ead

Subscribe to this mod's changes

checklist is a command published in the GitHub repository Linfee/spec-kit-cn (695 stars, last pushed 1mo ago), licensed MIT. It adds 14 tokens to every session and 4,225 once invoked, about $0.0001 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.