agentsclimarketplace

Where claude

Skill ada-ggf25/AI-Tools/global/claude/skills/where-claude

A cross-device synced catalog for Claude and Codex skills, agents, and workflows.

Install
npx -y skills add ada-ggf25/AI-Tools --skill where-claude

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Scan the current repository and recommend which directories deserve their own nested CLAUDE.md file (i.e. where to run /init), as a ranked report with a one-line rationale per directory. Global and project-agnostic. Does NOT generate the files - it tells you where /init is worth running. Trigger when the user says "where should I run /init", "which directories need a CLAUDE.md", "where-claude", "scout claude.md placement", or "find nested CLAUDE.md candidates".

SKILL.md

5.0 KB, as published. Nobody here has run it

Where to run /init (nested CLAUDE.md placement scout)

Project-agnostic, global skill. It scans the current repo and reports the directories that would most benefit from their own nested CLAUDE.md, ranked, each with a one-line reason. It does not create the files - it removes the guesswork of deciding where /init is worth running.

It pairs with /init: /init writes a CLAUDE.md for a directory; this skill decides which directories are worth that cost.

Why nesting matters (the model that drives every decision)

Claude Code auto-loads the CLAUDE.md in the cwd and its parent directories, and pulls in a nested CLAUDE.md on demand only when work happens inside that subtree. So a nested file is cheap (loaded only when relevant) but only earns its keep when the subtree has local context a parent file does not already supply. Two failure modes to avoid:

  • Over-placement: a CLAUDE.md in every folder = duplicated/contradictory context and maintenance burden. Most directories should NOT get one.
  • Redundant placement: recommending a child when its parent already covers it.

Bias to restraint: a few high-value placements beat a long list.

Scoring heuristic (what makes a directory a candidate)

Score each directory on these signals; recommend only those that clearly clear the bar.

Positive signals (raise the score):

  • Module boundary - has its own manifest: package.json, pyproject.toml, setup.py, go.mod, Cargo.toml, *.csproj, pom.xml, build.gradle, etc.
  • Distinct stack / conventions - different language, framework, build tool, or test runner than the repo root (e.g. a frontend/ in TS under a Python root).
  • Local config - its own lint/format/test/CI config, codegen, or fixtures that imply rules specific to this subtree.
  • Size / depth - enough source files that context would otherwise be re-derived on each visit (rough floor: ~15+ source files, or a clearly self-contained component).
  • Architectural seam - a top-level services/<x>, packages/<x>, apps/<x>, cmd/<x> in a monorepo; a bounded domain module.

Negative signals (disqualify or skip):

  • Generated / vendored / dependency dirs: node_modules, dist, build, out, vendor, .venv, target, __pycache__, .next, coverage, anything git-ignored.
  • Tiny leaf dirs, asset-only dirs, or dirs already fully covered by a parent CLAUDE.md.
  • The repo root itself if it has no CLAUDE.md - note that as a prerequisite, but the root is /init's normal job, not a "nested" recommendation.

Procedure

1. Orient

  • Find existing CLAUDE.md files (find . -name CLAUDE.md -not -path '*/node_modules/*') so you never recommend one that already exists or is covered by a parent.
  • Read the root CLAUDE.md/README* to learn what the root file already documents - a subtree only needs its own file for what the root does NOT cover.
  • Map the directory tree (respecting .gitignore) and locate manifests/config files that mark module boundaries.

2. Score

  • Apply the heuristic above to each candidate directory.
  • Collapse redundancy: if a parent and child both qualify, prefer the parent unless the child has genuinely distinct local context (then both, noting the relationship).
  • For a large or unfamiliar repo, delegate the directory sweep to the Explore agent and score from its summary, to keep context clean.

3. Report (do NOT create files)

Present a SHORT ranked list - the highest-value placements first. For each:

  • the directory path;
  • a one-line rationale (which signals fired);
  • a copy-pasteable command, e.g. cd <dir> && claude then /init, or just note the /init target. Then a "Skipped / not worth it" section naming notable directories you deliberately left out and why (generated, covered by parent, too small). If the root lacks a CLAUDE.md, flag that first as the prerequisite.

4. Hand off

  • Let the user pick which directories to act on; /init must be run per-directory by the user (it documents the cwd it runs in). Do not auto-run /init or write any CLAUDE.md yourself.

Guardrails

  • Report only; never create, edit, or auto-/init any CLAUDE.md.
  • Never recommend a directory already covered by an existing or parent CLAUDE.md.
  • Respect .gitignore and always exclude generated/vendored/dependency directories.
  • Keep recommendations few and honest; push borderline dirs into "Skipped" rather than padding the list.
  • Never fabricate repo facts - base every rationale on files you actually observed.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.