relay-80-100-workflow

Name: relay-80-100-workflow
Author: AgentWorkforce

769stars58forks

How to install relay-80-100-workflow?

agentworkforce/relay/relay-80-100-workflow

$npx -y skills add AgentWorkforce/relay --skill relay-80-100-workflow

Installs into the current project.

Summary

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-the

Files · 1

View on GitHub

SKILL.md

1	### Overview
2
3	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."
4
5	### When to Use
6
7	- Writing workflows where the deliverable must be production-ready, not just code-complete
8	- Features that touch databases, APIs, or infrastructure that can be tested locally
9	- Any workflow where "it compiles" is not sufficient proof of correctness
10	- When you want confidence that the commit actually works before deploying
11
12	### Core Principle: Test In The Workflow
13
14	#### 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.
15
16	```
17	implement → write tests → run tests → fix failures → re-run → build check → regression check → commit
18	```
19
20	### Repair Before Failure
21
22	An 80-to-100 workflow should not stop merely because a test, typecheck, lint, schema, or E2E gate turns red. That red output is work for the agent team. Capture it, hand it to a repair owner, fix it, and rerun. Workflow-owned validation gates should never terminate the run with `FAILED`. If the team exhausts its repair budget or hits an external blocker such as missing credentials, wrong repository, or unsafe dirty worktree, write a `BLOCKED_NO_COMMIT` artifact and end without committing or opening a PR instead of crashing the workflow.
23
24	Use this shape for every meaningful gate:
25
26	1. `run-*`: deterministic command with `captureOutput: true` and `failOnError: false`.
27	2. `fix-`: agent step that reads `{{steps.run-.output}}`, fixes source/tests/config, and reruns the command locally until green.
28	3. `verify-*`: deterministic rerun, usually still `failOnError: false`, followed by a final repair step if red.
29	4. `commit-if-green`: deterministic step that reruns the full acceptance command and commits only when every exit code is zero. If anything is still red, it writes `BLOCKED_NO_COMMIT` with the failing evidence and exits successfully so the workflow reports a handled blocked state, not a runtime failure.
30
31	AgentWorkforce/relay#827 added repair-aware reliability to the SDK (`.reliable()` / `.repairable()` and repair-aware retry-mode workflows). Prefer those presets when available, but still model explicit repair owners when gate output needs domain-specific fixing.
32
33	### Keep Repairable Gates On The Critical Path
34
35	Repair-before-failure only works after the workflow reaches a deterministic gate. If a long-running interactive agent step is a hard dependency for the first gate, then a dropped PTY, agent spawn error, or transport failure can stop the workflow before the repair loop ever sees evidence.
36
37	For large rollouts, treat implementation agents as advisory producers and put a deterministic reconciliation step on the critical path:
38
39	1. Start implementation/review agents in parallel if useful, but require them to write durable artifacts such as `.workflow-artifacts/<task>/runtime.md`, self-review notes, changed-file lists, and command evidence.
40	2. Add `implementation-reconcile`: a deterministic step that inspects `git status --short -- <paths>`, required files, artifact files, and diff stats. It should use `captureOutput: true` and `failOnError: false`.
41	3. Add `repair-implementation-reconcile`: a focused repair owner that reads the reconcile output and finishes missing artifacts or code before validation gates run.
42	4. Make discovery, typecheck, E2E, and final acceptance depend on the reconcile/repair path, not directly on every long-lived implementation agent.
43	5. Keep the final commit deterministic and green-only; red final evidence becomes a repair/blocking artifact, not a failed workflow.
44
45	This shape prevents "agent transport failed" from masquerading as "the product failed." The product still has to pass the same gates; the difference is that the workflow can reach the gates and repair them.
46
47	### Squad Review Before Final Acceptance
48
49	For high-stakes implementation workflows, validation should include human-like review structure, not only command gates. Use small implementation squads and make review state durable:
50
51	1. Split independent scopes into 2-3 agent squads. Ea

