Agentic Coding
Prompt Library.

If you are not sure which prompt to use, start here. These cover the loop most agentic coding work needs: scope the work, review the result, preserve the handoff.

Use when the task is real implementation work and you can name what "done" looks like. It tells the agent to inspect before editing, hold the scope boundary, and define done with evidence.

You are working in [repo/project]. Build exactly this scoped ticket:

[paste ticket or task]

Acceptance criteria:
- [observable result 1]
- [observable result 2]
- [test, check, screenshot, or command that proves it]

Constraints:
- Do not edit unrelated files.
- Do not change shared behavior unless the acceptance criteria require it.
- Preserve existing patterns and naming unless there is a concrete reason not to.
- If you find unrelated broken code, note it in the final report instead of fixing it.

Workflow:
1. Inspect the relevant files first.
2. State the smallest implementation plan.
3. Make the change.
4. Run the narrowest useful checks, plus broader checks if the touched code is shared.
5. Finish with changed files, verification evidence, and remaining risks.

Use when you have a diff, branch, or finished agent pass and want real problems surfaced before merge.

Review this work as a skeptical senior engineer. Your job is to find what could break, not to summarize the diff.

Scope:
- Branch/diff: [describe or paste link]
- Intended behavior: [what the change is supposed to do]
- Files or areas most likely affected: [optional]

Prioritize:
- correctness bugs and edge cases
- data loss, privacy, security, or permission mistakes
- broken user flows, mobile behavior, or browser regressions
- missing tests or weak verification
- unnecessary scope creep

Rules:
- Findings first, ordered by severity.
- Use file/line references or concrete evidence.
- Do not invent issues. If you are unsure, say what evidence would confirm it.
- If there are no blocking issues, say that clearly and name the residual risk.

Use after two agents, two branches, or two possible designs have produced enough evidence to compare. The goal is a decision, not an average.

Compare Solution A and Solution B. Pick the winner, merge the best parts, or reject both.

Problem:
[state the original task]

Solution A:
[paste summary, diff, branch, or notes]

Solution B:
[paste summary, diff, branch, or notes]

Judge by:
- correctness against the acceptance criteria
- maintainability
- smallest safe diff
- fit with existing project patterns
- verification evidence
- risk of hidden follow-up work

Rules:
- Do not compromise by averaging.
- Make a concrete recommendation.
- Explain the decision with evidence.
- End with the next action: choose A, choose B, merge specific parts, or ask for one missing proof.

Use when you keep pasting the same workflow or correcting the same agent behavior. A good skill is short, triggered by the right words, and loads detail only when needed.

Create a skill for this repeated workflow:

Workflow name:
[name]

When I want it used:
[phrases I will say, situations, file types, or repo areas]

What the skill should do:
1. [step]
2. [step]
3. [step]

Inputs it may need:
- [argument, file, ticket id, branch, URL, etc.]

Hard rules:
- [things it must always do]
- [things it must never do]

Output format:
- [report, checklist, patch, PR description, test plan, etc.]

Please produce:
1. A concise skill description that will trigger correctly.
2. A SKILL.md body that stays under 500 lines.
3. Any reference files or scripts that should exist, with filenames and purpose.
4. A quick test plan for validating the skill in a fresh session.

Use for durable project instructions after a mistake has repeated or a repo rule is easy to miss. These files should prevent repeat mistakes, not become a junk drawer for everything anyone once said.

Help write or refine durable agent instructions for this repo.

Target file:
[AGENTS.md / CLAUDE.md / nested project instruction file]

Project facts that are always true:
- [stack, package manager, framework, deployment target]
- [commands that matter]
- [testing or verification requirements]
- [style or architecture rules that differ from defaults]

Common mistakes agents have made:
- [mistake]
- [mistake]

Rules:
- Keep only instructions that would prevent real mistakes.
- Remove generic advice like "write clean code" or "be careful."
- Put optional procedures in skills or docs instead of this file.
- Keep the wording direct and scoped.
- If a rule only applies to one folder, suggest a nested instruction file.

Deliver:
1. The revised instruction file content.
2. A short explanation of what was kept, cut, or moved.
3. Any follow-up skills or docs that should exist instead of bloating this file.

Use for scheduled or recurring agent work when the same inspection keeps needing attention. The important part is not the schedule; it is the artifact the human will actually read.

Design an automation/routine for this recurring job:

Goal:
[what should be inspected or produced]

Cadence or trigger:
[daily, weekly, on PR, on CI failure, when file changes, etc.]

Inputs:
- [repo, branch, issue label, dashboard, docs page, logs, etc.]

Expected output artifact:
- [short report, PR comment, issue, checklist, dashboard summary, patch, etc.]

Definition of useful:
- [what would make me actually read or act on the output]

Safety boundaries:
- [read-only vs may edit]
- [approval required before external action]
- [files, branches, environments, or commands off limits]

