Prompts That Change Everything

When I need deep research on something I don't run one Claude session. I throw 3 Claude and 3 Codex subagents at it in parallel. Each one gets its own clean context and a focused angle on the problem.

can you run 3 claude and 3 codex subagents to analyse diangose research udnerstand what we would need to turn this poc to a real working product

Each subagent approaches the problem from a different angle — no shared assumptions, no tunnel vision inherited from the main session. One might focus on architecture, another on git history, another on how similar problems are solved elsewhere. Perspectives converge instead of compounding each other's blind spots.

After any significant build or refactor, I drop this one prompt on Claude. It switches modes completely — from collaborator to adversarial reviewer. It will surface security gaps, missing error handling, accessibility issues, performance problems, and things that would fail a real code review.

is there anything else in the code that is not enterprise ready production worthy ready for prime time and strict critiques?

Run it after shipping a new feature, before opening a PR, or any time you hand something to a stakeholder. Follow up with "fix all of those" and let it work through the list. Critique plus fix in the same session is faster than waiting for CI or a human reviewer to catch things.

Before any multi-step work I ask Claude to make a todo.md. Not just a bullet list — a structured file with description, solution, deliverables and testing criteria for each task. No ticket system, just a file in the repo.

lets make a todo.md in [ ] format for each task with description, solution description, key deliverables and testing criteria. then well tackle all of them grouped in prs as it makes sense. minimize number of prs review simialr others to create best versions

The format forces specificity before any code gets written. Vague tasks with no testing criteria become real work. Grouping by PR at planning time means you ship coherent changes instead of random one-off commits.

Describe what you want to be true, not what you want Claude to do. The second you say "use Postgres" or "add a cache layer" you're doing the architecture for it. Just tell it the outcome and let it figure out the how.

I want the list to filter as you type in the search box — right now you have to hit enter and wait

Describing the implementation locks Claude into your mental model of the solution. Describing the outcome gives it room to apply everything it knows — it often finds a simpler path than the one you'd have specified.

when you have a good agentic flow your job is mostly reviewing and approving prs. claude works through the plan, opens a pr, you check it and merge. this one prompt keeps the cycle going without breaking the rhythm

Merged. Validate and continue.

claude confirms the merge landed correctly — checks ci, verifies the feature works — then picks up the next item from the plan or todo automatically. you stay in the reviewer seat, it stays in the builder seat