DEV Community: Michael Elian Kevin

How I Simplified My GitHub Copilot Agent Squad

Michael Elian Kevin — Sun, 09 Aug 2026 05:42:35 +0000

A while back I built GitHub Copilot Squad, a custom multi-agent setup for the GitHub Copilot coding agent. After using it on real-world tasks, I rebuilt it into a simpler version. This is the story of what I tried, what I learned, and what I ended up with.

The first version: 4 agents

The original idea was role separation. Don't let one agent plan, build, and review all at once. So I split it into four agents:

Capybara: the router
Otter: the implementer
Owl: the reviewer
Squirrel: a lightweight helper for simple questions

kevinkwee / github-copilot-squad

Custom multi-agent orchestration for GitHub Copilot coding agent with role-based routing.

GitHub Copilot Squad

A custom multi-agent orchestration setup for GitHub Copilot coding agent.

This repo defines a 4-agent team with clear roles:

Capybara: router/orchestrator
Otter: implementation agent
Owl: reviewer/QA gate
Squirrel: general assistant for simple/non-technical requests

The goal is to separate execution and review, so technical tasks go through an implementation + review loop before final output, with different models contributing different perspectives.

Why this exists

When using one agent for everything, prompts often mix planning, coding, and reviewing in one pass, and the context window can fill up quickly. This setup enforces role separation:

Technical work is done by a builder agent (Otter)
Quality is validated by a strict reviewer (Owl)
Implementation and review can run on different models, giving a multi-perspective quality check
Non-technical/simple requests are handled fast by a lightweight helper (Squirrel)
Routing and iteration control…

View on GitHub

The goal was to keep implementation and review as separate perspectives, so technical work goes through a build-then-review loop before it comes back to you.

What using it taught me

The separation sounded clean on paper. In practice, a few things bugged me:

A separate generalist implementer didn't add much. Spinning up a separate agent just to offload execution only pays off when that agent is specialized (a frontend expert, a specific-framework expert). My Otter was a generalist, just like Capybara. Two generalists gave me handoff overhead, not more perspective.
A fresh isolated context per request is expensive. Because Otter was a separate sub-agent, every request started in a fresh context. That meant more tokens and more time for it to re-read the codebase and re-analyze the problem, even for follow-ups that built directly on the previous work.
The context-window fear was overblown. My worry with merging the builder into the entry point was that the context window would fill up fast. After running it on real, multi-step tasks, it grew slower than I expected, and the benefit of warm, carry-over context outweighed the cost.

So I built a simpler version.

The simplified version

kevinkwee / github-copilot-squad-simplified

Simplified version of my GitHub Copilot Squad, a custom multi-agent orchestration for GitHub Copilot coding agent with role-based routing.

GitHub Copilot Squad (Simplified)

A simplified orchestration setup for the GitHub Copilot coding agent, and a leaner variant of github-copilot-squad. It ships in two modes:

Trio (default): Capybara (entry point + implementer) + Owl (code reviewer) + Cat (comment/docstring reviewer).
Duo: Capybara + Owl only, with no dedicated comment/docstring pass. The Duo behavior lives in CapybaraDuo.agent.md.

In both modes the goal is the same: keep implementation and review as separate perspectives, so technical work goes through a build → review loop before final output. What's removed (vs the original 4-agent squad) is the overhead of a separate execution agent and a separate lightweight helper.

Why this simplified version exists

The original squad offloads implementation to a dedicated builder agent (Otter), with Capybara acting as a pure router. After using it on real-world tasks, that separation turned out to be unnecessary for this…

View on GitHub

I merged Otter into Capybara. Now Capybara is the entry point and the implementer. It receives the request, does the work, then hands off to Owl for review. I also dropped Squirrel (tbh it was useless, I never really used it irl 😂), so Capybara handles simple questions directly. Owl stayed as the reviewer.

It ships in two modes:

Duo. Capybara + Owl (the lean version)
Trio (default). Capybara + Owl + Cat (more on Cat in a moment)

For technical requests, Capybara implements, then loops with Owl until Owl approves. In Trio mode, it then loops with Cat until Cat approves, then returns the result.

Why I added a comment/docstring-only reviewer

For a while, Duo mode was enough. But I noticed something: agents sometimes write unnecessary, redundant, or inappropriate comments and docstrings, even when the rules already say not to. Owl's review covers this, but Owl also reviews the code implementation, so these prose issues sometimes got skipped.

So I added Cat, a reviewer that focuses ONLY on comments and docstrings. It runs after Owl approves, so the code is already correct. Cat's whole job is to groom the prose. Each review pass writes a report file, so there's a lightweight audit trail.

That's the Trio mode: Capybara and Owl (code review), then Capybara and Cat (comment/docstring review), then finish.

One thing that's not there yet

Both setups treat an AGENTS.md file as the source of truth for project-specific rules (stack, test commands, linter, naming, and the expected comment/docstring rules). The agent profiles stay generic and reusable. The project-specific detail lives in AGENTS.md, which is easier to update and maintain than editing the bundled agent profiles.

I haven't published an AGENTS.md example or template yet. I'll add one as soon as I have time to put a clean template together. Until then, you can write your own AGENTS.md describing your stack, your test command, your linter, and any hard constraints you want the agents to respect.

The animals

Because naming things is half the fun:

Role	Animal	Why it fits
Entry point + Implementer	Capybara 🦫	Calm and sociable. Comfortable doing the work itself and coordinating the review.
Code reviewer	Owl 🦉	Sharp observation. Spots sneaky issues.
Comment/docstring reviewer	Cat 🐱	Fastidious groomer. Grooms comments and docstrings until every word earns its place.

