メニュー
Use when the user asks to "update README", "sync README", "check README", "is README up to date", "are docs consistent", "does README match the code", or any request to verify or update README.md to match the current state of the codebase.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Build an interactive "codesign" decision page as one self-contained HTML file: the reader toggles choices (pick-one or pick-any), adds notes, and exports the decision as Markdown and JSON with stable IDs (sec-01, ch-01-a) so picks can be quoted in chat — "keep ch-01-a, swap ch-02-b" yields a diffable v2. Use when the user wants to choose between options and capture the decision: design directions, plan A vs B, prioritization, async option pages for a stakeholder. Triggers: codesign, co-design, decision page, pick from these, which should we, compare the options, prioritize these. ALWAYS confirms before generating — lists the UNANSWERED questions found in recent context, each with its ID and a recommendation, then waits for a yes; the gate fires even on explicit invocation with an argument. Answered questions are out of scope; if context is mostly settled material it offers html-explain instead. Styled by use-html-theme. NOT for signing macOS/iOS binaries (Apple's codesign).
Build a read-only "explainer" page as one self-contained HTML file — a rich explanation of settled material, where diagrams, annotated figures, charts, and small interactive widgets do work prose cannot. Authoring maps which parts are intrinsically hardest, budgets the page around them, then enriches ONLY where comprehension actually breaks. Use when an explanation should be a shareable PAGE not inline chat: "explain the design we just landed", "write up what the tests showed", "make an explainer for this spec", "deep dive on X as a page", explainer, walkthrough page, "explain this visually". Reads recent context and ALWAYS confirms the target before generating, even on explicit invocation with an argument. If context is mostly UNANSWERED questions it offers html-codesign instead (that answers questions; this explains — including a deep dive on one already resolved). Inline chat explanations are the `explain` skill; charts defer to dataviz when present. Pairs with use-html-theme.
Explain anything in a concrete-anchored style — succinct, just-enough context, always grounded in a real example. Use when the user invokes /explain, or asks in their own words: "explain X", "give me a before and after", "add more context on <finding/step/option>", "show examples of the options so I can decide", "what does this change get us", "what's the bigger picture here", "give me step by step instructions". A bare "explain" right after an explanation means "not enough to act on yet": diagnose the gap (bigger picture, clearer language, or a sharper example) and usually rewrite, not append; an argument steers the focus; a dissimilar target restarts fresh. Modes (inferred from the target; explicit argument wins): default, options (example per option + recommendation), deeper, steps (operator instructions). Not for manual testing steps (manual-test-guide) or whole-session recaps.
Whenever the user asks Claude to generate or restyle HTML — a page, artifact, mockup, dashboard, doc, status page, landing page, release-notes page, HTML email, or styled snippet — offer a small catalog of visual themes and apply the chosen one to all subsequent HTML in the session. v1 catalog: birchline (warm editorial), technical-minimal (docs-site neutral), high-contrast-dark (dashboard/terminal). Each theme is a self-contained folder of tokens, components, anti-patterns, and a worked example; only the chosen theme's files are read (progressive disclosure). The choice persists in session memory and can be saved per-project to `.claude/use-html-theme.local.md`. Overrides via natural language and `[theme: <name>]` / `[notheme]` inline flags; ask to preview or compare the themes to get a side-by-side catalog page. Do NOT activate for markdown, JSON, prose, or non-HTML code, or when the user said `[notheme]` or asked for no theme.
Walk a pile of open questions or undecided to-dos one at a time via the AskUserQuestion tool — smartest question first, just-enough context per item, and after EVERY answer re-evaluate the remaining pile (drop what became moot, reorder what changed, surface implied follow-ups). Sources it handles — mine open questions from the current conversation, read them from a document the user points at (PRD, design doc, notes), take a list given inline, or pull undecided items from task systems (tasks, PROJECTS.md). Decisions are recorded back at their source. Use when the user says "go through these one by one", "walk me through the open questions", "there's a bunch of to-dos, help me decide", "triage these decisions with me", or a doc/plan is blocked on several unanswered questions. Not for scoping a project idea (project-refine), not for batch shareable decision pages (html-codesign — offer it if they'd rather review async), and context style defers to the explain skill's anatomy.
Resolve a repo name to its local path(s) and identity facts — origin, default branch, checkout-vs-worktree kind, branch, dirty state, build tooling — with one fast config-bounded command instead of exploring the filesystem. Fire whenever a repo is referenced by bare name and its location isn't already established in this session — BEFORE running ls/find/glob over home or code directories to locate a repo, BEFORE gh repo view/list to identify an origin or enumerate org repos, and for "where is <repo>", "what repos do I have", "which org owns X", "is this a worktree", "what's the exact name to clone". Covers local multi-root scan plus a gh REST-first remote org fallback from user config. Not for searching file contents inside an already-located repo, and not for cloning or mutating anything — it only finds and describes.
| name | readme-sync |
| description | Use when the user asks to "update README", "sync README", "check README", "is README up to date", "are docs consistent", "does README match the code", or any request to verify or update README.md to match the current state of the codebase. |
Audit README.md for consistency with the actual codebase and suggest (or apply) updates.
--check — only report issues, don't apply fixes (default)--fix — apply fixes to README.md--since <commit> — only check changes since a specific commitls README.md 2>/dev/nullgit log --oneline -10ls pyproject.toml Cargo.toml package.json 2>/dev/nullls justfile Makefile 2>/dev/nullRead the full README.md; read recent git log to understand what changed
(git log --oneline -20). If --since is specified, scope to
git diff <commit>..HEAD --name-only.
Install instructions — package name matches manifest; install commands work
(pip install, uv add, npm install); dependency requirements match.
CLI commands & usage examples — documented commands exist in project scripts; flags/options match the implementation; run documented non-destructive examples to verify.
API/code examples — imported names exist in the package's public API (__init__.py,
__all__); documented signatures match reality; example code would run.
Project structure — documented directories/files exist; flag removed/renamed files.
Links & references — internal links (to other .md files) are valid; referenced paths exist.
Task runner recipes — referenced just/make commands exist; flag important new recipes
that aren't documented.
## README Sync Report
### Inconsistencies Found
1. **<category>**: <description>
- README says: `<quoted text>`
- Actual: `<what's true now>`
- Fix: <suggested change>
### Missing Documentation
- <new feature/command not mentioned in README>
### Outdated Sections
- <section referencing removed/changed functionality>
### README is Current
- ✅ <section that is accurate>
--fix)Apply the suggested changes to README.md.