Prompt templates and team adoption

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.

Explain @src/scheduler/queue.ts and its inputs/outputs.
Organize by entry points, key functions, side effects, error handling, and test gaps.

Where is {behavior} implemented? Locate it with rg before reading files.
Report paths, function names, and call chain.

Plan how to turn {module} into {goal}.
List affected files, risks, compatibility needs, and validation commands.
Do not edit anything.

I want {feature}. Interview me about users, scenarios, UI/API behavior,
permissions, empty/error states, migration, and compatibility.
Then write SPEC.md.

List error, empty, loading, insufficient-permission, and mobile cases for {feature}.
Return acceptance criteria only, without code.

Implement {feature} following {existing implementation}.
Scope: {allowed directories}.
Reuse existing dependencies/patterns, preserve API compatibility,
and run {validation commands}.

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.

Add {test type} for {module}. Follow existing test style and add focused coverage.
Do not change production behavior merely to make testing easier.

Explain this test failure, then locate the smallest fix.
Log: {relevant error}
Run focused tests and explain whether broader regression coverage is needed.

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

This code recently slowed down. Find hotspots and repeated renders/requests first.
Provide evidence before refactoring.

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.

Write a PR description from the actual diff: background, changes,
validation commands/results, risks, and rollback.
Do not invent checks that were not run.

Run the release checks: lint/types/tests/build, key user paths,
390px mobile, light/dark, empty/error states.
Report passes, failures, and next steps.

Update documentation from current code, tests, and official sources.
Do not guess API behavior; retain authoritative links.

Turn this investigation into a runbook:
symptoms, quick diagnosis, common causes, diagnostic commands,
repair steps, and rollback.

Extract durable CLAUDE.md rules from this task.
Keep only information future tasks consistently need, not this ticket's history.

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.

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.

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.

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}.

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.