Hiveram

Completion Compressor

Compress the path from vague work to verified completion

Most teams do not lose time writing code. They lose it in the loop after: the review that raises a maybe, the reopen a week later, the pull request that was green but not actually done. The Completion Compressor squeezes that loop — it cuts review rounds and reopens, and catches work that looks finished but isn't.

Your AI reviewer tells you something might be wrong. Hiveram tells you whether the work is closeable — and if not, what test, follow-up, or acceptance proof must exist before it can be.

Add the GitHub Action Read how it works

Comments do not close work

Most AI review tools produce comments. A comment is something a human must read, judge, remember, and act on — it quietly assumes a supervisor is standing by with the time and context to decide what matters.

At scale, comment-based review adds reading, not closure. More signal arrives, but the decision of whether the work is actually done still sits with you. A reviewer that raises ten possibilities has handed you ten more things to evaluate.

In practice, that loop is where completion goes to stall. Hiveram returns a decision, a checklist of what is missing, and the next work state.

What it does instead

The Completion Compressor returns a decision and the work still missing — not a pile of comments. It runs as a GitHub Action in two modes.

Upspec — for issues

Turns a vague request into an implementation-ready spec before anyone writes code: concrete acceptance criteria, the tests the change will likely need, and the follow-up risks worth naming up front. The output is something a developer or an agent can act on directly.

Completion — for pull requests

Evaluates whether the pull request is closeable against the issue, the stated acceptance criteria, the tests, and the changed files. The result is a single verdict — closeable: yes, no, or uncertain — and, when it is not closeable, a bounded checklist of the specific work that is missing. An optional status check can mirror the verdict.

One comment. One verdict. A bounded checklist.

Hiveram does not post a comment for every finding. It posts one sticky completion comment and updates it in place as the work changes. A pull request gets one result:

• the closeability verdict
• the missing tests
• the missing acceptance criteria
• the structured follow-ups
• the risks worth keeping visible after merge

Missing tests can come back as one-click suggestions. Blocking is opt-in — the default is evidence, not control.

A structured answer, not review prose

Every run produces a machine-readable artifact bundle under one predictable directory:

hiveram-completion/result.json
hiveram-completion/report.md
hiveram-completion/followups.json
hiveram-completion/test-checklist.md
hiveram-completion/close-proof.json

The comment is for humans. The artifacts are for automation, audit, and future tracking — fixed paths a script can read without guessing, like jq .closeable hiveram-completion/result.json. Together, they turn review from prose into the next work state.

Install motion

It is a GitHub Action. Point it at pull requests for completion mode, or issues for upspec mode. The minimal shape:

name: Hiveram Completion Compressor
on:
  pull_request:
    types: [opened, synchronize, ready_for_review]

permissions:
  contents: read
  pull-requests: write
  checks: write

jobs:
  compress:
    runs-on: ubuntu-latest
    steps:
      - uses: obstalabs/hiveram-compressor@v0
        with:
          mode: completion
          hiveram-api-key: ${{ secrets.HIVERAM_API_KEY }}

Conservative by default: minimal permissions, comment-first, and no auto-merge. Hiveram presents evidence and the shortest path to closeable. Your team decides.

Further reading

Two essays on why this shape matters:

A board nobody reads

What happens when review output assumes a supervisor who is not there.

The agent must not close its own ticket

Why completion needs evidence and a boundary, not self-certification.