# Claude Code Prompt templates and team adoption > Claude Code: Reusable prompts, champion messages, rollout templates, role-specific starting points, and caching considerations. URL: https://docs.passion8.cc/en/docs/claude-code/prompt-library Language: en Publisher: Passion8 This adapts the official Prompt library, Champion kit, Communications kit, and What's new into reusable local templates for individuals and team leads. Templates are not magic. They help preserve the essentials: goal, context, scope, validation, and output format. ## Prompt structure | Part | Include | Example | | --- | --- | --- | | Goal | Concrete outcome | Fix overlapping mobile login buttons | | Context | Files, logs, screenshot, PR, design | @src/app/login and failure evidence | | Boundary | Allowed/protected areas | Only login code and its tests | | Verification | Evidence of success | Lint, 390px screenshot, unit tests | | Output | Plan, patch, table, JSON, PR description | Risks first, then implementation | ## Explore code ```text Explore this repository read-only. Report: 1. Stack 2. Entry points 3. Main data flow 4. Test/build commands 5. High-risk areas Do not edit files. ``` ```text Explain @src/scheduler/queue.ts and its inputs/outputs. Organize by entry points, key functions, side effects, error handling, and test gaps. ``` ```text Where is {behavior} implemented? Locate it with rg before reading files. Report paths, function names, and call chain. ``` Research reads can be large. Short continuous follow-ups suit a five-minute TTL; a supported longer TTL may help when returning after longer pauses. ## Plan changes ```text Plan how to turn {module} into {goal}. List affected files, risks, compatibility needs, and validation commands. Do not edit anything. ``` ```text I want {feature}. Interview me about users, scenarios, UI/API behavior, permissions, empty/error states, migration, and compatibility. Then write SPEC.md. ``` ```text List error, empty, loading, insufficient-permission, and mobile cases for {feature}. Return acceptance criteria only, without code. ``` Planning before implementation keeps context stable. Switching model/effort immediately afterward can lose that cache benefit. ## Implement features ```text Implement {feature} following {existing implementation}. Scope: {allowed directories}. Reuse existing dependencies/patterns, preserve API compatibility, and run {validation commands}. ``` ```text Implement the UI from this screenshot. Run it, capture a comparison, and fix layout, spacing, color, and text overflow. Check 320px, 390px, 1440px, and dark mode. ``` ```text Add {test type} for {module}. Follow existing test style and add focused coverage. Do not change production behavior merely to make testing easier. ``` Large diffs, test output, and browser logs increase context. Supply the relevant 100–200 log lines instead of the whole log. ## Debug and repair ```text Explain this test failure, then locate the smallest fix. Log: {relevant error} Run focused tests and explain whether broader regression coverage is needed. ``` ```text Reproduce and fix the bug: 1. Find a minimal reproduction or related test 2. Identify the cause 3. Make a focused change 4. Verify 5. Summarize remaining risks ``` ```text This code recently slowed down. Find hotspots and repeated renders/requests first. Provide evidence before refactoring. ``` Continue debugging in the same session when useful instead of repeatedly clearing; ordinary turns can refresh TTL. ## Review and release ```text Review the current Git diff for bugs, regressions, security issues, and missing tests. For each finding give file/line, severity, and trigger. Omit style preferences. ``` ```text Write a PR description from the actual diff: background, changes, validation commands/results, risks, and rollback. Do not invent checks that were not run. ``` ```text Run the release checks: lint/types/tests/build, key user paths, 390px mobile, light/dark, empty/error states. Report passes, failures, and next steps. ``` Large reviews add substantial context. A review subagent or supported code-review workflow can return a concise summary to the main session. ## Documentation and knowledge ```text Update documentation from current code, tests, and official sources. Do not guess API behavior; retain authoritative links. ``` ```text Turn this investigation into a runbook: symptoms, quick diagnosis, common causes, diagnostic commands, repair steps, and rollback. ``` ```text Extract durable CLAUDE.md rules from this task. Keep only information future tasks consistently need, not this ticket's history. ``` Keep large references in skills or runbooks rather than repeatedly pasting them. ## Champion messages Share a real repository example, a copyable prompt, and a verifiable result instead of abstract promotion. ```text A useful technique from today: I asked Claude to inspect @src/components read-only for missing tests. Prompt: "Find components with missing or clearly insufficient tests, rank by risk, and do not edit files." It found two components I had missed. ``` ```text Plan mode makes it easier to try important code safely. Shift+Tab switches to a plan before editing, showing affected files first. Try it when approaching an unfamiliar module. ``` ```text For your first task, choose a real but bounded problem rather than the hardest refactor: a flaky test, missing coverage, an unfamiliar module, lint failure, or PR description. ``` ## Rollout messages ```text Claude Code is available to {team}. It works with the current repository in your terminal/IDE to explain code, fix bugs, write tests, run checks, and prepare PRs. Get started: 1. Install Claude Code 2. Configure your team's provider, then run claude in the repository 3. Run /init and review the instructions 4. Try: "Explain @src/auth login flow and risks. Do not edit files." Questions: {support channel}. Data handling, boundaries, and provider setup: {internal link}. ``` ```text Pilot request: use Claude Code for one real task this week. Post in {channel}: what you did, where it saved time, and what was unreliable or blocked. Feedback informs the next rollout. ``` See [Enterprise rollout](https://docs.passion8.cc/en/docs/claude-code/enterprise-rollout) for stages. ## Role-specific starting points | Role | Prompt | | --- | --- | | New engineer | Explain architecture, entry points, and common commands without edits | | Backend | Trace {API} from route to database, including errors and authorization | | Frontend | Inspect {page} at 320/390/768/1440, dark mode, and text overflow | | QA | Create P0/P1/P2 acceptance cases for {requirements}, without code | | PM | Interview me about {feature}, then write SPEC.md | | Design | Build from screenshot, compare captures, fix hierarchy/states/responsiveness | | SRE | Analyze logs for patterns, impact, causes, and next diagnostic commands | | Tech lead | Review diff for high-value architecture, compatibility, and coverage risks | ## Follow official changes | Source | Purpose | | --- | --- | | What's new | Weekly capabilities such as cd, artifacts, MCP login, automatic mode | | Changelog | Version-specific fixes and regressions | | Prompt library | Starting templates for teams | When a new command appears, update [Commands](https://docs.passion8.cc/en/docs/claude-code/commands) and [Cache effects](https://docs.passion8.cc/en/docs/claude-code/command-cache) before deciding whether it needs a dedicated page. ## Official references - [Prompt library](https://code.claude.com/en/docs/en/prompt-library.md) - [Champion kit](https://code.claude.com/en/docs/en/champion-kit.md) - [Communications kit](https://code.claude.com/en/docs/en/communications-kit.md) - [What's new](https://code.claude.com/en/docs/en/whats-new/index.md) - [Common workflows](https://code.claude.com/en/docs/en/common-workflows.md)