dot-issue-manage

# Create / Update / Query / Find GitHub Issues AI-agent-native skill for managing GitHub issues in `dotCMS/core`. Infers where possible — asks only what's needed. **Contents:** [Mode Detection](#step-0--mode-detection) · [CREATE](#create-mode) · [UPDATE](#update-mode) · [QUERY](#query-mode) · [FIND](#find-mode) · [Authorization](#authorization) **References:** [feature-labels.md](references/feature-labels.md) · [project-fields.md](references/project-fields.md) · [github-apis.md](references/github-apis.md) · [issue-refinement.md](references/issue-refinement.md) ## Step 0 — Mode Detection ### 0a — Check current branch for issue context Before classifying the request, check the current git branch for an embedded issue number: ```bash git branch --show-current 2>/dev/null ``` Extract the issue number by trying these patterns in order (stop at first match): | Priority | Pattern | Example branch | Extracts | |---|---|---|---| | 1 | `issue-(\d+)` | `issue-34791-nx-workspace` | `34791` | | 2 | Branch starts with digits | `34792-fix-login` | `34792` | | 3 | Digits after `/` or `-` separator | `fix/34793-something` | `34793` | Do **not** match short numeric suffixes that are clearly not issue numbers (e.g., `setup-e028`, `v2`, `node22`). A valid issue number is 4+ consecutive digits standing alone — not embedded inside a word or preceded by a letter. Store the result as the **branch issue number**. **Use the branch issue number as the default** for UPDATE and QUERY operations when the user refers to "the issue", "this issue", "it", "the current issue/PR", or any other pronoun without specifying a number explicitly — unless the user is clearly discussing a different issue mid-conversation. If no issue number is found in the branch name, proceed without a default. ### 0b — Classify mode Read the user's request and classify: - **CREATE** — "create an issue for X", "file a bug for Y", "spike on Z", "I need an issue for…" - **UPDATE** — "update issue #N", "set issue #N to In Progress", "add sub-issue to #N", "change the title of #N" - **QUERY** — "show issue #N", "what's the status of #N", "list sub-issues of #N", "check #N" - **FIND** — "find an issue", "what issues are assigned to me", "show my open issues", "which issues am I working on", "open issues for my team", "search for X", "what's on my plate", "show recent issues" If the mode is UPDATE or QUERY and no issue number is given but a branch issue number was found, use it and proceed — no need to ask. If genuinely unclear, ask one question to clarify. --- ## CREATE Mode ### Step 1 — Classify issue type From the user's description — do NOT ask unless genuinely ambiguous: | User signals | Template | |---|---| | Bug / not working / broken / error / regression | **Defect** | | Research / investigate / POC / spike / unknowns / explore | **Spike** | | Task / implement / refactor / update library / improve / CI / infra | **Task** | | New feature / add capability (product context) | **Feature** | | Large initiative / umbrella work | **Epic** | | UX / usability / interface problem / design | **UX** | Note: Feature and Epic templates are "Product team use only"; Defect, Task, and Spike are "Engineering team use". ### Step 2 — Read the correct template ```bash ls .github/ISSUE_TEMPLATE/ ``` Then read the specific template file for the type chosen in Step 1 using the Read tool. Always read fresh — never assume structure. ### Step 3 — Generate title Concise, imperative, in English. Translate from Spanish if needed. ### Step 4 — Select feature label (optional) Feature labels are optional. Use [references/feature-labels.md](references/feature-labels.md) to match against the issue description. - **Single clear match** → apply silently, no confirmation needed. "Clear" means the description contains an explicit keyword from the Keyword Matching Guide. Inferred context does not qualify. - **2–3 plausible matches** → ask using `AskUserQuestion`. Always include **"None — skip feature label"** as the first option. - **No clear match** → ask using `AskUserQuestion`. Always include **"None — skip feature label"** as the first option. Note: `dotCMS : Content Management` is a specific label for issues about core content management features (content types, contentlet operations, content creation workflows). It is **not** a generic fallback. ### Step 4b — Determine native GitHub Issue Type (REQUIRED) Set via REST PATCH immediately after creation. This is GitHub's first-class type system. Read the matching template file in `.github/ISSUE_TEMPLATE/` (e.g. `defect.yaml`, `task.yaml`) and use its `type:` field value — that is the exact string for the REST PATCH call. For example, `defect.yaml` has `type: bug` → use `Bug` (capitalize first letter). > **Exception:** `ux.yaml` has no `type:` field. Use `Task` for UX issues. ### Step 4c — Select `Type :` label (OPTIONAL) Apply alongside the feature label. Omit only when no reasonable match exists. | Template | Default `Type :` label | Refine on description keywords | |---|---|---| | Defect | `Type : Defect` | — | | Spike | `Type : Spike` | — | | Task | `Type : Task` | "refactor" → `Type : Refactoring`; "CI/CD/pipeline/workflow" → `Type : CI/CD`; "docs/documentation" → `Type : Documentation`; "test automation/e2e" → `Type : Test Automation`; "technical design/ADR" → `Type : Technical Design` | | Feature | `Type : New Functionality` | — | | Epic | `Type : New Functionality` | — | | UX | `Type : Visual Design` | — | ### Step 5 — Determine Technology Derived automatically from user description — no extra input needed: | Signals | Technology value | |---|---| | Angular / frontend / UI / TypeScript / component / admin interface | `Front-end` | | Java / REST / backend / Spring / Maven / server-side | `Java` | | Angular + Java / full-stack / both frontend and backend | `FE and BE` | | Build / CI / Docker / infra / Nx / npm / Maven structure / pipeline | `Platform` | | Marketing / sales / business | `Go-To-Market` | See [references/project-fields.md](references/project-fields.md) for field and option IDs. ### Step 6 — Determine team assignment **Cache file:** `~/.config/dotcms/create-issue/default-team` This path is user-level and stable regardless of where the skill is installed (user-level `~/.claude/` or project-level plugin). **Resolution order:** 1. **Explicit in user's message** (e.g., "Enablement team issue", "for the Falcon team") → use it directly; if different from cached default, offer to update the cache 2. **Cache hit** — read the file: ```bash cat ~/.config/dotcms/create-issue/default-team 2>/dev/null ``` If non-empty, use that team silently — no question asked. Mention it briefly in the confirmation (e.g., "Team: Enablement (default)"). 3. **No cache** → use a two-stage cascading selection. Team is determined by which team the developer belongs to — it has no relation to issue content. **Stage 1** — present the 4 highest-usage teams (by historical frequency): - `Team : Falcon` - `Team : Maintenance` - `Team : Scout` - `Team : Platform` If the user picks "Other", proceed to Stage 2. **Stage 2** — present the next tier: - `Team : Modernization` - `Team : Enablement` - `Team : Security` - `Team : UX` If the user picks "Other" again, they type the team name freely (covers `Team : Architecture`, `Team : Lunik`, `Team : Cloud Eng`, `Team : 3rd Party`, or any new team). After selection at any stage, ask: "Set as default team for future issues?" If yes: ```bash mkdir -p ~/.config/dotcms/create-issue && echo "Team : SELECTED_TEAM" > ~/.config/dotcms/create-issue/default-team ``` **Override:** If the user says the wrong team was used, or provides a different team explicitly, apply the new team and ask whether to update the default. **Reset:** User can clear the cache at any time: ```bash rm ~/.config/dotcms/create-issue/default-team ``` If the user specifies a team not in the known list, verify it exists before applying: ```bash gh label list --repo dotCMS/core --limit 1000 | grep "^Team :" ``` ### Step 7 — Check for relationships Scan user's description for: - "sub-issue of #N" / "child of #N" / "part of epic #N" → capture parent number - "blocks #N" / "blocked by #N" → capture dependency numbers Ask only if partially specified (e.g., "it's a sub-issue" but no number given). ### Step 7a — Quick-draft detection (skip Issue Refinement when requested) **Trigger:** User explicitly asks to create the issue without going through ambiguity resolution. Treat as quick-draft when the request includes any of: - **English:** "draft", "quick", "quick draft", "without full details", "skip ambiguities", "create quickly", "minimal details" - **Spanish:** "draft rápido", "rápido", "sin detalles completos", "sin resolver ambigüedades", "crear rápido", "sin pasar por ambigüedades" When **quick-draft** is set: - **Skip Step 7b** (Issue Refinement loop) entirely — do not run Phase 1–6, do not ask clarification questions. - In Step 8, for the Acceptance Criteria section use a short placeholder, e.g.: - "**Acceptance criteria** — To be refined. (Quick draft; details to be added later.)" - Or 1–3 bullet points derived only from the user's raw description, with no ambiguity resolution. - Proceed directly from Step 7 to Step 8 after relationships are captured. When quick-draft is **not** set, continue to Step 7b as usual. ### Step 7b — Issue Refinement Loop (REQUIRED before writing body, unless quick-draft) Read [references/issue-refinement.md](references/issue-refinement.md) and execute the full loop against the user's description. **Goal:** Produce unambiguous, testable Acceptance Criteria as checkbox items before the issue body is written. **Execute in strict order:** 1. **Phase 1 — Decompose**: Extract problem, actor, expected behavior, business rules, out-of-scope. 2. **Phase 2 — Ambiguity Scan**: Flag every ambiguity by type and severity (CRITICAL / MAJOR / MINOR). 3. **Phase 3 — Clarification Questions**: For each CRITICAL and MAJOR ambiguity, ask one precise question with concrete options. Present all questions at once. 4. **Phase 4 — Wait**: Print `>>> WAITING FOR ANSWERS.` and stop. Do NOT guess. Do NOT proceed. 5. **Phase 5 — Re-Analyze**: After user replies, confirm resolutions, check for new ambiguities. If new CRITICAL/MAJOR found → return to Phase 3. 6. **Phase 6 — Write AC**: When all CRITICAL + MAJOR are resolved (or loop 3 reached), write checkbox-based Acceptance Criteria covering happy path, sad path, and edge cases. Score the result (min 80/100 to proceed). **Loop control:** Max 3 clarification rounds. After round 3 — rewrite with best available info, flag unresolved items with `⚠ UNRESOLVED`. **Skip condition:** If the user's request is a Defect/Bug and contains reproduction steps with expected vs actual results — ambiguity scan still runs, but the bar for CRITICAL is higher (focus on missing edge cases and error handling rather than unclear outcomes). The checkbox output from Phase 6 becomes the **Acceptance Criteria section** of the issue body in Step 8. ### Step 8 — Build issue body Match the template structure read in Step 2. Populate all fields substantively from the user's description. **When quick-draft was set (Step 7a):** Use a short Acceptance Criteria placeholder (e.g. "To be refined" or 1–3 bullets from the description); do not run or reuse the Issue Refinement loop. Best-practice patterns: - Tables for comparisons - Code blocks for examples - Checkboxes for acceptance criteria - Numbered lists for reproduction steps All content in English (translate Spanish if needed). ### Step 9 — Create the issue **CRITICAL**: Do NOT use `--template` flag — incompatible with `--title`/`--body` in non-interactive mode. ```bash gh issue create \ --repo "dotCMS/core" \ --title "TITLE" \ --body "BODY" \ --label "LABEL1,LABEL2,..." ``` Build the label list by including only those that apply — omit any that were not selected: - `Type :` label from Step 4c (include when matched) - `Team : [Name]` from Step 6 (always include) - `dotCMS : [Feature]` from Step 4 (omit if none was selected — do not leave a trailing comma) - Template labels from the template file (e.g., `Triage`, `OKR : Customer Support`) Capture the returned issue number. ### Step 9b — Set native GitHub Issue Type (REQUIRED, always) Immediately after creation: ```bash gh api repos/dotCMS/core/issues/ISSUE_NUM -X PATCH -f type='TYPE_NAME' ``` Use the type name from Step 4b: `Bug` | `Task` | `Spike` | `Feature` | `Epic` | `Pillar`. See [references/github-apis.md](references/github-apis.md) — Section A. ### Step 10 — Set Technology field in Project #7 No extra user input needed — derived from Step 5. 1. Get the project item ID (Section B of [references/github-apis.md](references/github-apis.md)) 2. Set the Technology single-select field (Section C) using IDs from [references/project-fields.md](references/project-fields.md) Status defaults to "New" automatically — do not set it. ### Step 11 — Set relationships (if captured in Step 7) - **Parent/sub-issue**: POST to sub-issues REST endpoint — Section E of [references/github-apis.md](references/github-apis.md) - Requires the child issue's database ID (Section D), not the display number - **Blocked-by/blocking**: Add a cross-reference comment on the related issue ### Step 12 — Confirm Report back: - Issue URL - Team label applied - Feature label applied - `Type :` label applied (if any) - Native type set - Technology field set in Project #7 - Any relationships established **Quick-draft tip (only when Issue Refinement ran):** If the Issue Refinement loop (Step 7b) was executed (i.e., quick-draft was **not** set), append a brief tip after the confirmation: > *Tip: Say "quick draft" or "rápido" next time to skip the AC clarification step.* --- ## UPDATE Mode Accept an issue number and user intent. Show current state first, then apply changes. ### Flow **Step 1 — Fetch current state:** ```bash gh issue view NUMBER --repo dotCMS/core \ --json number,title,state,labels,assignees,body,projectItems,url ``` **Step 2 — Validate and show current state:** For each expected field, explicitly confirm ✓ correct or flag ✗ gap: - **Feature label** (`dotCMS : *`): Is one present? Is it the right one for this issue type/content? - **Team label** (`Team : *`): Present and correct? - **`Type :` label**: Present and matching the issue type? - **Native GitHub type**: Matches the issue template type?