Create Issue
Overview
Use this skill when asked to write or draft a GitHub issue. It ensures issues follow the conventions established in CONTRIBUTING.md and matches the user's specific architectural and stylistic preferences.
Instructions
When the user asks you to create a GitHub issue, follow these steps to draft the issue title, body, assignee, labels, and milestone. You MUST ALWAYS ask for explicit confirmation before creating the issue using the gh CLI. You should output the drafted issue to the terminal so the user can review it first.
1. Issue Title
All issues must have a path prefix indicating the relevant domain, followed by a lowercase summary.
Path Prefixes:
- Use package names or tool paths (e.g.,
librarian:, cli:, tool/cmd/migrate:).
- For language-specific code under
internal/librarian/<language>, use the lowercase language name (e.g., java:, dotnet:).
- For systemic proposals, chain prefixes (e.g.,
proposal: config:).
- Aside from proper nouns, the rest of the issue title must use lowercase.
2. Issue Body Structure
Match the user's specific writing style based on the type of issue:
Implementation/Tracking Issues
- Opening: Start with "This issue tracks the implementation of..." or "This issue tracks integrating..."
- Architecture Awareness: Explicitly call out the exact packages and files that need to be created or modified (e.g., "The implementation in
internal/librarian/dotnet/publish.go (and wired into internal/librarian/publish.go)").
- Action-Oriented Steps: Use a numbered list to break down the required logic into precise, ordered steps.
Systemic Proposals
- Use a cross-language comparative structure:
- Bolded categories for each language (e.g., Python, Go).
- A brief 1-2 sentence explanation of the current state.
- A markdown code block demonstrating the exact file output or configuration.
- Conclusion: A single, decisive concluding sentence that frames the evaluation goal without jumping to a solution.
Migration Tasks
- Use a two-sentence format:
- An imperative command to update a specific tool.
- A reference to an internal design document (e.g., "See go/sdk-librarian-nodejs for details.").
3. Assignee & Labels
- Assignee: Default to assigning if there's a clear owner; otherwise, leave unassigned.
- Labels:
- Use
critical for immediate attention (e.g., broken build on main).
- Use
needs fix soon for high-priority items.
4. Milestone
- Run
gh milestone list to retrieve available milestones.
- Ask the user to choose one, or suggest "Unplanned" if not on the roadmap.
Output Format
Present the drafted issue clearly:
Title: prefix: issue description
Assignee: @username (or Unassigned)
Labels: critical, needs fix soon, or None
Milestone: milestone_name
Body:
[Issue body here]
Ask the user if they would like to refine the issue or create it using gh issue create.
1---2name: create-issue3description: Helps create a GitHub issue that strictly follows the conventions in CONTRIBUTING.md. Use this skill when asked to create, draft, or open a GitHub issue or bug report.4---56# Create Issue78## Overview910Use this skill when asked to write or draft a GitHub issue. It ensures issues follow the conventions established in `CONTRIBUTING.md` and matches the user's specific architectural and stylistic preferences.1112## Instructions1314When the user asks you to create a GitHub issue, follow these steps to draft the issue title, body, assignee, labels, and milestone. **You MUST ALWAYS ask for explicit confirmation before creating the issue using the `gh` CLI.** You should output the drafted issue to the terminal so the user can review it first.1516### 1. Issue Title1718All issues must have a path prefix indicating the relevant domain, followed by a lowercase summary.1920**Path Prefixes:**21- Use package names or tool paths (e.g., `librarian:`, `cli:`, `tool/cmd/migrate:`).22- For language-specific code under `internal/librarian/<language>`, use the lowercase language name (e.g., `java:`, `dotnet:`).23- For systemic proposals, chain prefixes (e.g., `proposal: config:`).24- Aside from proper nouns, the rest of the issue title **must use lowercase**.2526### 2. Issue Body Structure2728Match the user's specific writing style based on the type of issue:2930#### Implementation/Tracking Issues31- **Opening:** Start with "This issue tracks the implementation of..." or "This issue tracks integrating..."32- **Architecture Awareness:** Explicitly call out the exact packages and files that need to be created or modified (e.g., "The implementation in `internal/librarian/dotnet/publish.go` (and wired into `internal/librarian/publish.go`)").33- **Action-Oriented Steps:** Use a numbered list to break down the required logic into precise, ordered steps.3435#### Systemic Proposals36- Use a cross-language comparative structure:37 - **Bolded categories** for each language (e.g., **Python**, **Go**).38 - A brief 1-2 sentence explanation of the current state.39 - A markdown code block demonstrating the exact file output or configuration.40- **Conclusion:** A single, decisive concluding sentence that frames the evaluation goal without jumping to a solution.4142#### Migration Tasks43- Use a two-sentence format:44 1. An imperative command to update a specific tool.45 2. A reference to an internal design document (e.g., "See go/sdk-librarian-nodejs for details.").4647### 3. Assignee & Labels4849- **Assignee:** Default to assigning if there's a clear owner; otherwise, leave unassigned.50- **Labels:** 51 - Use `critical` for immediate attention (e.g., broken build on main).52 - Use `needs fix soon` for high-priority items.5354### 4. Milestone5556- Run `gh milestone list` to retrieve available milestones.57- Ask the user to choose one, or suggest "Unplanned" if not on the roadmap.5859## Output Format6061Present the drafted issue clearly:6263**Title:** `prefix: issue description`64**Assignee:** `@username` (or Unassigned)65**Labels:** `critical`, `needs fix soon`, or None66**Milestone:** `milestone_name`6768**Body:**69```markdown70[Issue body here]71```7273Ask the user if they would like to refine the issue or create it using `gh issue create`.