skills/dev-linkify-cc-resources/SKILL.md
Link Claude Code skill names mentioned in a CodeGrid article (data/{series}/{n}.md) to the author's public claude-resources repo, pinned to the latest commit hash so links don't rot. Use when: (1) user says 'linkify cc resources', 'link the skills', 'link skill names', or invokes /dev-linkify-cc-resources; (2) editing a CodeGrid article that mentions `/commits`, `/pr-complete`, `/skill-creator` or other Claude Code skills and they should point to claude-resources. Only links skills that actually exist in the public repo; skips hypothetical examples and code blocks.
npx skillsauth add takazudo/claude-resources dev-linkify-cc-resourcesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
CodeGrid articles in the AI-agents series mention Claude Code skills by name (/commits,
/pr-complete, …). This skill turns the first prose mention of each published skill
into a link to the author's public collection, claude-resources,
pinned to the latest commit hash.
Pinning to a hash (not main) is deliberate: the repo changes often, and a hash-based ref
keeps the article's link pointing at the version that existed at writing time. The repo is
introduced once in an earlier article (a [column] titled 「筆者のスキルコレクション」 in
9.md), so later articles just inline-link — no need to re-introduce the repo.
Use the article the user is editing (from conversation context) or the path they pass. It's a
file like data/{series-slug}/{n}.md in the CodeGrid articles repo.
python3 $HOME/.claude/skills/dev-linkify-cc-resources/scripts/scan.py <article.md>
The script resolves the claude-resources repo ($HOME/repos/*/claude-resources), fetches and
reads the latest origin/main hash, lists the published skills, and reports a LINK THESE
block: the first prose mention of each skill that exists in the repo, with the ready-to-paste
markdown. It already excludes mentions inside code blocks, mentions already linked, and names
that aren't real published skills.
Pass --repo <path> if the repo lives somewhere other than $HOME/repos/*/claude-resources.
For each entry in LINK THESE, wrap the inline-code skill name in the suggested link, leaving
the surrounding prose untouched:
…9回目の連載で紹介した`/commits`という…
→ …9回目の連載で紹介した[`/commits`](https://github.com/Takazudo/claude-resources/blob/<hash>/skills/commits/)という…
Edit the live article, not the scan output. After editing, the URL format is
https://github.com/Takazudo/claude-resources/blob/<hash>/skills/<name>/ — keep /blob/ and
the trailing slash (GitHub redirects directory /blob/ to /tree/).
The scan's repo membership check enforces the editorial rule automatically:
Linked: skills present in claude-resources/skills/, at their first prose mention.
Not linked: names that are hypothetical examples in the prose (e.g. /fix-typo,
/brighten-photo) or personal skills the author hasn't published (e.g. /price-research) —
these simply aren't in the repo, so the scan won't surface them.
Skipped: mentions inside fenced code blocks, and any skill already linked elsewhere in
the article (only the first prose mention is linked, for readability).
If the user disagrees with a specific call (e.g. wants a second mention linked too, or wants to skip re-linking a skill already linked in an earlier article), follow their preference — the scan is a starting point, not a hard rule.
development
Second opinion from Claude Opus on a plan or approach. Use when: (1) Planning phase of /big-plan needs a higher-quality review than /codex-2nd / /gco-2nd / /gcoc-2nd, (2) User says 'opus 2nd' or 'opus opinion', (3) Wanting Anthropic's larger model to critique a plan. Spawns a general-purpose Agent with model: opus that reads the plan file and returns structured feedback. Anthropic quota — not free.
tools
AI-based testing via subagent + a per-task test-flow skill. Use when the user wants to verify something that mechanical assertions can't fully capture — image recognition, visual size/position comparison, animation smoothness, multi-step manual flows that need AI judgment. Triggers: 'AI-based test', 'AI test', 'visual verify', 'image recognition test', 'manual operation test', 'human-eye check', 'verify visually', 'compare screenshots', 'looks the same', 'looks correct'. The skill's job is to (1) author a focused test-flow skill that captures the exact procedure + verdict criteria, then (2) dispatch a verification subagent via the Agent tool that loads BOTH the test-flow skill AND a browser-driving skill (/verify-ui primary, /headless-browser fallback) so the subagent has clear context and consistent verdicts. NEVER uses `claude -p` — subagent dispatch goes through the Agent tool exclusively.
development
End-of-workflow audit of touched GitHub issues, PRs, and branches via a Sonnet subagent. Use when: (1) /big-plan, /x-as-pr, or /x-wt-teams finishes its main work and needs to verify every touched resource is in the right state (closed when done, kept when ongoing, deleted when dead), (2) User says 'cleanup resources', 'audit cleanup', or 'check what should be closed', (3) A long workflow ends and the manager wants a structured paper trail of what it closed/kept/deleted. Auto-execute by default — the Sonnet agent proposes, the manager (you) executes safe actions and prints a final report.
tools
Solve a complex bug or design problem by building a tiny isolated prototype first, instead of patching the production system in place. Trigger PROACTIVELY when (1) the same bug has resisted 2+ in-place fix attempts (fail-retry loop), (2) the user mentions "minimal prototype", "from zero", "from scratch", "simple script", "sandbox", "standalone", "isolate", "play around", or "try a sandbox version", (3) you find yourself ranking a list of suspects and ruling them out via source-grep on a runtime/visual bug, (4) the user is brainstorming many design options for a UI surface and wants speed (e.g., "make 20 patterns of the top page"), (5) the next reasonable step would be "instrument the existing complex code" — pause and consider this skill instead. Build the prototype in the repo-scoped Dropbox-synced cclogs dir (`$DROPBOX_CCLOGS_DIR/<repo>/<descriptive-name>/`) so it survives switching between Mac and WSL; the exception is a prototype that must import the repo's production code or use its workspace/Vite tooling — keep that one in `__inbox/<descriptive-name>/` in the project root (in-repo, gitignored) so relative imports resolve. Match the project's tech stack (HTML+CSS+vanilla JS for static sites, Vite+React for React apps, Node script for CLI/utility logic). Don't commit it — its value is the learning, not the artifact. **Variant for repeated regression cycles (8+ in-place fixes on the same bug class):** keep the prototype as a committed sub-package named `packages/prototype-<topic>/` — see the "Variant: project-level reference prototype" section below.