菜单
Use when the user asks "how to manually test", "what are manual testing steps", "what commands to test", "how to test the latest features", "what to test", "what are the testing commands", or any request for manual testing instructions and validation steps for a project.
用 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 | manual-test-guide |
| description | Use when the user asks "how to manually test", "what are manual testing steps", "what commands to test", "how to test the latest features", "what to test", "what are the testing commands", or any request for manual testing instructions and validation steps for a project. |
Generate a practical, copy-pasteable manual testing guide for the project.
--recent — focus only on features changed in recent commits--full — comprehensive test guide for the entire projectls pyproject.toml Cargo.toml package.json go.mod 2>/dev/nullls justfile Makefile 2>/dev/nullgit log --oneline -5ls -d examples/ 2>/dev/nullgrep -A2 '\[project.scripts\]' pyproject.toml or grep '"bin"' package.jsonScan for all runnable things:
[project.scripts] (pyproject), bin (package.json), [[bin]] (Cargo.toml)examples/If --recent or no specific scope: git diff HEAD~5 --name-only to find recently changed
files; map them to features/components; prioritize testing those areas.
## Manual Testing Guide
### Prerequisites
- [ ] `<install command>` — Install dependencies
- [ ] `<build command>` — Build the project
### Smoke Tests (run these first)
1. `<command>` — Expected: <what should happen>
### Feature Tests
#### <Feature Area>
1. `<command>` — Expected: <behavior>
### Recent Changes (needs extra attention)
- <file changed> → test with: `<command>`
### Examples
1. `<example command>` — Demonstrates: <what>
just <recipe> / make <target> over raw commands when available.examples/ exist, include the most representative ones.