readonly-research
Research the codebase to answer a question without making any changes. Use when exploring code, understanding architecture, or investigating how something works.
- License 许可
- MIT
- 最近更新
- 2026-05-15
- Stars
- ★ 13
- Forks
- 1
01 前言 Front Matter
- name
- readonly-research
- title
- readonly-research
- description
- Research the codebase to answer a question without making any changes. Use when exploring code, understanding architecture, or investigating how something works.
- allowed-tools
- Read Grep Glob Bash(find *) Bash(git log *) Bash(git show *)
- user-invocable
- false
02 资源文件 3
- 参考文档ADR-FORMAT.md2.7 KB
- 参考文档agents/openai.yaml101 B
- 参考文档GLOSSARY-FORMAT.md2.2 KB
03 SKILL.md 正文
Codebase research
Research the codebase to answer the question or complete the investigation. Do not modify any files. Do not create files. Do not run tests or build commands.
Step 1: Clarify the question
If $ARGUMENTS is empty or ambiguous, state the research question you are answering before proceeding. If the question is clear, proceed directly.
Step 2: Search for relevant files
Start broad, then narrow. Use a combination of approaches:
grep -r "<term>" --include="*.ts" --include="*.js" -lto find files containing a keywordglob("src/**/*.ts")or similar to list files in a known areafind . -name "<filename>" -not -path "*/node_modules/*"for specific filenames
Search for the primary concept, then for related symbols, then for tests that exercise the relevant code.
Step 3: Read the most relevant files
Read the files that are most likely to answer the question. Prioritize:
- The module or function directly named in the question
- Its callers and dependents (to understand how it is used)
- Its tests (to understand expected behavior)
- Any relevant configuration or type definitions
Avoid reading files speculatively. Only read a file if there is a specific reason it could answer the question.
Step 4: Check git history if relevant
If the question is about why something is the way it is, or when a change was made, use:
git log --oneline --follow -20 <file>
git show <commit-hash>
Step 5: Synthesize findings
Present a clear answer to the research question with:
- The specific answer (yes/no, the function name, the file path, etc.)
- Supporting evidence with file:line references for every specific claim
- Areas of uncertainty: files you could not access, code paths you could not trace, or ambiguities in the implementation
Format the response for the user's question, not as a generic research report. If the user asked "where is the auth logic?", answer that directly, then provide supporting detail.
04 同仓库更多 Skills
tag-version
Bump the package version and create an annotated git tag. Accepts a semantic version number (1.2.0) or a bump type (patch, minor, major). Does not push — use the publish skill to push. Use as part of a release workflow.
release
Run the complete release workflow: changelog entry, version bump, git tag, and GitHub release. Invokes changelog-entry, tag-version, and publish in sequence. Use when releasing a new version of the project.
publish
Push the current branch and all tags to origin, then create a GitHub release using the latest tag and its CHANGELOG.md entry. Use after tag-version to complete a release.
changelog-entry
Draft the changelog entry for all unreleased commits in Keep a Changelog format. Groups commits into Added, Changed, Fixed, Removed, and Security. Use before releasing a new version or when updating CHANGELOG.md.
auto-format-on-edit
Automatically format code files after every edit using Prettier and ESLint. Active in the background whenever Claude edits a file. Formatting is silent — no prompts, no output unless a formatter fails. Use when you want consistent formatting enforced automatically during a coding session.
code-quality-audit
Run a comprehensive code quality audit covering security, performance, and maintainability. Use for quarterly audits, pre-release reviews, or when onboarding to a large codebase.