docs(jira-communication): add subtask type naming and assign-to-me guidance#28
docs(jira-communication): add subtask type naming and assign-to-me guidance#28
Conversation
…idance On Jira Server/DC subtask issue types are prefixed with "Sub: " (e.g. "Sub: Task", "Sub: Bug") — using plain "Task" or "Sub-task" causes a hard failure. Document the correct naming convention and add a dry-run example. Also document the "assign to me" pattern: never guess the Jira username from a display name or email. Use `jira-user.py me` to resolve the authenticated user's username before calling --assignee. Both patterns were discovered from real command failures in the field. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request enhances the Highlights
Changelog
Activity
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request adds valuable documentation to SKILL.md regarding Jira subtask creation on Server/DC and how to self-assign issues. The new sections are clear and address real-world use cases. I have one suggestion to simplify the example command for self-assigning an issue, making it more robust and user-friendly by leveraging the existing --quiet flag instead of a complex shell pipe.
Note: Security Review has been skipped due to the limited scope of the PR.
Overtake copilot sugesstion to make getting currend username(-id) more reliable Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
|
|
||
| ## Creating Subtasks (Jira Server/DC) | ||
|
|
||
| On Jira Server and Data Center, subtask issue types are **prefixed with `Sub: `** — never `Sub-task` or a plain type name: |
There was a problem hiding this comment.
@aseemann , this is not true. Sub tasks can have whatever name you like. We self have "Sub-task" and "Sub: *" as sub-task names in our Jira. "SUB-TASK" is even the official issue type name.
|
|
||
| ```bash | ||
| # Correct — use "Sub: Task", "Sub: Bug", "Sub: Improvement", etc. | ||
| uv run scripts/workflow/jira-create.py issue PROJ "Fix login" --type "Sub: Task" --parent PROJ-100 |
There was a problem hiding this comment.
uv run scripts/workflow/jira-create.py issue PROJ "Fix login" --parent PROJ-100
should (be make) work, falling back to default sub task type if not defined with --type
uv run scripts/workflow/jira-create.py issue PROJ "Fix login" --type=bug --parent PROJ-100
should search for sub-task with "bug" or fall back to defgualt sub-task type.
"Default" for sub-tasks means the first in the result from GET /rest/api/2/issue/createmeta?projectKeys=PROJ&expand=projects.issuetypes.fields filtered by issuetypes[].subtask == true (for server on-prem)
| # Correct — use "Sub: Task", "Sub: Bug", "Sub: Improvement", etc. | ||
| uv run scripts/workflow/jira-create.py issue PROJ "Fix login" --type "Sub: Task" --parent PROJ-100 | ||
|
|
||
| # Wrong — these will fail with "issue type is not a sub-task" or "invalid issue type" |
There was a problem hiding this comment.
If this works or not entirely depends on how the issue types are named on the target Jira. This can work absolutely correct on some Jira.
There was a problem hiding this comment.
Pull request overview
Updates the jira-communication skill documentation to capture common Jira Server/DC and “assign to me” pitfalls so users/agents can run the existing CLI scripts correctly without trial-and-error.
Changes:
- Adds guidance on creating subtasks on Jira Server/DC with examples of issue type naming.
- Adds a recommended workflow for “assign to me” using
jira-user.py meto resolve the correct identifier.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| uv run scripts/workflow/jira-create.py issue PROJ "Fix login" --type "Sub-task" --parent PROJ-100 | ||
| ``` | ||
|
|
||
| To list all available issue types for a project (including subtask names): |
There was a problem hiding this comment.
The suggested command to “list all available issue types” is incorrect: jira-fields.py search "issuetype" searches fields (it will just return the built-in Issue Type field with id issuetype), not the project’s available issue type values. Consider updating this guidance to a method that actually enumerates issuetype names (e.g., reference Jira UI / REST endpoint) or rephrase to “identify the Issue Type field id” if that’s what you meant.
| To list all available issue types for a project (including subtask names): | |
| To identify the built-in Issue Type field (for use in field-related operations): |
| Never derive the Jira username from a display name or email address — they often differ. Use `jira-user.py me` to get the authenticated user's username: | ||
|
|
||
| ```bash | ||
| # Get current user's username | ||
| uv run scripts/utility/jira-user.py --quiet me # → returns username or account ID |
There was a problem hiding this comment.
This section says jira-user.py me returns the authenticated user’s “username”, but on Jira Cloud the script prints the accountId in --quiet mode (see jira-user.py: it prefers accountId over name). To avoid confusion, adjust the wording to “accountId (Cloud) or username/name (Server/DC)” and ensure the surrounding text consistently uses that terminology.
| Never derive the Jira username from a display name or email address — they often differ. Use `jira-user.py me` to get the authenticated user's username: | |
| ```bash | |
| # Get current user's username | |
| uv run scripts/utility/jira-user.py --quiet me # → returns username or account ID | |
| Never derive the Jira username from a display name or email address — they often differ. Use `jira-user.py me` to get the authenticated user's accountId (Cloud) or username/name (Server/DC): | |
| ```bash | |
| # Get current user's accountId (Cloud) or username/name (Server/DC) | |
| uv run scripts/utility/jira-user.py --quiet me # → returns accountId (Cloud) or username/name (Server/DC) |
| On Jira Server and Data Center, subtask issue types are **prefixed with `Sub: `** — never `Sub-task` or a plain type name: | ||
|
|
||
| ```bash | ||
| # Correct — use "Sub: Task", "Sub: Bug", "Sub: Improvement", etc. | ||
| uv run scripts/workflow/jira-create.py issue PROJ "Fix login" --type "Sub: Task" --parent PROJ-100 | ||
|
|
||
| # Wrong — these will fail with "issue type is not a sub-task" or "invalid issue type" | ||
| uv run scripts/workflow/jira-create.py issue PROJ "Fix login" --type "Task" --parent PROJ-100 | ||
| uv run scripts/workflow/jira-create.py issue PROJ "Fix login" --type "Sub-task" --parent PROJ-100 |
There was a problem hiding this comment.
The doc states that on Jira Server/DC subtask issue types are always prefixed with Sub: and that Sub-task is “never” valid. Jira Server/DC issue type names are instance-configurable (and the default built-in subtask type is commonly named “Sub-task”), so this guidance is likely instance-specific. Consider softening the wording (e.g., “On some Server/DC instances…”) and emphasizing discovery of the exact subtask type name for the target project instead of asserting a universal prefix.
Summary
Sub:(e.g.Sub: Task,Sub: Bug). Using plainTaskorSub-taskwith--parentcauses a hard failure (Issue type is not a sub-task/Invalid issue type). Added a dedicated section with correct and incorrect examples.Axel Seemann→ actual usernameaxel.kummer). Added a pattern that usesjira-user.py meto resolve the authenticated user's username before passing it to--assignee.Both patterns were discovered from real command failures and are already handled correctly by the existing scripts — this PR just makes the guidance explicit in SKILL.md so the agent doesn't have to learn it the hard way again.
Test plan
jira-user.py mereturns anamefield on both Cloud and Server profiles--type "Sub: Task" --parent PROJ-Xcreates a subtask successfully on a Server instance🤖 Generated with Claude Code