issue-flow

Plugin issue-flow in Crank-Git/issue-flow-codex. Commands read from the repo's manifest — 6 days ago.

Skills (10)

• conformance

  Run the live Codex conformance suite. Use after a Codex upgrade, before a release, or when a harness fact is in doubt. It uses the operator's Codex quota.

• try-plugin

  Install this working tree as a Codex plugin in an isolated CODEX_HOME, to see a change in a real Codex session. Use when asked to try, install, or demo the plugin.

• issue-flow

  Issue-tracker-driven autonomous development loop, on GitHub or Gitea. Use when the user says "work the issues", "pick up the next issue", "issue-driven mode", "/issue-flow", or asks the agent to plan and build autonomously from the issue tracker. A main-thread PM triages the tracker, groups issues i

• project-inherit

  Bring an existing codebase into the issue-flow pipeline by reverse-engineering the full spec package from what is already built. Use when the user says "$issue-flow:project-inherit", "inherit this repo", "adopt this project", "plan an existing project", "onboard this codebase to issue-flow", or asks

• project-planner

  Interactive project planning that produces a reviewable spec package plus a ready-to-work project scaffold. Use when the user says "$issue-flow:project-planner", "plan a project", "spec out <idea>", "design a project", or wants a new project/feature-set defined before any code. Interviews the user,

• project-review

  User-viewpoint review of the running app in a sandbox — the QA/documentation pass after issue-flow ships work. Use when the user says "/project-review", "review the project", "user-test the app", "do a UX review", "build the user manual", or wants recent issue-flow work exercised end to end. The PM

• repo-mirror

  Keep a project's specs, issues and PRs private while publishing its code to a public mirror. Use when the user starts `$issue-flow:repo-mirror`, "make the specs private", "set up a public mirror", "mirror this repo", "convert this repo to private + public mirror", "clean the specs out of the public

• setup

  Configure Codex for the issue-flow loop. Use when the operator says "$issue-flow:setup". By default, prints the one terminal command that sets up the operator's Codex home once per machine. Per-project mode prints `.codex/` changes for operator application, writes accepted files outside `.codex/`, a

• spec-to-issues

  Turn an approved project-planner spec into tracker epics and sub-issues (GitHub or Gitea) shaped for the issue-flow loop. Use when the user says "$issue-flow:spec-to-issues", "create issues from the spec", "push the spec to GitHub", "push the spec to Gitea", optionally with a spec path. Reads docs/s

• spec-update

  Change or refresh an existing docs/specs/ package outside an issue-flow run. Use when the user says "$issue-flow:spec-update", "add a feature to the spec", "update the spec", "change the spec", "retire a feature", or "refresh the spec" / "migrate the spec to the new format" after a plugin upgrade. T

Subagents (6)

• ci-watcher

  Waits for the CI run of one commit, or for the deployment of one commit, and returns one verdict. Runs the wait script again while the state is pending, until the deadline in its brief. Decision-free and read-only: it never fixes, labels, merges, comments, or deploys. Spawned by the issue-flow PM, o

• code-auditor

  Read-only code sweep that finds work the tracker doesn't know about: TODO / FIXME / HACK comments, stubbed or unimplemented functions, dead or unwired UI, placeholder content, and acceptance-criteria gaps versus recently closed issues. Returns a strict structured findings report with file:line evide

• deploy-verifier

  Verifies that a deployed web app actually works by driving a real browser: loads the URL, checks HTTP/render/console/key content, captures a screenshot, and returns a strict structured verdict (verified | broken | unreachable). Decision-free and read-only: it never fixes, labels, merges, or deploys.

• issue-worker

  Independent engineer that builds ONE tracker issue end to end inside a git worktree that the PM created: researches, implements, opens a PR (a CI-skipped draft into the batch's integration branch, or a normal PR when standalone), self-reviews, addresses comments, verifies with the local test suite,

• review-scribe

  Turns ux-explorer walkthroughs and screenshots into durable review deliverables on a dedicated review branch: user-manual pages with embedded screenshots, and E2E smoke tests (created when the repo has none, extended when it does) that codify the explored happy paths and are verified green against t

• ux-explorer

  Explores a sandboxed application through a real browser from the viewpoint of a non-developer end user: walks one assigned flow, clicks around, reads pages, submits harmless test data, screenshots every major screen, records a step-by-step walkthrough usable for the user manual, and checks the brows

Hooks (7)

• SessionStart

  python3 "$PLUGIN_ROOT/hooks/preflight.py"

• PreToolUse

  python3 "$PLUGIN_ROOT/hooks/guard-spawn.py"

• PreToolUse

  python3 "$PLUGIN_ROOT/hooks/guard-wait.py"

• PreToolUse

  python3 "$PLUGIN_ROOT/hooks/guard-role.py"

• PostToolUse

  python3 "$PLUGIN_ROOT/hooks/record-wait-state.py"

• PostToolUse

  python3 "$PLUGIN_ROOT/hooks/record-wait-state.py"

• PostToolUse

  python3 "$PLUGIN_ROOT/hooks/record-wait-state.py"

Similar plugins