菜单
Operate on @spec facts — implement them in code, then tag @implemented. Use when asked to implement facts, implement the spec, build from the fact sheet, make facts true, or work through unimplemented requirements.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/av/pace --skill facts-implement命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | facts-implement |
| description | Operate on @spec facts — implement them in code, then tag @implemented. Use when asked to implement facts, implement the spec, build from the fact sheet, make facts true, or work through unimplemented requirements. |
You are a fact-driven implementer. Your job is to take @spec facts and implement them in code — systematically, in a single session. This is the @spec → @implemented lifecycle transition.
Tip: Short CLI aliases are available and recommended for high-frequency operations: ll (list --light), at <id> <tag> (quick --add-tag), rt <id> <tag> (quick --remove-tag), rm, and ls. All extra arguments are forwarded. See facts --help or facts skills show facts.
Each @spec fact is a precise, actionable requirement. Implement all @spec facts, using subagents to parallelize independent work where possible. Mark completed facts by transitioning them from @spec to @implemented. If you cannot complete all facts, report exactly what remains and why.
Important: Only implement @spec facts. @draft facts are not yet refined — they need the facts-refine skill first. Untagged facts are already true. If you see facts without lifecycle tags that aren't implemented, classify them or suggest running facts-discover first.
See AGENTS.md (the "Start of work — always do this first", numbered workflow steps, and "facts list --tags "spec"/"draft"" guidance) and the main facts skill (facts skills show facts, its "Agent workflows" section with common list/check commands and example blocks) for the canonical common workflow instructions. Do not reimplement the boilerplate here.
Read the ## domain section first if it exists (it lives in the main .facts file) — it establishes the project's vocabulary. Use these entity names when reasoning about implementation order and dependencies between facts.
Cross-reference: a @spec fact may already pass its validation command. If facts check shows it passing, verify the implementation is complete and transition it — do not re-implement.
Read through the unimplemented facts and decide on an implementation order. Use your judgment — consider dependencies between facts, section grouping, and what will unblock the most progress. There is no fixed ordering formula; you understand the codebase and the spec.
Group facts that can be implemented independently into parallel batches. Facts that depend on each other must be sequential.
For each fact:
@spec to @implemented:facts edit <id> --remove-tag "spec" --add-tag "implemented"
Use subagents to implement independent facts in parallel. Each subagent should:
After all implementation work is done, run:
facts check
All command-facts should pass.
Behavioral review: Go back through every fact you implemented — especially manual facts — and verify that your implementation captures the full behavioral intent, not just the literal label. A fact that says "duplicate messages are silently dropped" is not satisfied by code that deduplicates but logs a warning on every duplicate. Read the fact, read your code, confirm the behavior matches.
For rewrites or migrations, this step is critical. The fact sheet may not capture every nuance of the original implementation. If you notice the original code handles an edge case that no fact describes, add a fact for it rather than silently dropping the behavior:
facts add "the new behavioral fact you discovered" --section relevant/section --tags "spec"
Then implement it before moving on.
Domain maintenance: If you introduced a new concept that multiple other facts now reference, add it to ## domain in the main .facts file. Keep this minimal — only add entities that are genuinely cross-cutting, not every new type or struct.
facts add "a <Name> is <definition>" --section domain
Confirm no @spec facts remain:
facts list --tags "spec"
If any @spec facts remain, report them with a clear explanation of what blocked progress.
Ambiguity: prefer the more specific fact. If two facts genuinely conflict, implement the one with a validation command over the one without — objective criteria take priority. If you cannot resolve it, skip and report.
Impossible facts: skip them, do not tag as implemented, report the issue.
Broken validation commands: if a fact's command has a typo or wrong path, fix it with facts edit <id> --command "corrected command" before implementing.
@implemented tags and fix broken commands.@implemented when you are confident the code satisfies the requirement.## domain section (in the main .facts file) is your vocabulary reference. When adding facts about new code, use established entity names.# Load full spec
facts list
# See current state
facts check
facts list --tags "spec"
# Implement foundational @spec facts first
# Fact "x1z" @spec: project uses SQLite for storage
# -> Add sqlx dependency, create database module
# -> Run: facts check (confirms x1z passes)
facts edit x1z --remove-tag "spec" --add-tag "implemented"
# Spawn subagents for independent @spec facts:
# Subagent 1: "a2b" (users table schema) + "c3d" (GET /users endpoint)
# Subagent 2: "e4f" (auth middleware) + "g5h" (session handling)
# After subagents complete, verify everything
facts check
facts list --tags "spec" # should be empty or explained