Starting Work on an Issue

Everything before this was retroactive. Now you log decisions as they happen, and Claude drives the commands.

In the Reconstructing History section, Claude looked backward—reading commit logs and inferring decisions that had already been made. Live development is the opposite. You give Claude a task, and it logs the decisions before writing any code. The graph grows forward in real time.

The key dynamic: you provide the direction, Claude operates the tooling. You never need to remember a deciduous command. Claude reads the instructions in your CLAUDE.md and knows exactly when and how to log each step.

The /work Skill

The /work skill is how you tell Claude to start a tracked work session. It creates a goal node with your verbatim request before doing anything else. Let's watch it work on GitHub issue #93: adding CI pipelines for snowflex.

Claude Code — /work on issue #93
❚❚
Animation paused
You
Add support for running tests in CI/CD. We need GitHub Actions workflows for both unit tests and integration tests. See issue #93.
Claude
I'll start by logging this as a goal in the decision graph, capturing your full request.
Claude
deciduous add goal "Add CI pipelines for snowflex" -c 90 --prompt-stdin << 'EOF' Add support for running tests in CI/CD. We need GitHub Actions workflows for both unit tests and integration tests. See issue #93. EOF
Created node 57 (type: goal) [confidence: 90%] [prompt: 167 chars] [branch: deciduous]
Claude
Now let me explore the options. There are two main approaches for structuring CI workflows—I'll log both before choosing.
Claude
deciduous add option "Separate CI workflow files for unit and integration tests" -c 80
Created node 58 (type: option) [confidence: 80%]
deciduous link 57 58 -r "possible approach"
Created edge 67 (57 → 58 via leads_to)
Claude
deciduous add option "Single CI workflow with test tagging and conditional execution" -c 75
Created node 59 (type: option) [confidence: 75%]
deciduous link 57 59 -r "possible approach"
Created edge 68 (57 → 59 via leads_to)
Claude
Separate files give clearer separation of concerns and easier contributor onboarding. New contributors can see at a glance which workflow does what. I'll go with that approach.
Claude
deciduous add decision "Use separate workflow files - clearer separation, easier contributor onboarding" -c 85
Created node 60 (type: decision) [confidence: 85%]
deciduous link 58 60 -r "chosen"
Created edge 69 (58 → 60 via leads_to)
Claude
Goal, options, and decision are recorded. The graph now shows: goal #57 leads to two options (#58, #59), and option #58 leads to decision #60. I'll start implementing.

What Just Happened

In under a minute, Claude built the first layer of the decision graph for this work session. The node flow follows the canonical pattern:

goal #57 → option #58 / option #59 → decision #60

Notice the order: goal first, then options, then decision. Options come before the decision, not after. The decision records which option was chosen and why.

Capturing the Verbatim Prompt

The --prompt-stdin flag on the goal node is critical. It stores your exact request word-for-word, not a summary. This matters because when a future session needs to recover context, the verbatim prompt tells Claude exactly what the user originally asked for.

Two ways to capture prompts
# Short prompts: use -p flag deciduous add goal "Fix login bug" -c 90 -p "The login page crashes on Safari" # Multi-line prompts: use --prompt-stdin deciduous add goal "Add CI pipelines" -c 90 --prompt-stdin << 'EOF' Add support for running tests in CI/CD. We need GitHub Actions workflows for both unit tests and integration tests. See issue #93. EOF

Claude chooses between -p and --prompt-stdin automatically based on prompt length. Short one-liners get -p. Anything multi-line or longer than a sentence gets --prompt-stdin with a heredoc.

Prompts are for root goals and redirections

Not every node needs a stored prompt. Downstream nodes (options, decisions, actions) inherit context through their edges back to the goal. Only capture prompts on root goal nodes and when the user significantly changes direction mid-session.

The Node Flow Rule

Deciduous enforces a canonical flow through the graph:

Step Node Type Issue #93 Example
1. What are we trying to do? goal #57: "Add CI pipelines for snowflex"
2. What approaches exist? option #58: Separate workflows / #59: Single workflow
3. Which approach do we take? decision #60: "Use separate workflow files"
4. Build it action (next page)
5. What resulted? outcome (next page)
6. Need to reconsider? revisit "Reconsider ODBC transport strategy"

Goals lead to options. Options lead to decisions. Decisions lead to actions. Actions lead to outcomes. Observations attach anywhere relevant. Revisit nodes connect old approaches to new ones when the team changes direction — they are the pivots in your project's story. Claude follows this flow automatically because the CLAUDE.md instructions spell it out. You don't need to direct the graph construction—just describe what you want done.

Forward logging vs. archaeology

Archaeology reconstructs decisions from evidence. Forward logging captures decisions as they happen. The graph structure is identical—same node types, same edges, same flow. The difference is timing: archaeology backdates nodes with --date and --commit; forward logging captures the present moment automatically.