The PR Workflow
Here's the recommended workflow for integrating decision patches into your PR process.
While Working on a Feature
Create nodes as you normally would:
$ deciduous add goal "Add OAuth login" -c 90 -p "User asked for OAuth" $ deciduous add decision "Choose OAuth provider" -c 75 ... continue working and logging decisions ...
Before Opening the PR
Step 1: Export Your Decisions
$ deciduous diff export \ --branch $(git rev-parse --abbrev-ref HEAD) \ -o .deciduous/patches/$(whoami)-$(git rev-parse --abbrev-ref HEAD).json Exported 12 nodes and 11 edges to .deciduous/patches/alice-feature-oauth.json
Step 2: Generate Visualization (Optional)
$ deciduous dot --auto --png --nodes 60-72 Generated docs/decision-graph-feature-oauth.png
Step 3: Commit the Patch and Graph
$ git add .deciduous/patches/ docs/decision-graph-*.png $ git commit -m "docs: add decision graph and patch for OAuth feature"
Step 4: Push and Create PR
$ git push -u origin feature/oauth $ gh pr create --title "Add OAuth Login" \ --body "$(deciduous writeup --auto -t 'Add OAuth Login' --nodes 60-72)"
For PR Reviewers
After pulling the branch:
$ git checkout feature/oauth $ git pull # Apply the patch to get the decisions in your local database $ deciduous diff apply .deciduous/patches/alice-feature-oauth.json Applied 12 nodes (12 new, 0 existing) # Now you can explore with TUI or web viewer $ deciduous tui
Reviewers now have full context on why decisions were made, not just what code changed.
After PR Merge
When the PR merges to main, teammates pull and apply:
$ git pull origin main $ deciduous diff apply .deciduous/patches/*.json Applied alice-feature-oauth.json: 12 nodes (12 new) Applied bob-refactor.json: 8 nodes (8 existing, already applied)
Because patches are idempotent, teammates who already applied a patch (during review) won't get duplicates.
Continuous Application
Some teams add this to their workflow (e.g., in a git hook or CI):
# After every pull, apply all patches $ git pull && deciduous diff apply .deciduous/patches/*.json
This ensures everyone's local database stays in sync.
Complete Example Timeline
| When | Who | Action |
|---|---|---|
| Day 1 | Alice | Creates nodes while implementing OAuth |
| Day 2 | Alice | Exports patch, opens PR |
| Day 2 | Bob | Reviews PR, applies patch to understand context |
| Day 3 | Alice | Addresses review feedback, updates patch |
| Day 3 | Bob | Re-applies patch (idempotent), approves PR |
| Day 3 | - | PR merges |
| Day 4 | Carol | Pulls main, applies patches, has full context |
Best Practice
Name patch files descriptively: <author>-<branch>.json. This makes it clear who created the patch and what it's for.