Menu
Create a SAAS Jira ticket. Just describe what you're working on and it handles the rest.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when creating, opening, or submitting a pull request in a Dimagi mobile/CommCare repo — identified by JIRA-prefixed branches (e.g. CCCT-1929-...), a `RELEASES.md` with `### Release Notes` and `### QA Notes` sections, and the dimagi PR template (Safety story / Product Description / Technical Summary / QA Plan). Also triggers on "ship this" or when implementation is complete and ready to push. For repos without these conventions, use the generic `create-pr` skill instead.
Fix CI failures and address review feedback on the current branch's PR. Use when CI is failing, review comments need addressing, or you need to push fixes for an open PR. Supports --dry-run to preview without changes.
Run a full dependency audit for a project — covers Python (pip-tools) and front-end (npm/yarn) if present. Produces report, applies safe bumps, emits Jira-ready ticket list for risky/EoL items. Use when running quarterly maintenance or on demand.
End of day wrap-up — captures what got done, what didn't, and plans for tomorrow. Weekly close-out on configurable review day (default Friday).
Conversational skill for reviewing, updating, and refining your professional goals.
Morning check-in — surfaces goals, summarizes where you left off, captures today's plan, and gives goal-alignment feedback. Weekly review mode on configurable review day (default Friday).
| name | jira-ticket |
| description | Create a SAAS Jira ticket. Just describe what you're working on and it handles the rest. |
| argument-hint | <describe the work> |
Create a ticket in the SAAS project with smart defaults so the developer can just describe the work in plain English.
$ARGUMENTS — A free-form description of the work. Can be as brief as a title or as detailed as needed. Examples:
/jira-ticket fix the login redirect bug/jira-ticket refactor the pillow processor to reduce memory usage/jira-ticket investigate formplayer memory spikes, assign to Graham/jira-ticket Delete FF follow-up: remove old SMS settings model, hours/jira-ticket update exports page header, assign to Daniel, P3/jira-ticket add case search filter, in the ERM epic, hours/jira-ticket Subtask 1: add geolocation to formplayer, under SAAS-18500SAAS (always)dbff467f-3c3f-4ced-a2ba-a29e1941edd6customfield_10160customfield_10010The assignee is determined from the input using natural language:
lookupJiraAccountId to search for that person's name and use their accountId.atlassianUserInfo to get the current authenticated user's account ID. Developers self-assign 94% of the time.assignee_account_id.Never hardcode an assignee ID. Always resolve dynamically.
Infer the issue type from the description using natural language. The user does NOT need to use exact keywords — understand intent.
Based on dev team patterns: Task is overwhelmingly dominant (88% of IC dev tickets). Improvement is a distant second. Bug and Story are rare. The team does not use the Feature, Design, or New Feature issue types.
| Issue Type | Exact Jira Name | When to Use |
|---|---|---|
| Task | Task | Default for almost everything. New functionality, creating things, investigations, follow-ups, migrations, deletions, management commands, specs, testing, FF cleanup, hotfixes. If "add", "new", "create", "implement", "build", "investigate", "delete", "set up", "test", "remove", "merge", "track", "confirm", "validate", "spec" — use Task. |
| Improvement | Improvement | Enhancing something that already works and the user explicitly frames it as an improvement: "improve", "refactor", "optimize", "clean up", "enhance", "modernize", "simplify", "consolidate", "better error message", "disable when already", "replace X with Y". Only use this when the intent is clearly about making an existing thing better, not building something new. |
| Bug | Bug | Something is broken or wrong and the user explicitly says so: "bug", "broken", "crash", "error", "fails", "regression", "not working". Devs rarely file bugs (3% of tickets) — most bug tickets come from support. |
| Performance/Scale | Performance/Scale | Infrastructure performance issues: "slow", "performance", "memory spikes", "latency", "OOM", "bottleneck", "connection spikes", "apdex". |
| Story | Story | User stories, research spikes, ideation, UX research. Very rarely used. |
Important: Use the exact Jira name from the second column when calling createJiraIssue. When in doubt, use Task.
The team writes summaries in a consistent style. Follow these conventions:
Delete FF: ... (feature flag removal — most common pattern)Delete FF follow-up: ... (post-deletion cleanup)GA FF: ... (GA feature flag work)User & Security Features: ... (feature audit)Data & Export Features: ... (feature audit)Subtask N: ... (numbered subtasks)Onboarding: ... (onboarding tasks)[Investigation] ... or [Mobile] ... (bracket tags)Hotfix X.Y.Z - ... (hotfix tasks)The Effort Range (customfield_10160) is required. Infer from natural language in the input:
| Value | Jira Option ID | Trigger Signals |
|---|---|---|
| Hours | 10384 | "hours", "hour", "quick", "small", "a few hours", "half day", "simple" |
| Days | 10385 | "days", "day", "a day or two", "multi-day", "several days", "large" |
| Too Large - Needs Breaking Down | 11973 | "too large", "needs breaking down", "epic-sized", "needs to be split", "way too big" |
| Awaiting Score | 10383 | "not sure", "unsure", "unknown effort", "TBD", "awaiting score" |
| N/A | 10426 | "n/a", "not applicable" |
Default when no effort is mentioned: Use Hours (id: 10384). This matches 62-79% of dev-created tickets. Only ask the user if the work sounds like it could be multi-day or ambiguous.
Detect priority from the input using natural language. If no priority is mentioned, do not set it — the Jira default is P6 and developers almost never override this (88-98% leave it at P6). Only set priority when the user explicitly mentions it.
| Priority | Jira ID | Trigger Signals |
|---|---|---|
| P1 | 1 | "P1", "blocker", "site down", "production down", "outage", "SEV1", "sev-1" |
| P2 | 2 | "P2", "urgent", "ASAP", "critical", "SEV2", "drop everything" |
| P3 | 3 | "P3", "high priority", "important", "soon" |
| P4 | 4 | "P4", "normal priority", "medium priority" |
| P5 | 5 | "P5", "low priority", "when you get a chance", "not urgent" |
| P6 | 10000 | "P6" (rarely set explicitly — it's the default) |
| P7 | 10001 | "P7", "someday", "lowest" |
Set priority via additional_fields: "priority": {"id": "<priority_id>"}
If the user mentions an epic, link the new ticket as a child of that epic using the parent field on createJiraIssue.
Team patterns: Developers link to a parent epic ~80-100% of the time. However, don't always interrupt the flow to ask — use judgment:
How to detect epic references (natural language):
How to resolve the epic:
parent value.project = SAAS AND issuetype = Epic AND statusCategory != Done AND summary ~ "<search terms>" ORDER BY created DESCSet via parent parameter: parent: "SAAS-18371"
Determine the sprint based on the nature of the work. 91% of dev-created tickets are assigned to a sprint.
Search for active sprints using JQL: project = SAAS AND sprint in openSprints() with the searchJiraIssuesUsingJql tool. Fetch at least 2 results to find both sprints. The sprint data is in the customfield_10010 field. If the first result only shows one sprint, run a second query excluding that sprint ID to find the other.
Identify sprints by name: Sprint names follow the pattern CommCare [Product|Platform] [Name]. Look for "Product" or "Platform" in the sprint name to classify them. Do NOT rely on specific sprint names — they change every sprint cycle.
Classify the work using natural language:
If the user says "backlog" anywhere in their description, do NOT assign a sprint (leave it in the backlog).
If you can't determine which sprint, ask the user: "Product sprint or Platform sprint? (or backlog)"
Set sprint via additional_fields: "customfield_10010": <sprint_id_number> (plain integer, NOT an object).
Developers on this team rarely set components on their own tickets. Don't add one unless the input explicitly specifies a component (e.g., "component: Formplayer", "Component: Data Privacy / Security"). Other skills like /jira-cve may pass a component — always honor it when present.
If a component is specified, use additional_fields: "components": [{"name": "Component Name"}]
Whether to include a description depends on how much detail the user provided:
Only transition if a sprint was assigned. New issues default to Backlog — no transition needed when there is no sprint.
When a ticket is assigned to the current (active) sprint, transition it to Prioritized after creation unless otherwise specified:
getTransitionsForJiraIssue on the newly created ticket to get available transitions."Prioritized" and use its id.transitionJiraIssue with that transition ID.If the ticket has no sprint, do NOT call getTransitionsForJiraIssue or transitionJiraIssue — skip this section entirely.
$ARGUMENTS to extract: summary, description details, issue type, effort, priority, assignee, epic, and sprint intent.lookupJiraAccountId.atlassianUserInfo (for self-assignment).Created [SAAS-XXXXX](https://dimagi.atlassian.net/browse/SAAS-XXXXX): Summary here
Sprint: CommCare Product W | Effort: Hours | Assigned to: Graham
Include the ticket URL (clickable in the terminal), the sprint it was added to (or "Backlog" if none), effort range, and assignee. Only include epic/priority/status lines if they were explicitly set. Keep it compact — no more than 3 lines.