Walkthrough for connecting your AI tool to a staging branch + safe promotion flow, once initial GitHub + Noibu MCP setup is already done.

Prerequisite

• GitHub is connected to you AI harness (Claude, Codex, MS Copilot) and is authorized on the repo, including the write-approval setting: reads auto-approved, writes need approval.

  Nothing below changes this setting; merges still require human review.

• To connect Github to your AI harness please follow these steps first:

  • Connecting GitHub to Claude

  • Connecting GitHub to OpenAI Codex

  • Connecting GitHub to Microsoft 365 Copilot Cowork

Setup

Two phases:

• One-Time Setup (done once)

• Recurring (repeated for every future fix).

At a glance

One-Time Setup

Do these two steps once, the first time a client gets a staging environment. Never repeated.

Step 1: Create the staging branch

Applies to any platform.

Manual:

• Via GitHub Desktop: check out main, Fetch origin → Branch → New Branch → name it staging → Create Branch → Publish branch.

• Via GitHub.com: repo → branch dropdown (shows "main") → type staging → Create branch: staging from main.

Or prompt you AI Tool:

"Create a branch called staging off main in [repo]."

The GitHub MCP connector can create the branch directly. Pick whichever route fits how the client works.

Step 2: Connect staging to a previewable environment (Shopify)

1. Shopify admin → Online Store → Themes

2. Theme library → "Add theme" → Connect from GitHub

   ⚠ May show as "Import" on some Shopify versions; verify live rather than assuming either label.

3. Select the repo → pick the staging branch (not main).

4. Confirm a new draft theme was created. Do not publish it. Leave it as draft/preview.

Notes:

• Not AI-promptable: no GitHub API call creates a platform preview environment. This connection only exists in Shopify's own UI.

• On a different platform (not Shopify)? The equivalent action is whatever that platform uses to preview a branch before it's live, e.g. a per-branch preview deployment (Vercel, Netlify), or a custom staging environment via CI/CD. Confirm the exact click-path with the client's dev team; the steps above won't apply as-written.

At the end of setup: staging is an exact copy of main, connected to its own draft theme. Nothing live has changed. Setup is done. Everything from here happens in the Recurring section, every time a new fix comes up.

Recurring: Every Fix, From Here On

Repeat this full 3-step cycle for every individual fix, indefinitely, once setup above is done.

Step 1: Open a fix branch, PR it into staging

Manual:

1. From staging (make sure it's up to date; Fetch origin first), create a new branch named for the fix, e.g. fix/checkout-button-error.

2. Make the change, commit, push.

3. Open a PR on GitHub: base = staging, compare = your fix branch.

Or prompt you AI Tool:

"Investigate [issue] and open a PR with the fix. Target branch: staging."

The GitHub MCP connector can create the fix branch and open the PR directly. Remember to always name staging as the target branch in the prompt (see the Safe Practice note below for why).

Step 2: Test the fix in the preview environment (Shopify)

1. Shopify admin → Online Store → Themes

2. Find the draft theme connected to staging in the theme library.

3. Click Preview.

4. Walk through the affected page/flow and confirm the fix works and nothing else broke.

Notes:

• Not AI-promptable by default: Your AI tool cannot natively view a rendered preview page. If you also have a browser-capable connector (e.g. Claude in Chrome) set up, the AI tool could navigate to the preview and check visually.

• On a different platform? Same idea: open whatever preview URL/environment that platform generates for the branch, and manually walk through the affected flow there.

Step 3: Promote staging → main

This is the actual deploy: main is the branch tied to what's published.

Both routes below are valid. Pick whichever fits how the team works:

Manual (GitHub UI):

1. Open a PR: base = main, compare = staging.

2. Review and merge.

Or prompt you AI Tool:

"Open a pull request from staging into main in [repo]. Don't merge it; I'll review and confirm first."

Then, once reviewed:

"Looks good, go ahead and merge it."

Same write-approval guardrail as the original setup applies here: your AI tool can open/update the PR freely, but merging is a separate, confirmed step, never something the AI does on its own initiative.

Then the cycle repeats. Next fix starts back at Recurring Step 1, cutting a new branch off staging (which is now back in sync with main).

Important Notes

Clarification: do you create a new staging branch every time, or reuse it?

staging is a permanent branch, created once in One-Time Setup and reused forever after (same as main). It's never deleted or recreated. What is new each time is the fix branch in Recurring Step 1: that one's short-lived, created fresh per fix, and only ever merges into staging (never main directly).

• Why not commit fixes directly onto staging? If the AI or a dev pushes commits straight onto staging with no branch/PR of its own, you lose the ability to review, isolate, or revert one specific change, especially with more than one fix in flight. The PR is what makes a change a reviewable, revertable unit.

• Recommended cadence: run Recurring Step 3 (promote to main) immediately after each fix is verified in Step 2, rather than batching multiple fixes on staging before promoting. This keeps "one fix per PR" discipline intact through the deploy step too, and means staging and main are back in sync after every promotion.

• Batching several verified fixes before promoting is possible but adds risk (harder to isolate which change caused an issue if something looks off post-deploy). Steer the client away from this unless they have a specific reason, like a release-train cadence.