Using custom commands to structure the Plan, Act cycle as a stable OODA loop in Claude Code

This post outlines my Claude Code Anthropic's command-line interface for Claude, designed for software engineering tasks Read more → workflow using custom commands User-defined command shortcuts that extend Claude Code functionality Read more → from ~/.claude/commands/, which loosely follows an OODA loop Observe-Orient-Decide-Act: a decision-making framework originally developed for military strategy, now used in business and development for rapid iteration cycles Read more → .

Sometimes I follow this approach really closely, especially for more complex things. Sometimes I don’t do any of this and just turn on auto-accept on a hot mic and spam msg after msg without a care in the world. All depends on context, per usual.

The workflow mostly hinges on the relationship between /analyze, /plan, and /act with a few supporting sidekicks. Let’s dig in now!

The File-Tree Based OODA Loop Flow

First step is observing and orienting to the project and context.

1. /prepare

Quick workspace orientation and context loading

# Prepare for Work
**Task**: $ARGUMENTS

Quick workspace prep - read the memory bank to get oriented, check current 
project status, then get ready to tackle whatever you need.

## Memory Bank Review
Reading ALL the memory bank files to understand where we are:
- projectbrief.md - What we're building and why
- activeContext.md - What's happening right now  
- progress.md - What's done and what's next
- systemPatterns.md - Architectural patterns and decisions
- techContext.md - Technologies, environment, and constraints
- .clauderules - Project patterns I've learned

## Git Status Check
Quick check of what's changed, staged, or needs attention in the repo.

2. /analyze

Deep codebase examination using subagents

# Analyze Code
Use a subagent to examine existing codebase and understand current 
implementation focused on: $ARGUMENTS

## Instructions
**IMPORTANT**: Launch a Task agent to handle this analysis. The agent should 
examine relevant files, identify patterns, and provide a clear technical 
explanation.

## Output Format
**Understanding:**
[Concise summary of what the code currently does and how it works]

**Files under review:**
[Tree structure showing relevant files and their purpose in the analysis]

3. /plan

Implementation roadmapping with file-level changes

# Plan Feature

Review the current codebase, analyze the user's request, and create a concise implementation plan.

**Task:** $ARGUMENTS

**Context Intelligence**: In the absence of explicit arguments, consider recent conversation history as context for guiding plan direction. For example, if recent messages discussed switching from alacritty to a simpler terminal launcher, receiving `/plan` with no args should convey: execute something like `/plan my previous instruction which was to reconfigure i3 to use simple term launcher instead of the newer alacritty launcher which has turned out buggier than hoped`.

## Instructions

1. **Quick Code Review**: Briefly examine relevant files to understand current implementation
2. **Request Analysis**: Parse the user's feature request to identify core requirements  
3. **Simple Understanding**: Reflect back a clear, concise summary of what needs to be built
4. **File Structure Plan**: Output a directory tree showing files to create, modify, or delete

## Output Format

```
## Understanding
[2-3 sentences summarizing what you'll build]

## File Changes
```
path/to/file.ext
├── [C] NewComponent.tsx - Brief description of new component
├── [M] ExistingFile.tsx - What changes will be made
├── [M] styles.css - Style updates needed
└── [D] OldFile.tsx - Why this file will be removed
```

## Legend
- [C] = Create new file
- [M] = Modify existing file  
- [D] = Delete file

Keep descriptions to one line. Focus on the essential file changes needed to implement the feature.

4. /elaborate

Detailed implementation specifications

# Elaborate Command
This command pairs with `/plan` to provide specific file-level implementation details.

**Usage**: `/elaborate [plan-context]`

## Instructions:
When the user runs `/elaborate`, provide VERY BRIEF explanations of the specific 
changes needed for each file mentioned in the most recent plan. Focus on concrete 
modifications rather than high-level strategy.

For each file, explain:
- What specific lines/sections need modification
- What exact content gets added/removed/changed
- Key implementation details (function names, CSS properties, etc.)

Keep explanations to 1-2 sentences per file. Be concrete and actionable.

5. /act

Execute planned changes

# Act Command
Execute the plan or insights that have been developed in the current conversation.

**Usage**: `/act [specific-focus]`

## Instructions:
When the user runs `/act`, immediately begin implementing the plan or acting on 
the insights discovered during the conversation. This transitions from planning 
to execution mode.

Key behaviors:
1. **Read the conversation context** - Review any plans, decisions, or insights from recent messages
2. **Use TodoWrite tool** - Create a todo list based on the plan if one doesn't exist
3. **Begin implementation** - Start making the actual code changes, file modifications, or other actions
4. **Work systematically** - Follow the plan step-by-step, marking todos as in_progress/completed
5. **Stay focused** - Don't ask for additional clarification unless absolutely necessary

Workflow Benefits

• Structured approach: Each phase has clear objectives
• Consistent process: Repeatable methodology across projects
• Better outcomes: Thorough planning reduces implementation errors

Implementation Example

# Typical workflow sequence
/prepare "new authentication system"
/analyze "current auth patterns"  
/plan "OAuth2 integration"
/elaborate "JWT token handling"
/act "implement auth service"

Reviewing Claude’s Work

To ensure the model stayed on track with the plan, I review the changes by visualizing a tree from the git status

git status --porcelain | awk '{print $2}' | tree --fromfile

This produces output like

.
├── data
└── site
    └── src
        ├── components
        │   └── WikiTooltip.astro
        ├── content
        │   └── blog
        │       ├── claude-code-workflow-commands.mdx
        │       └── cline-claude-code-integration.mdx
        ├── layouts
        │   └── Layout.astro
        └── styles
            ├── global.css
            └── WikiTooltip.css

9 directories, 6 files

Conclusion

Using custom commands like these can help to “keep the genie in the bottle” and standardize Claude’s non-deterministic outputs, helping to optimize for clarity, precision, and overall workflow efficiency.

This approach synergizes strongly with structured task-planning methodologies. I’m currently experimenting with letting Claude manage a GTD (Getting Things Done) workflow using an MCP server I’ve created, allowing me to operate from /capture and execute /plan next from captured tasks. This creates a seamless pipeline from idea capture to implementation planning to final execution and review.