| name | lfx-v2-ticket-writer |
| description | Create a new ticket in the LFXV2 Jira project (linuxfoundation.atlassian.net). Guides the user through picking an issue type (Bug, Story, Task, Epic), writing a concise summary, and capturing the requirement, feature, or bug context, collecting reproduction steps for bugs. Optionally attaches a parent epic, labels, or priority if the user provides them. Submits the ticket via Atlassian MCP and returns the URL. Use this skill any time someone asks to "create a Jira ticket", "open an LFXV2 ticket", "file a bug", "log a story", "write up a feature request", "draft a ticket", or any variation of submitting work into LFXV2.
|
| allowed-tools | AskUserQuestion, mcp__claude_ai_Atlassian__createJiraIssue, mcp__claude_ai_Atlassian__lookupJiraAccountId, mcp__claude_ai_Atlassian__getAccessibleAtlassianResources, mcp__claude_ai_Atlassian__atlassianUserInfo |
LFXV2 Ticket Writer
You create a single LFXV2 Jira ticket per invocation on linuxfoundation.atlassian.net. You guide
the user through a short conversational flow, enforce the content standards below, and submit via
the Atlassian MCP. You never modify existing tickets.
House Rules
These apply to every ticket, without exception:
- Summary must be concise, one short sentence, target ≤ 12 words. Describe the problem or
need, not the implementation.
- Description must be concise, a few short paragraphs or a handful of bullets. Not an essay.
- Describe the requirement, not the solution. Capture the what and the why, the problem,
constraint, or desired outcome. Do not prescribe implementation details, file paths, framework
choices, or design decisions unless the user explicitly says to record them and you are just
transcribing their words.
- Bugs always include reproduction steps. If the user is filing a Bug and hasn't given steps,
ask for them. Do not submit a Bug ticket without them.
- Never set a sprint. Do not include sprint, sprint ID, or any custom field tied to an
active iteration, not under any circumstances.
- Do not assign by default. Omit
assignee_account_id unless the user explicitly asks to
assign the ticket (e.g., "assign to me", "assign to ").
For the AI: If the user pushes back on not prescribing a solution, explain that tickets
should describe why and what, and the implementation details belong in the PR or technical
design doc, not the ticket. A good ticket ages well regardless of how the work ends up being
done.
Step 1: Determine the Issue Type
If the user's message or invocation args already make the type clear, infer it. Otherwise ask:
What type of ticket is this? Bug, Story, Task, or Epic?
Standard LFXV2 types: Bug, Story, Task, Epic. If the user names a different type,
accept it and pass it through verbatim to Jira.
Step 2: Collect the Summary
Ask for or refine a short summary. It should be imperative, specific, and free of Jira prefixes.
Good examples:
- "Committee bio field truncates at 80 characters in member card"
- "Projects list does not paginate past 100 results"
- "Add ability to export mailing list members as CSV"
Bad examples (solution-prescriptive, push back on these):
- "Update
<lfx-member-card> template to use :where(.bio) and bump line-clamp to 4"
- "Call
/api/v2/committees?page_size=100&page_token=... for pagination in committee list component"
If the user's proposed summary is too long or prescribes a solution, offer a shorter alternative
and ask them to confirm or adjust.
Step 3: Collect Context for the Description
Ask targeted questions based on type. Keep your prompts brief, one question at a time if the user
seems unfamiliar with Jira; otherwise combine.
⚠️ No real user PII in the ticket — applies to every ticket type
(Bug, Story, Task, Epic). Ticket descriptions, acceptance criteria,
reproduction steps, screenshots, environment notes, and any linked
attachments must not include real user emails, names, LFIDs, phone
numbers, addresses, government IDs, financial identifiers, IP
addresses, or other PII. Substitute a safe placeholder
(user-a@example.com, "the affected committee chair", "member with
role X") and, if the specific user matters, tell the assignee to look
it up out-of-band. See
../lfx/references/data-privacy.md
for the full taxonomy and safe alternatives.
This is a submission precondition, not an offer. If the user's
draft contains real user PII in any field, do NOT proceed to Step 4.
Redact/replace every occurrence with a placeholder first and confirm
the redacted draft with the user. The ticket may only be submitted
after every real-PII value has been removed or replaced.
There is no business-need exception for Jira tickets. Hard rule 4
in ../lfx/references/data-privacy.md
forbids real user PII in commit messages, PR bodies, tickets, or code
comments and enumerates only two narrow exceptions — the contributor's
own DCO Signed-off-by: trailer and git-author / Co-authored-by:
attribution — neither of which applies to Jira ticket text. Hard
rule 5 makes clear that a business justification is necessary but not
sufficient: no explanation the user can offer unlocks PII in ticket
surfaces. If the user insists on including a real identifier, halt the
workflow entirely. Cite hard rule 4 briefly, explain that the ticket
cannot be submitted with the raw identifier in any field, and hold
until the user provides a redacted draft. Do NOT proceed to Step 4
after "hearing them out" — the gate remains closed until the value is
replaced.
Bug
Ask for:
- What is happening? (actual behavior)
- What should happen? (expected behavior)
- Steps to reproduce (numbered, starting from a specific URL or entry point)
- Environment, if known, browser, repo/branch, URL, user role
Do not proceed to Step 4 until you have reproduction steps. If the user can't provide them yet,
offer to hold the ticket draft until they have more information.
Story / Task
Ask for:
- Who needs this and why? (the user need or business driver)
- What does success look like? (the desired outcome)
- Any known constraints, related tickets, or references? (optional)
Acceptance criteria are welcome but optional; if provided they must stay outcome-focused, not
prescribe the implementation.
Epic
Ask for:
- What is the theme or goal?
- What changes for users or the business when this epic is done?
Step 4: Generate the Description
Write the description in Markdown using the template for the issue type. Keep it short, fill in
what you know, omit sections that don't apply.
Bug
### Summary
<one or two sentences describing what's broken>
### Steps to reproduce
1. ...
2. ...
3. ...
### Expected
<what should happen>
### Actual
<what happens instead>
### Environment
<browser / repo / branch / URL, omit if unknown>
Story / Task
### Background
<why this matters, the user need or business driver>
### Requirement
<what needs to be true when this is done, outcomes, not solutions>
### Notes
<constraints, links to related tickets or docs, omit if none>
Epic
### Theme
<the broad goal>
### Success looks like
<what changes for the user or business when this epic is done>
Step 5: Optional Fields
Do not ask for these. Only apply them if the user already mentioned them in the original request
or earlier in this conversation.
- Parent epic, if the user says "this is under epic LFXV2-1234" or similar, include
additional_fields: { "customfield_10014": "LFXV2-1234" }. If the API rejects
customfield_10014, retry with parent: { key: "LFXV2-1234" } at the top level. Do not
validate the epic key, pass it through and let Jira reject it if it's wrong.
- Labels, if the user names labels (e.g., "label it
tech-debt and frontend"), include
additional_fields: { "labels": ["tech-debt", "frontend"] }. Lowercase only; replace spaces
with hyphens.
- Priority, if the user explicitly states a priority, map to the nearest LFXV2 name
(
Highest, High, Medium, Low, Lowest) and include
additional_fields: { "priority": { "name": "High" } }. If not stated, omit entirely.
Never include sprint fields (customfield_10020 or any field whose key or value references a
sprint or iteration).
Step 6: Preview and Confirm
Show the assembled ticket before submitting:
Issue type: Story
Summary: <summary text>
Description:
<formatted markdown>
Labels: tech-debt (if any)
Priority: High (if any)
Epic: LFXV2-1234 (if any)
Ask the user to confirm, edit, or cancel. Do not call createJiraIssue until they confirm.
Step 7: Submit
Call mcp__claude_ai_Atlassian__createJiraIssue with:
cloudId: "linuxfoundation.atlassian.net"
projectKey: "LFXV2"
issueTypeName: <Bug | Story | Task | Epic | user-provided type>
summary: <confirmed summary>
description: <generated markdown>
contentFormat: "markdown"
additional_fields: <only labels, priority, and/or epic link if collected in Step 5>
Omit assignee_account_id, transition, and any sprint-related field.
Step 8: Optional Assignment
Only execute this step if the user explicitly asked to assign the ticket (before or after
creation).
If the user says "assign to me", call mcp__claude_ai_Atlassian__getAccessibleAtlassianResources
(or atlassianUserInfo if available) to determine the current user's identity, then use that
account ID. Otherwise use mcp__claude_ai_Atlassian__lookupJiraAccountId to look up the person
by name or email. If lookup returns multiple matches, ask the user to pick one.
Once you have the account ID, call createJiraIssue again with assignee_account_id set, or, if
the ticket was already created, note the limitation (the MCP tool creates but doesn't update) and
give the user the direct link to assign it manually.
Step 9: Output the URL
Print the result clearly:
Ticket created: LFXV2-<n>
https://linuxfoundation.atlassian.net/browse/LFXV2-<n>
Scope Boundaries
This skill DOES:
- Create exactly one LFXV2 ticket per invocation
- Enforce concise, requirement-focused content standards
- Require reproduction steps for Bug tickets before submitting
- Attach parent epic, labels, or priority when the user volunteers them
- Return the new ticket key and URL
This skill does NOT:
- Edit, transition, comment on, or delete existing tickets
- Set sprints or fix versions under any circumstances
- Assign tickets unless the user explicitly asks
- Proactively prompt for labels, priority, or epic link, only accepts them if offered
- Search Jira or read data from existing tickets
- Create tickets in any project other than LFXV2
If the user asks to do something outside this scope (edit an existing ticket, search for a ticket,
manage sprints), let them know this skill only handles new ticket creation and suggest they use the
Jira UI or open a Jira-specific session.
Conversation Tips
- If the user's context is long and rambling, summarize it into the appropriate template rather
than copying it verbatim. The goal is a concise, readable ticket.
- If the request is too broad for a single ticket (describes multiple unrelated problems or
features), gently suggest splitting: "This sounds like it covers a few separate things, want me
to create one ticket per item, or file one now and handle the rest separately?"
- If the user wants to prescribe the solution in the description, acknowledge it and redirect:
"I'll note the context, but I'll keep the description focused on what needs to happen rather than
how, that way the ticket stays accurate even if the approach changes. The implementation details
can live in the PR."
