菜单
Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Resolve ambiguous requests by investigating, choosing the best-supported reading, and stating the interpretation — instead of guessing silently or blocking on questions. Use whenever a request has multiple plausible readings or an unstated parameter (which file, which env, how thorough, what format).
Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.
When recommending between options, match the strength of the claim to the strength of the evidence — commit when evidence is clear, say it's a coin flip when it is. Use whenever the user asks "which should I use", "what's the best way", "A or B?", or you're proposing a design choice.
Async/concurrent/streaming discipline — five questions (overlapping runs, check-then-act, mutation across await, response ordering, cancellation), idempotent retries, shared-state audit, race amplification. Use for async fan-out, streams/SSE, jobs, caches, or flaky timing-smell bugs.
Externalize working state to files so long tasks survive context compaction and interruption. Use at the start of any task likely to exceed ~30 minutes or span many files, and again whenever a major phase completes or the plan changes.
Write scripts and file handling that survive the machine they didn't develop on — path separators, shell dialects, line endings, case-sensitivity, missing tools. Use when writing shell scripts, CI steps, path manipulation, file I/O, or install/setup instructions others will run.
基于 SOC 职业分类
| name | codebase-orientation |
| description | Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture. |
The expensive failure is building something that fights the codebase's own architecture because you never learned it. Orientation is 5–10 minutes of reads that pay for themselves immediately.
Instructions first. CLAUDE.md / AGENTS.md / CONTRIBUTING / README — in that order. These override your defaults and often name the exact gotchas you'd otherwise rediscover the hard way. If project instructions exist, they win over your habits.
The manifest. package.json scripts (or Makefile/justfile/pyproject) tells you: how to build, test, lint, run — and the dependency list tells you the intended stack. Use the project's declared commands, never your generic equivalents.
Shape of the tree. One ls-level pass over the source root. Learn the layering (where do types live? where does business logic vs UI vs IO live?) before deciding where new code goes. New code goes where the existing analog lives.
The relevant flow, end to end. For the specific task, trace one representative request/action from entry point to effect (route → handler → service → store, or CLI arg → command → output). Read the actual files on that path — this is the single highest-value read. Note the idioms: error handling style, naming, how modules import each other.
Recent history. git log --oneline -20 and, for files you'll edit, git log --oneline -5 -- <file>. Recent commits reveal active conventions, in-flight migrations (don't build on the OLD pattern mid-migration), and who/what last touched your area. A recent commit titled "migrate X to Y" means new code uses Y.
Find the precedent. For "add a Z" tasks, find the most recently added Z (tool, route, component, migration) and read its full diff if possible (git log --diff-filter=A, or just read all its wiring). Imitate the precedent exactly; deviate only deliberately.
When the codebase contains two competing patterns for the same thing, prefer: (1) the one in newer code, (2) the one the instructions endorse, (3) the one nearest your change. If genuinely ambiguous and load-bearing, ask — citing both patterns you found.
Orientation is breadth-first and time-boxed. Read signatures and shapes, not every body. Depth comes later, on the specific path you're changing. If the repo is huge, delegate the broad sweep (search agents) and keep only the conclusions.
