Agent skill

Relay 80 100 Workflow

by AgentWorkforce in AgentWorkforce/relay

A skill your agent uses when writing agent-relay workflows that must fully validate features end-to-end before merging.

Apache-2.0Auto-check passedTesting & QA

Install Relay 80 100 Workflow

skills CLI
$ npx skills add AgentWorkforce/relay --skill relay-80-100-workflow -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install AgentWorkforce/relay relay-80-100-workflow --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/AgentWorkforce/relay.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/relay-80-100-workflow .claude/skills/relay-80-100-workflow && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
relay-80-100-workflow
GitHub stars
866
Token cost
~5.7k tokens
SKILL.md length
1,259 words
Files
1
Skills in repo
14
Repo updated
First seen
Licence
Apache-2.0

At a glance

A skill your agent uses when writing agent-relay workflows that must fully validate features end-to-end before merging.

  • Works in 4 steps: run-*: deterministic command with… → fix-*: agent step that reads… → verify-*: deterministic rerun, usually… → …
  • Writing agent-relay workflows that must fully validate features end-to-end before merging
  • Calls git, npx and npm
  • Tasks that involve End-to-end testing

What it does

Relay 80 100 Workflow is an agent skill from AgentWorkforce/relay. 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, review-depth 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.

Its SKILL.md is about 5.7k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Testing & QA, covering End-to-end testing. It works with PostgreSQL. The repository describes itself as: Infrastructure for coding agents. The licence is Apache-2.0.

When your agent uses it

  • Writing agent-relay workflows that must fully validate features end-to-end before merging
  • Tasks that involve End-to-end testing

Example prompts

  • “code compiles”
  • “feature works, tested E2E locally.”
  • “/relay-80-100-workflow”

Requirements

  • Node.js

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. run-*: deterministic command with captureOutput: true and failOnError: false.
  2. fix-*: agent step that reads {{steps.run-*.output}}, fixes source/tests/config, and reruns the command locally until green.
  3. verify-*: deterministic rerun, usually still failOnError: false, followed by a final repair step if red.
  4. commit-if-green: deterministic step that reruns the full acceptance command and commits only when every exit code is zero. If anything is…

What it can do on your machine

Read from SKILL.md and the folder at commit 20ae3e3. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git
    • npx
    • npm

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, npx and npm, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Relay 80 100 Workflow loads about 5.7k tokens when it runs. Until then it costs about 131 tokens; SKILL.md has 1,259 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~131
When it runs · the whole SKILL.md, loaded when a task matches
~5.7k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from AgentWorkforce/relay at commit 20ae3e3, republished under its Apache-2.0 licence (© AgentWorkforce). 1,259 words, ~5,702 tokens.

