Use when syncing a feature spec to Jira after it is saved. Handles four states — no epic/ticket, epic only, both exist, or dev opts out. Invoked automatically by the spec skill after the spec file is saved. Also invoked after stage approvals to update ticket status.
From casaflownpx claudepluginhub casaperks/casaflow --plugin casaflowThis skill uses the workspace's default tool permissions.
Designs and optimizes AI agent action spaces, tool definitions, observation formats, error recovery, and context for higher task completion rates.
Enables AI agents to execute x402 payments with per-task budgets, spending controls, and non-custodial wallets via MCP tools. Use when agents pay for APIs, services, or other agents.
Compares coding agents like Claude Code and Aider on custom YAML-defined codebase tasks using git worktrees, measuring pass rate, cost, time, and consistency.
This skill runs after a spec is saved. It syncs the spec content to Jira by creating or updating epics and tickets using the Atlassian MCP server. It requires explicit developer approval before any Jira action is taken.
Jira sync is always optional and failure is always recoverable. It must
never block the developer from reaching /build.
Before any MCP call, confirm the Atlassian MCP server is available. If Jira MCP tools are not configured, say:
"The Atlassian MCP server is not configured. To enable Jira sync, add the Atlassian MCP server to your Claude Code settings.json under
mcpServers. Skipping Jira sync and continuing to/build."
Then proceed to /build with no Jira action.
"Spec saved. Do you want to sync this spec to Jira? (yes / skip)"
/build." Stop here.Ask in a single message:
"Two quick questions:
- What is the Jira project key? (e.g. CASA, ENG, PLAT)
- Do you have an existing epic key, a ticket key, both, or neither?
- Neither → I'll create both
- Epic only → provide the epic key, I'll create the ticket
- Both → provide both keys, I'll update the ticket"
Parse the response to determine which state applies (A, B, or C below).
Generate a concise summary from the saved spec:
This summary becomes the Jira description. The full spec markdown becomes a comment on the ticket.
Present before any MCP call:
"Here is what I will push to Jira:
Action: [create epic + ticket / create ticket under [EPIC-KEY] / update [TICKET-KEY]] Project: [PROJECT-KEY]
Description: [generated summary]
Comment: Full contents of
specs/<feature>.mdadded as a comment.Approve this push? (yes / skip)"
/build." Stop here.After each MCP create or update call, read back the affected issue by key.
Confirm independently:
Description correct, comment missing:
"The ticket description was synced successfully, but the comment could not be confirmed. Paste the contents of
specs/<feature>.mdinto the ticket comment manually to stay consistent with other tickets." Proceed to Step 7 for the description success.
Description missing or wrong: Fall through to the failure path.
Both correct: Proceed to Step 7.
Output only the keys that were created or updated:
"Jira sync complete. [Epic: EPIC-KEY / ] Ticket: TICKET-KEY"
Then immediately invoke /build without waiting for further input.
After each approved build stage, optionally update the Jira ticket status.
Check casaflow.config.md for jira.auto-update-on-stage.
If enabled:
jira.done-on-merge: true)Status transitions use the MCP transitionIssue tool. If the transition
fails, surface the failure but do not block the pipeline.
If any MCP call fails:
State clearly what failed:
"The Jira sync failed — [epic / ticket / comment] was not created or updated successfully."
Output the summary for manual entry:
"Here is the summary to paste into the Jira description manually:" [generated summary]
Remind to add the spec as a comment:
"For the ticket comment, paste the contents of
specs/<feature>.md."
Proceed to /build without waiting for further input.
Empty or missing spec file: Confirm the spec file exists and is non-empty
before Step 3. If missing: skip Jira sync, proceed to /build.
Invalid project key: If the MCP returns a key-not-found error, allow one re-entry. If the second attempt also fails, fall through to failure path.
Special characters in feature name: Pass as-is — the MCP handles encoding. If the MCP rejects the name, surface the error and use failure path.
/build