一行要約
Claude Code 用のコピペできるプロンプト 52件。SDLC のフェーズ（discover / design / build / ship / operate）とロール（pm / design / docs / marketing / data / ops / security）でタグ付けされているのが構造。
要点
分布
| フェーズ | 件数 | カテゴリ |
|---|---|---|
| discover | 7 | Onboard, Understand |
| design | 6 | Plan, Prototype |
| build | 22 | Implement, Test, Refactor, Review, Steer |
| ship | 5 | Git, Release |
| operate | 12 | Debug, Incident, Data, Automate |
{} はプレースホルダで、ページ上では例の値が埋まっている。
プロンプトの型として読むと
このライブラリを眺めて見えてくる共通の型:
- 「読んで → 書き出す」 —
read {input} and write up ...、read {file}, summarize ..., and write the results to {output} - 「実装して → 検証する」 —
implement the fix, and run the tests、take a screenshot of the result, compare it to the original, and fix any differences - 「既存を学んでから作る」 —
look at how {example} is implemented to understand the pattern, then build {new} the same way、read the {examples} in {folder} to learn the structure and voice, then draft a new one - 「訂正を仕組みに変える」 —
you keep {mistake}. add a rule to CLAUDE.md so this stops happening
そのまま使える具体例
discover（探索・理解）
give me an overview of this codebase: architecture, key directories, and how the pieces connect
explain what {path} does and how data flows through it. write it up as {format}
where do we {behavior}?
what would break if I deleted {target}?
look through the commit history of {path} and summarize how it evolved and why
which files would I need to touch to {change}?
I am a {role}. walk me through what happens when a user {action}, from the UI down to the resultdesign（計画・プロトタイプ）
plan how to refactor the {target} to {goal}. list the files you would change, but don't make changes yet
I want to build {feature}. interview me about implementation, UX, edge cases, and tradeoffs until we have covered everything, then write the spec to SPEC.md
read {input} and write up the action items, then create a {tracker} ticket for each with acceptance criteria
list the error states, empty states, and edge cases for {feature} that the design needs to cover
here is a mockup. build a working prototype I can click through, matching the layout and states shownbuild — implement
implement this design, then take a screenshot of the result, compare it to the original, and fix any differences
look at how {example} is implemented to understand the pattern, then build {new} the same way
find {scope} without {format} comments and add them, matching the style already used in the file
add a {endpoint} endpoint that returns {payload}
create a {tool} using HTML, CSS, and vanilla JavaScript, then open it in my browser
read issue #{issue}, implement the fix, and run the tests
find every place we say "{copy}" or a close variant, show me each one in context, then update them all to "{new}". leave tests and the changelog alone
read the {examples} in {folder} to learn the structure and voice, then draft a new one for {topic}build — test
write tests for {path}, run them, and fix any failures
write tests for {feature} first, then implement it until they pass
read {report} and add tests for the lowest-covered files until each is above {target}%build — refactor
migrate everything from {from} to {to}: identify every place that needs to change, then make the changes
port {source} to {target}, keeping the same {keep}
optimize {target} to bring {metric} from {current} down to under {goal}
the {element} extends {amount} beyond the {container} on {viewport}. fix it.build — review
review my uncommitted changes and flag anything that looks risky before I commit
review PR #{pr} and summarize what changed, then list any concerns
here is my Terraform plan output. what is this going to do, and is anything here going to cause problems?
use a subagent to review {path} for security issues and report what it finds
review {file} for {concerns} and list anything I should fix before it goes to {reviewer}build — steer（軌道修正の3型）
that is not right: {feedback}. try a different approach
that is too much. keep only the changes to {scope} and undo your other edits
you keep {mistake}. add a rule to CLAUDE.md so this stops happeningship
resolve the merge conflicts in this branch and explain what you kept from each side
commit these changes with a message that summarizes what I did
find the {tracker} ticket about {topic} and open a PR that implements it
compare {from} to {to} and draft release notes grouped by feature, fix, and breaking change
write a GitHub Actions workflow that {steps} on every push to {branch}operate — debug / incident
the {test} test is failing, find out why and fix it
users are seeing {symptom} on {where}. investigate and tell me what is going on
here is a build error. fix the root cause and verify the build succeeds
{symptom}. check the logs, recent deploys, and config changes, then tell me the most likely cause
here is a screenshot of {console}. walk me through why {resource} is failing and give me the exact commands to fix it
show me all {events} for {scope} over {timeframe}. write the query, run it, and tell me what stands outoperate — data / automate
read {file}, summarize the key patterns, and write the results to {output}
read {file}, find the underperforming {items}, and generate {n} new variations that stay under {limit} characters
create a /{name} skill for this project that {steps}
write a hook that {action} after every {event}
set up the {server} MCP server so you can read my {data} directly
summarize what we did this session and suggest what to add to CLAUDE.md原典で言及されている関連文書
- common-workflows — 同じレシピを手順として展開したもの
- claude-code-best-practices — プロンプトの背後にある原則
- memory — 「訂正を CLAUDE.md のルールに変える」
- skills —
create a /{name} skill for this project - hooks-guide —
write a hook that {action} after every {event} - mcp —
set up the {server} MCP server