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

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:

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.

Step 5 — Determine Technology

Derived automatically from user description — no extra input needed:

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?
• Technology field (Project #7): Set? Correct for the content?

Show a validation table to the user, e.g.:

✓ dotCMS : Build    — feature label, correct
✓ Team : Enablement — team label, correct
✗ Type : Spike      — missing
✗ Native type       — Task (should be Spike)
✗ Technology        — not set (should be Platform)

Then propose the changes needed based on the gaps found.

Step 3 — Apply changes (as specified by user or ask what to change):

Step 4 — Confirm each change applied.

QUERY Mode

Accept an issue number. Return comprehensive state.

Flow

# Main issue data
gh issue view ISSUE_NUM --repo dotCMS/core \
  --json number,title,state,labels,assignees,body,projectItems,url

# Sub-issues
gh api repos/dotCMS/core/issues/ISSUE_NUM/sub_issues

# Native type
gh api repos/dotCMS/core/issues/ISSUE_NUM --jq '.type.name'

Output includes:

• Title, state, labels, assignees, URL
• Native GitHub Issue Type
• Project #7 Status, Technology, Priority fields
• Parent issue (if sub-issue)
• Sub-issues list with completion status
• Blocked-by / blocking relationships

See Section H of references/github-apis.md for full query patterns.

FIND Mode

Discover issues relevant to the user without needing a specific issue number. Results are presented as a numbered list with clickable URLs that can be used directly in follow-up UPDATE, QUERY, or CREATE (sub-issue) operations.

Trigger classification

Infer the search intent from the user's phrasing. Sprint and scope filters compose freely.

Scope filter (who/what):

Sprint filter (when — applied on top of scope filter when present):

Sprint + scope combinations are valid: "my issues in the current sprint" = Assigned filtered to current; "Enablement issues next sprint" = Team filtered to next sprint.

If the intent is ambiguous between Assigned and Team, run both and merge results.

Flow

Step 1 — Read cached team and resolve project view URL (if available):

CACHED_TEAM=$(cat ~/.config/dotcms/create-issue/default-team 2>/dev/null)

If $CACHED_TEAM is set, look up the team's project view number from references/project-fields.md. If the view number is known, construct the direct board URL:

https://github.com/orgs/dotCMS/projects/7/views/N

If the view number is not yet recorded, discover it:

gh api graphql -f query='
  {
    organization(login: "dotCMS") {
      projectV2(number: 7) {
        views(first: 30) {
          nodes { number name }
        }
      }
    }
  }' | jq -r --arg team "TEAM_NAME" \
    '.data.organization.projectV2.views.nodes[] | select(.name | test($team; "i")) | "\(.number) \(.name)"'

Store the resolved view URL (if found) as $TEAM_VIEW_URL.

Step 1b — Resolve sprint filter (if a sprint intent was detected):

If the user's request includes a sprint filter, resolve it before querying issues.

No cached team + sprint filter: If $CACHED_TEAM is empty and the user asked for a sprint-filtered view, ask which team before proceeding — sprint fields are team-specific and cannot be resolved without a team. Use AskUserQuestion with the same two-stage team list from Step 6 of CREATE mode.

Derive the sprint field name: strip Team : prefix, append Sprint (e.g. Team : Scout → Scout Sprint). Known field IDs and the iteration discovery query are in references/project-fields.md — "Sprint / Iteration Fields" section. Use known IDs to skip the discovery call for Falcon, Maintenance, Scout, and Platform.

From the returned configuration, identify the target sprint title using today's date:

Store the resolved sprint title as $SPRINT_TITLE for use in Step 2 jq filtering.

No sprint field found (teams without iteration fields): Teams known to use kanban / status-only workflows (Enablement, Modernization, UX, Architecture, and others not in the sprint field table in project-fields.md) do not have iteration fields. When the field query returns no match:

1. Tell the user: "[Team] doesn't use sprint iterations — showing issues by status instead."
2. Map the sprint intent to Status values:

3. Use the flat gh issue list + jq status filter (see references/project-fields.md) rather than the GraphQL sprint query.

Step 2 — Run the appropriate queries:

jq shell-quoting rules (apply to all queries below):

• Never use != in a jq expression passed via bash — the ! is shell-escaped as \! causing a compile error. Use chained select() calls instead: select($x) | select(...) rather than select($x != null).
• Never reuse a --arg name as an internal as $var binding in the same expression. Use distinct names (e.g. --arg sprint "..." + internal as $iterTitle).

Assigned to current user (open):

gh issue list --repo dotCMS/core \
  --assignee @me \
  --state open \
  --json number,title,url,labels,assignees,updatedAt,projectItems \
  --limit 50

Open issues for cached team (if $CACHED_TEAM is set, no sprint filter):

gh issue list --repo dotCMS/core \
  --label "$CACHED_TEAM" \
  --state open \
  --json number,title,url,labels,assignees,updatedAt,projectItems \
  --limit 50

Sprint filter — use GraphQL instead of gh issue list: Teams have 1000+ issues; gh issue list returns up to 100 oldest-first and misses recent Done/closed items. Use the GraphQL sprint query from references/project-fields.md — "Filter issues by sprint iteration" section. It uses states: [OPEN, CLOSED] and orderBy: UPDATED_AT DESC, filtering by $iterTitle == $sprint.

Keyword search:

gh issue list --repo dotCMS/core \
  --search "KEYWORD in:title,body" \
  --state open \
  --json number,title,url,labels,updatedAt \
  --limit 10

Recently updated (not filtered by assignee or team):

gh issue list --repo dotCMS/core \
  --state open \
  --json number,title,url,labels,updatedAt,assignees \
  --limit 10 \
  --sort updated

Run only the queries relevant to the user's intent. For Default, run Assigned and Team in parallel and deduplicate by issue number.

Step 3 — Extract project fields from results:

gh issue list --json projectItems returns a flat structure per project — Status is directly accessible but sprint/iteration values are not. See references/project-fields.md — "Filter issues by status (fast — flat structure)" for the exact extraction pattern. Show "—" when status is absent.

Step 4 — Present results:

Pagination note: Sprint queries use first: 100 with orderBy: UPDATED_AT DESC. This covers almost all cases since sprint work is recent. On very active teams where 100+ issues were updated more recently than the sprint's oldest items, some sprint items could be missed. If results look incomplete, paginate by adding after: "CURSOR" using the pageInfo.endCursor from a prior response — but this is rarely needed in practice.

Format as a numbered list grouped by query type. Include the sprint column when a sprint filter was applied or when sprint data is present.

When results are from a sprint query, prepend a velocity summary line:

5 Done · 2 In Progress · 1 In Review · 1 Current Sprint Backlog

Derive counts from the result set:

jq 'group_by(.status) | map({status: .[0].status, count: length}) | sort_by(.count) | reverse'

Render as N StatusName · N StatusName · ... ordered by count descending. Omit statuses with 0 count.

For each issue show:

• Number and title
• Clickable URL
• Status from Project #7 (if available)
• Sprint assignment (if available — "—" if not set)
• Assignee(s) — always show; helps spot misassignment or abandoned work
• Last updated (relative: "today", "2 days ago", "3 weeks ago")
• Exception flags (see below) — shown inline as ⚠

Exception flag — applies when status is "In Progress" or "In Review":

Sprint assignment is shown as "—" when not set — no flag, just the data. The stale flag is the only active signal. It doesn't filter out the issue — it appears inline so the user can decide whether to investigate.

Example output (no sprint filter):

**Team: Scout (In Progress)**
Board: https://github.com/orgs/dotCMS/projects/7/views/5

1. #34354 — [DEFECT] Content Drive Search leaks info with limited user
   https://github.com/dotCMS/core/issues/34354
   Status: In Progress | Sprint: — | Assignee: jsmith | Updated: yesterday

2. #33829 — [TASK] Create Developer Onboarding Guide for Next.js with dotCMS UVE
   https://github.com/dotCMS/core/issues/33829
   Status: In Progress | Sprint: — | Assignee: fmontes | Updated: Nov 2025
   ⚠ stale (3 months)

Example output (with sprint filter "last sprint"):

**Team: Scout — Sprint 4: Feb 24, 2026 (previous)**
Board: https://github.com/orgs/dotCMS/projects/7/views/5
5 Done · 0 In Progress

1. #34723 — CollectionBuilder.draft() does not return draft content when deployed to Vercel
   https://github.com/dotCMS/core/issues/34723
   Status: Done | Assignee: — | Updated: Feb 24

2. #34708 — Expose `registerStyleEditorSchema` in the `dotUVE` Global Object
   https://github.com/dotCMS/core/issues/34708
   Status: Done | Assignee: — | Updated: Feb 24

When a sprint filter is active, include the resolved sprint title and intent ("current", "next", "previous") in the group header so the user can confirm it matched the right sprint.

Include the Board link at the top of every team-scoped group when $TEAM_VIEW_URL is known. Omit silently if the view number is unknown — do not show a broken URL.

After listing, offer:

"Enter a number to query details, update, or use as a parent for a new sub-issue."

Step 5 — Handle follow-up selection:

If the user selects a number from the list:

• Map the selection to the issue number from the results
• Treat it as if the user had said "query issue #N", "update issue #N", or "sub-issue of #N" — proceed in the appropriate mode
• No need to re-ask for the issue number

Notes

• If neither --assignee @me nor a team label returns results, fall back to recently updated issues across the repo (limit 10, sort by updated).
• If a keyword search returns no results, say so clearly and suggest broadening the terms.
• De-duplicate results across query types — if an issue appears in both Assigned and Team lists, show it once under whichever group is more specific (Assigned takes priority).
• Issues from the current branch (Step 0a) are shown at the top of results if they appear, flagged as "current branch".

Authorization

If project field mutations fail, refresh GitHub CLI auth:

gh auth refresh -s read:project -s project --hostname github.com