Your coding agent is missing half the story.
A ticket tells Claude, Codex, or Cursor what to change. It rarely tells them every API promise, migration rule, architecture decision, old PR, or downstream dependency they are expected to remember. HoldUp finds the few things that matter before the agent starts, then checks the PR against the same decisions.
- ✓Public API policy
Fields stay available for a 90-day deprecation window. - ✓Mobile still reads
workspace.slug
Referenced in the current iOS release branch. - ✓SDK is generated from
openapi.yaml
Schema changes affect every generated client. - ✓Database migration rule
Expand → backfill → switch reads → contract.
Should this release return both fields and deprecate slug, or is this intentionally a breaking API version?
Give the agent one clean packet instead of your whole company wiki.
HoldUp sends the task, constraints, relevant code, and approved decisions to the coding agent. When the PR opens, it checks whether the implementation stayed inside that contract.
Agents can write code faster than teams can explain the context around it.
The failure is usually not “the model cannot code.” It is that the task looked simple while the important constraints lived somewhere else.
A migration works in tests and hurts production.
The issue says “make email non-null.” The agent writes ALTER COLUMN SET NOT NULL. The migration playbook says large tables require a backfill and validation step first.
missing: backfill → validate → constraint
The task and API contract imply different releases.
The ticket says rename a field. The public API policy requires a deprecation window and the mobile client still reads the old field.
API policy: preserve slug for 90 days
A retry-safe worker becomes non-idempotent.
The agent adds an email send directly inside a job that can retry. Tests pass. The worker contract requires side effects to be deduplicated by job key.
PR: sendEmail() on every attempt
One task in. One clear contract out.
Pick the task
Start from a Linear/Jira issue or a plain task description. HoldUp figures out what parts of the codebase and team knowledge are relevant.
Find what matters
Pull only the useful constraints from repo instructions, ADRs, API schemas, migration docs, related PRs, and connected work tools.
Resolve the gaps
If the sources disagree or the task leaves a meaningful choice open, ask the human before the agent quietly chooses for them.
Check the PR
Use the same approved packet to verify that the implementation did what the team meant, not just what the agent guessed.
The stuff senior engineers catch because they remember the history.
HoldUp is aimed at cross-file and cross-tool constraints that compile, test, and still produce the wrong change.
Expand/contract migrations
An agent removes an old column or API field in one PR. The real rollout requires dual-write, backfill, consumer migration, and only then cleanup.
team rule: add → backfill → migrate reads → remove
Generated client drift
The backend changes an OpenAPI response and passes service tests, but generated SDKs and an older mobile client still depend on the previous shape.
consumer contract: still expects old field
HoldUp is about intent before code review.
Not style comments
We are not trying to tell you that a function is too long or a variable name could be better.
Not another spec framework
Keep the docs, tickets, repo rules, schemas, and decisions your team already uses.
Not “more context”
Agents already drown in context. HoldUp's job is to decide which few constraints actually govern this task.
Give us one task your coding agent misunderstood.
Send the ticket, PR, or a short description. We will reconstruct the context the agent should have received and show you the HoldUp work packet.
Try it on one task