GitHub for
collaboration and
agent-supported work.

Git helps software teams collaborate.

One application. Several contributors. A shared result.

What changed? Who checked it? Which version should go live?

Git records history. GitHub connects the team.

Git / on your computer

Local Git history / invoicing-app

Check reminder timingLatest recorded version

Add reminder schedulingThe feature takes shape

Accepted starting versionBefore the new feature

Selected file versions, recorded over time.

GitHub / online

Shared repositories, review, and collaboration.

Left: illustrative local history. Right: actual AIBL template on GitHub.

One software feature moves through a shared cycle.

A subscription invoicing service adds automatic overdue-payment reminders.

The wider GitHub platform.

A map of capabilities, not a checklist to learn. Availability varies by plan and setup.

From repository to running application.

A VPS is a rented computer. Coolify can manage app deployment onto it.

Coolify documentation example: GitHub connection and repository selector.

GitHub repository > retrieve and build > VPS runs app > customer

A configured connection enables deployment. A push alone does not run an app.

Connect GitHub, choose the repository, configure the app, then deploy.

Agent work follows the same cycle.

Next: watch one client brief move through the cycle.

Give the agent context. Agree on the plan.

After agreement, ask the agent to save the plan in the project.

The agent creates the work in your project.

The conversation directs the work. The project holds the files.

One deliverable can produce many files

context/brief.md
plan.md
research/source-notes.md
methods.json
scripts/render_brief.py
tests/test_render_brief.py
output/client-brief.html

def build(data, destination):
    destination.parent.mkdir(
        parents=True, exist_ok=True
    )
    destination.write_text(
        render_brief(data)
    )

Context, inputs, code, tests and output belong to one project.

Editor-style illustration / fictional project / code from the teaching example

Run checks on the code and its output

Check the reported result and what the tests actually cover.

Illustrative activity summary / four tests executed on the fictional teaching example

Review the result. Guide the next version.

Producing a draft, accepting it, and sending it externally are different decisions.

GitHub through the Workforce experience

Begin with your workbench.

Add the course.

Do a real piece of work.

Choose where the next project belongs.

AIBL Workforce course artwork / Studio launch asset

How Workforce reaches your workbench

Setup creates the home. Enrollment brings course materials into it.

Conceptual flow. The course-provided route must match the installed setup.

Find the course inside your local workbench

Does this project need its own repository?

A folder organizes work. A repository gives the project its own history and access settings.

Small task: a folder inside my-workbench

One repo. Shared history. A clearly named folder for the task.

Independent project: start from the template

Fresh project context and history. Future template changes do not sync automatically.

What follows you into a new project?

Project tools stay with that project. Shared tools can follow you.

Scope is specific to the app, user and machine. Verify what the session actually loads.

GitHub through the Camp experience

AGENT NATIVE CAMP

Start with your existing system.

Your agent and memory.

Your OS repository.

Your separate project work.

Camp artwork from the AIBL Studio design system.

The agent runs. Your repositories hold the work.

Git records selected repo files. It does not capture every running service or memory record.

Example topology. Names, hosts and storage paths depend on the student's existing system.

Camp sources inform your own system and projects

The course is a reference. Your personalized work belongs in your own repos.

Camp: separate homes on your computer

Camp: a system change or a separate project?

Review runtime and memory changes in their own layer, whichever repo holds the notes.

System work stays with the OS context

Example: revise a standing preference or add the location of a new project.

New project, alongside the existing system

Carry a useful structure forward. Establish new facts, methods and permissions.

Shared capabilities and project-specific capabilities

General writing preference
Reusable agent role
Shared skill
Configured guard hook

Client-specific instructions
Project reviewer role
Research method + sources
Project build/check hook

A skill is a procedure. An agent is a role. A hook runs on an event.

Where shared and project capabilities live

agents/
  reviewer.md
skills/
  writing-review/SKILL.md
settings.json
hooks/
  check-command.sh

agents/
  client-reviewer.md
skills/
  client-brief/SKILL.md
settings.json
hooks/
  check-output.sh

settings.json connects hooks to events. A hooks folder alone does not activate them.

Claude Code example / ~ means your home folder / dot-folders are often hidden / other apps use their own layouts

Updates follow the destination and the layer

Preview changes, resolve overlapping edits, then verify the result.

Ignored files, local learning state and memory databases need separate backup handling.

Two starting points. The same ownership decisions.

Know the source, choose the destination, and review what changes.

Understanding Git mechanics and jargon

Next: understand what your agent is doing with the files.

A recorded history for the whole project

Record related changes together, then review the proposed result.

One folder or parallel folders?

Both use branches. A worktree adds a separate working folder.

Illustrative folder view. Branch names are annotations, not extra folders.

Send checkpoints online. Jargon: push.

Loose edits are not sent just because a push succeeds.

Three tasks. Three working folders.

A branch separates a line of changes. A worktree gives it a separate folder.

Three worktrees, three sets of working files

CLAUDE.md
context/
research/
scripts/
tests/
output/

CLAUDE.md
context/
research/
scripts/
tests/
output/

CLAUDE.md
context/
research/
scripts/
tests/
output/

Each folder has the tracked project files. All three share repository history.

Ordinary full checkouts shown. Ignored files and local settings are not automatically copied.

When to pause.

1. Two edits disagreePreserve both versions and ask what should be kept.
2. The destination is unclearConfirm the repository and who can access it.
3. An import replaces your instructionsInspect ownership and reconcile before accepting.
4. Permissions are uncertainAsk for the decision the agent cannot infer.

Two valid edits can disagree

Both changed the same sentence. Git cannot choose the business priority.

Give the agent a decision, not just "fix it"

Choose the intended outcome. Claude or Codex can make the file changes.

Review the resolution and finish the integration

A resolved file is not the same as an accepted, merged or published result.

The agent says "done". Is your intended result done?

Ask: what is complete, what remains, and what evidence shows it?

Course sources and your repositories

Course clone: read-only reference
OS/context repo: your system
Project repos: your own work

Template starts my-workbench
Program student branch adds course
Reviewed merges bring updates

Keep course sources, student ownership and runtime state distinct.

September 21 source snapshot. Earlier package and course-derived routes remain separate.