GitHub Issue Operations

Issue create via Junior's github_createIssue tool; update, comment, label, state, and inspection via gh CLI. Use only for GitHub issues. For pull requests, branches, pushes, or PR creation order questions, load github-code instead.

Reference loading

Workflow

1. Resolve operation and target

• Determine whether the task is create, update, comment, labels, state, or read-only inspection.
• Resolve repository from the requested action: explicit target wins; otherwise use <configuration> github.repo. If absent, run standalone jr-rpc config get github.repo.
• Preserve non-target GitHub references that materially support created issue or comment bodies.
• Run jr-rpc config get github.repo as its own bash command. Do not combine it with cd, &&, pipes, or any gh command.
• After resolving a configured repo, pass it explicitly to the next gh command with --repo owner/repo; do not rely on implicit GitHub CLI repository discovery.
• Resolve the issue number for non-create operations.
• Keep --repo owner/repo explicit on gh commands so the command itself targets the intended repository, not a stale default.

2. Classify issue type

• Use explicit user type when provided (bug, feature, task).
• Otherwise infer from intent:
  • bug: broken behavior, regression, error, failure.
  • feature: net-new capability or behavioral expansion.
  • task: maintenance, cleanup, docs, refactor, operational chore.
• Default to task when uncertain.

3. Draft issue content

Load the type-specific guide:

Follow references/research-rules.md for cross-type research standards. Use references/issue-examples.md to calibrate structure and depth.

Hard constraints — apply to every new issue:

• Title ≤ 60 characters. Descriptive for bugs, imperative for tasks/features.
• Issue title format: plain language, no type prefix. Do not use fix(x):, feat(x):, chore:, ref(x):, or any other type-scope prefix — those belong in commit messages and PR titles, not issues.
• Summary ≤ 3 sentences. Do not restate the title in the body.
• Prefer flat bullet lists over headed sections for simple issues. Remove empty sections.
• Generalize session framing — strip channel references, slash commands, Slack thread IDs, user @mentions, and transcript fragments; replace with the underlying technical problem.
• Compress source material. Research notes, hypotheses, or transcripts become a short summary + scoped bullets — never paste raw investigation into the body.
• Do not add desired outcome, expected behavior, or acceptance criteria unless the thread explicitly requests them.
• Preserve material source references inline.

Source attribution:

• GitHub records the issue creator natively; do not add body or footer text to identify who asked Junior to create the issue.
• If the person who originally reported or observed the problem differs from the issue creator, capture that with durable body text such as Reported by Alice. or Raised by Alice during incident triage.
• Attach screenshots from the thread as image links when present.
• Include code snippets, related issues, and related PRs only when they materially improve the issue.

4. Verify draft

Before running the gh create/edit command, check each gate. If any fails, revise and re-check before executing:

• Title length ≤ 60 characters.
• No session framing remains (channel refs, slash commands, @mentions, Slack thread IDs).
• Body structure matches complexity — no empty sections, no restated title, no raw research dump.

Run references/issue-quality-checklist.md for holistic soft-signal review when the draft warrants it.

5. Execute

• Use github_createIssue for new issues so Junior owns idempotency and session-link footers.
• Use gh issue commands from references/api-surface.md for non-create operations.
• For issue listing or other read-only inspection, prefer --json output so empty results still produce deterministic stdout.
• Check duplicates silently before creating a new issue. Do not mention this check in the final reply unless a duplicate blocks creation.

6. Report result

• Return canonical issue URL, issue number, and issue type.
• Mention only user-visible issue changes. Do not mention duplicate checks, searches, "no duplicates found", or routine preparation steps.

Guardrails

• Require explicit confirmation only for close/reopen or destructive broad rewrites.
• Do not overwrite issue fields unless explicitly requested. Prefer partial updates over full body replacement.
• For bug issues, do not present a fix as definitive unless root-cause evidence is explicit.
• If repository or installation access is missing, stop and return a concrete remediation message.