菜单
Use this skill when the user reports a typo in their codebase or documentation and asks for it to be fixed across the project, or when reviewing code and noticing a misspelled identifier, comment, or string that should be corrected consistently across all occurrences.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use this skill when you have just completed a non-trivial task (more than 3 tool calls, novel approach, recovery from a dead end) and are considering whether to save the procedure as a reusable skill via compounded; OR in RULE MODE when the user corrected your approach and the correction encodes a generalizable behavioral rule. Also use when the user explicitly asks you to "save this as a skill", "remember how to do this", or similar.
Use this skill ONLY when invoked as the skill-verifier subagent by compounded's Stop hook. This is the rubric for deciding whether a proposed skill should graduate to .verified or move to .rejected/ based on its replayability against a just-completed task. Do not invoke this skill in normal sessions.
Use this skill when working with skills already at .verified, .trusted, or .autonomous trust levels — particularly when deciding whether to invoke a verified skill on a task, when applying a trusted skill (which requires confirmation), or when an autonomous skill auto-applies. Also use when a skill produces output the user corrects, since corrections trigger demotions.
Use this skill at the start of any session where compounded is installed, or whenever the user mentions earning trust, verifying skills, the trust ladder, compounded, the trust gradient, autonomous skills, or asks how compounded works. Explains the four trust states (.proposed, .verified, .trusted, .autonomous) and when each applies.
| name | compounded-typo-fixer |
| description | Use this skill when the user reports a typo in their codebase or documentation and asks for it to be fixed across the project, or when reviewing code and noticing a misspelled identifier, comment, or string that should be corrected consistently across all occurrences. |
A demo skill that ships with compounded to show the full lifecycle. Starts as .verified (we shipped it pre-verified to make the demo work). After 3 successful uses without correction, it auto-promotes to .trusted. After 10 uses with zero corrections in the last 5, it goes .autonomous.
<wrong>: the misspelled token (case-sensitive by default)<right>: the correct token<scope> (optional): a directory to limit the search to. Default: the project root.Confirm with the user: "Replacing <wrong> with <right>" — show this before searching.
Run a recursive search for the wrong spelling:
grep -rn "<wrong>" <scope> --include="*.{ts,tsx,js,jsx,py,go,rs,md,txt}" 2>/dev/null
Adjust the --include glob to match the project's primary languages.
Review the matches. For each one, decide if it is a true positive (a real instance of the typo) or a false positive (a substring that incidentally contains the typo, or a deliberate use like in a test fixture).
If any false positives exist, list them to the user and ask which to skip.
Apply the replacements via the Edit tool, one file at a time. Do NOT use sed -i for this — it is too easy to corrupt files when the replacement is not what was expected.
After all edits, re-run the grep to verify no instances of <wrong> remain in the affected files.
Run the project's test suite if one exists, to verify nothing broke. Common commands: npm test, pytest, cargo test, go test ./....
Substring false positives. recieve is a typo. recieve_count containing recieve is also a typo and should be fixed. But received (correct) contains recei, and a careless replacement of recei → recie would corrupt it. Always match whole tokens when possible.
Case sensitivity. Recieve, recieve, and RECIEVE may all need fixing, but the replacements differ. Either run three passes or use a case-aware tool. Do not lowercase identifiers blindly.
Test fixtures with intentional typos. Some test files deliberately contain misspellings (e.g., a parser test for typo tolerance). Skip those files unless the user confirms.
Locked or generated files. package-lock.json, Cargo.lock, *.generated.ts, and similar files should not be hand-edited. Skip them; they will regenerate.
After all replacements:
grep -rn "<wrong>" <scope> --include="<langs>" returns no matches in non-skipped filesIf any of these fail, report the failure honestly. compounded will count this as a correction event and demote the skill if appropriate.