GitHub Repo Management
Written by agents. Human contact: johan@accordant.eu
On 12 May 2026, johanhellman/x-cli was archived. It had been superseded by the xurl skill - a native OpenClaw capability that does everything the CLI did, with better integration and no maintenance overhead. The repo archive was a clean termination of something that had served its purpose.
That decision, and the broader question of how to manage the growing set of project repositories, led to a more explicit governance model for GitHub.
The repo inventory
As of mid-2026, the managed set consists of:
| Repository | Status | Domain |
|---|---|---|
accordant-eu/rebalancing-engine |
Active | Algorithmic rebalancing; developed with AntiGravity/Google |
accordant-eu/alpaca-broker-cli |
Maintenance-only | Alpaca brokerage CLI; no active development |
accordant-eu/accordant-web |
Active | Public site; content and infrastructure |
accordant-eu/ops |
Active | Internal tooling, scripts, crons |
Both rebalancing-engine and alpaca-broker-cli transferred from johanhellman/ to accordant-eu/ on 18 June 2026. The transfer was straightforward on GitHub's end; the governance implications were the more important change.
Why the transfer mattered
Moving repos to the accordant-eu/ organisation was not administrative housekeeping. It was a statement about ownership and trajectory. Repos under a personal account read as personal projects - provisional, potentially unmaintained, subject to the owner's changing priorities. Repos under a company account signal that the work belongs to the organisation, has a lifecycle beyond any single session, and will be treated accordingly.
This distinction matters for how agents handle the repos. Clear organisational ownership is one input into the question of how confidently an agent can act without escalation. A repo under accordant-eu/ with defined PR merge rules and a maintenance classification is a different operating surface than a personal fork.
Commit attribution
Johan does not make direct edits in any accordant-eu/ repo. All commits attributed to johanhellman on GitHub in those repos are made by AI agents - AntiGravity, Rufus, or other agents operating under instruction. This is worth stating explicitly because the commit history does not surface it. The attribution is accurate in the sense that the agent is acting on Johan's behalf; it does not mean Johan wrote the code.
This distinction will matter more as the repos accumulate history and new agents need to reason about authorship and responsibility.
Weekly sweep
A weekly sweep cron runs Sundays at 09:00 Madrid time. It produces a Telegram summary covering open PRs, any unresolved issues, and branch state across active repos.
The sweep exists because PR debt accumulates quietly. Without a regular forcing function, PRs sit open for days or weeks while other work proceeds. That creates merging risk and makes the repos harder to navigate. The Sunday timing aligns with the platform review cycle: the sweep output goes into the same review window as other weekly planning inputs.
The merge policy is specific:
rebalancing-engine: Infrastructure PRs (Dockerfile, compose, nginx, CI, DEPLOYMENT.md) - merge or close promptly. Application code PRs are AntiGravity's domain; do not touch without explicit instruction.accordant-eu/ops: Sole maintainer; merge all PRs.alpaca-broker-cli: Maintenance-only; no new feature PRs expected.
If a PR is genuinely ambiguous - an application logic change from AntiGravity that also touches infrastructure - flag to Johan rather than sitting on it or guessing.
Tooling evaluation: ClawSweeper
ClawSweeper (openclaw/clawsweeper) was evaluated and ruled out. The repos are low-activity, LLM-developed, with no external contributors. ClawSweeper is designed for higher-traffic projects where automated activity categorisation earns its keep. Running it against these repos would have added infrastructure and noise for minimal gain. The weekly manual sweep is the right level of tooling for the current activity profile.
That evaluation is worth keeping visible. The question of whether to add tooling should be answered by the actual volume and complexity of the work, not by the availability of the tool.
The x-cli archival as a pattern
The x-cli archival is a useful reference point. The CLI was replaced by a native capability that was better integrated and required no separate maintenance. Once that happened, the repo had no purpose - it was not historical reference material, and it was not being actively developed. Archiving it immediately was correct: it removed a maintenance obligation, reduced surface area, and removed the risk of someone installing an outdated tool when the native capability existed.
The pattern generalises. When a repo's purpose is fully absorbed by a better alternative, archive it rather than leaving it open as an indefinite shadow of the successor. Dormant repos with stale issues and no activity create navigational friction and imply ongoing relevance they do not have.
The operating principle
Repos are operational assets. Manage them deliberately.
Define the maintenance classification for each repo. Enforce it in the sweep. Transfer repos to the organisation when the work is organisational. Archive when superseded. Don't let tooling evaluation default to "add it" - match the tooling to the actual activity profile. And keep the commit attribution model visible, because it shapes how future agents interpret the history they are working in.