relay-80-100-workflow
Use when writing agent-relay workflows that must fully validate features end-to-end before merging. Covers the 80-to-100 pattern - going beyond "code compiles" to "feature works, tested E2E locally." Includes repair-before-failure validation gates, mandatory sequential Claude-then-Codex fresh-eyes review/fix loops with test hardening, PGlite for in-memory Postgres testing, mock sandbox patterns, test-fix-rerun loops, verify gates after every edit, and the full lifecycle from implementation through passing tests to commit.
npx skills add AgentWorkforce/relay --skill relay-80-100-workflow --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
Instructs the agent to implement end-to-end feature validation workflows that go beyond code compilation, ensuring features are tested and verified locally before commit. Uses deterministic test runs, repair loops, and gated commits to produce green results only when all gates pass. Includes instructions for in-memory Postgres testing via PGlite, mock sandbox usage, and structured loops for running, repairing, re-running, and committing.
How it works
- The workflow emphasizes running tests as part of the workflow, not just placing tests in files. Steps execute tests, verify results, fix failures, and re-run until green, with a final commit only if all gates exit with code zero.
- Repair-before-failure gates are used: for any red gate, a repair owner fixes issues and reruns, never terminating the run on red output. If blockers occur (e.g., missing credentials), a BLOCKED_NO_COMMIT artifact is written and the run ends without a commit or PR.
- Gate shapes include:
- run-* deterministic steps that capture output and do not fail immediately
- fix-* agent steps that read previous outputs, apply fixes, and rerun
- verify-* deterministic reruns after edits
- commit-if-green that rechecks all acceptance commands and commits only when green
- The pattern includes explicit steps for test-fix-rerun, PGlite in-memory Postgres testing, and a full lifecycle from implementation to commit.
- The full workflow example demonstrates multiple agents, deterministic gates, and artifact creation for blocked states when needed.
When to use it
- Use when the deliverable must be production-ready, not just code-complete.
- Use for features touching databases, APIs, or infrastructure that can be tested locally.
- Use when a mere code compile is not sufficient proof of correctness and you want confidence before deployment.
What it can touch
- The skill prescribes the use of
@electric-sql/pglitefor in-memory Postgres testing and defines file-oriented gates and artifacts. It references commands and file checks such asnpx tsx --test,git diff, and artifact paths like.workflow-artifacts/...andtests/helpers/pglite-db.ts.
Caveats
- The workflow relies on deterministic gates and artifact management; if external blockers occur, it emits
BLOCKED_NO_COMMITartifacts instead of failing. - Repairable gates and sequential fresh-eyes reviews are part of the process; success requires adherence to the specified gate patterns and artifacts.
- License provided is Apache-2.0 as declared by the skill.
### Overview Most agent workflows get features to ~80%: code written, types check, maybe a build passes. This skill covers the **80-to-100 gap** — making workflows that fully validate features end-to-end before committing. The goal: every feature merged via these workflows is **tested, verified, and known-working**, not just "it compiles." ### When to Use - Writing workflows where the deliverable must be **production-ready**, not just code-complete - Features that touch databases, APIs, or infrastructure that can be tested locally - Any workflow where "it compiles" is not sufficient proof of correctness - When you want confidence that the commit actually works before deploying ### Core Principle: Test In The Workflow #### The key insight: **run tests as deterministic steps inside the workflow itself**. Don't just write test files — execute them, verify they pass, fix failures, and re-run. The workflow doesn't commit until tests are green. ``` implement → write tests → run tests → fix failures → re-run → build check → regression check → commit ``` ### Repair Before Failure An 80-to-100 workflow should not stop merely because a test, typecheck, lint, schema, or E2E gate turns red. Th
- Overview
- When to Use
- Core Principle: Test In The Workflow
- Repair Before Failure
- Keep Repairable Gates On The Critical Path
- Squad Review Before Final Acceptance
- The Test-Fix-Rerun Pattern
- PGlite: In-Memory Postgres for Database Testing
- Verify Gates After Every Edit
- Mock Sandbox Pattern
- Regression Testing
- Full Workflow Template
- Checklist: Is Your Workflow 80-to-100?
- Common Anti-Patterns
What does the relay-80-100-workflow skill do?
Use when writing agent-relay workflows that must fully validate features end-to-end before merging. Covers the 80-to-100 pattern - going beyond "code compiles" to "feature works, tested E2E locally." Includes repair-before-failure validation gates, mandatory sequential Claude-then-Codex fresh-eyes review/fix loops with test hardening, PGlite for in-memory Postgres testing, mock sandbox patterns, test-fix-rerun loops, verify gates after every edit, and the full lifecycle from implementation through passing tests to commit.
How do I install it?
Run `npx skills add AgentWorkforce/relay --skill relay-80-100-workflow --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From AgentWorkforce/relay, a repository with 784 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.
