My top 3 tools for multi-repository projects

I. What should survive a change of coding environment?

By Marcel Kombächer · Marcel’s Top 3, part 2

The previous article covered my favourite coding environments. This time, I am looking at what should not disappear when I switch between them: open tasks, useful working methods and the decisions behind the code.

Especially when a project spans several repositories, I do not want to piece those things together from individual chats. These three tools are my favourites for that job. They are complementary, with a clear division of responsibilities.

II. Beads: my tasks should not live inside the coding app

Beads, by Steve Yegge, is task management for coding agents. Its command-line tool is bd; the current system stores tasks, status and dependencies in a versioned Dolt database.^[1][2]

What matters to me is that this task state is not tied to one coding environment. I want to continue with another agent without having to reconstruct the plan from an old conversation.

Dependencies are particularly useful. The interface cannot be finished until the API is ready. bd ready shows tasks without open blockers. Dependencies across repositories are supported too, once the corresponding multi-repository setup is configured.^[1][3]

Alongside the available agent integrations and hooks, I therefore want a short pointer in AGENTS.md: this project tracks work in Beads. bd prime gives the agent its workflow guidance, instead of duplicating the full instructions in every instruction file.^[1]

My example: from task state to a project overview

At kombify, I also use Beads as a foundation for an overall progress view, supplemented by code analysis. For this, I combine ChatGPT Desktop with Sites, the feature for creating and hosting websites and web apps in ChatGPT.^[4]

This lets me see more than individual tickets: where work comes together and where it gets stuck. The percentage is not proof of product readiness. The proportion of completed tasks is not automatically the same proportion of total development effort.

My recommendation: Beads is especially worthwhile for me when tasks need to survive several sessions, agents or repositories. The underlying data still needs to be reachable and synchronised; switching tools does not do that by itself.^[1]

Explore Beads ↗

III. Matt Pocock’s skills: reuse good ways of working

A skill is a reusable working guide for an agent. Matt Pocock’s collection packages these guides for specific development situations: /grill-me challenges a plan, /tdd guides test-driven development and /code-review reviews the implementation.^[5]

That is a useful starting point: deliberately invoke the appropriate skill while developing. For me, it gets particularly interesting when I integrate suitable skills automatically at defined points in my own workflow.

Skills can invoke other skills that permit that use. There is already a concrete example in the repository: the manually started /implement skill uses /tdd during implementation and /code-review at the end.^[6]

The detailed method no longer needs to be repeated in every workflow I create. A higher-level skill can specify when to use an appropriate building block.

There is an important boundary. The collection explicitly distinguishes user-invoked skills from skills the model may invoke itself. A skill marked disable-model-invocation: true is not a candidate for unsolicited automatic invocation; the agent environment must support the corresponding controls too.^[5][7]

My recommendation: start with a few relevant skills rather than enabling the entire collection indiscriminately. Integrate their permitted calls deliberately. A skill instruction is not a technically enforced check: mandatory quality controls belong in tests and CI as well.

Explore Matt Pocock’s skills ↗

IV. OpenWiki: the code does not explain every decision

Code should make it as clear as possible what a system does. But it does not reliably tell you why a responsibility deliberately lives in another repository, which alternative was rejected, or which economic constraint shaped the implementation.

That is where I find OpenWiki, from LangChain, interesting. It generates and maintains a linked Markdown wiki. The combination of its two modes is especially useful to me.^[9]

In Code Mode, the wiki lives under openwiki/ in the individual repository: a local entry point to its components, workflows and architecture.

In Personal Mode, the default location is ~/.openwiki/wiki/. This becomes a broader knowledge base from connected sources, which can include multiple explicitly configured local Git repositories.^[10]

My division would be simple: the repository wiki explains one building block; the personal wiki makes the connections between projects accessible. Personal Mode does not automatically combine every existing repository wiki without configuration.^[10]

A wiki cannot conjure up missing reasons for a decision. Those reasons need an identifiable source, such as an architecture decision record. openwiki/INSTRUCTIONS.md lets you define the scope and priorities of wiki maintenance; that brief remains user-authored.^[11]

My recommendation: OpenWiki should make existing knowledge easier to use, not create a second, contradictory version of it. I check implemented behaviour against the code, and intentions and trade-offs against their decision sources.

Explore OpenWiki ↗

V. Bonus: an AGENTS.md with five principles

AGENTS.md is the agent’s short entry point, not the entire project handbook. Concrete project instructions and build and test commands belong here; detailed procedures can live in the appropriate places.^[12]

For a repository with these three tools already configured, I would start with this core: five principles and three tool references.

Verify assumptions against current code and reliable sources.
Keep changes scoped to the task and preserve others' work.
Test changed behavior; report checks run, results and remaining gaps.
You may return unresolved tasks with reasons and consult authorized agents; never invent success.
Minimize long-term total cost; prefer maintainable reuse over disposable code or speculative abstraction.

Beads: Start with `bd prime`; track tasks, status and dependencies only in `bd`.
Skills: Use relevant installed `mattpocock/skills` per their `SKILL.md`; automate only permitted invocations.
OpenWiki: Read relevant pages in `openwiki/`, and the authorized `~/.openwiki/wiki/` across projects; keep decision sources current.

Download AGENTS.md

The first three rules are intended to prevent unverified assumptions, unnecessary changes and untested success claims. The last two matter just as much to me: an agent may return a task it cannot solve with a reason, or consult another authorised agent. And an implementation should remain economical over time, not merely work today.

Reuse is not an end in itself. An existing, suitable building block can save future work; a universal architecture built in anticipation can just as easily make it more expensive.

Before you copy it

Add the actual project commands. This template does not replace existing repository rules or integration blocks. Add the valid build and test commands, and adapt the personal-wiki path to your environment. Include only sources that are actually accessible and authorised.^[12][10]

Configure the skills to use Beads. Matt Pocock’s setup supports custom tracker workflows. Record Beads as the custom tracker in docs/agents/issue-tracker.md so the skills do not quietly create a second task-management system in GitHub or Markdown.^[8]

Avoid maintaining the same knowledge twice. Existing architecture decisions and domain terminology remain the authoritative sources; OpenWiki makes them accessible. Record new decisions in the agreed source first, not only in a conversation or a generated summary.

For me, that separation is the real benefit: I can switch coding environments without having to reorganise tasks, working methods and project knowledge every time.