菜单
Use when ready to build from a spec, design, or plan, or to resume from notes. Triggers include "implement this", "build this", "implement the spec/design/plan", "continue implementation", and "resume where we left off".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when checking whether field-guide reference pages still match current code and tests. Reads pages plus fg-evidence anchors, reports or fixes semantic drift, and can use sub-agents for parallel audit batches. Triggers include "resolve drift", "semantic drift", "check accuracy", "verify the reference against code", and "audit the wiki".
Use after ingesting or editing field-guide pages to attach living code/test anchors. Adds or refreshes fg-evidence metadata without trying to prove prose accuracy. Triggers include "update evidence", "wire evidence", "add evidence anchors", and "connect the wiki to code".
Use when extracting knowledge from .lore/ artifacts into the reference wiki. Converts work artifacts (retros, specs, plans, research, notes) into structured wiki pages grouped by knowledge type. Reads Markdown or HTML sources and writes Markdown by default. Triggers include "ingest this", "extract knowledge from", "add this to the wiki", "update the reference from", and "populate the field guide".
Use when setting up field-guide on a project for the first time, or to refresh the scheduled lint job after it expires. Triggers include "init field-guide", "set up field-guide", "refresh field-guide lint schedule", and "bootstrap the wiki".
This skill is used when the project wiki needs a health check. Triggers include 'lint the wiki', 'check wiki health', 'run field-guide lint', 'are there stale wiki pages', 'find orphaned pages', 'check for contradictions in the wiki'.
Use when asking questions about the project wiki, querying accumulated knowledge, searching project decisions or lessons. Triggers include "query the wiki", "what does the wiki say about", "search project knowledge", and natural language questions directed at the field-guide wiki.
| name | implement |
| description | Use when ready to build from a spec, design, or plan, or to resume from notes. Triggers include "implement this", "build this", "implement the spec/design/plan", "continue implementation", and "resume where we left off". |
Act as orchestrator. Dispatch work to sub-agents via the Task tool and record what happens. Do not write code, run tests, or review code directly. Every implementation, testing, and review action goes through a Task tool invocation. No exceptions.
Invoked as /implement <path> where <path> is a lore artifact: spec, design, plan, or notes file. Read the input artifact and any lore documents it references. If the input is a notes file, resume from where it left off.
Implemented code plus a notes file at .lore/work/notes/<artifact-name>.md. Load ${CLAUDE_PLUGIN_ROOT}/shared/frontmatter-schema.md for the frontmatter fields before writing.
The notes file needs enough structure to be resumable: a progress tracker (phases with checkboxes) and a log (what happened, failures, decisions, discoveries). Update it after every phase, not just at session end.
Write the body in Markdown per the "Body Format" section of ${CLAUDE_PLUGIN_ROOT}/shared/frontmatter-schema.md. Reach for embedded inline HTML only when a visual carries meaning prose can't, such as a color-coded phase-status diagram readable at a glance mid-session.
Search for related prior work: invoke the lore-researcher agent via Task tool with the artifact description. Wait for the result before continuing.
Break the input into implementable phases. If the input is a plan, phases are its steps. If a spec or design, break into independently testable chunks.
Task file detection. When the input is a plan, check whether .lore/work/tasks/<plan-name>/ exists. If it does, read task files sorted by their sequence frontmatter field — these become the phases. Compare the plan's modification timestamp against the oldest task file. If the plan is newer, warn the user and offer three options: re-run /plan-breakdown, use existing tasks, or abort.
Select agents. Consult .lore/lore-agents.md if it exists. Match agents to three mandatory roles:
| Role | Registry Category | Fallback |
|---|---|---|
| Implementation | Implementation | general-purpose |
| Testing | Testing | general-purpose |
| Review | Code Quality | general-purpose |
For each phase:
a. Implement. Dispatch to an implementation agent via Task tool. Include: what to build, relevant file paths, context from prior phases or failures. One phase at a time — the agent does not see the full plan.
b. Test. Dispatch to a testing agent via Task tool. Include: which files changed, what behavior to verify, how to run the test suite. Expect back: pass/fail and notable findings only.
c. Review. Dispatch to a review agent via Task tool. Include: which files to review, relevant requirements from the source artifact. Expect back: non-conformances only.
d. Handle failures. Route test or review failures back to an implementation agent via Task tool for correction. Re-dispatch only the failing step, not the full cycle. After two consecutive failed attempts on the same issue, escalate to the user.
e. Record. Update the notes file: mark the phase complete, log anything worth preserving (failures, unexpected behavior, decisions not specified in the source).
When phases come from task files, update the task file's status meta to complete after the cycle passes. If the implementation agent reports work is already done (task file still says pending), surface this to the user before skipping.
After all phases complete, dispatch a review agent with the full source artifact. Directive: validate the implementation against the source, flag requirements not met or behavior that diverges. This is a holistic check, not a code quality review.
Route any findings back through the implement/test/review cycle.
Update the notes file status to complete. Summarize: what was built, how many phases, any divergences.
Suggest: Run /simplify on the changed files to clean up for clarity.
Two conditions require human intervention. Everything else is autonomous.
Do not ask for confirmation between phases.
If reality requires something the source artifact didn't account for, do not proceed. Escalate to the user with the specific divergence and why it's needed. Record approved divergences in the notes file.
