Claude Code needs guided prompting in order to work better. It has a tendency to get off the rails if left unattended, especially when auto-applying edits.

Links:

Prompts

Starting a task

Command: start-task

We are starting a new task. Before coding anything, I want you to think hard about the task and how you are gonna go about it. Scan the codebase for any potential gotchas for the solution you are approaching. Think of potential pitfalls for your approach and propose mitigations. Write about your understanding about the problem, your proposed solution, pitfalls and gotchas, into a markdown file inside the TASKS/ folder, with the filename the slugified issue ID (if provided) and description, all lowercase. Keep the plan at a high level, providing a high level overview of each script that's needed and only critical snippets at most for nuanced portions you want to convey. If given an issue ID, name the task (issue ID): (title). List out in an ## IMPLEMENTATION section each high level task, with nuanced descriptions of each task and any snippets that you deem important. For the next section of the workplan, you will add the list of subtasks for this task in a ## TASKS section, a ## LEARNINGS section which is initially empty and which you will update with insights and gotchas you find along the way,, and a new section called ## LOG which you will update every time you make progress. You will modify this workplan along the way for any changes to the architecture, update on tasks, and log of work you've done. The workplan will be the authoritative source for our current implementation and progress in this task. After I approve your workplan, give me a 2 paragraph max description of this task I can copy paste to JIRA. Give background info and implementation overview in the JIRA description. Once that's approved, we will start immediately with Test-Driven Methodology. Start with tests (either a test script, unit tests, or integration tests) that will measure your progress on this task. You will write smaller tests along the way to test any code you write. Make sure to read @README.md. Your task is:

Updating the workplan after work is done

Command: update-workplan

Think hard on what else you should add to the workplan. We will be clearing your context so make sure the next claude instance has enough info it needs in the 
 workplan. MAKE SURE NOT TO INCLUDE SENSITIVE INFORMATION. Make sure to read @README.md Update the architecture, learnings and logs if you deem them necessary.

Continuing from the workplan

Command: continue-workplan

You are a senior software engineer continuing the work from a previous engineer. You will get the context from a workplan to see what the task is, what the subtasks are, the learnings and the log of work done. The workplan is and should be the authoritative source of the task at hand. Make sure it is up-to-date if implementation details change. Make sure the learnings are updated with insights and gotchas you find along the way. Make sure you update the log when you have achieved a major milestone, or when requested to make an update. Read any files you think are relevant, after reading the workplan. Then scan the codebase for any additional context you might need. Start immediately with Test-Driven Methodology. Start with tests (either a test script, unit tests, or integration tests) that will measure your progress on this task. You will write smaller tests along the way to test any code you write. I want you to think hard about the task and how you are gonna go about it. Construct the TODO list for this session and show me first. Make sure to read @README.md The workplan is:

Reviewing the changes that aren't committed yet

Command: review-uncommitted

You are a senior software engineer. Give a critical, no-BS review the changes currently in the git index. Ultrathink on whether the logic and solves the issue in the best way, according to your knowledge. Look for code smells and inconsistencies in how things are coded right now vs. what's in the rest of the codebase. Point out over-engineered solutions for the problem space. We may feed your output into another AI agent, so make sure you provide the context of the work and enough description and suggestions for how to address your comments.

Committing the work so far

Command: prepare-commits

You are a senior software engineer now prepping the work done so far into PR review. Review the pending changes we've made using git status. The reviewer will go commit by commit, reviewing the changes on a per-commit basis. Think hard about how you want to group the changes by commit. Make sure each commit's changes are logically chunked and can be described in a single sentence in the commit message. Make sure to commit the workplan and any accompanying test scripts. Unless the changes are very small, do not commit all the changes into one single commit. Before starting the git commits, Show me each commit you'll make and its accompanying commit messages, and what files you'll include. If adding a hunk, show me a snippet of that hunk. Once I approve the commit log, start constructing and doing each commit. Use Conventional Commits for formatting the change, and use something like feat({issue ID}) if the issue ID is given. Make sure to read @README.md. DO NOT SAY THIS WAS DONE BY CLAUDE CODE. Review this workplan to find out the context:

Proposing commits with commit messages and the contents of each commit

Command: prepare-jj-commits

You are a senior software engineer preparing work for a PR review. You will be using 'jj', an alternative to git, for version control. Your task is to review pending changes, group them logically into commits, and organize these commits into PR stacks where appropriate.

first, review the following workplan to understand the context of the changes. It will be given to you in the end.

Now, follow these steps to prepare the changes for review:

  1. Review the pending changes. Make sure to review the diff or open the file and read its contents.
  2. Group the changes logically into commits.
  3. Formulate commit messages using the Conventional Commits format (https://www.conventionalcommits.org/en/v1.0.0/).
  4. Organize commits into PR stacks where appropriate.
  5. Present a commit plan.
  6. Once approved, provide the necessary jj commands to implement the plan.

In your analysis, consider the following:

In <commit_planning> tags inside your thinking block:

  1. List out all files mentioned in the workplan.
  2. Categorize changes by type (e.g., feat, fix, refactor).
  3. Consider dependencies between changes.
  4. Group changes into logical commits.
  5. Formulate commit messages.
  6. Organize commits into PR stacks where appropriate.

Then, outside of the thinking block, present your commit plan using the following format:
Commit 1: [commit message]
files:

PR 1: [PR title]
[Continue with more commits and PRs as needed]

After presenting the commit plan, wait for approval. Once approved, provide the jj commands to implement the plan. Use the following format for jj commands:


jj split -m "[commit message]" [files]

jj bookmark create -r @- [username]/[issue-id]-[descriptivename]

Finally, include the command to push all changes:


jj git push -r 'pr_stack'

Remember, 'pr_stack' is a custom alias that has already been set up.

Your final output should consist only of the commit plan and jj commands, and should not duplicate or rehash any of the work you did in the thinking block. The workplan is:

Reviewing a PR

Give a no-BS, critical review of a PR. If relevant, show snippets of the code where your comment applies, including the file and line number. PR is: