Skip to content

Repository files navigation

🚀 Relay

The ship & operate skill of the Forge suite. From a green build to healthy production — and back.

License: MIT Made by Mohammed Nasher AI Skill Part of: Forge PRs Welcome GitHub stars

Created by Mohammed Nasher · Open source (MIT) · Free for anyone to use


Relay is a self-contained ship & operate engine for AI coding assistants. You point it at a project and it carries your code the last mile: it designs the CI/CD pipeline, deploys safely with a rollback path, watches the release run with observability and golden-signal alerts, and — the part people skip until it hurts — runs the incident and the blameless postmortem when a release goes wrong.

A relay carries a signal the last mile and hands it off cleanly. Relay does that for your code: from a passing build through the gates to production, and back when it isn't healthy.

Who built this? Relay is designed and authored by Mohammed Nasher (@mhd-nasher). Released open source under MIT — use it, fork it, ship with it. If it helps you, a ⭐ and a mention go a long way.

Why Relay is different

Most ops tooling fails in one of two ways: it ships blind (a "deploy" button with no gate, no rollback, no smoke test), or it drowns the team in ceremony and noise (an enterprise pipeline and a pager that cries wolf on a weekend project). Relay refuses both:

  1. The Don't-Ship-Blind Law. Never deploy without the gates green and a rollback path ready. No "just this once" deploy past a red test, a failed security scan, or with no way back. If it can't show the gates passed and name the rollback, it doesn't ship. This is Evidence-Before-Done in operational form.
  2. It orchestrates; it does not own. The pipeline is the Forge suite assembled — lint (Lens) → test (Anvil) → security scan (Bastion) → build → deploy → smoke (Anvil's E2E). Relay wires and gates on each sibling's verdict; it never writes a test, judges style, or rules on a vulnerability itself.
  3. A pipeline reduces risk; it does not guarantee a flawless release. Green gates mean "our checks passed," never "this release is perfect." Relay says so, plainly.
  4. Observability detects; it does not prevent. Metrics and alerts catch what slipped through — they are detection, not prevention. Prevention is Cairn/Anvil/Lens/Bastion's job upstream.
  5. It's stack-aware and anti-ceremony. A solo MVP gets a lean pipeline and basic monitoring; a team/regulated system gets the full gate set, canary, and on-call. It won't impose enterprise ops on a weekend project — and it reads the same complexity budget Cairn set.
  6. It's verifiable. Relay ships with evals that prove it activates correctly, flags real ops defects, and refuses to ship blind or do a sibling's job.

The modes

Mode For Workflow
Mode 0 — Guided First Deploy (Beginner) "I've never shipped this; walk me through it." workflows/guided-first-deploy-for-beginners.md
Mode A — Design a CI/CD Pipeline Build the install→lint→test→scan→build→deploy→smoke pipeline. workflows/design-cicd-pipeline.md
Mode B — Add Observability Logs, metrics, traces, golden-signal alerts. workflows/add-observability.md
Mode C — Incident Response / Postmortem Something is broken in prod, or just was. workflows/incident-response.md

Metadata

  • Version: 1.0.0
  • Name: relay
  • Author: Mohammed Nasher (@mhd-nasher)
  • Tagline: from a green build to healthy production — and back
  • Owns: ship & operate — CI/CD, safe deploy, rollback, observability, alerting, incident response
  • Modes: Guided (beginner) · Design CI/CD · Add Observability · Incident Response / Postmortem
  • Stack-aware: Firebase deploy + emulator-in-CI + staged rollout (flagship) · Flutter store releases · Next.js/Vercel preview→prod
  • Citable: every finding maps to a stable D-### id (reference/checks.md)
  • Category: DevOps / SRE — delivery, deployment, observability, incident response
  • Risk: Low (advisory — designs, proposes, and gates; the human pulls the trigger on every production deploy, Rules change, and money/auth flag flip)
  • License: MIT
  • Part of: the Forge suite (security member: Bastion)

What's inside

relay/
├── SKILL.md                          # Entry point: identity, Honesty Contract, Step 0, the modes, top checks, the Don't-Ship-Blind Law
├── README.md                         # This file
├── FORGE_DNA.md                      # The shared suite contract (boundary contract, philosophy)
├── LICENSE                           # MIT
├── CHANGELOG.md                      # Version history
├── CITATION.cff                      # Citation metadata
├── CONTRIBUTING.md                   # How to add deploy profiles / checks / evals (skill-TDD)
├── reference/
│   ├── checks.md                     # ALL ops checks: D-### (CI/CD, safe deploy, observability, alerting, incident, secrets) — the backbone
│   ├── cicd.md                       # Pipeline anatomy: the ordered, blocking gates
│   ├── stack-deploy-profiles.md      # Per-stack deploy/CI profiles (Firebase deepest) — load in Step 0
│   ├── safe-deploy.md                # Rollback, canary, flags, Rules, smoke — the Don't-Ship-Blind detail
│   ├── observability.md              # Logs, metrics, traces, golden signals
│   ├── alerting.md                   # Symptoms over causes, no fatigue, runbooks, P0 pages
│   ├── incident-response.md          # Detect → mitigate → communicate → resolve; blameless postmortem
│   ├── secrets-and-config-in-ci.md   # Secret store, env promotion, 12-factor config
│   └── glossary.md                   # Ops vocabulary, defined plainly
├── workflows/
│   ├── guided-first-deploy-for-beginners.md  # Mode 0 — plain-language guided first deploy
│   ├── design-cicd-pipeline.md       # Mode A — wire the gates
│   ├── add-observability.md          # Mode B — golden signals + alerts
│   └── incident-response.md          # Mode C — incident + postmortem
├── checklists/
│   ├── pre-launch-ops.md             # The "before you go live" ops gate
│   └── pipeline-review.md            # Tickable, tied to D-### ids
├── templates/
│   ├── pipeline-template.md          # A GitHub Actions workflow wiring Anvil + Lens + Bastion as stages
│   ├── postmortem-template.md        # Blameless postmortem
│   └── runbook-template.md           # Per-alert runbook
├── examples/
│   ├── firebase-functions-github-actions-pipeline.md   # lint → test → security-scan → deploy with rollback
│   └── observability-for-a-serverless-money-path.md     # golden signals + symptom alerts on the money path
├── scripts/
│   └── pipeline_lint.py              # Sanity-checks a CI workflow YAML for missing test/security gates + a missing rollback note (self-tested)
└── evals/
    ├── trigger-eval.json             # Activation tests (should / shouldn't trigger; boundary cases route to siblings)
    ├── evals.json                    # Behavior: ops defects it MUST flag + must-NOT ship-blind / do-a-sibling's-job cases
    └── README.md                     # Skill-TDD (RED · GREEN · REFACTOR) for ops evals

Install

Personal skill (recommended):

# Claude Code
cp -R relay ~/.claude/skills/

Then start a new session. Relay auto-activates when you discuss setting up CI/CD, deploying, rollback, observability/alerting, or incident response / postmortems.

Project skill:

mkdir -p .claude/skills && cp -R relay .claude/skills/

How to use it

Beginner — "I've never deployed this":

"I built a booking app on Firebase. How do I actually ship it to production without breaking anything?"

Relay runs Step 0 (detects Firebase, reads Cairn's complexity budget, maps the money/auth critical path), then Mode 0: a plain-language guided first deploy with progress gauges — gates wired, rollback named, smoke test on the critical journey, before users see it.

Design a pipeline:

"Build me a GitHub Actions pipeline that lints, tests, security-scans, and deploys my Cloud Functions."

Relay wires the ordered, blocking gates (lint (Lens) → test (Anvil) → security (Bastion) → build → deploy → smoke), each sibling owning its stage, with a rollback path and a post-deploy smoke test (D-001/D-002/D-010/ D-015).

Incident:

"My deploy just broke prod — what do I do?"

Relay runs Mode C: mitigate first (roll back / flip the flag — D-041), communicate, then root-cause, and writes the blameless postmortem with tracked action items (D-040…D-043).

Verify it works

# Activation + behavior tests live in evals/. See evals/README.md for the skill-TDD workflow.
python3 -c "import json; json.load(open('relay/evals/trigger-eval.json')); json.load(open('relay/evals/evals.json')); print('evals OK')"

# The pipeline linter is self-tested (proves it catches a gate-less pipeline AND leaves a good one clean):
python3 relay/scripts/pipeline_lint.py --self-test

# Lint a real CI workflow for missing test/security gates and a missing rollback note (verify each before acting):
python3 relay/scripts/pipeline_lint.py <path-to-workflow.yml>

Scope & honesty

Relay produces a delivery & operations plan — a wired pipeline, a safe-deploy procedure with rollback, observability and alerting, and an incident/postmortem flow. It does not, by itself, make a release flawless or a system immune to outages. A pipeline reduces deploy risk; it does not guarantee a perfect release, and observability detects problems; it does not prevent them. Relay is stack-aware (it won't add ops ceremony a small project doesn't need, and it states what it suppresses and why), it shows the actual gate results and post-deploy smoke output before it says "deployed", and it leaves every production deploy, Firestore Rules change, and money/auth feature-flag flip for a human to pull the trigger. It orchestrates its siblings — it gates on Anvil's tests, Lens's quality checks, and Bastion's security scan, and it never writes tests, judges style, or rules on vulnerabilities itself.

The Forge suite & the boundary contract

Relay is the ship & operate member of the Forge suite — eight composable skills that carry a product through its whole lifecycle, sharing one philosophy via FORGE_DNA.md so they reinforce instead of collide:

Skill Owns
Helm The product loop — bets, priorities, verdicts (Relay owns health; Helm owns outcomes)
Loom Feature definition & completeness
Facet The interface (its design-system migration is Relay's rollout)
Cairn Architecture & structure
Anvil Testing
Lens Code quality & review
Bastion Security & resilience (the suite's security member)
Relay Ship & operate (this skill)

The natural flow: Helm sets the course → Loom defines → Facet gives it a face → Cairn designs → Anvil tests → Lens cleans → Bastion guards → Relay ships → Helm reads the results — and rolls back when it must. Each decision has exactly one owning skill; when skills interact they defer to the owner instead of re-deciding (the boundary contract, Forge DNA §4). Relay's pipeline runs Anvil (tests), Lens (quality gate), and Bastion (security scan) as stages and gates on their verdicts — it owns none of their logic. Structure decisions defer to Cairn. The suite's security member is Bastion; where Relay touches a security concern (logging hygiene, Rules correctness, denial-of-wallet), it cites Bastion by name and the relevant B- id and never re-decides security itself.

Author & Credits

Relay is created and maintained by Mohammed Nasher.

  • 👤 Author: Mohammed Nasher
  • 🐙 GitHub: @mhd-nasher
  • 📦 Repository: github.com/mhd-nasher/relay
  • 🧩 Part of: the Forge suite — composes with Cairn, Anvil, Lens, and Bastion (the security member)
  • 💬 Contact / questions / collaboration: open an issue or start a discussion on the repo.

If you use Relay in a project, a credit back to @mhd-nasher is appreciated. See CITATION.cff for citation details.

License

MIT © Mohammed Nasher (@mhd-nasher). Free to use, modify, and distribute — keep the copyright and license notice.


Built with intent by Mohammed Nasher 🚀

Cairn designs, Anvil proves, Lens cleans, Bastion guards, Relay ships — and rolls back when it must. If Relay helped you ship something safer, drop a ⭐.

About

Part of the Forge suite by @mhd-nasher — composable Claude Code skills.

Topics

Resources

Contributing

Stars

0 stars

Watchers

0 watching

Forks

Releases

Packages

Contributors

Languages