executive summary

How we run Adaptto on GitHub

And what we would set up in your team.

We are three AI-native founders. Two of us, Giuseppe and Raffaello, are non-technical, and one is technical. Agents do most of our writing and coding. We run the company on GitHub Enterprise: we plan, sell, build training content, run client software and track decisions there. Most of that work involves no code.

This summary assumes the basics of working on GitHub with Claude Code: branches, changes, review and merge. Our AI Builder course teaches those basics, and we can customise it so your team also learns the pro setup described here. Syllabus

Five things we do

1. The mental model: we set the priorities, agents map the work

The mental model is something Giuseppe came up with. You write your own short list of priorities for a project, in plain language, in one file. Each priority is a key item: what matters, its priority from P0 (blocking) to P3 (housekeeping), one owner and what done means. Then GitHub and the agents do the mapping. They find every open issue that belongs to each key item, and they flag what is untracked: open issues linked to no priority, priorities with no issue behind them, unassigned tasks and stale items.

People set the priorities from the top down. Agents keep the bottom-up reality of issues and pull requests reconciled against them, every night and whenever one of us runs our /check skill. They propose fixes as PRs and create nothing without a yes. It works for our two non-technical founders because we think in priorities, not tickets.

The tracker is not a separate tool. A GitHub Action turns the map and the issues into a live dashboard page, published privately with GitHub Pages, and we check every project from that link. The product we run for a lighting distributor has a go-live dashboard built the same way. In one nightly run, 16 of 19 open issues in a product repository were linked to no key item. Most of them formed one initiative the map did not have yet, and adding it was left to a founder.

example format: a key item

## P1 · Launch the partner program
**Owner:** Maria
**Done:** ten partners signed, each has run one webinar.

### Partner onboarding kit
<!-- refs: #212 website#41 -->
**Done:** kit published and used by three partners.

example format: the nightly tracker output

P1 · Launch the partner program    owner: Maria
   Onboarding kit       next: #212   assigned tonight: Maria
   Webinar series       STALE: #219, 16 days quiet
NOT LINKED TO A KEY ITEM: 5 of 14 open issues
   #233 New CRM field   no clear fit, needs a decision

2. Business knowledge lives in the repo, not only code

Each prospect and client has a folder in our sales repository. Right after a call, the transcript goes into that folder. An agent updates the call notes and the status file, and the same notes reach our CRM that day. Our ideal customer profiles are documents in the same repository, one per product line, and agents score new leads against them. Decisions go on issues. A question gets the type:topic label, and we close it with a comment that starts with "Decision:".

example format

sales/
├── docs/icp.md               ideal customer profile
├── pipeline/acme-distribution/
│   ├── status.md             stage, last contact, next action
│   ├── call-notes.md         dated notes, newest first
│   ├── 2026-09-11_call.txt   raw call transcript
│   └── proposals/
└── clients/globex-industrial/

3. The weekly report writes itself

Every Monday morning a scheduled job lists all our repositories and collects the week's merged PRs and commits. It groups them by business area using repository topics. A model writes one short line per area plus details, and every line keeps its exact PR number. The job counts contributions per person, marks each repository active or quiet, posts the report to our team chat and commits it to the planning repository. A rules file keeps it honest. Internal work is never described as shipped, links are checked against their source, and missed runs are announced at the top of the next report. A lessons file records what went wrong and what we changed.

preview of a real report, anonymized

Weekly digest · 7 to 13 September 2026sample weekly report (anonymized)
  • Tech Platform kill switches for email polling and request analysis 42 commits
  • Commercial a /bootcamp-recommend skill and a LinkedIn asset set 81 commits
  • Corporate Bootcamps a student projects showcase added to the map 42 commits
client-productfeat(admin): kill switches, with a banner users can read #2141 @founder3
client-productchore(model): triage #2083 into the Pricing key item #2129 @founder1
@founder1 77 · @founder3 55 · @founder2 33active 11 · quiet 15

See a sample weekly report

4. Agents draft, people decide

Every repository has a CLAUDE.md file that agents read before they start. The rules are short. Never commit to main. Work on a branch and open a PR. If a fact can't be checked, write "unknown, verify directly" instead of guessing. No work starts without an issue: when Raffaello needs a live session ready for a client cohort that afternoon, he opens one, a Claude Code agent adds it to the map in a small PR, and he merges it within minutes. On our training platform, a change goes to a staging site first and reaches the live site only when Raffaello approves it.

5. Customer feedback becomes GitHub issues automatically

In a product we run for a lighting distributor, every screen has a "Report an issue" button. Once a day a triage agent checks the new reports against the live system, read-only, and turns each one it can confirm into a GitHub issue. Agents label the issue and link it to a key item in the mental model. For the rest, the agent notes the missing evidence and one of us follows up.

The fix is a PR. It merges only when the automated tests pass and it adds an entry to the product's "what's new" page, or a written reason for skipping it. Merging to main deploys. When the issue closes, the customer's report is marked resolved.

What we set up with you in the first month

  • A GitHub organisation with one planning repository and one repository per team, with a folder template for every prospect and client.
  • Your first mental model: three to six key items, each with a priority, an owner and a definition of done.
  • The tracker: a live dashboard page built from your repositories and published with GitHub Pages, refreshed nightly and by /check, flagging unassigned, unlinked and stale work.
  • Issue and PR templates, a small set of labels, and a CLAUDE.md file per repository, with one agent taking small tasks through PRs.
  • The call habit: transcript and notes into the folder and the CRM the same day, and your ideal customer profile written down.
  • The weekly report and a lessons file. If you run software for customers, also a report button that files GitHub issues and checks before anything goes live.

The full playbook has the step-by-step plan, the checklists and the templates we use ourselves. AI Builder teaches the basics of working on GitHub with Claude Code, and we can customise it so your team learns the pro setup described here.

See the AI Builder syllabus