People who liked this also viewed

6 picks

Type

relay-80-100-workflow

769stars58forks

View on GitHub

How to install relay-80-100-workflow?

agentworkforce/relay/relay-80-100-workflow

$npx -y skills add AgentWorkforce/relay --skill relay-80-100-workflow

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	### Overview
2
3	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."
4
5	### When to Use
6
7	- Writing workflows where the deliverable must be production-ready, not just code-complete
8	- Features that touch databases, APIs, or infrastructure that can be tested locally
9	- Any workflow where "it compiles" is not sufficient proof of correctness
10	- When you want confidence that the commit actually works before deploying
11
12	### Core Principle: Test In The Workflow
13
14	#### 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.
15
16	```
17	implement → write tests → run tests → fix failures → re-run → build check → regression check → commit
18	```
19
20	### Repair Before Failure
21
22	An 80-to-100 workflow should not stop merely because a test, typecheck, lint, schema, or E2E gate turns red. That red output is work for the agent team. Capture it, hand it to a repair owner, fix it, and rerun. Workflow-owned validation gates should never terminate the run with `FAILED`. If the team exhausts its repair budget or hits an external blocker such as missing credentials, wrong repository, or unsafe dirty worktree, write a `BLOCKED_NO_COMMIT` artifact and end without committing or opening a PR instead of crashing the workflow.
23
24	Use this shape for every meaningful gate:
25
26	1. `run-*`: deterministic command with `captureOutput: true` and `failOnError: false`.
27	2. `fix-`: agent step that reads `{{steps.run-.output}}`, fixes source/tests/config, and reruns the command locally until green.
28	3. `verify-*`: deterministic rerun, usually still `failOnError: false`, followed by a final repair step if red.
29	4. `commit-if-green`: deterministic step that reruns the full acceptance command and commits only when every exit code is zero. If anything is still red, it writes `BLOCKED_NO_COMMIT` with the failing evidence and exits successfully so the workflow reports a handled blocked state, not a runtime failure.
30
31	AgentWorkforce/relay#827 added repair-aware reliability to the SDK (`.reliable()` / `.repairable()` and repair-aware retry-mode workflows). Prefer those presets when available, but still model explicit repair owners when gate output needs domain-specific fixing.
32
33	### Keep Repairable Gates On The Critical Path
34
35	Repair-before-failure only works after the workflow reaches a deterministic gate. If a long-running interactive agent step is a hard dependency for the first gate, then a dropped PTY, agent spawn error, or transport failure can stop the workflow before the repair loop ever sees evidence.
36
37	For large rollouts, treat implementation agents as advisory producers and put a deterministic reconciliation step on the critical path:
38
39	1. Start implementation/review agents in parallel if useful, but require them to write durable artifacts such as `.workflow-artifacts/<task>/runtime.md`, self-review notes, changed-file lists, and command evidence.
40	2. Add `implementation-reconcile`: a deterministic step that inspects `git status --short -- <paths>`, required files, artifact files, and diff stats. It should use `captureOutput: true` and `failOnError: false`.
41	3. Add `repair-implementation-reconcile`: a focused repair owner that reads the reconcile output and finishes missing artifacts or code before validation gates run.
42	4. Make discovery, typecheck, E2E, and final acceptance depend on the reconcile/repair path, not directly on every long-lived implementation agent.
43	5. Keep the final commit deterministic and green-only; red final evidence becomes a repair/blocking artifact, not a failed workflow.
44
45	This shape prevents "agent transport failed" from masquerading as "the product failed." The product still has to pass the same gates; the difference is that the workflow can reach the gates and repair them.
46
47	### Squad Review Before Final Acceptance
48
49	For high-stakes implementation workflows, validation should include human-like review structure, not only command gates. Use small implementation squads and make review state durable:
50
51	1. Split independent scopes into 2-3 agent squads. Ea

People who liked this also viewed

6 picks

Type