ideation → development → testing →
review → done) maps cleanly onto a typical pull-request lifecycle.
This guide wires that mapping up so phases update without anyone hand-
editing frontmatter.
The mapping no-tickets ships with by default:
If you want this mapping, you don’t have to do anything beyond enabling the
GitHub Actions integration — the
action infers the phase from the GitHub event that triggered it.
Overriding the mapping
The mapping is a default, not a rule. Two ways to override:- Per-feature — set
phase:explicitly in the feature’s frontmatter. Explicit always wins over inferred. - Per-project — set a project-level mapping in the dashboard: Project settings → Workflow → Phase mapping.
phase: testing to mean “deployed to a staging env” can
re-map testing to fire on a separate deploy-staging.yml workflow instead
of on the PR.
Linking features to PRs
By default, the GitHub Action links a PR to a feature when the feature ID appears in the PR title or branch name:Required-status-check pattern
A common request: gate merges on no-tickets validation. Set up a required status check using the GitHub Action’snt validate output:
no-tickets validate / validate as a required status check in
your branch protection rules.
Slash commands in PR comments
The dashboard accepts a small set of slash commands posted as PR comments, authenticated by the commenter’s GitHub identity (linked to their dashboard account):
These are convenience hooks for reviewers; the canonical source remains the
files in the repo. Slash-command edits ship as commits to the PR’s source
branch (with a
[skip ci] marker on the commit message).
Multi-repo PRs
For epics that span multiple repos (cross-project epics), each repo’s PR drives transitions on its own features only. The epic’s overall progress rolls up from all features regardless of which repo owns them.See also
- Concepts → Phases — the underlying state machine
- GitHub Actions — the integration that drives most of this
- Concepts → Push origins —
origin: cirules