菜单
Use when ready to build a reviewable implementation plan as a lore artifact. Input can be a spec, design, brainstorm, research, or a well-defined prompt. Triggers include "prep plan", "prepare a plan", "plan this", "make a plan", "plan the implementation", and "break this into steps".
用 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 | prep-plan |
| description | Use when ready to build a reviewable implementation plan as a lore artifact. Input can be a spec, design, brainstorm, research, or a well-defined prompt. Triggers include "prep plan", "prepare a plan", "plan this", "make a plan", "plan the implementation", and "break this into steps". |
Build an implementation plan the user can review and approve before any code is written. The plan is the output. Implementation is a separate step via /implement.
Do not use EnterPlanMode. This skill authors a document, not a precursor to immediate code changes.
Gather context. Invoke the lore-researcher agent via Task tool with the topic description — wait for the result. Read any relevant lore artifacts (spec, design, brainstorm, research). Explore the codebase with an Explore subagent to understand what exists and where changes will land.
Surface gaps before drafting. If the input has ambiguous requirements, contradictions, or unstated assumptions that would force guesses, list them and ask the user to resolve them first. A plan built on unreviewed assumptions fails during implementation.
Draft collaboratively. Map the goal or requirements to concrete implementation steps. Order by dependency. Flag steps that need specialized expertise. Include a final validation step that checks the implementation against the source artifact.
Save. The saved file is the review vehicle — don't present the plan in chat before saving.
Fresh-eyes review. After saving, invoke the plan-reviewer agent via Task tool on the saved plan. Present findings and offer to address issues before implementation begins.
Save to .lore/work/plans/[feature-name].md using kebab-case. Load ${CLAUDE_PLUGIN_ROOT}/shared/frontmatter-schema.md for the frontmatter fields. The document body is freeform — what matters is that steps are concrete (files, functions, changes) and the source artifact or goal is clearly referenced so validation has something to check against.
Write the body Markdown-first per the "Body Format" section of ${CLAUDE_PLUGIN_ROOT}/shared/frontmatter-schema.md. Reach for embedded inline HTML when the step flow needs it — a visual step sequence with dependency indicators, and validation gates distinguished visually from the step description.
