cliban-workflow

# Cliban Workflow — The Contract This skill is policy, not mechanics. Every command, flag, JSON shape, trap, and the parseable-description grammar is specified once, in the `cliban` skill — consult it there; nothing below restates it. What lives here is the contract that workflow skills share: which repo binds to which board, what each workflow event means in board terms, and which artifacts belong on the board versus in git. ## Per-Repo Binding (the adapter) A repo that has run `setup-cliban` carries `docs/agents/issue-tracker.md` — the adapter. It binds four things and is authoritative over the defaults below. Read it once per session before the first cliban action. | Binding | Meaning | Default when no adapter | |---|---|---| | Project key | which board | basename of `git rev-parse --show-toplevel`, matched case-insensitively against `project ls` keys and names; ask on miss | | Craft stack | who owns the craft of spec/plan/execute/finish | none — perform stages directly | | Key policy | where issue keys may appear in git artifacts | branches and commit messages yes; source code, comments, docs never | | Branch convention | what starting an issue does | switch to the issue's `git_branch_name` | If the user is wiring up a new repo, point them at `setup-cliban`; don't improvise a binding. If `cliban` itself is missing from `$PATH`, skip all board actions silently for the session. ## Status Mapping | Workflow event | Board action | |---|---| | Spec/plan written | issue ...