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 — fewer review rounds, fewer reopen cycles, less work that looks finished and is not.

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 does something different: it returns a decision, a bounded checklist, and the next concrete 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.