> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cloud.anex.is/llms.txt
> Use this file to discover all available pages before exploring further.

# Issue tracker

# Issue tracker: Jira

Issues and specs for this repo live in the Jira project **AXC** (keys `AXC-####`). Use the `mcp__atlassian__*` MCP tools; resolve `cloudId` once per session with `getAccessibleAtlassianResources`. GitHub Issues are not used.

## Conventions

* **Create an issue**: `createJiraIssue` with `projectKey: "AXC"`, an issue type from `getJiraProjectIssueTypesMetadata`, summary and markdown description.
* **Read an issue**: `getJiraIssue` with the key (e.g. `AXC-4806`), including comments.
* **List issues**: `searchJiraIssuesUsingJql`, e.g. `project = AXC AND labels = ready-for-agent AND statusCategory != Done`.
* **Make an issue a child of a parent**: set `parent` to the parent's key (Epic → Story/Task, or Story → Sub-task).
* **Comment on an issue**: `addCommentToJiraIssue`.
* **Apply / remove labels**: `editJiraIssue` with the full updated `labels` array (read current labels first; the field is replaced, not merged).
* **Close**: comment with the reason, then `transitionJiraIssue` to a Done-category transition from `getTransitionsForJiraIssue`.

Branches and commits carry the key (`AXC-####-slug`; Husky prefixes commits with `[AXC-####]`), so a ticket mentioned without a key can usually be recovered from the current branch name.

## When a skill says "publish to the issue tracker"

Create a Jira issue in `AXC`.

## When a skill says "fetch the relevant ticket"

`getJiraIssue` with the key; fall back to the key in the current branch name.

## Specs

Used by `/spec` and `/build`.

* **Story**: the description is the whole spec (format: `.claude/skills/spec/JIRA-FORMAT.md`): problem, goal, numbered acceptance criteria `AK1…`, edge cases, out of scope, prototype link, assumptions. No spec file or branch exists in the repo.
* **Epic**: a change too big for one PR; each child Story carries its own complete spec and ships as its own PR. Order is native `Blocks` links.
* `/spec` labels what it publishes `ready-for-agent`. `/build` posts its plan as a comment, opens one draft PR per Story, comments the PR link and adds `needs-info` when the PR is unfinished or has unresolved findings.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.