Coding

This is my current @OpenAI Codex workflow.

It's insanely powerful, and allows Codex to implement far more complex features than the default setup.

It's also much more reliable and leads to better code, with significantly less scope creep.

Follow it exactly (models and all). The results are amazing:

Start by using this prompt (fill in your feature description), with gpt-5 high:

---
# Initial Explanation Stage

Your task is NOT to implement this yet, but to fully understand and prepare.

Here is exactly what I need implemented:

```[DETAILED FEATURE DESCRIPTION HERE]```

--

Your responsibilities:

- Analyze and understand the existing codebase thoroughly.
- Determine exactly how this feature integrates, including dependencies, structure, edge cases (within reason, don't go overboard), and constraints.
- Clearly identify anything unclear or ambiguous in my description or the current implementation.
- List clearly all questions or ambiguities you need clarified.

Remember, your job is not to implement (yet). Just exploring, planning, and then asking me questions to ensure all ambiguities are covered. We will go back and forth until you have no further questions. Do NOT assume any requirements or scope beyond explicitly described details.
---

Once you've answered all of GPT-5's questions and it has nothing more to ask, paste in this prompt:

---
# Plan Creation Stage

Based on our full exchange, now, produce a markdown plan document (`https://t.co/D3A6TySWHM`).

Requirements for the plan:

- Include clear, minimal, concise steps.
- Track the status of each step using these emojis:
  - 🟩 Done
  - 🟨 In Progress
  - 🟥 To Do
- Include dynamic tracking of overall progress percentage (at top).
- Do NOT add extra scope or unnecessary complexity beyond explicitly clarified details.
- Steps should be modular, elegant, minimal, and integrate seamlessly within the existing codebase.

Markdown Template Example:

```https://t.co/D3A6TySWHM (example)
# (Example) Feature Implementation Plan

**Overall Progress:** `0%`

## Tasks:

- [ ] 🟥 **Step 1: Setup authentication module**
  - [ ] 🟥 Create authentication service class
  - [ ] 🟥 Implement JWT token handling
  - [ ] 🟥 Connect service to existing database schema

- [ ] 🟥 **Step 2: Develop frontend login UI**
  - [ ] 🟥 Design login page component (React)
  - [ ] 🟥 Integrate component with auth endpoints
  - [ ] 🟥 Add form validation and error handling

- [ ] 🟥 **Step 3: Add user session management**
  - [ ] 🟥 Set up session cookies securely
  - [ ] 🟥 Implement session renewal logic
  - [ ] 🟥 Handle session expiry and logout process

...
```

Again, for clarity, it's still not time to build yet. Just write the clear plan document. No extra complexity or extra scope beyond what we discussed. The plan should lead to simple, elegant, minimal code that does the job perfectly.
---

Now, once this plan is done, look it over, and if it looks good, switch the model to gpt-5-codex high, then prompt it with:

---
Now implement precisely as planned, in full.

Implementation Requirements:

- Write elegant, minimal, modular code.
- Adhere strictly to existing code patterns, conventions, and best practices.
- Include thorough, clear comments/documentation within the code.
- As you implement each step:
  - Update the markdown tracking document with emoji status and overall progress percentage dynamically.
---

💡CLAUDE[.]md Tips & Tricks (Cheatsheet)

CLAUDE[.]md is one of the most important files in any Claude Code project. Think of it as project memory + execution guidelines.

It tells Claude what your project is, how the codebase is structured, what design rules to follow, and what patterns to avoid.

Here are 8 practical tips for writing a better CLAUDE[.]md:

1⃣ Know the difference between project and global CLAUDE.md

A project-based CLAUDE[.]md lives in your project root and is specific to that product.
A global CLAUDE[.]md lives in your Claude env and defines reusable preferences across all projects.

Project CLAUDE.md = project context
Global CLAUDE.md = personal working style

2⃣ Structure it properly

Claude performs better when information is grouped semantically.
Thats why don’t write random instructions.

Use clear sections like:
✅ Project Overview
✅ Tech Stack
✅ Folder Structure
✅ UI/UX Principles
✅ Component Rules
✅ Accessibility Requirements
✅ Testing Strategy
✅ Content Guidelines
✅ Deployment Notes

3⃣ Use [/]init to create the first draft

You don’t need to start from a blank page.
Run [/]init so Claude Code will scan your project and generate a first version of CLAUDE[.]md
It won’t be perfect, but it gives you a solid starting point.

4⃣ Keep it short

CLAUDE[.]md is loaded into every Claude Code session, so it consumes context.

My rule of thumb: Keep it under 200 lines.
Ideally, under 100.

For detailed documentation, use routing rules

5⃣ Be specific

Bad instruction: “Write clean code.”
Better instruction: “Use descriptive prop names, no abbreviations” and “Prefer composition over inheritance.”

The more precise your instructions are, the more deterministic Claude’s output becomes.

6⃣ Treat CLAUDE.md as a living document

Don’t create it once and forget it.

Update it when:
✅ Claude repeats the same mistake
✅ You introduce a new pattern
✅ Your product requirements change
✅ Your design system evolves
✅ Your team agrees on new rules

The best CLAUDE.md files are built from real usage, not theory.

7⃣Use [.]claude/rules for modular instructions

Instead of putting everything into one file, split rules by topic and then reference them from CLAUDE[.]md or directly in Claude Code chat.

This creates cleaner, more focused context.

8⃣ Commit CLAUDE[.]md to Git

Your project-based CLAUDE.md is part of your project infrastructure.

When you commit it to Git, the whole team gets more consistent AI behavior.

Complete guide 👇

My fav way to un-slop a codebase:

- find large files
- ask to break up, improve code quality, add tests
Once done, ask "now that you read the code, what can we improve?"
- store that in a tracker file (i use docs/refactor/*.md) and let the model pick
- do one by one

I'm Boris and I created Claude Code. I wanted to quickly share a few tips for using Claude Code, sourced directly from the Claude Code team. The way the team uses Claude is different than how I use it. Remember: there is no one right way to use Claude Code -- everyones' setup is different. You should experiment to see what works for you!

1. Do more in parallel

Spin up 3–5 git worktrees at once, each running its own Claude session in parallel. It's the single biggest productivity unlock, and the top tip from the team. Personally, I use multiple git checkouts, but most of the Claude Code team prefers worktrees -- it's the reason @amorriscode built native support for them into the Claude Desktop app!

Some people also name their worktrees and set up shell aliases (za, zb, zc) so they can hop between them in one keystroke. Others have a dedicated "analysis" worktree that's only for reading logs and running BigQuery

See https://t.co/yXde5dW1vZ

Claude Code tips that have made my life easier:

(Add these to your CLAUDE .md file)

1. "Before writing any code, describe your approach and wait for approval. Always ask clarifying questions before writing any code if requirements are ambiguous."

2. "If a task requires changes to more than 3 files, stop and break it into smaller tasks first."

3. "After writing code, list what could break and suggest tests to cover it."

4. "When there’s a bug, start by writing a test that reproduces it, then fix it until the test passes."

5. "Every time I correct you, add a new rule to the CLAUDE .md file so it never happens again."

The wording in the file is much more detailed than what I wrote above, but hopefully these show the spirit.