For trackers where issue status is tied to release/deployment rather than to PR/merge
events (notably Jira-managed projects such as Unibook/kobic), the
In Progress โ In Review
transition is gated on staging deployment, not on PR creation.
This overrides the generic ZenHub flow (which moves an issue to Review/QA
on PR creation โ
see zenhub-conventions.md). Use this policy whenever the project's
tracker is deployment-gated.
Policy#
Keep the ticket in In Progress through PR creation and merge. Move it to In Review only once the merged change is reflected in the staging deployment.
| Event | Status action |
|---|---|
| Branch creation | โ In Progress |
| PR creation | stay In Progress (do NOT move to In Review) |
PR merge (into the deploy branch, e.g. development) |
stay In Progress |
| Change deployed & reflected in staging | โ In Review |
| Production deploy / acceptance verified | โ Done/Closed (per project policy) |
Rationale#
- Reviewers/QA validate against the running staging build, not a diff. Moving to In Review before the change is deployable would surface a ticket that can't yet be verified in staging.
-
In Jira-managed projects there is no GitHub
Closes #auto-close (Jira โ GitHub issues), so status is driven by the deployment pipeline, not by merge keywords. The generic "merge = Close" shortcut does not apply here.
Staging deployment#
How "deployed to staging" is detected/triggered is project-specific. For Unibook/kobic,
staging is deployed from the development branch via a manual GitHub Actions
workflow_dispatch
(see the project's deployment workflow docs). Move the ticket to In Review
after that deploy
lands and the change is observable in staging.
/dev workflow impact#
When this policy applies, the /dev cycle changes as follows (vs. the generic steps in
../skills/dev/SKILL.md):
- Step 10 (Move to Review/QA on PR creation) is skipped โ the ticket stays In Progress after the PR is opened.
- A later deploy step moves the ticket to In Review once the merge is reflected in staging.
- The generic "merge = Close" auto-closure is not used.
Transition reference (Jira example โ Unibook/kobic, UB project)#
getTransitionsForJiraIssue is global here, so these IDs are available from any status:
| Target status | Transition id |
|---|---|
| In progress | 21 |
| In review | 31 |
| To do | 11 |
| Done | 41 |
| Cancel | 2 |
Always query
getTransitionsForJiraIssueto confirm IDs per project โ they are not guaranteed stable across Jira sites/workflows.
Related#
- zenhub-conventions.md โ generic (PR-creation-gated) pipeline flow this overrides
- ../skills/dev/SKILL.md โ full
/devworkflow - ../commands/agents/dev/issue-state-agent.md โ issue status transitions