메뉴
Use when an internal package, module, or shared component has little or no usage documentation and people (or future AI sessions) keep using it wrong — "document this", "write docs for our library", onboarding someone onto an internal API, or handing a package to another team.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | explain |
| description | Use when an internal package, module, or shared component has little or no usage documentation and people (or future AI sessions) keep using it wrong — "document this", "write docs for our library", onboarding someone onto an internal API, or handing a package to another team. |
Most internal packages ship with no usage docs, so every consumer — a teammate, or an AI — reads the source, guesses the intended usage, and gets the gotchas wrong. This skill fixes that: one colocated usage doc per public unit, capturing the API and the non-obvious rules, so the next reader is correct on the first try. It applies to any package — a UI component kit, a utils library, a services/API layer, a hooks package, an internal SDK.
Why it matters for portability: these docs are the layer that makes your package understandable to any model. If you move from one AI tool to another, the new model still understands your package immediately — the knowledge lives in the repo, not in one model's head.
This writes files into the user's repo. Confirm before doing anything: "I can generate AI-friendly
usage docs for <package> so any model (and teammate) understands it correctly — one doc per public unit,
with the gotchas. Want me to? (I'll show one sample first.)" Show a sample doc for one unit and get a
thumbs-up before fanning out across the package.
Discover the public units. Read the package's public entry (index.ts/exports) for the real list —
components, exported functions, hooks, services, classes. Note any existing docs' style and match it.
Read the source of truth, then write. For each unit: the implementation, its types, its variants/options, its tests/stories, and one real usage in the codebase. Verify every claim against the code (never document a guess; mark "unverified" or omit).
Write a colocated doc (a README.md/doc beside the unit) with a consistent template:
Prioritize the gotchas. The API table can be inferred from types; the gotchas cannot. That's the value.
Stamp it so drift is detectable. The code is the SSOT; the doc is derived — so record what it
was derived from, the way engineering/ROUTER.md records a hash per node. End each doc with a
footer naming the source file(s), the repo commit SHA at generation time, and a short content hash
of each source (git rev-parse --short HEAD, git hash-object <file>):
<!-- generated-from: src/Button.tsx@a1b2c3d (hash 9f4e21bc) · regenerate if the hash differs -->
Detecting drift is then a one-liner anyone (or any model) can run: re-hash the source and
compare to the footer — git hash-object src/Button.tsx — or git log a1b2c3d..HEAD -- src/Button.tsx
to see whether the unit changed since. Mismatch → treat the doc as stale: re-read the source and
regenerate that unit before trusting it. No build script required; if the repo already has a docs
check or pre-commit hook, wire the same comparison into it rather than inventing a second mechanism.
Use when implementing any non-trivial feature, change, or fix — "build me X", "add this feature", "implement this", "make this work", "can you create". Covers new functionality, meaningful changes to existing code, and anything where quality matters. Not for a one-line diff — just do that.
Use when a bug isn't obvious, resists a quick fix, keeps coming back, or you're about to start guessing — "why is this broken", "this keeps happening", intermittent or flaky failures, a crash you can't explain, behaviour that makes no sense. Not for a typo or an obvious mistake.
Use when something has to be removed or retired — a feature, endpoint, table column, config key, feature flag, package or whole service; migrating consumers off an old API or version; code that looks dead but might not be. Symptoms: "can we delete this?", "is anything still using this?", "we need everyone off v1", "kill the old one". Not for restructuring that keeps the interface — that's the `refactorer` agent.
Use when you are about to tell the user something works, hand over a decision you feel confident about, or make a change that can't be undone — and when a review came back suspiciously clean. Symptoms: "are you sure?", "you said that was fixed last time", nothing to report, the answer feels too tidy. Not for a routine small change; not for reviewing a finished diff — that's `code-reviewer`; not for driving a finished change end-to-end to get evidence — that's `qa`. Doubt tests a claim (a diagnosis, a design call, an answer), which is often not runnable code.
Use when work needs to survive losing context — before a /clear on a long task, when pausing something unfinished, when handing over to a teammate or the next session, when the context window is filling up on multi-day work, or when a long multi-step task starts re-covering ground it already finished. Not the project's decision history across weeks — that's `roadmap`.
Use when the user asks what MasterMind can do or how to drive it — "help", "what can you do", "how do I use this", "what commands are there", "list your skills", "what are my options" — or when they seem unsure how to get started.