Download SKILL.mdSave it as .claude/skills/relay-80-100-workflow/SKILL.md (or your agent's skills folder).
name
relay-80-100-workflow
description
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, review-depth 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.
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. 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.

Use this shape for every meaningful gate:

  1. run-*: deterministic command with captureOutput: true and failOnError: false.
  2. fix-*: agent step that reads {{steps.run-*.output}}, fixes source/tests/config, and reruns the command locally until green.
  3. verify-*: deterministic rerun, usually still failOnError: false, followed by a final repair step if red.
  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.

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.

Keep Repairable Gates On The Critical Path

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.

For large rollouts, treat implementation agents as advisory producers and put a deterministic reconciliation step on the critical path:

  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.
  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.
  3. Add repair-implementation-reconcile: a focused repair owner that reads the reconcile output and finishes missing artifacts or code before validation gates run.
  4. Make discovery, typecheck, E2E, and final acceptance depend on the reconcile/repair path, not directly on every long-lived implementation agent.
  5. Keep the final commit deterministic and green-only; red final evidence becomes a repair/blocking artifact, not a failed workflow.

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.

Squad Review Before Final Acceptance

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:

  1. Split independent scopes into 2-3 agent squads. Each squad has an implementer, a shadow reviewer, and optionally a validation/test owner.
  2. The shadow reviewer follows the implementer while work is happening and flags spec drift early.
  3. Before external review, the implementer writes a self-reflection artifact under .workflow-artifacts/<task>/ covering spec coverage, changed files, tests/proofs, repo-rule alignment, and known risks.
  4. A fresh self-review agent reads the actual files, AGENTS.md / CLAUDE.md, recent related work, and local conventions. It writes findings to disk.
  5. The implementer repairs valid findings, then deterministic gates rerun from captured output.
  6. After all squads converge, run the selected review-depth fresh-eyes review/fix path. Light requires review-claude -> fix-loop and gates final review pass on post-fix-validation. Standard adds final-review-claude -> final-fix-claude and gates final review pass on final-fix-claude. Deep requires the standard Claude path plus review-codex -> fix-loop-codex -> final-review-codex -> final-fix-codex and gates final review pass on final-fix-codex.
  7. If the selected review path still finds issues, run another explicit fix pass or write BLOCKED_NO_COMMIT with exact evidence.
  8. Commit or PR creation is allowed only after the selected review-depth path, final-review-pass gate, final deterministic acceptance, and scoped diff/regression gates are green. Otherwise write a BLOCKED_NO_COMMIT artifact with exact evidence.

This keeps "100%" tied to both executable evidence and independent review over the final state.

Show full SKILL.md (447 more words)Show less
The Test-Fix-Rerun Pattern
Every testable feature in a workflow should follow this four-step pattern:
typescript
// Step 1: Run tests (allow failure — we expect issues on first run)
.step('run-tests', {
  type: 'deterministic',
  dependsOn: ['create-tests'],
  command: 'npx tsx --test tests/my-feature.test.ts 2>&1 | tail -60',
  captureOutput: true,
  failOnError: false,  // <-- Don't fail the workflow, let the agent fix it
})

// Step 2: Agent reads output, fixes issues, re-runs until green
.step('fix-tests', {
  agent: 'tester',
  dependsOn: ['run-tests'],
  task: `Check the test output and fix any failures.

Test output:
{{steps.run-tests.output}}

If all tests passed, do nothing.
If there are failures:
1. Read the failing test file and source files
2. Fix the issues (could be in test or source)
3. Re-run: npx tsx --test tests/my-feature.test.ts
4. Keep fixing until ALL tests pass.`,
  verification: { type: 'exit_code' },
})

// Step 3: Deterministic rerun — capture result for a final repair pass
.step('run-tests-final', {
  type: 'deterministic',
  dependsOn: ['fix-tests'],
  command: 'npx tsx --test tests/my-feature.test.ts 2>&1',
  captureOutput: true,
  failOnError: false,
})

// Step 4: Repair again if the rerun is still red
.step('fix-tests-final', {
  agent: 'tester',
  dependsOn: ['run-tests-final'],
  task: `If the final test rerun passed, record the green evidence.
If it failed, fix the remaining issue and rerun until green:
{{steps.run-tests-final.output}}`,
  verification: { type: 'exit_code' },
})
PGlite: In-Memory Postgres for Database Testing
Setup
typescript
.step('install-pglite', {
  type: 'deterministic',
  command: 'npm install --save-dev @electric-sql/pglite 2>&1 | tail -5',
  captureOutput: true,
})
Test Helper Pattern
typescript
// tests/helpers/pglite-db.ts
import { PGlite } from '@electric-sql/pglite';
import { drizzle } from 'drizzle-orm/pglite';
import * as schema from '../../packages/web/lib/db/schema.js';

// Raw DDL matching your Drizzle schema — PGlite doesn't run Drizzle migrations
const MY_TABLE_DDL = `
CREATE TABLE IF NOT EXISTS my_table (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  name TEXT NOT NULL,
  created_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
`;

export async function createTestDb() {
  const pg = new PGlite();
  await pg.exec(MY_TABLE_DDL);
  const db = drizzle(pg, { schema });
  return { db, pg, schema, cleanup: () => pg.close() };
}
Test Structure
typescript
// tests/my-feature.test.ts
import { describe, it } from 'node:test';
import assert from 'node:assert/strict';
import { randomUUID } from 'node:crypto';
import { createTestDb } from './helpers/pglite-db.js';

describe('my feature', () => {
  it('does the thing correctly', async () => {
    const { db, schema, cleanup } = await createTestDb();
    try {
      // Arrange
      const testId = randomUUID();
      // Act — use your module against the real (in-memory) Postgres
      // Assert
      assert.equal(result.name, 'expected');
    } finally {
      await cleanup();
    }
  });
});
Verify Gates After Every Edit
Never trust that an agent edited a file correctly. Add a deterministic verify gate after every agent edit step:
typescript
// Agent edits a file
.step('edit-schema', {
  agent: 'impl',
  dependsOn: ['read-schema'],
  task: `Edit packages/web/lib/db/schema.ts...`,
  verification: { type: 'exit_code' },
})

// Deterministic verification — did the edit actually land?
.step('verify-schema', {
  type: 'deterministic',
  dependsOn: ['edit-schema'],
  command: `if git diff --quiet packages/web/lib/db/schema.ts; then echo "NOT MODIFIED"; exit 1; fi
grep "my_new_table" packages/web/lib/db/schema.ts >/dev/null && echo "OK" || (echo "MISSING"; exit 1)`,
  failOnError: false,
  captureOutput: true,
})
.step('fix-schema-verification', {
  agent: 'impl',
  dependsOn: ['verify-schema'],
  task: `Fix the schema edit if verification failed. Output:\n{{steps.verify-schema.output}}`,
  verification: { type: 'exit_code' },
})
Edit Gates That Include New Files
typescript
.step('edit-gate-capture', {
  type: 'deterministic',
  dependsOn: ['implement'],
  command: `if [ -z "$(git status --short -- packages/new-adapter tests docs)" ]; then
  echo "NO_CHANGES"
  exit 1
fi
echo "EDIT_GATE_OK"`,
  captureOutput: true,
  failOnError: false,
})
.step('fix-edit-gate', {
  agent: 'impl',
  dependsOn: ['edit-gate-capture'],
  task: `If the edit gate reported NO_CHANGES, inspect the acceptance contract
and current git status, then add the missing source/test/artifacts.

Gate output:
{{steps.edit-gate-capture.output}}

If it already passed, do nothing.`,
  verification: { type: 'exit_code' },
})
.step('edit-gate-final', {
  type: 'deterministic',
  dependsOn: ['fix-edit-gate'],
  command: `if [ -z "$(git status --short -- packages/new-adapter tests docs)" ]; then
  echo "NO_CHANGES"
  exit 1
fi
echo "EDIT_GATE_FINAL_OK"`,
  captureOutput: true,
  failOnError: true,
})
Mock Sandbox Pattern
When testing code that interacts with Daytona sandboxes, use inline mock objects matching the existing test conventions:
typescript
const daytona = {
  create: async () => ({
    id: 'sandbox-id',
    process: {
      executeCommand: async (cmd, cwd, env) => ({
        result: 'output',
        exitCode: 0,
      }),
    },
    fs: {
      uploadFile: async () => undefined,
    },
    getUserHomeDir: async () => '/home/daytona',
  }),
  remove: async () => undefined,
};
Regression Testing
After your new tests pass, always run the existing test suite to catch regressions:
typescript
.step('run-existing-tests', {
  type: 'deterministic',
  dependsOn: ['fix-build'],
  command: 'npm run orchestrator:test 2>&1 | tail -40',
  captureOutput: true,
  failOnError: false,
})

.step('fix-regressions', {
  agent: 'impl',
  dependsOn: ['run-existing-tests'],
  task: `Check the full test suite for regressions caused by our changes.

Test output:
{{steps.run-existing-tests.output}}

If all tests passed, do nothing.
If EXISTING tests broke, read the failing test, find what we broke, fix it.
Most likely cause: constructor signatures changed, new required fields added
without defaults, or import paths shifted.

Run: npm run orchestrator:test
Fix until all tests pass.`,
  verification: { type: 'exit_code' },
})
Full Workflow Template
Here's the complete pattern for a feature that touches the database:
typescript
import { workflow } from '@agent-relay/sdk/workflows';

const result = await workflow('my-feature')
  .description('Add feature X with full E2E validation')
  .pattern('dag')
  .channel('wf-my-feature')
  .maxConcurrency(3)
  .timeout(3_600_000)
  .repairable()

  .agent('impl', { cli: 'claude', preset: 'worker', retries: 2 })
  .agent('tester', { cli: 'claude', preset: 'worker', retries: 2 })

  // ── Phase 1: Read ────────────────────────────────────────────────
  .step('read-target', {
    type: 'deterministic',
    command: 'cat path/to/file.ts',
    captureOutput: true,
  })

  // ── Phase 2: Implement ───────────────────────────────────────────
  .step('edit-target', {
    agent: 'impl',
    dependsOn: ['read-target'],
    task: `Edit path/to/file.ts. Current contents:
{{steps.read-target.output}}
<specific instructions>
Only edit this one file.`,
    verification: { type: 'exit_code' },
  })
  .step('verify-target', {
    type: 'deterministic',
    dependsOn: ['edit-target'],
    command: 'git diff --quiet path/to/file.ts && (echo "NOT MODIFIED"; exit 1) || echo "OK"',
    failOnError: false,
    captureOutput: true,
  })
  .step('fix-target-verification', {
    agent: 'impl',
    dependsOn: ['verify-target'],
    task: `Fix the target edit if verification failed. Output:\n{{steps.verify-target.output}}`,
    verification: { type: 'exit_code' },
  })

  // ── Phase 3: Test infrastructure ─────────────────────────────────
  .step('install-pglite', {
    type: 'deterministic',
    command: 'npm install --save-dev @electric-sql/pglite 2>&1 | tail -5',
    captureOutput: true,
  })
  .step('create-test-helpers', {
    agent: 'tester',
    dependsOn: ['install-pglite'],
    task: 'Create tests/helpers/pglite-db.ts with <DDL for your tables>...',
    verification: { type: 'file_exists', value: 'tests/helpers/pglite-db.ts' },
  })
  .step('create-tests', {
    agent: 'tester',
    dependsOn: ['create-test-helpers', 'fix-target-verification'],
    task: 'Create tests/my-feature.test.ts with <test descriptions>...',
    verification: { type: 'file_exists', value: 'tests/my-feature.test.ts' },
  })

  // ── Phase 4: Test-fix-rerun loop ─────────────────────────────────
  .step('run-tests', {
    type: 'deterministic',
    dependsOn: ['create-tests'],
    command: 'npx tsx --test tests/my-feature.test.ts 2>&1 | tail -60',
    captureOutput: true,
    failOnError: false,
  })
  .step('fix-tests', {
    agent: 'tester',
    dependsOn: ['run-tests'],
    task: `Fix any test failures. Output:\n{{steps.run-tests.output}}`,
    verification: { type: 'exit_code' },
  })
  .step('run-tests-final', {
    type: 'deterministic',
    dependsOn: ['fix-tests'],
    command: 'npx tsx --test tests/my-feature.test.ts 2>&1',
    captureOutput: true,
    failOnError: false,
  })
  .step('fix-tests-final', {
    agent: 'tester',
    dependsOn: ['run-tests-final'],
    task: `If the final test rerun is red, fix and rerun until green. Output:\n{{steps.run-tests-final.output}}`,
    verification: { type: 'exit_code' },
  })

  // ── Phase 5: Build + regression ──────────────────────────────────
  .step('build-check', {
    type: 'deterministic',
    dependsOn: ['fix-tests-final'],
    command: 'npx tsc --noEmit 2>&1 | tail -20; echo "EXIT: $?"',
    captureOutput: true,
    failOnError: false,
  })
  .step('fix-build', {
    agent: 'impl',
    dependsOn: ['build-check'],
    task: `Fix type errors if any. Output:\n{{steps.build-check.output}}`,
    verification: { type: 'exit_code' },
  })
  .step('run-existing-tests', {
    type: 'deterministic',
    dependsOn: ['fix-build'],
    command: 'npm test 2>&1 | tail -40',
    captureOutput: true,
    failOnError: false,
  })
  .step('fix-regressions', {
    agent: 'impl',
    dependsOn: ['run-existing-tests'],
    task: `Fix regressions if any. Output:\n{{steps.run-existing-tests.output}}`,
    verification: { type: 'exit_code' },
  })

  // ── Phase 6: Commit ──────────────────────────────────────────────
  .step('commit', {
    type: 'deterministic',
    dependsOn: ['fix-regressions'],
    command: [
      'npx tsx --test tests/my-feature.test.ts',
      'npm test',
      'git add <files>',
      'git commit -m "feat: ..."',
    ].join(' && '),
    captureOutput: true,
    failOnError: false,
  })
  .step('repair-commit', {
    agent: 'impl',
    dependsOn: ['commit'],
    task: `If commit failed, fix the blocker, rerun the feature and regression tests, and create the commit.
If commit passed, confirm the commit subject.
Output:
{{steps.commit.output}}`,
    verification: { type: 'exit_code' },
  })
  .step('verify-commit-created', {
    type: 'deterministic',
    dependsOn: ['repair-commit'],
    command:
      'git log -1 --pretty=%s | grep -q "^feat: " && echo "COMMIT_OK" || (echo "COMMIT_MISSING"; exit 1)',
    captureOutput: true,
    failOnError: true,
  })

  .onError('retry', { maxRetries: 2, retryDelayMs: 10_000 })
  .run({ cwd: process.cwd() });
Checklist: Is Your Workflow 80-to-100?
CheckHow
Tests existfile_exists verification on test file
Tests actually runDeterministic step executes them
Test failures get fixedAgent step reads output, fixes, re-runs
Final test run is repairableDeterministic rerun captures output, then a repair owner gets one more pass
Build passesnpx tsc --noEmit deterministic step
No regressionsExisting test suite runs after changes
Every edit is verified and repairablegit diff --quiet + grep for tracked-only edits; git status --short -- <paths> when new files/packages may appear; then a fix step
Commit only happens after green evidenceFinal commit step reruns acceptance checks and commits only on zero exit codes
Common Anti-Patterns
Anti-patternWhy it failsFix
Tests written but never executedAgent claims they pass, they don'tAdd deterministic run-tests step
Single failOnError: true test runFirst failure kills workflow, no chance to fixUse repairable run-fix-rerun-final-fix loops
No regression testNew feature works, old features breakRun npm test after build check
Agent asked to "write and run tests" in one stepAgent writes tests, runs them, they fail, it edits, output is garbledSeparate write/run/fix into distinct steps
PGlite DDL doesn't match Drizzle schemaTests pass on wrong schemaDerive DDL from schema.ts or test with real migration
Final test output not handed to an agentBroken tests can stop the run or get ignoredAdd a final repair owner before commit
Testing only happy pathEdge cases break in prodSpecify edge case tests in the task prompt
No verify gate after agent editsAgent exits 0 without writing anythingAdd git diff --quiet check after every edit, then route failures to a repair step
git diff --quiet for new package/test directoriesUntracked files are invisible, so valid new artifacts can look like "no changes"Use git status --short -- <paths> and a repairable capture → fix → final gate pattern
Committing after failOnError: false without checking exitsBroken work can be committed because the shell step returned successfullyIn commit-if-green, record each exit code and skip commit unless all are zero

© AgentWorkforce, Apache-2.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/relay-80-100-workflow of AgentWorkforce/relay.

Open the folder on GitHubat commit 20ae3e3

Compare with similar skills

Relay 80 100 Workflow next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Relay 80 100 Workflow compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Relay 80 100 Workflow this skillAgentWorkforce/relay866—~5.7kAutomated safety check: PassApache-2.0
Airbyte Postgres Source E2E Testsairbytehq/airbyte22k—~2.5kAutomated safety check: PassCustom licence
Postgres CDC E2E Test Harnessairbytehq/airbyte22k—~1.9kAutomated safety check: PassCustom licence
Twenty QA Scouttwentyhq/twenty58k—~2kAutomated safety check: PassCustom licence
E2Eopenathleteorg/openathlete100—~675Automated safety check: PassAGPL-3.0
Pure Lsp SQL E2Efinos/legend-engine112—~1.8kAutomated safety check: PassApache-2.0

Similar skills

  • Official

    Starts a local PostgreSQL 16 container, loads SQL fixtures and runs the Airbyte spec, check, discover and read commands against a chosen source-postgres image.

    22k GitHub stars~2.5k tokensUpdated today
    Testing & QAAuto-check passed
  • Official

    Reproduces PostgreSQL logical-decoding CDC behavior for Airbyte's source-postgres connector on a local backend, with CDC fixtures, a catalog and smoke case scripts.

    22k GitHub stars~1.9k tokensUpdated today
    Testing & QAAuto-check passed
  • Twenty QA Scout

    twentyhq/twenty

    Browser QA for a pull request against a running Twenty app: scenarios drawn from the diff, run in a real browser, checked in the database and logs, and closed with a verdict and report.

    58k GitHub stars~2k tokensUpdated today
    Testing & QAAuto-check passed
  • E2E

    openathleteorg/openathlete

    Run, debug or extend the OpenAthlete Playwright end-to-end tests, which exercise the production Docker images (API, worker, web, PostgreSQL, Redis) through the API and a real browser on desktop and…

    100 GitHub stars~675 tokensUpdated yesterday
    Testing & QAAuto-check passed
  • Pure Lsp SQL E2E

    finos/legend-engine

    Runs cases from the legend-engine SQL e2e parity corpus (TestPostgresParity, ~2300 SQL cases compared against a real Postgres) through the warm interpreted Pure LSP with pure-sql-e2e, so edits to…

    112 GitHub stars~1.8k tokensUpdated yesterday
    Testing & QAAuto-check passed
  • Local Platform E2E

    computesdk/benchmarks

    Stand up benchmarks-platform locally (Postgres + MinIO + ClickHouse in docker) and run a real @benchsdk/runner benchmark against it, with no cloud or provider credentials.

    126 GitHub stars~3k tokensUpdated yesterday
    DatabasesAuto-check: notes

More from AgentWorkforce/relay

All 14 skills in this repo
  • A skill your agent uses when testing web applications with visual verification - automates Chrome browser interactions, element selection, and screenshot capture for confirming UI functionality

    866 GitHub starsUsed in 1 repo~2.2k tokens
    Auto-check passed
  • Agent Relay

    AgentWorkforce/relay

    A skill your agent uses when you need Codex to coordinate multiple agents through Agent Relay for peer-to-peer messaging, lead/worker handoffs, or shared status tracking across sub-agents and…

    866 GitHub stars~1.7k tokensUpdated today
    Auto-check passed
  • Debugging Websocket Issues

    AgentWorkforce/relay

    A skill your agent uses when seeing WebSocket errors like "Invalid frame header", "RSV1 must be clear", or "WSERRUNEXPECTEDRSV1" - covers multiple WebSocketServer conflicts, compression issues, and…

    866 GitHub starsUsed in 1 repo~1.3k tokens
    Auto-check passed
  • GitHub OAuth Nango Integration

    AgentWorkforce/relay

    A skill your agent uses when implementing GitHub OAuth + GitHub App authentication with Nango - provides two-connection pattern for user login and repo access with webhook handling

    866 GitHub starsUsed in 1 repo~3.4k tokens
    Auto-check passed
  • Implementing Command Palettes

    AgentWorkforce/relay

    A skill your agent uses when building Cmd+K command palettes in React - covers keyboard navigation with arrow keys, keeping selected items in view with scrollIntoView, filtering with shortcut…

    866 GitHub starsUsed in 1 repo~2.5k tokens
    Auto-check passed
  • Setting Up Relayfile

    AgentWorkforce/relay

    A skill your agent uses when an agent or human needs to set up relayfile end-to-end so agents can read and write provider files through a local mount.

    866 GitHub starsUsed in 1 repo~3.3k tokens
    Auto-check passed

Works with

Categories

Questions about Relay 80 100 Workflow

What does Relay 80 100 Workflow do?

A skill your agent uses when writing agent-relay workflows that must fully validate features end-to-end before merging. Relay 80 100 Workflow is an agent skill from AgentWorkforce/relay. Use when writing agent-relay workflows that must fully validate features end-to-end before merging.

When should I use Relay 80 100 Workflow?

Relay 80 100 Workflow fits situations like: writing agent-relay workflows that must fully validate features end-to-end before merging; tasks that involve End-to-end testing.

How do I install Relay 80 100 Workflow in Claude Code?

Run `npx skills add AgentWorkforce/relay --skill relay-80-100-workflow -a claude-code`. Or copy the skill folder (.agents/skills/relay-80-100-workflow in AgentWorkforce/relay) into .claude/skills/relay-80-100-workflow in your project. Claude Code loads it when a task matches its description.

How do I install Relay 80 100 Workflow in Codex?

Run `npx skills add AgentWorkforce/relay --skill relay-80-100-workflow -a codex`. Or copy the skill folder (.agents/skills/relay-80-100-workflow in AgentWorkforce/relay) into .agents/skills/relay-80-100-workflow in your project. Codex loads it when a task matches its description.

Can I use Relay 80 100 Workflow in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add AgentWorkforce/relay --skill relay-80-100-workflow -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/relay-80-100-workflow, .gemini/skills/relay-80-100-workflow, .github/skills/relay-80-100-workflow and .opencode/skills/relay-80-100-workflow in your project.

What does Relay 80 100 Workflow need to run?

Going by SKILL.md and its folder, Relay 80 100 Workflow needs the command-line tools its instructions call (git, npx and npm). Our summary lists: Node.js.

Does Relay 80 100 Workflow access the network?

SKILL.md contains no URLs. Its commands use git, npx and npm, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Relay 80 100 Workflow safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Relay 80 100 Workflow use?

Relay 80 100 Workflow is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Relay 80 100 Workflow use?

About 5.7k tokens (SKILL.md is roughly 23k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Relay 80 100 Workflow?

Skills that share tags, products or a category with Relay 80 100 Workflow: Airbyte Postgres Source E2E Tests (airbytehq/airbyte, 22k stars), Postgres CDC E2E Test Harness (airbytehq/airbyte, 22k stars), Twenty QA Scout (twentyhq/twenty, 58k stars) and E2E (openathleteorg/openathlete, 100 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Relay 80 100 Workflow?

AgentWorkforce (a GitHub organization) maintains it in AgentWorkforce/relay, which has 866 GitHub stars. The repository holds 14 skills in this directory. The repository was last updated on October 8, 2026.

Source: AgentWorkforce/relay on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.