ayeo news

Compass 7.0.0: see what your agent decided before anything ships

2026-10-20T00:00:00Z

Before 7.0.0, a finished change could still list its spec and design as drafts, and nothing told you whether anyone had actually read them. If your agent settled a requirement on your behalf, you found out in the verification report, after the code was written.

7.0.0 closes both gaps. Compass now keeps track of each document's status itself, refuses to ship anything that hasn't been accepted, and stops to show you what your agent decided before it builds anything.

What was wrong

In 6.x, five things got in the way on shared projects:

Agents made calls you didn't see. An agent could answer a requirement question for you, and you'd only read about it once the code existed.
Statuses never moved. Nothing updated a document's status, so "draft" could mean unread or could mean done.
A hand-ticked box counted as proof. Anyone could tick a box on the page, and Compass took it as evidence.
Big designs were too big to review. On the largest changes, the technical design grew past the point where anyone would read it closely.
Some things had nowhere to go. There was no place for non-functional requirements, data and interface contracts, or a test plan.

What's new

You see what your agent decided, before it writes code

When your agent makes a decision for you, Compass records it. On balanced and controlled autonomy, the agent stops at a checkpoint at the end of /compass:define and /compass:plan until you confirm each decision or reopen it. Later, compass retro --decisions shows how many you confirmed, changed or never got to.

You approve from the session you're already in

Type /compass:approve or /compass:reject in Claude Code. No terminal, no context switch.

If you'd rather not be the bottleneck, /compass:delegate lets one named agent approve for you, for up to 24 hours and only within the scope you set. You can see everything it approved afterwards. A delegation never covers the human sign-off on auth, payments, personal-data or migrations work unless you type back a code Compass shows you.

Every document has a status, and Compass checks it

Each stage now sets the status of the documents it produces. A document that needs no human check is approved when its stage ends. One that does stays awaiting-approval until a person signs it off.

/compass:ship won't ship a change while any of its documents is still a draft or waiting for approval, and it tells you which command clears it. Quick fixes skip the extra stop.

Ticks, counts and statuses on the issue page now come from Compass's own records, not from what someone typed. compass check fails a document that disagrees with them, and compass issue render rebuilds the page.

Documents that are easier to review

New sections where teams needed them. The spec gets Non-functional requirements. The design gets Data and interfaces, Verification plan, and Risks and dependencies.
Every document starts the same way. One header block, and headings without numbers, so leaving out an optional section doesn't leave a gap.
A short intent for regular changes. Four headings: Problem, Desired outcome, Success signals and Non-goals. Regular changes also get a short requirements review, and hotfixes get a bug report.
Word limits on technical designs. Each depth has a limit. On the full approach, the detail moves into one low-level design per work unit.
A release line on every shipped change. One sentence, written for your users. compass release notes --since <ref> collects them, so your release notes start from what you already wrote.

Also in 7.0.0

Readiness limits autonomy. compass readiness checks your repository against 11 signals. Before Compass accepts an autonomous assessment, four of them must pass: agent instructions, a build that succeeds, tests that finish in under 2 minutes, and clean lint. compass readiness --fix-list tells you what to change for each one that fails. balanced and controlled projects are never refused.

Issues can wait on other issues. Add a dependency with compass issue depends add. While it's open, the issue can't start implementation, and the board shows what it's waiting for. Spec and design aren't blocked, so you can get ahead on those.

The issue page on GitHub, if you want it. Set github_labels: {page: true} and Compass posts the issue page to the linked GitHub issue. It's off by default, because it shows your documents to everyone who can read that issue.

Getting started

New to Compass

Install it from inside Claude Code:

/plugin marketplace add ayeo-io/compass
/plugin install compass@compass

Then type /compass:go followed by the change you want to make. The five-minute walkthrough takes you through your first issue.

Upgrading from 6.x

Copy your Compass folders before you upgrade. There is no supported rollback of the issue migration. Copy .compass/work and docs/compass to a folder outside the project first.

Update every checkout and every installed plugin at the same time, and don't run a 6.x CLI on a 7.0.0 tree. If you have existing issues, follow the 7.0.0 upgrade guide. It lists every change, what breaks and what to do about it. The release notes cover everything since 6.1.0.

Compass is coming to Codex

2026-10-24T00:00:00Z

Compass has only ever run in Claude Code. That's been fine if that's where you work. If your team is in Codex, or split between the two, it has meant Compass wasn't for you.

That's changing. Compass now installs into a Codex project, and once it's there you work the way a Claude Code team does. Describe the change in one line, and Compass reads it for risk, familiarity, size and goal, picks an approach, and tells you what it will write and what it will check before anything ships.

The problem

Choose a coding agent and you've chosen your process. While Compass only ran in Claude Code, a team in Codex couldn't have it, and a company using both ended up with two ways of shipping on one codebase. We don't think your choice of agent should decide how carefully you ship.

What's new

We didn't write a second Compass. The commands, the agents, the skills and the Python CLI are shared. Codex gets a small adapter on top: one entry skill, and a translation that turns Codex's hook events into the ones Compass already understands.

In practice:

$compass:compass assess "Add rate limiting to the public API" starts the same assess stage that /compass:assess starts in Claude Code. The other stages, from define to ship, follow the same way.
A change leaves the same documents behind, in the same place, with the same statuses. The records are the same files whichever runtime wrote them.
compass check and compass ci run unchanged, so a pull request is judged the same way.

The hooks are where the two runtimes differ. Codex runs them only once you've trusted them, and we haven't yet measured how they behave through a full native session. Rather than claim parity, we publish a support table that says, control by control, what Codex enforces, what it advises on, and what it doesn't have.

Getting started

Pin a Compass checkout at 7.0.0 or later and point the installer at your project:

python3 adapters/codex/install.py --project /absolute/path/to/your/project

Restart Codex, trust the project, then review and trust the hooks it installed with /hooks. The Codex guide explains what the installer adds, how to take it out again, and exactly what we have and haven't tested.

Compass for GitHub Copilot

2026-10-24T00:00:00Z

If your team's coding agent is GitHub Copilot, Compass hasn't been an option. We're changing that. Compass will install as a plugin for Copilot, in the app and in the CLI, and a change you make there will get the same treatment it gets in Claude Code: assessed first, given the process it needs, and checked before it ships.

The problem

Governance tools tend to arrive with a preferred tool built in. Compass has had one too: it only ran in Claude Code. That left Copilot teams out, and it meant a company that uses more than one agent couldn't have one way of shipping across all of them. We don't think your choice of agent should decide how carefully you ship.

What's new

Compass will install as a supported Copilot plugin, for local sessions in the Copilot app and the Copilot CLI. It's the same Compass: the same Python CLI, the same record on disk, the same policy. So:

assess a change in Copilot and you get the approach the policy gives it, whichever agent you'd have used;
every change leaves the same documents behind, each with a status;
compass check and compass ci judge the pull request the same way.

We're building it the way we built the Codex adapter: one shared source for the commands, agents and skills, with a thin adapter for Copilot. Copilot lets a plugin step in at its own points, so we'll publish a support table that says, control by control, what Copilot enforces, what it advises on, and what it can't do.

Getting started

Not yet. Codex comes first. After that, the first job on Copilot is a feasibility check: what can a plugin install, run and refuse? Then an install you can diagnose, then the stages, then the hooks and the evidence. We'll update this post as each step lands.