The GitHub cycle

Flow

How one piece of work travels from an idea to merged code.

Every change cckit makes follows this same path. Read it left to right: an issue says what to do, a branch gives the work a private place to happen, the work becomes a pull request, and review either merges it or sends it back. cckit gives you one command for each step.

You don't do this by hand

cckit runs each of these steps for you. Read this to understand what’s happening behind the commands — you don’t need to memorize it or do any of it manually.

The steps

1. Issue — a short note of one thing to do. It has a number (like #42) that follows the work the whole way through.

2. Branch — a private copy of the code to change, so your work never disturbs anyone else’s. cckit start 42 makes the branch and an isolated worktree for issue #42.

3. Work — make the change. Run bash scripts/check.sh (or your project’s checks) until it passes.

4. Pull request — propose the change back to the main code. cckit pr 42 "<summary>" opens it and links it to issue #42, so merging the request closes the issue.

5. Review — automated checks run, and a person or an agent takes a look. If it’s good, it merges into main. If not, it comes back as changes and you return to step 3.

The commands, in order

Step	Command
Start the work	cckit start <issue>
Open the request	cckit pr <issue> "<summary>"
Close a no-op	cckit close <issue> "<reason>"
See the board	cckit sync
What’s next	cckit next

Each command is explained in the CLI reference.