What is speckit.checklist?

A requirements checklist generator that turns a feature request into questions about whether its written requirements are complete, clear, consistent, and precise.

Use it to review requirements for missing edge cases, measurable details, accessibility needs, and consistent behavior.

It catches gaps in a specification before coding begins. It checks the requirements themselves, not whether the finished code works.

How IsJunNa/OpenClawForJun configures Claude Code and Codex

Reuse

Borrowing it

Nothing to install: this file belongs to IsJunNa/OpenClawForJun. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.

Copy the file

curl -O https://raw.githubusercontent.com/IsJunNa/OpenClawForJun/main/.codex/prompts/speckit.checklist.md

Clone the repo

git clone --depth 1 https://github.com/IsJunNa/OpenClawForJun

Made for: Claude Code, Codex.

Wrote 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.

README.md

[![agentmods](https://agentmods.dev/badge/commands/isjunna/openclawforjun/speckit.checklist/github.svg)](https://agentmods.dev/commands/isjunna/openclawforjun/speckit.checklist)

Your own site

<a href="https://agentmods.dev/commands/isjunna/openclawforjun/speckit.checklist"><img src="https://agentmods.dev/badge/commands/isjunna/openclawforjun/speckit.checklist/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.

Your own site · 80×15

<a href="https://agentmods.dev/commands/isjunna/openclawforjun/speckit.checklist"><img src="https://agentmods.dev/badge/commands/isjunna/openclawforjun/speckit.checklist.svg" alt="Reviewed on agentmods" width="80" height="20"></a>

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,035 The whole file, excluding the scripts and references it only reads on demand.

Security scan A 0 findings. A grade says what 26 rules found in the file — not that it is safe.

Origin 83% copy Near-identical to another mod 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.

Model	Per session	Once invoked
Fable 5.1	$0.00014	$0.04035
Opus 5.5	$0.00006	$0.01614
Sonnet 5.5	$0.00003	$0.00807
Haiku 4.5	$0.00001	$0.00404

Measured 1mo ago against content hash a85b129dd551, method: parsed. Prices are Anthropic first-party input rates as of 2026-10-07, from the pricing page.

Security

Grade A, and why

speckit.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 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.

Origin

This is a copy

83% identical to checklist — 320 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.

.codex/prompts/speckit.checklist.md · 288 lines

How it starts

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

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

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

不用于验证/测试:

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

用于需求质量验证:

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

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

用户输入

$ARGUMENTS

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

执行步骤

设置: 从仓库根目录运行 .specify/scripts/bash/check-prerequisites.sh --json 并解析JSON以获取FEATURE_DIR和AVAILABLE_DOCS列表.
- 所有文件路径必须是绝对路径.
- 对于参数中的单引号如"I'm Groot", 使用转义语法: 例如 'I'''m Groot'(或者尽可能使用双引号: "I'm Groot").
澄清意图(动态): 推导最多三个初始上下文澄清问题(无预编目录). 它们必须:
- 从用户的表述 + 从规范/计划/任务中提取的信号生成
- 只询问实质上改变清单内容的信息
- 如果在$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 · 288 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.

1mo ago First seen · 288 lines · 14 tokens per session scan A a85b129dd551

Subscribe to this mod's changes

speckit.checklist is a command published in the GitHub repository IsJunNa/OpenClawForJun (77 stars, last pushed 8mo ago), licensed MIT. It adds 14 tokens to every session and 4,035 once invoked, about $0.0001 per session on Opus 5.5. A static security scan graded it A with 0 findings. It is 83% identical to checklist, differing in 320 lines, and is treated as a copy.

Planning

speckit.checklist next to 6 commands from other repositories
Mod	Type	Stars	Last push	Licence	Scan	Tokens	Works with
speckit.checklistIsJunNa/OpenClawForJun	Command	77	8mo ago	MIT	A	14	Claude Code, Codex
checklistgithub/spec-kit	Command	148k	yesterday	MIT	A	13	Claude Code
clarifygithub/spec-kit	Command	148k	yesterday	MIT	A	27	Claude Code
specifygithub/spec-kit	Command	148k	yesterday	MIT	A	13	Claude Code
analyzegithub/spec-kit	Command	148k	yesterday	MIT	A	26	Claude Code
convergegithub/spec-kit	Command	148k	yesterday	MIT	A	35	Claude Code
implementgithub/spec-kit	Command	148k	yesterday	MIT	A	14	Claude Code

OpenClawForJun: Command for Claude Code