AI Collaboration Implementation Course: GitHub, Confluence, and Jira
Table of Contents
Build two complete AI collaboration workflows for developers, operations staff, and non-coding contributors. Carry one synthetic retention change through GitHub-first and GitHub with Confluence Cloud/Jira Cloud. Each track produces source records, review evidence, publication history, recovery records, and a fresh-session handoff.
What You Will Build
The fictional project is export-service-lab. Approved retention starts at seven days. Your proposal changes it to thirty days. No production data or deletion job is involved. The exercise tests authority and coordination, not compliance requirements.
| Track | Authoritative homes | Final artifact |
|---|---|---|
| GitHub-first | Repository policy, requirements, implementation, runbook | Reviewed PR, consistency log, Issue, handoff |
| Mixed workplace | GitHub implementation, Confluence requirement/runbook, Jira delivery | Fixed proposal and cross-system ledger |
This course implements the AI collaboration framework . The framework explains ownership. These lessons supply exact procedures, copyable policies, worked examples, verification, negative tests, troubleshooting, rollback, and exercises. Course policy choices are not vendor defaults.
Before You Begin
Who: contributor, product owner, operations owner, maintainer, and publisher. Assign people privately and use separate contributor/reviewer users for denial tests.
What and where: disposable GitHub repository, an approved coding/chat tool if desired, and dedicated Confluence/Jira Cloud sandboxes for Mixed. Python 3.10 or later runs the local lab without packages. Browser-only contributors ask the maintainer to run checks.
When and why: begin before attaching write-capable integrations. Reserve roughly 10 to 14 hours plus review across a one-week pilot. Finish GitHub-first before repeating the change in Mixed. The goal is reconstructable reviewed delivery, not agreement between two assistants.
Plan boundaries: GitHub protection depends on plan/visibility. Confluence Free lacks content restrictions. Jira Free lacks configurable permission schemes. Setup lessons explain the limits and provide official references. No particular paid chat connector, hosted coding agent, Rovo feature, or marketplace app is required.
Course Modules
| # | Lesson | Reader artifact |
|---|---|---|
| 1 | Pilot Foundation | Charter, authority register, policy, test matrix |
| 2 | GitHub Repository Setup | Source map, owners, protected boundary |
| 3 | Agent Adapters and Actions | Adapters, manifest, trusted-base check |
| 4 | Browser Contributions | Issue, reviewed PR, non-coder handoff |
| 5 | Confluence and Jira Setup | Authority pages and permission evidence |
| 6 | Cross-System Publication | Fixed proposal and publication ledger |
| 7 | Map-First Retrieval | Lookup procedure and optional RAG evaluation |
| 8 | Drift, Recovery, and Handoffs | Recovery decision and fresh verification |
| 9 | Retention Capstone | Two runs and independent acceptance |
How to Use It
- Approve the foundation before connecting tools.
- Complete modules 2 to 4 for coding-agent and browser/chat GitHub contribution.
- Complete modules 5 and 6 to preserve workplace authority across systems.
- Run modules 7 and 8 for discovery, drift, denial, recovery, and handoff.
- Deliver the capstone in both tracks and obtain independent review.
Keep each artifact for the next module. Lessons explain who acts, what changes, when to proceed, where evidence lives, why the control matters, and how to verify it. Worked examples are illustrative. Expected outcomes become observations only after your sandbox produces evidence.
Download the Lab
The synthetic lab archive contains baseline records, a Python validator, a runbook, and ten unit tests. Extract into an empty directory and follow module 1. It makes no network calls and requires no credentials.
The validator is not an approval service. It detects source-byte drift and inconsistent requirement, configuration, proposal, and runbook records. Live permissions, identity, owner approval, and external publication require separate course tests.
Completion Standard
| Case | Required demonstration |
|---|---|
| Approved change | Review and consistent publication read-back |
| Stale context | Changed base rejected |
| Unauthorized write | Contributor denied by platform controls |
| Conflict | Authority owner reconciles sources |
| Partial publication | Incomplete delivery remains visible |
| Access denial | Protected text absent from unauthorized task |
| Recovery | Reviewed completion or compensation |
| Handoff | Fresh session independently reads sources |
Completion requires observed evidence. Mark missing controls Blocked. Synthetic success supports another bounded pilot, not automatic production authorization.
Next Steps
Start with Pilot Foundation . After the capstone, review provider handling, runtime tests, secrets, deployment, and production access before selecting another pilot. Return to Courses and Playbooks for related study.
