SKILL PROJECT MANAGEMENT

GitHub Ticket

Create, route, and inspect GitHub issues from Claude Code or Codex with gh CLI-backed defaults for DiversioTeam/monolith, repo-local execution repos, and project-board hydration.

Overview

Create, route, and inspect GitHub issues from Claude Code or Codex with gh CLI-backed defaults for DiversioTeam/monolith, repo-local execution repos, and project-board hydration.

This skill ships inside the GitHub Ticket Manager plugin and can be installed through the Claude Code marketplace or directly in Codex from its skill path.

Parent Surface

Parent docs: GitHub Ticket Manager

Related wrapper commands from the parent plugin:

/github-ticket:create-issue/github-ticket:get-issue/github-ticket:my-issues/github-ticket:quick-issue/github-ticket:list-issues/github-ticket:route/github-ticket:configure/github-ticket:create-linked-issue/github-ticket:add-to-backlog

When to Use This Skill

Use this Skill when you want to:

This Skill is the GitHub-native replacement for the old clickup-ticket workflow. Issue forms in monolith are a human fallback and a schema reference, not the primary creation path.

  • create GitHub issues without opening the browser
  • capture backlog work quickly with smart defaults
  • fetch or list issues across monolith and a small repo set
  • view your assigned work
  • route planning work into repo-local execution issues
  • add created issues to Diversio Work with the right board fields
  • keep GitHub issue creation skill-driven instead of form-driven

Command Modes

Goal:

Workflow:

Use jq to write or update the config rather than inventing a custom format. If project config is present but gh auth status shows no project scope, surface that clearly instead of pretending project hydration will work.

Accepted input formats:

Behavior:

Prefer the smallest backend that matches the ask:

Support these filters:

Keep the filter model smaller than the old ClickUp plugin.

This is the convenience view for assigned work.

Default behavior:

Use gh search issues --assignee @me --state open when a cross-repo query is needed.

This is the full interactive creation path.

Gather:

Then:

issue to the project with gh project item-add.

option when that field exists. If there is no exact option for that repo, use other instead of leaving the field blank.

report the failure clearly so the user is not left with invisible board items.

explicitly and point at gh auth refresh -s project.

This should stay under three prompts.

Required input:

Preferred flow:

adding it to a project. Only upgrade to Ready when the issue is already actionable from the captured context.

This is the fastest capture path.

Default behavior:

Do not over-prompt. If the user only gives a title, create the issue.

Use this when turning planning work into explicit follow-up or execution work.

Safe default:

dependency chain means it should start in Blocked.

Do not rely on child-issue-only GitHub features for MVP behavior.

Use this when a planning issue in monolith should become repo-local execution work.

Behavior:

  • validate gh auth
  • create or update local defaults
  • keep prompts minimal
  • prefer git rev-parse --show-toplevel
  • then git remote get-url origin
  • normalize SSH or HTTPS GitHub remotes into owner/repo
  • planning repo
  • preferred execution repos
  • backlog labels
  • quick-issue labels
  • project owner/number
  • optional project field defaults such as Status and Priority
  • only add path_repo_map when repo detection via git is insufficient
  • 1234
  • #1234
  • owner/repo#1234
  • a GitHub issue URL
  • one repo: gh issue list
  • cross-repo or richer filtering: gh search issues
  • repo
  • assignee
  • label
  • open / closed state
  • imported: clickup
  • updated recently
  • search across the planning repo plus configured execution repos
  • show open issues assigned to @me
  • prefer recently updated or explicitly blocked work near the top
  • title
  • work type
  • target repo
  • problem or request
  • success criteria
  • optional constraints or non-goals
  • optional supporting links
  • optional legacy ClickUp metadata
  • always include triage unless the user says otherwise
  • map work type to type:* labels when available
  • Status
  • Target Repo
  • optional Priority
  • Ready for scoped, actionable work
  • Blocked when the issue depends on incomplete upstream work
  • Inbox only for intentionally rough capture
  • title
  • repo: DiversioTeam/monolith
  • labels: triage plus configured backlog labels
  • minimal body with problem/request plus optional links
  • when added to Diversio Work, prefer Status: Inbox

Prerequisites

Before doing anything else:

Preferred auth model:

prefer gh auth refresh -s project

  • repo for issue read/write
  • read:org for org visibility
  • project when project add or field hydration is expected
  • normal gh login
  • no plugin-specific token in the common case
  • if project hydration is part of the workflow and project scope is missing, prefer gh auth refresh -s project

Default Operating Model

Treat these defaults as the steady-state baseline unless the user overrides them:

Routing rules:

DiversioTeam/monolith.

as the execution repo after normalizing the git remote into owner/repo.

DiversioTeam/monolith.

issue in that repo when issues are enabled there.

it is still valid to use that repo; do not reject it only because it is not prelisted in config.

  • planning repo: DiversioTeam/monolith
  • execution repos:
  • DiversioTeam/Django4Lyfe
  • DiversioTeam/Diversio-Frontend
  • DiversioTeam/Optimo-Frontend
  • DiversioTeam/diversio-ds
  • DiversioTeam/infrastructure
  • DiversioTeam/naboo
  • DiversioTeam/diversio-serverless
  • DiversioTeam/launchpad
  • DiversioTeam/skiddie
  • DiversioTeam/terraform-modules
  • DiversioTeam/agent-skills-marketplace
  • canonical IDs: native GitHub issue numbers
  • legacy ClickUp GH-xxxx IDs: metadata only when applicable
  • If you are in the monolith root and no repo is specified, prefer DiversioTeam/monolith.
  • If you are inside a repo checkout and no repo is specified, prefer that repo as the execution repo after normalizing the git remote into owner/repo.
  • If the work clearly spans repos or still needs planning, create the issue in DiversioTeam/monolith.
  • If the user asks for implementation work in a specific repo, create the issue in that repo when issues are enabled there.
  • If repo detection yields a GitHub repo outside the default execution list, it is still valid to use that repo; do not reject it only because it is not prelisted in config.

Resources

Declared allowed tools:

BashReadEditWriteGlobGrep

References

  • config-and-body-shape.md

Installation

Switch between Claude Code and Codex, then copy the install command for the runtime you use.

claude plugin marketplace add DiversioTeam/agent-skills-marketplace
claude plugin install github-ticket@diversiotech

Invocation:

/github-ticket:create-issue
/github-ticket:get-issue
/github-ticket:my-issues
/github-ticket:quick-issue
/github-ticket:list-issues
/github-ticket:route
/github-ticket:configure
/github-ticket:create-linked-issue
/github-ticket:add-to-backlog