{
  "markdown": "# Quiver\n\n[![Version](https://img.shields.io/badge/version-1.22.0-blue)](https://github.com/yagizdo/quiver/releases)\n\nQuiver is a development lifecycle plugin for AI coding CLIs. Purpose-built skills for brainstorming, planning, execution, debugging, code review, and session handover, plus specialized agents for review and debugging.\n\n## Contents\n\n- [Typical workflow](#typical-workflow)\n- [Installation](#installation)\n- [Components](#components)\n- [What Do I Use?](#what-do-i-use)\n  - [Building Something](#building-something)\n  - [How /work runs a large plan](#how-work-runs-a-large-plan)\n  - [Building a Whole Project](#building-a-whole-project)\n  - [Implementing a Design](#implementing-a-design)\n  - [Reviewing Code](#reviewing-code)\n  - [Fixing a Bug](#fixing-a-bug)\n  - [Committing & PRs](#committing--prs)\n  - [Session Management](#session-management)\n  - [Tooling & Maintenance](#tooling--maintenance)\n- [Hooks](#hooks)\n- [Agents](#agents)\n  - [Review](#review)\n  - [Research](#research)\n  - [Debug](#debug)\n  - [Workflow](#workflow)\n- [External Dependencies](#external-dependencies)\n- [CLI Notes](#cli-notes)\n- [Uninstall](#uninstall)\n- [Contributing](#contributing)\n- [License](#license)\n\n## Typical workflow\n\nA normal feature cycle chains these skills. Each one is self-contained and works on its own. Skip steps, reorder them, or use just the ones you need. If you hit a bug at any point, run `/hypothesis-debugging` to investigate it systematically.\n\n1. `/brainstorm`: turn a vague idea into a validated spec by walking through clarifying questions and trade-off analysis on 2-3 design approaches.\n2. `/plan`: research the codebase in parallel, then break the chosen approach into verifiable step-by-step tasks with exact file paths.\n3. `/work`: execute the plan with continuous testing, branch setup, and incremental commits. Plans of 3+ tasks run as parallel subagents in separate worktrees.\n4. `/commit`: generate a Conventional Commits message from staged changes and commit (optionally pushing).\n5. `/create-pr`: open a GitHub pull request with an auto-generated title and description from the branch diff.\n6. `/review`: dispatch review agents to check code quality, security, and architecture, then synthesize findings into one report. Runs 5 agents by default; `--deep` for the full pipeline.\n7. `/handover`: save an 8-section summary of the session so the next session resumes with full context.\n\n## Installation\n\nClaude Code and the Codex CLI have their own plugin managers. Cursor reads Claude Code's directory. OpenCode has none, so Quiver installs there from a clone. Once it is installed, `/brainstorm` works in any session; per-CLI differences are in [CLI Notes](#cli-notes).\n\n### Claude Code\n\n```\n/plugin marketplace add yagizdo/quiver\n/plugin install quiver@quiver\n```\n\n### OpenAI Codex CLI\n\n```text\ncodex plugin marketplace add yagizdo/quiver\ncodex plugin add quiver@quiver\n```\n\n### Cursor\n\nCursor reads Claude Code's plugin directory, so a Claude Code install already covers it. Run `Developer: Reload Window` and the skills are there.\n\nWithout one, import the repo from Cursor's Plugins panel:\n\n```text\nhttps://github.com/yagizdo/quiver.git\n```\n\nImporting on top of a Claude Code install leaves two copies on separate update schedules, so do not do both.\n\n### OpenCode\n\n```bash\ngit clone https://github.com/yagizdo/quiver.git\ncd quiver\n./install.sh\n```\n\nThe script symlinks Quiver into every runtime it detects, and prints the install command for the ones that have their own plugin manager. After that, `git pull` in the clone updates every linked runtime. OpenCode details: [`.opencode/README.md`](.opencode/README.md)\n\n## Components\n\n| Component | Count |\n|-----------|-------|\n| Hooks | 3 |\n| Skills | 27 |\n| Agents | 20 |\n\n## What Do I Use?\n\n### Building Something\n\n| Situation | Command | What happens |\n|-----------|---------|--------------|\n| I have a vague idea, not sure where to start | `/brainstorm` | Walks through clarifying questions, compares 2-3 approaches, outputs a validated spec |\n| Scope is clear, need a step-by-step breakdown | `/plan` | Researches codebase in parallel, produces a task-by-task plan with file paths |\n| Plan is ready, want hands-off execution | `/work` | 1-2 tasks run sequentially in your session; 3+ tasks run as parallel subagents in separate git worktrees. Progress lives in a ledger on disk that survives compaction, so re-running `/work` on the same plan resumes where it stopped |\n| Want a quick second opinion on an approach | `/advise` | Gives a senior-style inline review -- no spec or plan artifact |\n\n### How /work runs a large plan\n\nA plan with 3+ tasks is split into execution groups by dependency and file overlap. Each group's tasks are dispatched together, one subagent per task, each in its own git worktree so parallel tasks never edit the same checkout. When a group finishes, its branches merge into the working branch before the next group starts, so later tasks build on what earlier ones landed. A merge conflict stops the run and names the files; nothing is resolved automatically.\n\nState lives in `.claude/work/<plan-name>/`:\n\n- `progress.md` is the ledger. Every dispatch, completion, and merge is appended there as it happens, so the run can be read back after compaction or a crash. Re-running `/work` on the same plan skips completed tasks and merges any branch that finished but never landed.\n- `task-<N>-brief.md` carries one task's requirements out of the plan. The subagent reads that file instead of receiving the whole plan in its prompt.\n- `task-<N>-report.md` is where the subagent writes its full account. The orchestrator opens it only when a task is blocked or failed, or when the final test run points at that task; a task that succeeded returns one status line and its report is never loaded into your session.\n\nAfter the last group merges, the resolved test command runs once on the combined result. A successful run offers to delete the workspace; a blocked, failed, or cancelled run keeps it, because the surviving ledger is what makes the retry cheap.\n\n### Building a Whole Project\n\n| Situation | Command | What happens |\n|-----------|---------|--------------|\n| I want to build a project from a description without touching it myself | `/ship` | Deep planning Q&A (outcomes, scope, stack, verification), then autonomous loop: code + test + review + fix until done. Manifest at `docs/ship/<project>-manifest.md` |\n\n### Implementing a Design\n\n| Situation | Command | What happens |\n|-----------|---------|--------------|\n| A Figma frame is ready to become code | `/design` | Reads the selected nodes through the figma-bridge MCP, maps Figma variables onto the project's own theme tokens, and writes a self-contained plan to `.claude/plans/` |\n| Want the frame built and measured without babysitting it | `/design --auto` | Same extraction and same questions, then straight through the build and the fidelity measurement with no further prompt |\n| Design plan is ready, want it built pixel-accurate | `/design-build` | Implements each node against its embedded spec, then fixes whatever `/design-verify` reports, under a bounded retry budget |\n| Built UI is on screen, want to know how far off it is | `/design-verify` | Captures the running app on a connected phone when there is one and the simulator otherwise, normalizes both images to a common logical width, measures the deviations, and writes a report to disk |\n\n```\n/design                    # extract whatever is selected in Figma\n/design 4029:12345         # extract a specific node by ID\n/design --auto             # extract, then build and measure without stopping\n/design --auto --no-commit # same, and write no commit whatever the plan says\n/design-build              # pick a design plan and build it\n/design-verify             # measure a built screen against its spec\n```\n\n`--auto` removes the handoffs between the three stages, not the questions that decide what gets built.\n\n- `/design` still asks which file, which nodes, what an unmapped variable resolves to, how the build should commit and verify, and whether to overwrite a plan that already exists for the same screen. When a selection expands into many nodes and you described none of them, it also asks which of those nodes the build should implement.\n- Those questions all arrive in one call. After that the run stays quiet until the fidelity summary.\n- One node still gets three fix attempts. Auto mode records whatever deviation is left over and moves on rather than asking.\n\n`--no-commit` forces `commit_strategy: none` for a single run.\n\n- On a fresh plan it changes nothing. Not committing is already the recommended answer to `/design`'s commit question, so the flag guarantees that answer rather than overriding it.\n- It earns its keep against an existing plan that carries `per-task` or `single`, because `/design-build` never re-asks that question.\n- The override lasts one run and never edits the plan.\n- The two flags are independent. `/design-build <plan> --no-commit` is as valid as `/design --auto --no-commit`.\n\n`/design` is the only stage that talks to Figma.\n\n- The plan carries every measurement, token, and layout anchor `/design` produced, so `/design-build` runs with Figma disconnected and `/design-verify` measures against the plan alone.\n- `/design-verify` reads any file with a `### Node Specs` section, including a measurement spec you wrote by hand. It does not need a screenshot or an installed comparison tool.\n- Setup is in [External Dependencies](#external-dependencies).\n\n### Reviewing Code\n\n| Situation | Command | What happens |\n|-----------|---------|--------------|\n| About to merge, want multi-agent review | `/review` | Dispatches 5 review agents, synthesizes findings into one report |\n| Want a quick senior dev sanity check | `/senior-review` | One pragmatic reviewer evaluates structure, quality, risks |\n| Got a review report, not sure which findings matter | `/report-check` | Audits the report for noise, false positives, and overkill |\n\n```\n/review                    # fast review (5 agents, prompts for base branch)\n/review --deep             # full pipeline: all agents + quality check + senior review\n/review --base main        # review against a specific base branch\n/review <PR-URL>           # review a pull request by URL\n```\n\nPass `--comment-pr` to post the report as a PR comment. Use `--deep --with-codex` for cross-model coverage (requires `codex` CLI).\n\nRe-review detection: if you run `/review` again on the same branch after fixing issues, it automatically detects the previous report and switches to re-review mode.\n\n### Fixing a Bug\n\n| Situation | Command | What happens |\n|-----------|---------|--------------|\n| Bug won't go away after multiple attempts | `/hypothesis-debugging` | Generates hypotheses, tests each systematically, traces root cause, proposes reviewed fix |\n\n### Committing & PRs\n\n| Situation | Command | What happens |\n|-----------|---------|--------------|\n| Changes ready to commit | `/commit` | Generates a Conventional Commits message, commits, optionally pushes |\n| Branch ready for PR | `/create-pr` | Creates a GitHub pull request with auto-generated title and description |\n\n### Session Management\n\n| Situation | Command | What happens |\n|-----------|---------|--------------|\n| Ending a work session | `/handover` | Saves an 8-section summary so the next session resumes with full context |\n| Starting a new session | `/load-handover` | Loads the most recent handover and highlights top priorities |\n| Last handover is stale or wrong | `/delete-last-handover` | Shows and deletes the most recent handover file with confirmation |\n| Want a clean slate | `/delete-all-handovers` | Lists all handover files, confirms, then deletes everything |\n\n### Tooling & Maintenance\n\n| Situation | Command | What happens |\n|-----------|---------|--------------|\n| A skill is broken or outdated | `/repair-skill` | Diagnoses the skill's structure and fixes API references |\n| Need a new agent for the project | `/create-agent` | Scaffolds a new agent interactively from a description |\n| Want an AGENTS.md for the project | `/create-agents-md` | Analyzes project context and generates an operational checklist |\n\n## Hooks\n\n| Hook | Event | Description |\n|------|-------|-------------|\n| `pre-tool-use-guard` | PreToolUse | Classifies every Bash command before it runs -- refuses the handful that are irreversible, prompts on the destructive-but-recoverable ones, stays silent otherwise |\n| `pre-compact-handover` | PreCompact | Summarizes the conversation and saves a handover before the CLI compacts context |\n| `session-start-auto-dispatch` | SessionStart | Reads every skill's `when-to-use` and emits a routing block so intent matches invoke the right skill |\n\n> The handover hook keeps the 3 most recent handovers in `.claude/handovers/` and prunes older ones automatically. Filenames are timestamps, so sort order is lexicographic.\n\n## Agents\n\nReview, research, and debug agents run with the `Edit`, `Write`, `NotebookEdit`,\n`WebSearch`, and `WebFetch` tools denied -- they are built to read your code and\nreport findings, not to change it. `Bash` stays enabled because these agents need\n`git diff`, `git log`, and `git blame`, so the denial is a guardrail against\naccidental edits rather than a sandbox: a shell command can still write a file or\nreach the network. Two agents carry a narrower denylist: `best-practices-researcher`\nkeeps web access so it can check library versions against upstream release notes,\nand `codex-code-reviewer` can write because it persists the raw output of the\nexternal reviewer it wraps.\n\n<!-- agents-start -->\n\n### Review\n<!-- agents:review-start -->\n\n| Agent | What it catches |\n|-------|-----------------|\n| `architecture-strategist` (`quiver:architecture-strategist`) | Code that violates the project's own conventions and module boundaries |\n| `logic-reviewer` (`quiver:logic-reviewer`) | Branches where inputs don't reach the documented output correctly |\n| `waste-detector` (`quiver:waste-detector`) | Dead code, redundant utilities, unnecessary abstractions |\n| `stress-tester` (`quiver:stress-tester`) | Failure scenarios: inputs, timings, and states that break the new code |\n| `security-audit` (`quiver:security-audit`) | Concrete exploit paths for web, API, and mobile surfaces |\n| `test-reviewer` (`quiver:test-reviewer`) | Tests that pass without proving the code works |\n| `developer-experience-auditor` (`quiver:developer-experience-auditor`) | Confusing error messages, hidden debugging paths, brittle UX for humans and agents |\n| `codex-code-reviewer` (`quiver:codex-code-reviewer`) | Cross-model code review via the OpenAI Codex CLI; dispatched only when `--with-codex` is passed and the `codex` CLI is installed. Uses whatever model your local codex is configured for: Quiver does not override `--model` |\n| `report-checker` (`quiver:report-checker`) | Independent quality auditor for review reports -- detects noise, false positives, overkill, and findings that exist to appear thorough |\n| `senior-reviewer` (`quiver:senior-reviewer`) | Language-aware senior developer review -- evaluates code through a pragmatic team lead lens with optional meta-review of other agents' findings in the pipeline |\n\n<!-- agents:review-end -->\n\n### Research\n<!-- agents:research-start -->\n\n| Agent | What it catches |\n|-------|-----------------|\n| `best-practices-researcher` (`quiver:best-practices-researcher`) | Deprecated APIs and outdated patterns versus current library docs |\n| `project-context-analyst` (`quiver:project-context-analyst`) | Prior decisions, past bugs, and churn patterns in this area of the codebase |\n| `code-locator` (`quiver:code-locator`) | Fast file:line locations for \"where is X / what calls Y\" without heavy mapping |\n| `code-navigator` (`quiver:code-navigator`) | CodeGraph-first codebase explorer that maps files, symbols, and patterns relevant to a task |\n\n<!-- agents:research-end -->\n\n### Debug\n<!-- agents:debug-start -->\n\n| Agent | What it does |\n|-------|--------------|\n| `code-tracer` (`quiver:code-tracer`) | Traces execution paths across files to find where behavior diverges from expectation |\n| `log-analyzer` (`quiver:log-analyzer`) | Parses log dumps and stack traces to extract error patterns and map them to source code |\n| `regression-finder` (`quiver:regression-finder`) | Analyzes git history to find which commit introduced a bug |\n| `environment-checker` (`quiver:environment-checker`) | Checks dependency versions, config files, and environment setup for mismatches |\n| `fix-reviewer` (`quiver:fix-reviewer`) | Reviews every proposed fix for overengineering, workarounds, and architectural consistency |\n\n<!-- agents:debug-end -->\n\n### Workflow\n<!-- agents:workflow-start -->\n\n| Agent | What it does |\n|-------|--------------|\n| `plan-reviewer` (`quiver:plan-reviewer`) | Reviews implementation plans for logical coherence, dependency ordering, coverage completeness, and spec alignment |\n\n<!-- agents:workflow-end -->\n<!-- agents-end -->\n\n## External Dependencies\n\nThis plugin includes a [Context7](https://context7.com) MCP server for real-time library documentation lookups. It starts automatically when the plugin is enabled (configured in `plugin.json` under `mcpServers`). No authentication required.\n\n**Tools provided:**\n- `resolve-library-id`: Find library ID for a framework/package\n- `query-docs`: Get documentation for a specific library\n\nSupports 100+ frameworks including Rails, React, Next.js, Vue, Django, Laravel, and more. Library/framework names from your codebase are sent to the service only during review agent execution (e.g., best-practices checks), not at plugin load time.\n\n### figma-bridge (optional, for `/design`)\n\n`/design` reads Figma through the [figma-mcp-bridge](https://github.com/gethopp/figma-mcp-bridge) MCP server. It is not bundled in `plugin.json` -- the bridge also needs a Figma plugin installed by hand, so auto-starting the server alone would only get you halfway.\n\nAdd the server to your MCP config:\n\n```json\n{\n  \"figma-bridge\": {\n    \"command\": \"npx\",\n    \"args\": [\"-y\", \"@gethopp/figma-mcp-bridge\"]\n  }\n}\n```\n\nThe Figma plugin side is a manual import from the bridge's [releases page](https://github.com/gethopp/figma-mcp-bridge/releases), and its README carries the current steps. Leave the plugin running inside the file you are reading -- it holds the WebSocket, and closing it drops the connection mid-extraction.\n\n`/design` only calls the bridge's read tools. `/design-build` and `/design-verify` never call it at all. Every other Quiver skill works without it.\n\n### ImageMagick (optional, for `/design-verify`)\n\n`/design-verify` works with nothing installed -- it reads the built UI against the spec and marks the report low confidence. Installing ImageMagick upgrades that structural read into a measured differing-pixel count:\n\n```\nbrew install imagemagick\n```\n\nThe skill probes `magick -version` and `magick -list metric`, picks the `PDC` metric when the build has it, and records which comparison path produced each report. Nothing breaks without it; the reports simply carry fewer numbers.\n\nDevice capture is optional in the same way. `/design-verify` uses a connected phone when one is attached and falls back to the simulator when there is not, because a phone renders the real safe-area insets and display scaling. Which tool takes the screenshot depends on the stack:\n\n| Target | Tool | Install |\n|--------|------|---------|\n| iOS simulator | `xcrun simctl` | ships with Xcode |\n| Android phone or emulator | `adb` | ships with the Android SDK |\n| Physical iOS device | `pymobiledevice3` | not suggested -- used only when it already resolves |\n| Flutter app anywhere it runs, phone included | `marionette` | `dart pub global activate marionette_cli`, plus `marionette_flutter` in the app |\n| Web | Playwright MCP | MCP config |\n\nmarionette connects to the running app's Dart VM service instead of the device, which is how it screenshots a physical phone with no device tooling installed. The app has to be running in debug with `MarionetteBinding` initialized in `main.dart`.\n\nThe skill probes for these before it picks a target. When nothing on the machine can screenshot the attached phone, it drops the phone from the order and uses the simulator, since building on a device you cannot photograph loses the measurement the step exists for. An absent tool prints one line and the run continues to the next option.\n\n`pymobiledevice3` is the one row with no install hint. On iOS 17+ it needs a root tunnel daemon and a mounted Developer Disk Image, which is more than a screenshot is worth from a tool you did not pick, so the skill uses it when it is already on the machine and never suggests installing it. Apple ships no alternative -- `xcrun devicectl` has no screenshot subcommand -- so a non-Flutter iOS project without it captures the simulator.\n\nNo iOS MCP server screenshots a physical device. The xcodebuild-wrapping servers build, install, launch, and test on one, and their screenshot tools only cover the simulator, so every native row above is a plain CLI command. Web is the exception: the browser is where the app runs, so that row goes through the Playwright MCP.\n\n## CLI Notes\n\nEvery CLI runs the same skills and the same agents, and `/review` fans out to 5 agents by default on all of them, or the full pipeline with `--deep`.\n\n### Cursor\n\n- Cursor discovers skills by scanning a fixed set of roots: `~/.cursor/skills/`, `~/.cursor/skills-cursor/`, `~/.cursor/cloud-skills/`, `~/.cursor/plugins/`, `~/.claude/skills/`, `~/.claude/plugins/`, `~/.codex/skills/`, `~/.agents/skills/`. A Claude Code install lands in `~/.claude/plugins/`, so Cursor picks it up. A Codex install lands in `~/.codex/plugins/`, which is not on that list.\n- Two installs give you two copies on separate update schedules, and nothing warns you when you are reading the old one. Keep the Claude Code install and let Cursor read it.\n- `install.sh` has no Cursor target, because a symlink under `~/.cursor/plugins/local/` is not picked up. On Cursor 3.17.21, disabling the Claude Code install made Quiver disappear from Cursor while that symlink was still in place, and `cursor.plugins.installedIds` stayed empty the whole time. Use Cursor's own plugin import.\n- The `cursor-agent` CLI does not load plugin skills (IDE-only). Use Cursor IDE for skill-using workflows.\n- `WebFetch` and `WebSearch` are unsupported on Cursor; the included context7 MCP covers documentation lookups.\n- If handover auto-save does not fire after install, Cursor's `preCompact` event may use a different JSON field name than Claude Code. Edit `.cursor/hooks.json` to log raw stdin to a file, trigger context compaction, and inspect the log for the actual field names.\n\n### Codex\n\n- Codex uses the bundled default `PreCompact` hook in `hooks/hooks.json` for automatic handover auto-save before automatic compaction. If Codex prompts for hook review, open `/hooks` and trust the Quiver hook; `/handover` also works manually.\n- `AskUserQuestion` is polyfilled as numbered text prompts: reply with the option number.\n- Agent dispatch uses `spawn_agent(worker)` with the agent's persona prompt read from `agents/`.\n\n### OpenCode\n\n- Installing from an earlier release put a git-backed `quiver` entry in the `plugin` array of your `opencode.json`. That entry no longer resolves: delete it, then run `./install.sh`.\n- The plugin registers the skills directory and the context7 MCP server itself, so you do not need an `mcp` or `skills` entry of your own.\n- Skills do not appear in the `/` autocomplete menu, because OpenCode's TUI filters out anything with `source: \"skill\"`. Typing `/brainstorm` still runs it.\n\n### Gemini CLI (legacy)\n\nGoogle retired Gemini CLI on 18 June 2026, with no grace period for free, AI Pro, and Ultra personal accounts. Under a Gemini Code Assist Standard or Enterprise license the extension still installs and runs:\n\n```text\ngemini extensions install quiver\n```\n\nAntigravity CLI is Google's replacement. Quiver has not been tested there yet.\n\n- `ask_user` is native: interactive prompts render with full fidelity.\n- The handover auto-save hook maps to Gemini CLI's `PreCompress` event, which fires only before history compression (like Claude Code's PreCompact) -- no cooldown guard needed.\n- Agent dispatch reads agent persona prompts from `agents/` and executes them inline.\n- The hook script uses `claude -p` for transcript summarization. If the `claude` CLI is not installed, the auto-save hook will silently skip (manual `/handover` still works).\n\n## Uninstall\n\nOn Claude Code:\n\n```\nclaude plugin uninstall quiver\n```\n\nOn the Codex CLI:\n\n```text\ncodex plugin remove quiver@quiver\n```\n\nOn OpenCode, from the clone:\n\n```bash\n./install.sh --uninstall\n```\n\nThat removes only the symlinks that resolve into the clone, and reports anything it declined to remove.\n\n## Contributing\n\nBug fix: open a PR. New skill, agent, or hook, or a behaviour change: open an issue first. Setup, tests, and PR expectations are in [CONTRIBUTING.md](CONTRIBUTING.md).\n\n## License\n\nThis project is licensed under the MIT License - see the [LICENSE](LICENSE) file for details.\n",
  "bytes": 25229,
  "sha": "afcd36ec56de60bc162bd02a5ac7432ec83101c49dac6b7ee6fce834cc6f5f49",
  "repo_slug": "yagizdo/quiver",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/plg_yagizdo_quiver_acc02c9c/readme"
}