{"id":50714587,"url":"https://github.com/signalridge/slipway","last_synced_at":"2026-06-09T18:00:40.874Z","repository":{"id":360694726,"uuid":"1171529024","full_name":"signalridge/slipway","owner":"signalridge","description":"Spec-driven development with full lifecycle accountability for Claude, Codex, Cursor \u0026 Gemini","archived":false,"fork":false,"pushed_at":"2026-06-04T05:20:23.000Z","size":1351,"stargazers_count":13,"open_issues_count":5,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-06-04T07:12:24.208Z","etag":null,"topics":["agentic-workflows","ai-agents","ai-coding","audit","claude","claude-code","cli","codex","cursor","developer-tools","gemini","go","golang","governance","opencode","software-delivery","spec-driven-development","workflow"],"latest_commit_sha":null,"homepage":"https://signalridge.github.io/slipway/","language":"Go","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/signalridge.png","metadata":{"files":{"readme":"README.md","changelog":"CHANGELOG.md","contributing":"docs/contributing.md","funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-03-03T10:30:17.000Z","updated_at":"2026-06-04T05:20:14.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/signalridge/slipway","commit_stats":null,"previous_names":["signalridge/slipway"],"tags_count":0,"template":false,"template_full_name":null,"purl":"pkg:github/signalridge/slipway","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/signalridge%2Fslipway","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/signalridge%2Fslipway/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/signalridge%2Fslipway/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/signalridge%2Fslipway/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/signalridge","download_url":"https://codeload.github.com/signalridge/slipway/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/signalridge%2Fslipway/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34118757,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-09T02:00:06.510Z","response_time":63,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["agentic-workflows","ai-agents","ai-coding","audit","claude","claude-code","cli","codex","cursor","developer-tools","gemini","go","golang","governance","opencode","software-delivery","spec-driven-development","workflow"],"created_at":"2026-06-09T18:00:26.740Z","updated_at":"2026-06-09T18:00:40.865Z","avatar_url":"https://github.com/signalridge.png","language":"Go","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cdiv align=\"center\"\u003e\n\n\u003cimg alt=\"Slipway - Governance CLI for AI-assisted software delivery\" src=\"docs/assets/brand/slipway-mark.svg\" width=\"112\"\u003e\n\n\u003cbr/\u003e\n\u003cbr/\u003e\n\n\u003cp\u003e\n  \u003ca href=\"https://github.com/signalridge/slipway/actions/workflows/ci.yml\"\u003e\u003cimg alt=\"CI\" src=\"https://img.shields.io/github/actions/workflow/status/signalridge/slipway/ci.yml?branch=main\u0026style=for-the-badge\u0026logo=github\u0026label=CI\"\u003e\u003c/a\u003e\u0026nbsp;\n  \u003ca href=\"https://github.com/signalridge/slipway/actions/workflows/docs.yml\"\u003e\u003cimg alt=\"Docs\" src=\"https://img.shields.io/github/actions/workflow/status/signalridge/slipway/docs.yml?branch=main\u0026style=for-the-badge\u0026logo=materialformkdocs\u0026label=Docs\"\u003e\u003c/a\u003e\u0026nbsp;\n  \u003ca href=\"https://github.com/signalridge/slipway/releases\"\u003e\u003cimg alt=\"Release\" src=\"https://img.shields.io/github/v/release/signalridge/slipway?style=for-the-badge\u0026logo=github\"\u003e\u003c/a\u003e\u0026nbsp;\n  \u003ca href=\"https://pkg.go.dev/github.com/signalridge/slipway\"\u003e\u003cimg alt=\"Go Reference\" src=\"https://img.shields.io/badge/Go-Reference-00ADD8?style=for-the-badge\u0026logo=go\u0026logoColor=white\"\u003e\u003c/a\u003e\n\u003c/p\u003e\n\n\u003cp\u003e\n  \u003ca href=\"docs/installation.md\"\u003e\u003cimg alt=\"Homebrew Cask\" src=\"https://img.shields.io/badge/Homebrew_Cask-FBB040?style=flat-square\u0026logo=homebrew\u0026logoColor=black\"\u003e\u003c/a\u003e\n  \u003ca href=\"docs/installation.md\"\u003e\u003cimg alt=\"Scoop\" src=\"https://img.shields.io/badge/Scoop-00BFFF?style=flat-square\u0026logo=windows\u0026logoColor=white\"\u003e\u003c/a\u003e\n  \u003ca href=\"docs/installation.md\"\u003e\u003cimg alt=\"AUR\" src=\"https://img.shields.io/badge/AUR-1793D1?style=flat-square\u0026logo=archlinux\u0026logoColor=white\"\u003e\u003c/a\u003e\n  \u003ca href=\"docs/installation.md\"\u003e\u003cimg alt=\"Nix\" src=\"https://img.shields.io/badge/Nix-5277C3?style=flat-square\u0026logo=nixos\u0026logoColor=white\"\u003e\u003c/a\u003e\n  \u003ca href=\"docs/installation.md\"\u003e\u003cimg alt=\"Docker\" src=\"https://img.shields.io/badge/Docker-2496ED?style=flat-square\u0026logo=docker\u0026logoColor=white\"\u003e\u003c/a\u003e\n  \u003ca href=\"docs/installation.md\"\u003e\u003cimg alt=\"deb\" src=\"https://img.shields.io/badge/deb-A81D33?style=flat-square\u0026logo=debian\u0026logoColor=white\"\u003e\u003c/a\u003e\n  \u003ca href=\"docs/installation.md\"\u003e\u003cimg alt=\"rpm\" src=\"https://img.shields.io/badge/rpm-EE0000?style=flat-square\u0026logo=redhat\u0026logoColor=white\"\u003e\u003c/a\u003e\n  \u003ca href=\"docs/installation.md\"\u003e\u003cimg alt=\"apk\" src=\"https://img.shields.io/badge/apk-0D597F?style=flat-square\u0026logo=alpinelinux\u0026logoColor=white\"\u003e\u003c/a\u003e\n  \u003ca href=\"docs/installation.md\"\u003e\u003cimg alt=\"Go\" src=\"https://img.shields.io/badge/Go-00ADD8?style=flat-square\u0026logo=go\u0026logoColor=white\"\u003e\u003c/a\u003e\n\u003c/p\u003e\n\n[Documentation](https://signalridge.github.io/slipway/) | [Installation](docs/installation.md) | [Release Notes](CHANGELOG.md)\n\n\u003c/div\u003e\n\n# Slipway\n\n**Governance that keeps your AI coding agent honest: \"done\" means proven, not promised. You drive it in plain language and never memorize a slash command.**\n\nAI coding agents are fast, but they cut corners. They skip the tests, drift from the plan, and call work \"done\" that was never verified. Slipway is a local, Git-native governance layer that makes that hard to fake: it turns the agent's work into a durable, inspectable change record and keeps the lifecycle authority in the repository itself, not in a hosted service. Your AI tool does the work; Slipway decides when it is actually done. It works with **Claude Code, Codex, Cursor, Gemini, and OpenCode**.\n\n- **The model can't fake \"done.\"** Completion is gated on fresh review *and* verification evidence: checks compiled into the CLI, not advisory prompts the agent can rationalize past. If the evidence goes stale or the work drifts from the plan, Slipway reopens the change instead of waving it through.\n- **No commands to learn.** After a one-time `slipway init`, a generated entry skill routes your ordinary plain-language requests through the governed lifecycle; on tools that support session hooks, live governed state is also surfaced every session, unprompted. You describe the change, and the agent drives the process.\n- **Lighter on tokens.** The governance logic runs as compiled Go in the CLI, not as phase prompts your model re-reads and re-reasons every turn. One thin entry skill stays resident; stage skills load only when the CLI asks for them.\n\n## See it in action\n\nYou talk to your AI tool the way you already do. The agent handles the governance, and you never type a Slipway command:\n\n```text\nYou:  Add a --dry-run flag to the export command.\n\n(The agent already knows this repo is governed and that no change is active:\n the entry skill routes it there, and on tools with session hooks that state\n is pushed in automatically, so no action is needed from you.)\n\nAgent (routing on its own):\n  → slipway new      captures intent, scope, and guardrail class\n  → slipway next     intake → planning; writes requirements / decision / tasks\n  → implements the flag, runs your test + build commands\n  → slipway run      spec review, quality review, goal verification\n  → done-ready ✓     every step backed by evidence committed beside the code\n\nYou:  Looks good, finalize it.\n\nAgent:\n  → slipway done     archives the terminal state\n\nYou never typed a slash command. Slipway handed the agent the lifecycle;\nthe agent drove it.\n```\n\nAnd if the agent had tried to call it `done` before the tests ran and the review evidence existed? `slipway done` refuses: the gate lives in the CLI, not in a prompt the agent can decide to skip.\n\n## How Slipway compares\n\nSpec, workflow, and skill toolkits for AI coding are all good at *structuring* work. The axis that sets Slipway apart is **where the rules live and whether the model can ignore them**: almost all of them encode the process as prompts or Markdown the agent is *asked* to follow, so the gates stay advisory. Slipway compiles the process into a deterministic CLI backed by repo evidence, so the gates fail closed.\n\n| Tool | How you drive it | Enforcement of \"done\" |\n| --- | --- | --- |\n| [Spec Kit](https://github.com/github/spec-kit) (GitHub) | `/speckit.*` slash command per phase | Advisory: an incomplete checklist passes on a \"yes\" |\n| [OpenSpec](https://github.com/Fission-AI/OpenSpec) | `/opsx:*` slash commands | Advisory by design: \"fluid, not rigid,\" and verify is optional |\n| [spec-kitty](https://github.com/Priivacy-ai/spec-kitty) | `/spec-kitty.*` plus a `spec-kitty next` autopilot loop | Partial: `merge` gates on status, but review is an advisory \"nudge\" |\n| [gsd](https://github.com/gsd-build/get-shit-done) | 80+ `/gsd-*` slash commands | Advisory: hooks must not block, and `--skip-*` / `--auto` bypass |\n| [superpowers](https://github.com/obra/superpowers) | Skills auto-fire from a session bootstrap (no commands) | Self-discipline: an \"Iron Law\" the model is *asked* to obey |\n| **Slipway** | **Plain language; an entry skill auto-fires (no commands)** | **Compiled, fail-closed**: gates live in the CLI and repo evidence |\n\nThe pattern is consistent: those tools enforce process by asking the model to comply, while Slipway enforces it in code the model runs but can't rewrite. (superpowers is the closest on *experience*, since its skills also auto-trigger without slash commands, but its rules live in the model's context, not in a binary.) On capability the lines blur, because Slipway also runs dependency-ordered waves, dedicated worktrees, and TDD governance, so the real divide is enforcement, not feature count. Where the peers genuinely lead is **reach and ecosystem**: far more supported agents, more mileage, and models Slipway lacks, like OpenSpec's delta-specs or Spec Kit's large integration catalog.\n\n### What Slipway deliberately trades off\n\nSeveral of the differences above are intentional, not gaps. Slipway optimizes for *provable* outcomes on changes that matter, and accepts the costs that come with that:\n\n| Dimension | Most spec / skill toolkits | Slipway's deliberate choice | What the trade-off buys |\n| --- | --- | --- | --- |\n| Agent reach | 15 to 30+ agents via generated prompt files | 5 first-class adapters (growing) | A tested contract per tool, not a lowest-common-denominator prompt |\n| Install \u0026 runtime | `npx` / `uvx`, no binary | A single versioned Go binary | One deterministic engine; no per-session prompt or version drift |\n| State integrity | Repo or spec files the model maintains | Engine-owned state with freshness digests | Stale or hand-edited evidence is detected, not trusted |\n| Flexibility | Edit any artifact anytime (\"fluid\") | A staged lifecycle that reopens on drift | Plan and code can't silently diverge, at the cost of less freeform editing |\n| Speed vs. assurance | Fast by default; gates optional | Gates are mandatory and freshness-checked | Slower on throwaway edits; safe on the changes that matter |\n| Failure mode | Skipping a step degrades silently | Missing or stale evidence fails closed | You learn the work isn't done *before* you ship, not after |\n\nOne thing is **not** a deliberate trade-off, just where Slipway is today: mileage. It is younger and less battle-tested than Spec Kit or superpowers, and the five-tool list is still growing. The bet is that fail-closed depth is the harder thing to retrofit later, and breadth and mileage come with time.\n\n## Depth, not just a gate\n\nA single \"did you run the tests?\" check is easy to fake. The point of Slipway is the depth behind the gate: a chain of stage-owned checkpoints that each demand their own evidence, so quality is enforced all the way through instead of rubber-stamped at the end.\n\n- **Intake** fixes intent, scope, open questions, and a **guardrail class**. Sensitive domains (auth, credentials/PII, financial, schema migration, irreversible ops, external-API contracts) fail closed harder and get no bypass, force-close, or private attestation path.\n- **Planning** binds a `requirements.md` / `decision.md` / `tasks.md` bundle that execution is held to, so the agent can't quietly re-scope mid-flight.\n- **Review** is *two independent passes* (spec-compliance, then code-quality) read with fresh context, not by the agent that wrote the code.\n- **Goal verification** re-checks the acceptance criteria against fresh evidence before anything may claim done.\n- **Drift and freshness** are enforced, not trusted: edit the plan or let evidence go stale, and Slipway reopens the *earliest* affected stage and re-walks it. A change can't limp to done on half-stale proof.\n\nThat chain is what command-driven spec toolkits and in-context skill packs don't carry. Instead of a single end-of-run checkbox, you get an auditable trail of stage-owned evidence that the next session, human or AI, can re-inspect and trust.\n\n## Quick start\n\n**1. Install** (pick one; full matrix in [Installation](docs/installation.md)):\n\n```bash\nbrew install --cask signalridge/tap/slipway   # macOS\nscoop install slipway                          # Windows (after adding the bucket)\ngo install github.com/signalridge/slipway@latest   # any platform with Go\n```\n\nLinux users also have `.deb` / `.rpm` / `.apk`, the `ghcr.io/signalridge/slipway` container image, AUR `slipway-bin`, and Nix. See [Installation](docs/installation.md) for every path and checksum verification.\n\n**2. Initialize your repo and generate the adapter for your AI tool:**\n\n```bash\nslipway init --tools claude        # or: codex, cursor, gemini, opencode\nslipway init --tools all           # generate every adapter\n```\n\nFor each `--tools` target, this writes `.slipway.yaml`, a managed `.gitignore` block, and the governed skills that teach the AI tool how to enter the lifecycle. Tools that support session hooks also get one. (Omit `--tools` to set up runtime only.)\n\n**3. Just talk to your AI tool.** Start a new session and describe what you want: \"add a retry to the upload client,\" \"fix the off-by-one in pagination,\" \"refactor the auth middleware.\" The entry skill routes the request, and on tools with session hooks governed state is surfaced automatically, so Slipway walks it from intake to done-ready. No command to remember.\n\n\u003cdetails\u003e\n\u003csummary\u003e\u003cstrong\u003ePrefer explicit control, or scripting?\u003c/strong\u003e The same lifecycle is available command-first.\u003c/summary\u003e\n\n\u003cbr/\u003e\n\n```bash\nslipway new \"refresh governance docs\" --preset standard\nslipway next --json        # read-only handoff: what's next, what's blocking\nslipway run --json         # advance until a skill, blocker, or done-ready stop\nslipway status --json\nslipway done --json\n```\n\n\u003c/details\u003e\n\n## How it works\n\n\u003cdiv align=\"center\"\u003e\n  \u003cimg alt=\"Slipway governed lifecycle: new, S0 Intake, S1 Plan, S2 Execute, S3 Review, S4 Verify, done\" src=\"docs/assets/diagrams/lifecycle.svg\" width=\"920\"\u003e\n\u003c/div\u003e\n\nA governed change moves through intake → planning → execution → review → verification → closeout. `change.yaml` holds the current authority; mutating lifecycle events append to `events/lifecycle.jsonl`; evidence accumulates beside the code. `slipway next`, `slipway status`, and `slipway validate` are read-only inspection surfaces; `slipway new`, `slipway run`, `slipway done`, and a few others are the explicit mutation surfaces.\n\nThe plain-language experience rests on generated surfaces per AI tool:\n\n- **A thin entry skill** (every supported tool) whose description triggers on natural-language change requests and routes into the right CLI command. It never re-implements governance; it hands off to the CLI, and the CLI decides state, readiness, recovery, and the next governed step.\n- **A session-start hook** (on tools that support session hooks: Claude, Cursor, Gemini, OpenCode, but not Codex) that asks the CLI for current governed state every session and injects a compact handoff, so the agent knows whether a change is active before you prompt it. Where a tool has no hook, the entry skill has the agent pull the same state with `slipway status --json` on first contact, so enforcement is identical and the state is just pulled instead of pushed.\n\nAll these surfaces emit `--json`, so agents and scripts get structured handoffs, and `slipway health`, `repair`, `stats`, and `codebase-map` inspect or recover local state. When evidence drifts, `slipway next` shows the recovery path and `slipway run` re-walks it. The deeper JSON contracts live in the [Operator Guide](docs/operator-guide.md#diagnostic-json) and [Command Reference](docs/commands.md).\n\n## Design philosophy\n\n- **One current authority.** A single `change.yaml` owns lifecycle state; logs and Markdown support it but never replace it.\n- **Human-readable, machine-checkable.** Markdown stays readable to people, while stable sections and YAML give the runtime something deterministic to inspect.\n- **Smallest useful control plane.** Slipway stays narrower than adjacent spec, workflow, and agent frameworks by keeping authority in the CLI and repository artifacts.\n\nSee [Design Philosophy](docs/design.md) for the longer architecture explanation.\n\n## AI tool adapters\n\nGenerate host-tool surfaces with `slipway init --tools \u003cid\u003e` (`claude`, `codex`, `cursor`, `gemini`, `opencode`, `all`, or `none`). Use `--refresh` to regenerate managed files deterministically.\n\n\u003cdetails\u003e\n\u003csummary\u003eGenerated surfaces per tool\u003c/summary\u003e\n\n\u003cbr/\u003e\n\n| Tool | Generated surfaces |\n| --- | --- |\n| Claude | `.claude/skills/slipway-*/SKILL.md`, `.claude/commands/slipway/*.md`, `.claude/hooks/slipway-session-start.sh`, `.claude/settings.json` |\n| Codex | `.codex/skills/slipway-*/SKILL.md`, `$CODEX_HOME/prompts/slipway-*.md` |\n| Cursor | `.cursor/skills/slipway-*/SKILL.md`, `.cursor/commands/*.md`, `.cursor/hooks/slipway-session-start.sh` |\n| Gemini | `.gemini/skills/slipway-*/SKILL.md`, `.gemini/commands/slipway/*.toml`, `.gemini/hooks/slipway-session-start.sh`, `.gemini/settings.json` |\n| OpenCode | `.opencode/skills/slipway-*/SKILL.md`, `.opencode/commands/slipway-*.md`, `.opencode/hooks/slipway-session-start.sh` |\n\nEvery tool gets the entry skill. Codex enters the lifecycle through its skill and prompt surfaces; the other four also get an auto-injecting session-start hook (Codex has no session-hook surface to attach to, so its agent pulls governed state via `slipway status --json` instead).\n\n\u003c/details\u003e\n\nWant an agent to install and initialize Slipway for you? Paste the [AI Tool Installation Prompt](docs/installation.md#ai-tool-installation-prompt) into Claude Code, Codex, OpenCode, or another tool, but read it first and supervise the run. See [AI Tool Adapters](docs/ai-tools.md) for invocation spellings and safety rules.\n\n## Runtime files\n\n- `artifacts/changes/`: governed change bundles. Each holds `change.yaml` plus the Markdown artifacts (intent, research, requirements, decision, tasks, assurance) and verification records for the change. Active records are runtime authority; archived records stay Git-safe in the owning workspace.\n- `artifacts/changes/**/evidence/`, `events/`, `verification/`: raw local proof directories, ignored by Slipway-managed `.gitignore` rules. Keep them for local audit and validation.\n- `artifacts/codebase/`: advisory repo-scoped codebase maps from `slipway codebase-map`, git-tracked by default so brownfield context is shared rather than hidden.\n- `.worktrees/`: dedicated governed worktrees, local-only by default.\n\nSee the [Operator Guide](docs/operator-guide.md) for state authority, freshness state, and recovery details.\n\n## Documentation\n\n- [Installation](docs/installation.md): platform packages, source builds, repo initialization, and the AI-tool install prompt.\n- [Design Philosophy](docs/design.md): governing principles, authority boundaries, and adjacent-system tradeoffs.\n- [Governed Workflow](docs/workflow.md): lifecycle states, read-only surfaces, mutating commands, and Open Questions semantics.\n- [Command Reference](docs/commands.md): core, situational, and diagnostics commands.\n- [AI Tool Adapters](docs/ai-tools.md): generated paths and host invocation styles.\n- [Operator Guide](docs/operator-guide.md): worktrees, state authority, health, repair, verification, and closeout.\n- [Contributing](docs/contributing.md): repo layout, docs build, adapter contracts, and governance tests.\n\n## Verification\n\nUse focused package tests while developing, then run the full local proof before closeout:\n\n```bash\ngo test -timeout=20m ./... -count=1\ngo build ./...\ngo vet ./...\nmkdocs build --strict\n```\n\nCI also runs Markdown/YAML/action linting, Go tests across platforms, race tests, build checks, security scans, release checks, Nix checks, and the docs workflow in `.github/workflows/docs.yml`.\n\n## Repository status\n\n![Repobeats analytics image](https://repobeats.axiom.co/api/embed/20e468225cab8a858d9bc969314a0e9c3d12bddb.svg \"Repobeats analytics image\")\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsignalridge%2Fslipway","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsignalridge%2Fslipway","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsignalridge%2Fslipway/lists"}