Workflow as code.
Terraform, but for how work moves through your team.
Write the rules in a plain YAML file, then check every Jira ticket and GitHub pull request against them.
States, transitions, gates and review requirements, versioned next to your code. Free and open source.
curl -fsSL https://workfile.sh/install.sh | shStart with the states.
List the stages a ticket moves through, in order. This team uses five, from todo to done.
tracker: jira tells workfile.sh where to read tickets. The provider configuration maps your board’s status names to these states.
- todo
- ready
- doing
- review
- done
Transitions define how tickets move between states.
transitions define the states a ticket can move to. requires names the conditions that gate the move: each one must pass before the ticket can move forward.
Here, moving a ticket into ready requires refinement to pass. Moving from review to done requires a code review.
Moving backwards is allowed. A review can send a ticket back to todo without passing the gate.
Gates define what needs to happen before a ticket can move
gates are a set of conditions. Every applicable condition must pass.
This one checks for an acceptance criteria heading, a minimum description length, and no needs-more-information label.
Use when for conditions that only apply to certain tickets. Stories need 500 characters; other types need 100.
message sets the explanation shown when a check fails.
Another gate, this time with more complex conditions
Another gate. Here each PR needs an approval and a risk label. Medium and high-risk changes also need an approval from a lead engineer.
by: [lead] restricts whose approval counts. when limits that rule to the relevant risk labels.
Reviewers are defined in people.yml Connections are defined in providers.yml
These checks run per linked PR. To require a PR as well, add github.prs >= 1.
A CLI work flow for getting things done
wf status compares what the policy says with what actually happened. It reads your Jira tickets and their pull requests, and checks each one against the gate it has to pass next.
--me narrows the list to your tickets.
See what actions are needed to move tickets forward
Name a ticket to see the whole picture: where it sits on the board, the gates it passed to get there, and what stands between it and the next state.
Each linked PR is checked on its own. payments#128 has the high-risk label, so it still needs an approval from the team lead.
wf health shows what work fails to meet policy
wf health looks back instead of forward. It checks how each ticket reached its current state, and whether it passed every gate on the way.
Pass rates show which gates get skipped. Each out-of-policy ticket comes with the state to send it back to.
--failing hides tickets that are in policy. --json returns the same results for scripts and dashboards.
Try it on your board
curl -fsSL https://workfile.sh/install.sh | shEnterprise enforces the policy for you
We're building an enterprise edition to enforce your policy automatically.
It’s early, but we’d like to talk and hear how your team works: missing integrations, deployment requirements, awkward edge cases. If you're up for a chat, get in touch.
The core will always remain open source.