Design the automation with:
1. Trigger and scope.
2. Exact prompt/instructions.
3. Required tools or integrations.
4. Failure behavior.
5. A sample output format.
6. A deletion rule: when this automation should be retired.

Use when an agent loops, stalls, keeps testing the wrong thing, or explains the obstacle instead of moving around it. This is a reset prompt, not a pep talk.

You are stuck. Stop trying the same path.

Current goal:
[state the goal]

What has failed so far:
[commands, errors, dead ends, missing context]

Do this now:
1. Summarize the blocker in one paragraph with evidence.
2. List three alternate paths around it.
3. Pick the fastest path that preserves correctness.
4. State the smallest next command or edit.
5. Continue only on that path.

Rules:
- Do not repeat a failed command unless something changed.
- Do not broaden scope.
- Do not ask me to do manual work unless the environment truly blocks you.
- If the correct move is to stop, produce a handoff with exact current state and next required input.

Use before compaction, handoff, switching agents, or stepping away. Good summaries preserve state, decisions, evidence, and the next useful move.

Summarize this session for a fresh agent who must continue without rereading the whole conversation.

Include:
- Objective and current status.
- Decisions made and why.
- Files changed, with purpose.
- Commands/checks run and their results.
- Bugs, blockers, or failed attempts.
- Open questions and assumptions.
- Exact next steps, in order.
- Things not to touch or revert.

Rules:
- Be concrete.
- Do not include chat filler.
- Distinguish facts from guesses.
- Preserve any user constraints verbatim if they affect future work.
- If code changed, include the verification gap that remains.

Use this only when the task is big enough for workflow-scale orchestration: independent lanes, clear evidence, and a real reason to spend more usage. /effort ultracode is not "try harder"; it is "let Claude decide whether this deserves a Dynamic Workflow."

You are running Claude Code with Opus 4.8 and Dynamic Workflows available.

Use ultracode as orchestration, not as "try harder."
Subagents delegate work. Dynamic Workflows delegate the orchestration itself.

First decide whether this task deserves a workflow.

Use a Dynamic Workflow only if the task has:
- 3+ independent lanes
- clear file ownership or no file edits
- useful cross-checking between agents
- evidence each phase can return
- enough value to justify higher usage

Task:
[paste the task]

Acceptance criteria:
- [observable result 1]
- [observable result 2]
- [tests, screenshots, checks, or review evidence required]

Before launching the workflow:
1. State the independent lanes.
2. Name files or directories that must have one owner only.
3. Name anything that must stay serial.
4. Set a max scope and stopping condition.
5. Tell me what evidence will prove the workflow helped.
6. Tell me when you will stop and ask me instead of continuing.

During execution:
- Use subagents only for independent lanes.
- Do not assign two agents to edit the same file.
- Use reviewers or adversarial agents for high-risk findings.
- Stop and ask before deploys, migrations, billing, production data, or external sends.

Final report:
- orchestration graph / lanes used
- agents or workflow stages launched
- changed files and owner per lane
- checks run and results
- findings rejected as false positives
- remaining risks
- whether you would use a workflow again for this class of task

Use before parallel agents touch the repo. Worktrees only help when ownership, proof, and merge order are clean.

Plan a worktree split for this project.

Overall objective:
[what we are trying to ship]

Candidate workstreams:
- [stream A]
- [stream B]
- [stream C]

Repo constraints:
- [shared files, generated files, migrations, app shells, routing, design system, etc.]

For each worktree, define:
1. Branch/worktree name.
2. Owner role.
3. Exact files or directories it may edit.
4. Files it must not edit.
5. Acceptance criteria.
6. Verification command or browser evidence.
7. Merge order and conflict risk.

Rules:
- Do not assign two agents to the same file unless one is read-only.
- Keep shared abstractions in their own workstream.
- Identify any workstream that should happen serially instead of in parallel.
- End with the commands or app steps to create the worktrees.

Use after frontend changes or content edits that affect layout. A code diff is not proof that the page renders, responds, or fits on mobile.

Verify this UI change with browser evidence.

Target:
- URL or route: [local URL / deployed preview / route]
- Change to verify: [what should be visible or interactive]

Check:
- Desktop viewport: [size if important]
- Mobile viewport: [size if important]
- Core interaction path: [click/type/scroll/filter/open/submit]
- Console errors.
- Network or asset failures if relevant.
- Text overflow, clipping, overlap, or layout shift.
- Visual state before and after interaction.

Evidence required:
- Screenshot description or screenshot path if the tool captures one.
- Exact browser actions performed.
- Any console/network errors found.
- Pass/fail against each acceptance criterion.

Rules:
- Do not call it verified from code inspection alone.
- If the app cannot run, report the command tried and exact failure.
- If something looks wrong, identify the selector/area and propose the smallest fix.

The prompts are the operating layer. The guides explain the systems they plug into, and the Practice Dojo turns them into repeatable reps.