plankit

Plan-driven development for Claude Code: guarded branches, immutable plan records, and conventional-commit releases, shipped as a plugin. plankit is the plugin; pk is the command it installs.

The skills are the documentation. The same pages load as /plankit: shortcuts in Claude Code and render in a terminal as pk help. The pk binary holds every decision: the hooks that guard branches and preserve plans, and the changelog and release machinery. Uninstall the plugin and pk still does everything from a terminal.

Install

/plugin marketplace add https://plankit.com/marketplace.json
/plugin install plankit

The same marketplace file is attached to every GitHub release, so https://github.com/markwharton/plankit/releases/latest/download/marketplace.json works as the source too. The plugin runs the pk bundled with it; with pk already on the PATH from go install or Homebrew, it runs from any source, the GitHub repository included.

To update to a new release:

/plugin marketplace update plankit
/plugin update plankit@plankit
/reload-plugins

With auto-update enabled for the marketplace (/plugin, Marketplaces), Claude Code runs the first two at startup and prompts for the third. The brief at the start of every session names the plugin's version, so a plugin behind the latest release is visible without asking.

What the plugin runs: five hooks, each a pk command on your machine, at session start, before a shell, edit, or write, and after a plan is approved. pk runs git in the repository and nothing else. It contacts no service: the one thing that leaves your machine is what git pushes to your own remote, when you ask for a release. Updates come through Claude Code's marketplace commands above.

Then, in a repository you want plankit to manage:

pk init

One run writes .pk.json, the policy, adds the plankit marketplace and plugin to .claude/settings.json so a teammate who trusts the folder is one /plugin install away, commits both, and starts a develop branch when the release branch was the only one. The plans directory, named in the policy, appears when the first plan is preserved; pk help preserve has the key and its default. No .pk.json means off: every hook exits immediately.

In Claude Code, the skills are the normal way in: /plankit:ship cuts a release. Allowing pk in the repository's .claude/settings.json is an option, not a requirement; it pre-approves every pk command:

{
  "permissions": {
    "allow": ["Bash(pk:*)"]
  }
}

To allow one command instead, name it: Bash(pk status:*).

What it looks like

Generated when this page was built, by running pk in a scratch repository.

Configure a repository
$ pk init
plankit configured in ~/acme-app (created: .pk.json, .claude/settings.json, commit, branch develop)
Note: 1 commits precede plankit's and will be in the first release; to keep them as history, tag the last of them: git tag v0.0.0 7859fae

plankit 1.8.2 is configured in this repository.

Commits follow Conventional Commits, type(scope): subject. Types: feat, fix, deprecate, revert, security, refactor, perf, docs, chore, test, build, ci, style (from .pk.json changelog.types).

Never add a breaking marker (! or BREAKING CHANGE) on your own judgment; only on explicit user direction. guard asks before one is committed.

The commits decide the release version. Pass --bump or --exclude to pk ship or pk changelog only when the developer asks, with the value given. guard asks before a --bump lower than the commits infer.

main is protected: commits and pushes there are blocked. Pushing is the developer's action; do not push. Work on the development branch; releases merge into main with pk ship.

docs/plans/ is immutable. Approved plans are preserved there; preserve mode is manual, so run /plankit:preserve to commit a pending plan.

pk help lists every command.
See the state
$ pk status
plankit status
  project:   ~/acme-app
  branch:    develop (clean)
  preserve:  manual
  guard:     block (push: block, breaking: ask, bump: ask) on main
  protect:   docs/plans/ immutable
  release:   merge flow: pk ship merges develop into main and tags it
  plans:     0 preserved
  pending:   none
  tag:       none yet
What every session is told at start
$ pk brief
plankit 1.8.2 is configured in this repository.

Commits follow Conventional Commits, type(scope): subject. Types: feat, fix, deprecate, revert, security, refactor, perf, docs, chore, test, build, ci, style (from .pk.json changelog.types).

Never add a breaking marker (! or BREAKING CHANGE) on your own judgment; only on explicit user direction. guard asks before one is committed.

The commits decide the release version. Pass --bump or --exclude to pk ship or pk changelog only when the developer asks, with the value given. guard asks before a --bump lower than the commits infer.

main is protected: commits and pushes there are blocked. Pushing is the developer's action; do not push. Work on the development branch; releases merge into main with pk ship.

docs/plans/ is immutable. Approved plans are preserved there; preserve mode is manual, so run /plankit:preserve to commit a pending plan.

pk help lists every command.
Preview the release
$ pk changelog --dry-run
no release yet: the first release covers all 5 commits
Found 5 conventional commit(s)
Generating v0.1.0
## [v0.1.0] - 2026-11-03

### Added

- add passkey sign-in (0bfe5fa)

### Fixed

- expire entries on clock skew (9fc6214)

### Documentation

- describe the passkey flow (57e3e0c)

### Maintenance

- scaffold acme-app (7859fae)
- configure plankit (0bb1993)
Guard asks before a breaking marker is committed
$ Claude Code runs: git commit -m "feat!: drop the legacy session cookie"
{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "ask",
    "permissionDecisionReason": "pk guard: the commit message marks a breaking change (! or BREAKING CHANGE). That marker drives the next major version, and it is the developer's claim to make, not the agent's. Confirm the change is breaking, or reword the message without the marker."
  }
}

Commands

One page per command, the same page in the terminal as pk help <name>.

pk briefWhat each session is told about this repository's plankit policy at start, generated from .pk.jsonpk changelogGenerate CHANGELOG.md from conventional commits and stage a release with the Release-Tag trailerpk guardHow pk guard decides what an agent may do to git, and how to tune itpk helpShow documentation for pk and its commandspk initConfigure a repository for plankitpk pinUpdate a version pin in a file, for release hookspk preserveKeep each approved plan as a record in the plans directory, on approval or on requestpk protectWhy preserved plans are immutable and how pk protect enforces itpk releaseTag the pending release from the Release-Tag trailer and push it, with pre-flight checks and rollbackpk shipCut the pending work as one release - changelog then release in a single commandpk statusReport plankit configuration and repository statepk versionPrint the pk build version

Latest release: v1.8.2 · six platforms · marketplace.json