The AI Assistant Workflow

Watch how your AI assistant logs decisions in real-time as it builds a feature. This is what deciduous looks like in practice.

A Complete Session: Adding Rate Limiting

Here's an actual Claude Code session where a user asks for rate limiting. Watch how Claude logs the goal, considers options, makes decisions, and tracks the outcome—all in real-time.

What Just Happened

Let's break down the five key patterns you saw:

1. Log the Goal First

Claude immediately creates a goal node with -p to capture the user's original request:

deciduous add goal "Add rate limiting" -c 90 -p "User asked: ..."

The -p flag captures the prompt that triggered this work. This is crucial for future context recovery—when a new session starts, Claude can see exactly what the user originally asked for.

2. Decisions Before Code

Before writing any code, Claude logs the decision point and the options being considered:

deciduous add decision "Choose rate limiting strategy" -c 75
deciduous add option "Redis-based with sliding window" -c 80
deciduous add option "In-memory with token bucket" -c 70

This captures the reasoning before it happens, when the context is fresh. The options exist in the graph even if they're not chosen.

3. Mark the Chosen Path

When Claude picks an approach, it uses the chosen edge type:

deciduous link 48 51 --edge-type chosen -r "Redis already in stack"

This makes it clear which option was selected and why. The rationale lives in the edge, not just a comment.

4. Link Commits to Outcomes

After committing, Claude links the outcome to the git commit:

deciduous add outcome "Rate limiting working" -c 95 --commit HEAD

This creates traceability between decisions and code. You can trace any commit back to the goal that spawned it.

5. Sync Before Push

Finally, deciduous sync exports the graph for the web viewer:

deciduous sync

The Complete Decision Chain

After this session, the graph looks like this:

    #47 [goal] Add rate limiting to API
        │
        │ leads_to: "Deciding implementation approach"
        ▼
    #48 [decision] Choose rate limiting strategy
        │
        ├────────────────────┬────────────────────┐
        │                    │                    │
        ▼                    ▼                    ▼
#49 [option]       #50 [option]       #51 [action]
Redis sliding      In-memory          Implementing Redis
window             token bucket       rate limiter
                                              │
                                              │ chosen
                                              ▼
                                      #52 [outcome]
                                      Rate limiting working
                                      [commit: abc123]

Anyone (human or AI) can now query this to understand:

• What was the goal?
• What options were considered?
• Why was Redis chosen over in-memory?
• Where is the code? (commit abc123)

Mid-Stream Direction Changes

Sometimes the user changes direction during implementation. Here's how Claude captures that:

The -p flag on the new action captures the exact moment the user redirected. This preserves the context of why the approach changed mid-stream.

The Workflow Summary