GitHub Collaboration Model

Purpose of This Section

This document describes how collaboration between the human operator and the assistant is structured using GitHub. The goal is to enable productive cooperation while preserving reviewability, accountability, and control. GitHub is not treated merely as a code hosting platform but as a governance surface — a place where intent, work, and approval are made explicit and where the boundary between the assistant’s authority and the human’s authority is enforced by workflow rather than by trust.

Collaboration as a Design Concern

In many AI-assisted workflows, collaboration is implicit. The assistant writes directly into the human’s repositories, often using shared credentials or elevated access. This is convenient, but it collapses boundaries and obscures authorship. When a commit appears under the human’s identity, there is no reliable way to determine whether the human wrote it, the assistant wrote it, or some combination of the two produced it. Attribution becomes ambiguous, and ambiguous attribution undermines accountability.

This architecture rejects implicit collaboration in favor of explicit, reviewable workflows. Every modification proposed by the assistant must be attributable to the assistant’s own identity, inspectable before it takes effect, reversible if it proves incorrect, and explicitly accepted by the human before it enters any protected codebase. These are not aspirational properties — they are enforced by the structure of the GitHub workflows described below.

Dedicated Shared Organization

Collaboration occurs within a dedicated GitHub organization created solely for human–assistant work. The organization has exactly two members: the human and the assistant. The human is the sole administrator. The assistant holds regular member privileges with no administrative access. All repositories within the organization are private by default.

The organization serves as neutral ground. It is not the human’s personal space, where the assistant would be a guest with borrowed access, nor is it the assistant’s own space, where the human would lack administrative control. It is a shared workspace governed by the same separation of authority that runs through the rest of this architecture: the human controls the structure, the assistant contributes within it.

Separation from Personal Repositories

The human’s personal GitHub account and repositories remain isolated from the collaboration space. The assistant may be granted read access to selected human repositories when that access is needed for a specific task, but it holds no direct write access to any human-owned repository and cannot merge changes into one.

When the assistant needs to modify a human-owned project, the workflow is explicit. The assistant forks the repository into the shared organization, performs its work within the fork, and opens a pull request back to the human’s repository. No changes cross identity boundaries without the human reviewing and accepting them. This is the same workflow used by open-source contributors who lack commit access to an upstream project, and it is employed here for the same reason: it makes collaboration possible without granting trust that has not been earned.

Pull Requests as Governance

Pull requests are the primary mechanism through which the assistant’s work enters the human’s codebase. A pull request represents a proposed change, a rationale for that change, a surface for review, and a decision point where the human accepts or rejects the proposal. Nothing enters a protected branch without passing through this gate.

This approach mirrors established professional software workflows and has the advantage of being well-understood, well-tooled, and inherently auditable. Every pull request produces a permanent record of what was proposed, what discussion occurred, and whether the change was accepted. That record is available for post-incident analysis, for understanding the history of a decision, or simply for the human to review what the assistant has been working on.

Project and Issue Tracking

GitHub Projects and Issues are used within the shared organization to coordinate work and capture intent. Issues represent tasks or problems. Projects represent ongoing initiatives. Status changes reflect actual progress rather than aspirational planning.

This creates a shared, persistent record of what is being worked on, why it matters, and what remains unresolved. The assistant uses these tools to organize its own work and to communicate priorities and progress to the human. It does not use them to self-assign authority — creating an issue does not grant permission to act on it, and moving a task to “in progress” does not bypass the review requirements that govern all changes.

No Silent Changes

The assistant is not permitted to push directly to protected branches, modify repositories without an associated issue or task, or make changes that bypass review. Any attempt to do so is treated as a violation of collaboration rules and triggers intervention. This constraint may occasionally slow the assistant’s throughput, but it ensures that the human is never surprised by changes they did not review. In a system where trust is maintained through visibility, surprise is the more expensive outcome.

Auditing and Attribution

Because all work occurs under distinct identities — the human’s GitHub account and the assistant’s GitHub account — authorship is unambiguous. Activity logs are meaningful because they reflect who actually performed each action. Responsibility can be assigned accurately after the fact, which is essential both for ongoing trust and for post-incident analysis. If something goes wrong, the question of “who did this” has a clear answer.

Failure and Recovery

If the assistant’s GitHub account is compromised, the human can remove it from the organization immediately. All repositories remain intact, and no personal repositories are affected, because the assistant never held write access to them. Recovery involves creating a new account for the assistant and re-establishing collaboration under the same organizational rules. The assistant’s GitHub identity, like all its identities, is designed to be disposable — replaceable without loss of the underlying work or the governance structure that surrounds it.

Summary

By structuring collaboration through a shared GitHub organization, fork-based workflows, and pull request gating, the architecture achieves strong separation of authority, clear audit trails, and low-friction collaboration without silent risk. GitHub becomes not just a tool for hosting code, but the primary mechanism through which the coworker model is operationalized in day-to-day software work.

This document defines how work is proposed, reviewed, and accepted. Subsequent sections extend these principles to memory, documentation, and long-term auditability.