The Complete Workflow

A real BACON-AI scenario from start to finish — from "I have an idea" to "the feature is live".

The scenario

Feature request

Colin wants to add physics controls to the BACON Mesh Hub. Right now the agent nodes float around with a fixed layout. He wants sliders that let users adjust the gravity, repulsion, and link distance in real time.

Here is how this feature moves from idea to production, step by step. Each step maps back to the concepts from the previous pages.

Step-by-step walkthrough

1

Create a branch

The developer (or Claude Code) creates a new branch called feature/physics-controls based on the current develop branch. This is a safe copy of the project to work on. 

"Create a new branch called feature/physics-controls from develop"
2

Create a worktree

To work on this feature without disrupting the main workspace, a worktree is created. This puts the new branch in its own folder at .worktrees/feature-physics-controls/. 

"Create a worktree for the physics-controls feature"
3

Do the work

The developer works inside the worktree folder, making changes:

  • Creates a PhysicsPanel.ts component with sliders
  • Modifies ForceLayout.ts to accept dynamic parameters
  • Updates the sidebar to include the new controls

Meanwhile, the main workspace on develop is untouched. Other features can be developed there simultaneously.

4

Commit the changes

As work progresses, the developer saves checkpoints (commits) with descriptive messages: 

"Commit with message: feat: add physics control panel with force sliders"

Multiple commits might be made as different parts are completed.

5

Push to GitHub

The branch is uploaded to GitHub so others can see it and the automated tests can run. 

"Push this branch to GitHub"
6

Open a Pull Request

A PR is created on GitHub, requesting to merge feature/physics-controls into develop. The PR includes a description of what was built, screenshots of the new panel, and testing notes. 

"Create a PR to merge this into develop"
7

Review and feedback

Colin or another team member reviews the PR. They might:

  • Approve it right away if everything looks good
  • Request changes ("Can you add a reset button for the sliders?")
  • Ask questions ("Why did you choose these default values?")

If changes are requested, the developer makes them, commits, and pushes again.

8

Merge

Once approved, the PR is merged. The physics controls are now part of the develop branch and available to everyone.

9

Clean up

The feature branch is deleted (it served its purpose) and the worktree folder is removed to keep the workspace tidy. 

"Clean up the physics-controls worktree and delete the branch"

The full process as a diagram

flowchart TB A["Idea: Add physics controls"] --> B["Create branch\nfeature/physics-controls"] B --> C["Create worktree\n.worktrees/physics/"] C --> D["Build the feature\nPhysicsPanel.ts, ForceLayout.ts"] D --> E["Commit changes\nfeat: add physics panel"] E --> F["Push to GitHub"] F --> G["Open Pull Request"] G --> H{Review} H -->|Changes needed| I["Make fixes"] I --> E H -->|Approved| J["Merge into develop"] J --> K["Delete branch + worktree"] K --> L["Feature is live!"] style A fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0 style B fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0 style C fill:#1e2a4a,stroke:#ffab40,color:#e0e6f0 style D fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0 style E fill:#1e2a4a,stroke:#00e5ff,color:#e0e6f0 style F fill:#1e2a4a,stroke:#448aff,color:#e0e6f0 style G fill:#1e2a4a,stroke:#448aff,color:#e0e6f0 style H fill:#141a2e,stroke:#ffab40,color:#e0e6f0 style I fill:#1e2a4a,stroke:#ff5252,color:#e0e6f0 style J fill:#1e2a4a,stroke:#00e676,color:#e0e6f0 style K fill:#1e2a4a,stroke:#8892a8,color:#e0e6f0 style L fill:#141a2e,stroke:#00e676,color:#00e676

The complete lifecycle of a feature: from idea to live code. The review loop (steps 7-4) may repeat multiple times until the work is approved.

What happens behind the scenes

sequenceDiagram participant C as Colin (stakeholder) participant D as Developer / Claude Code participant G as GitHub participant T as Automated Tests C->>D: "I want physics controls for the mesh" D->>D: Create branch + worktree D->>D: Build feature (commit, commit, commit) D->>G: Push branch D->>G: Open PR with description G->>T: Run automated tests T-->>G: Tests pass G->>C: "New PR ready for review" C->>G: Review changes C->>G: "Looks great, approved!" D->>G: Merge PR G-->>G: Feature merged into develop D->>D: Delete worktree + branch D->>C: "Physics controls are live on develop"

The interaction between stakeholder, developer, GitHub, and automated testing during a typical feature development cycle.

Decision guide: when to use what

mindmap root((I need to...)) Fix a bug Create a fix/ branch Use a worktree if urgent Open a PR when done Add a feature Create a feature/ branch Use a worktree for isolation Open a PR for review Experiment Create any branch Use a worktree to keep main clean Delete if it does not work out Release Merge develop into main Tag the version Deploy

A quick decision guide: what Git actions to take based on what you need to accomplish.

Questions a stakeholder might ask

"What is the status of the physics controls feature?"
Check if the PR is open, in review, or merged. The developer can tell you which step of the workflow they are on.
"Can I see the feature before it goes live?"
Yes! The worktree has a working version. The developer can run it locally for a demo, or you can review the changes in the PR on GitHub.
"Is it safe to add this feature now?"
Yes. The feature is on its own branch, so it cannot break the live version. It only enters develop after passing review and automated tests.
"How long until this is deployed?"
After the PR is merged into develop, it needs to go through one more merge (develop into main) before deployment. Ask the developer for the timeline.

Key takeaways

The complete workflow in one sentence:

Create a branch, optionally create a worktree, do the work, commit and push, open a PR, get it reviewed, merge it, clean up.