source-investigator
Source Investigator
Inspect real source when that is the most reliable way to answer the question. Keep the main thread focused on synthesis and decisions, not on carrying around large amounts of raw source code.
Workflow
- Decide whether source inspection is warranted.
- Prefer source over docs when the question depends on real control flow, defaults, edge cases, or version-specific behavior.
- Prefer docs first for public API overviews or setup instructions. If docs are still useful, have a subagent use
find-docsrather than loading long documentation into the main thread. - If the user named a specific repo, library, or framework version, treat that as a strong signal to inspect the exact source.
- Create a project-local temp workspace before cloning.
- Work from the current project root.
- Create
.tmp/if it does not exist. - Create or update
.gitignoreso.tmp/is ignored. Do not assume a.gitignorefile already exists. - Keep disposable investigation clones under
.tmp/repos/. - Keep any generated notes or scratch outputs under
.tmp/work/.
- Clone the exact repository and ref you need.
- Clone into a clearly named directory such as
.tmp/repos/reactor.tmp/repos/context7. - Prefer
git clone --depth 1when current source is enough. - If the question depends on a branch, tag, or commit, check out that exact ref and report it in the answer.
- Keep the clone disposable. Do not wire it into the current project or treat it as a dependency.
- Delegate exploration to subagents.
- Do not inspect a large repository inline in the main thread unless a very small local excerpt is all you need.
- Spawn focused subagents with narrow questions such as:
- where the entry point is
- how configuration is loaded
- which module implements a specific behavior
- what changed between two refs
- why a specific error or default occurs
- Tell subagents to return concise findings, supporting file paths, and only the minimum quoted code needed to justify the answer.
- Use subagents because their exploration stays out of the main thread's context window. The main thread should receive distilled findings, not raw repository contents.
- When docs matter, give a subagent the
find-docsskill or have it read primary documentation while the main thread stays focused on the decision.
- Synthesize the answer in the main thread.
- Combine the subagent findings into a direct answer.
- Cite concrete repo paths, symbols, and refs so the user can verify the conclusion.
- Separate direct observations from inference.
- Keep the answer focused on what the user asked, not on everything the exploration uncovered.
Guardrails
- Do not clone into tracked source directories.
- Do not leave temp directories unignored.
- Do not paste large source files into the main thread just because they seem relevant.
- Do not use a single broad subagent task when several smaller, well-scoped questions would keep findings cleaner.
- Do not let subagents make the final user-facing conclusion when the main thread should synthesize the result.
Example Triggers
- "Figure out how this library resolves config defaults. Clone the repo and inspect the source."
- "The docs are vague. Check the actual implementation for this behavior."
- "Investigate how this framework handles streaming responses in the current version."
- "Use a temp clone and subagents to learn how this repo is structured without polluting the main thread."
More from sjunepark/custom-skills
summarize
Use the steipete/summarize CLI to summarize URLs, local files, stdin, YouTube links, podcasts, and media with LLM models. Trigger when users ask to install or run summarize, configure model/provider API keys, tune output flags (length/language/json/extract/slides), set defaults in ~/.summarize/config.json, or troubleshoot summarize CLI errors.
41post-implementation-review
Manually review already-implemented code for design flaws, abstraction issues, structural problems, or refactors that only became clear in real code. Use only when the user explicitly asks for a post-implementation review, explicitly asks whether recent implementation work revealed design or structure problems, or explicitly wants refactor recommendations after the code exists. Do not auto-trigger for ordinary implementation, debugging, explanation, or generic code review requests. Prefer embedded snippets with file-path comments over editor-oriented file and line references. Prioritize real design, ownership, abstraction, and organization weaknesses over minor local polish, call out real tradeoffs, and separate straightforward recommendations from items worth discussion.
29architecture-md-writer
Create, update, review, and split ARCHITECTURE.md files that explain a codebase's shape, major components, runtime flow, code map, and important invariants. Use when a repository lacks architecture docs, an existing ARCHITECTURE.md is stale or too detailed, a subsystem needs its own nested ARCHITECTURE.md, or a root architecture doc should link to deeper module architecture docs.
27agents-md-writer
Create, edit, review, and improve AGENTS.md files for repositories used by agentic coding tools with concise, actionable instructions and correct precedence behavior. Use whenever AGENTS.md content is being changed, including updating existing guidance, drafting a new AGENTS.md, migrating legacy instruction files, defining nested overrides in monorepos, or debugging why tools load the wrong guidance.
26briefing
Manually brief the user on the current task or session so they can make the next decision without reloading the whole codebase. Use only when the user explicitly asks for a briefing, catch-up, current state, relevant architecture, or implementation context. Prefer this skill for task-scoped context recovery when the conversation is long, the code has changed, or the user wants the relevant details without a long explanation.
22tailwind-semantic-theme
Set up or refactor Tailwind v4 app theming around shadcn-compatible semantic CSS tokens without using shadcn itself. Use only when the user explicitly asks for this skill by name or explicitly asks for this exact methodology: OKLCH theme variables in `:root` and `.dark`, class-based dark mode, `@theme inline`, and shadcn-compatible token naming for future UI compatibility.
21