dot-issue-manage

name	dot-issue-manage
owner	@dotcms/scout
status	active
description	Create GitHub issues using repository templates. Use when the user asks to create an issue, bug report, feature request, task, spike, epic, or UX requirement. Also use when the user describes a problem, bug, enhancement, or work item that should be tracked. Also use when the user asks to update, query, or view an existing GitHub issue. Also use when the user wants to find, search, list, or discover issues — assigned to them, open for their team, recently active, or matching a keyword. Supports both English and Spanish input.

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 · CREATE · UPDATE · QUERY · FIND · Authorization

References: feature-labels.md · project-fields.md · github-apis.md · 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:

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

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 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 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:

   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:

   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:

rm ~/.config/dotcms/create-issue/default-team

If the user specifies a team not in the known list, verify it exists before applying:

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 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.

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:

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 — 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)
2. Set the Technology single-select field (Section C) using IDs from 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
  • 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:

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?