Wrapping up

The short version: I started with 4 agents, found that one generalist implementer was enough, and ended up with a 2-agent setup with an optional 3rd for docstring grooming. The configs are just markdown agent profiles you can drop into VS Code Copilot Chat.

Find this useful? Smash the star on the repo! ⭐

Star on GitHub

FckVer: A Practical Versioning Strategy for Odoo

Michael Elian Kevin — Fri, 31 Jul 2026 04:46:30 +0000

FckVer: A Practical Versioning Strategy for Odoo

Disclaimer

This article contains profanity. The naming is intentional. The idea started from a long debugging session with Odoo's module versioning. If you don't appreciate the name, feel free to rename it internally.

The Problem

Odoo has a single version field inside __manifest__.py.

{
    "version": "18.0.1.0.0",
}

Simple?

Not really.

That single version is expected to represent several completely different concepts:

application version
module version
migration version
deployment ordering
upgrade detection

In reality, these are different things.

Coming from ecosystems like Django, Rails, Alembic, Flyway or Liquibase, this felt strange because those ecosystems separate:

application release
database migration

For example:

Application
v2.0.0

Database
Migration 001
Migration 002
Migration 003

Nobody tries to squeeze both into one version number.

Unfortunately, Odoo only gives us one.

Our Development Workflow

Our company does not have disposable development databases.

Instead, we have:

Developer
      │
      ▼
Shared Development Server
(real company users)
      │
      ▼
QA
      │
      ▼
Production

The shared development server contains real data.

Sales use it.

QA uses it.

Project members use it.

Because of that, every deployment to this server becomes part of the database history.

That immediately breaks many traditional versioning assumptions.

The Problem with Semantic Versioning

Semantic Versioning asks questions like:

Is this a major change?
Is this a minor feature?
Is this a patch?

Our team had a different question:

"We deployed a new build to the shared development server. Which number do we bump?"

Semantic Versioning doesn't answer that.

Odoo documentation doesn't answer that.

Different Odoo teams even interpret the five-part version differently.

Eventually we realized something.

We weren't trying to version software.

We were trying to version our deployment lifecycle.

Introducing FckVer

FckVer (Fuckantic Versioning)

Because sometimes software engineering deserves an appropriately named versioning system.

The format is:

18.0.RELEASE.HOTFIX.DEV

where

Component	Meaning
18.0	Odoo version
RELEASE	Production release generation
HOTFIX	Production hotfix generation
DEV	Shared development deployment generation

Unlike Semantic Versioning, none of these numbers describe API compatibility.

They describe our deployment lifecycle.

The Rules

Rule 1

Every deployment to the shared development server increments DEV.

It doesn't matter whether the change is:

migration
new feature
bug fix
refactoring
view changes
security rules
XML data

If users receive a new build on the shared development server...

...DEV increments.

We call this a fump.

Definition

fump = fucking bump

Rule 2

Production releases increment RELEASE.

Suppose production currently runs

18.0.4.0.0

Development continues:

18.0.4.0.1
18.0.4.0.2
18.0.4.0.3
...
18.0.4.0.696

Eventually QA signs off.

Now comes an important step.

Before deploying to production, we perform a release fump on the shared development server.

18.0.5.0.0

No code changes.

No migration changes.

Nothing.

Only the version changes.

Then we perform one final smoke test.

If everything passes...

Deploy that exact build to production.

Shared Dev
18.0.5.0.0

↓

Production
18.0.5.0.0

Production always receives the exact version that was tested.

Rule 3

Hotfixes increment HOTFIX.

Suppose production is

18.0.5.0.0

An emergency fix is required.

The hotfix becomes

18.0.5.1.0

That version is tested.

Then deployed.

Development continues from there.

18.0.5.1.1
18.0.5.1.2
18.0.5.1.3

Typical Lifecycle

18.0.4.0.0   Production Release 4

18.0.4.0.1   Dev deployment
18.0.4.0.2
18.0.4.0.3
...
18.0.4.0.696

18.0.5.0.0   Release fump
              Final smoke test

18.0.5.0.0   Production Release 5

18.0.5.0.1   New development
18.0.5.0.2

18.0.5.1.0   Production hotfix

18.0.5.1.1   Continue development
18.0.5.1.2

Why This Works

This approach gives us several nice properties.

Monotonic versions

Odoo's version parser is always happy.

Every version is greater than the previous one.

No version rewrites

Once a version has been deployed anywhere shared, it is permanent.

No rewriting history.

No pretending intermediate versions never existed.

Production always runs a tested version

There is never a last-minute version change immediately before production deployment.

The production artifact is the same artifact that passed QA.

No Semantic Versioning debates

Nobody asks

"Is this a patch?"

Nobody asks

"Is this a minor feature?"

Nobody asks

"Should this be 2.1 or 2.2?"

The only question becomes

"Did we deploy a new build to the shared development environment?"

If yes...

Fump.

Is FckVer Better Than SemVer?

No.

It solves a different problem.

Semantic Versioning describes compatibility.

FckVer describes deployment history.

For our Odoo workflow, deployment history is far more important than compatibility semantics.

Final Thoughts

I don't claim this should become an industry standard.

I don't even claim it's the best possible solution.

But after trying to force Semantic Versioning into Odoo's module versioning, our team realized we were solving the wrong problem.

Once we started treating the manifest version as a deployment lifecycle instead of a semantic version...

Everything became much simpler.

Sometimes the best engineering solution isn't the most elegant one.

It's the one your team can understand at a glance.

P.S.

Yes, the official name is Fuckantic Versioning.

You might want to abbreviate it to FckVer because writing "fuck" into deployment scripts somehow felt unprofessional.