> For the complete documentation index, see [llms.txt](https://docs.flxbl.io/flxbl/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flxbl.io/flxbl/codev/ci-cd/work-items.md).
# Work items
codev reads work-item references straight from your commit messages and shows them across the delivery pipeline — on builds, on release candidates, and on releases. It recognises pull request numbers, Jira issue keys, and Azure DevOps work items with no configuration.
Work items detected from commit messages, shown on a release candidate
## What codev recognises
Detection runs over each commit's subject and body. A reference is picked up when it appears in one of these forms:
| You write | Detected as |
| ----------------------------------------------------------------------------------------- | ---------------------- |
| `#123` or `(#123)` | Pull request |
| `SALES-301` standing on its own (a space or line start before it, a space or colon after) | Issue key |
| `[SALES-301]` | Issue key |
| `feat: SALES-301 …`, `fix(payments): SALES-301 …`, `feat/SALES-301` | Issue key |
| `AB#123` | Azure DevOps work item |
An issue key is two or more letters, a hyphen, and digits (`SALES-301`, `DP-12`). Matching is case-insensitive, and keys are shown in upper case.
## When a reference is not detected
An issue key is picked up only when it stands on its own — with a space, a line start, or a colon around it — when it is in square brackets, or when it follows a [conventional-commit](https://www.conventionalcommits.org/) prefix such as `feat:` or `fix:`. **An issue key wrapped in round parentheses is not picked up.**
For example, `chore: bump to 1.4.45 (SALES-301)` records no work item: the key is jammed against the `(`, so it is none of the recognised forms. Write it in one of these instead:
* `SALES-301: bump to 1.4.45`
* `chore: bump to 1.4.45 [SALES-301]`
* `feat: SALES-301 bump to 1.4.45`
This round-parenthesis rule applies to **issue keys only**. A pull request number in parentheses — `(#123)`, the form GitHub adds to squash-merge commits — is always detected.
## Where work items appear
* On a **build**, the references found in that build's commits.
* On a **release candidate**, under the **Work Items** tab — the items new in that candidate, alongside the cumulative set since the last release.
* On a **release**, the items that were deployed, with cumulative totals.
When a [Jira integration](/flxbl/codev/integrations/issue-tracking/jira.md) is connected, detected issue keys are shown with their summary, status, and a link to the issue. Without one, the keys are still detected and listed; they are simply not enriched or linked.
## Customising
Everyday detection needs no configuration — writing commit messages in a recognised form is enough. Two things can be tuned when you need them:
* **Which Jira issues are read.** The Jira integration can be limited to specific project keys and uses a base URL to build issue links. See [Jira](/flxbl/codev/integrations/issue-tracking/jira.md).
* **Custom key patterns for the generated changelog.** If your project records work items in a form the defaults do not recognise, sfp's changelog generation accepts custom `workItemFilters` regular expressions under the `changelog` block of your release configuration:
```yaml
releaseName: sales
releasedefinitionProperties:
changelog:
workItemFilters:
- "SALES-[0-9]{3,4}"
workItemUrl: https://your-domain.atlassian.net/browse/
```
This governs the changelog file sfp writes during a release. See [sfp: Generating a changelog](https://docs.flxbl.io/flxbl/sfp/releasing-artifacts/generating-a-changelog) and the [Release config reference](https://docs.flxbl.io/flxbl/sfp/development/defining-a-domain/release-config) for placement and the full set of options.
{% hint style="info" %}
`workItemFilters` shapes the changelog file sfp writes during a release. The work items shown in codev — on builds, release candidates, and releases — come from the built-in detection described above and are not changed by it.
{% endhint %}
## Related
* [Release candidates](/flxbl/codev/ci-cd/overview-1.md)
* [Releases](/flxbl/codev/ci-cd/overview-3.md)
* [Jira](/flxbl/codev/integrations/issue-tracking/jira.md)
* [sfp: Generating a changelog](https://docs.flxbl.io/flxbl/sfp/releasing-artifacts/generating-a-changelog)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.flxbl.io/flxbl/codev/ci-cd/work-items.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.