Issue tracker: GitHub

Issues and specs for this repo live as GitHub issues. Use the gh CLI for all operations. Every delegated issue carries a type, Priority, Effort, and native relationships — set all four, not just a title and body.

Conventions

• Create an issue: gh issue create --title "..." --body "...". Use a heredoc for multi-line bodies.
• Read an issue: gh issue view <number> --comments, filtering comments by jq and also fetching labels.
• List issues: gh issue list --state open --json number,title,body,labels,comments --jq '[.[] | {number, title, body, labels: [.labels[].name], comments: [.comments[].body]}]' with appropriate --label and --state filters.
• Comment on an issue: gh issue comment <number> --body "..."
• Apply / remove labels: gh issue edit <number> --add-label "..." / --remove-label "..."
• Close: gh issue close <number> --comment "..."

Infer the repo from git remote -v — gh does this automatically when run inside a clone.

Issue anatomy (delegation-ready)

A well-sized issue has three parts:

1. Goal — one sentence, the user-facing behavior or capability.
2. Implementation plan — vertical TDD slices (RED → GREEN per slice), each naming the seam under test and the files touched.
3. Acceptance criteria — checkbox list, each item testable.

Keep one issue = one tractable unit of work (a focused session, not an epic). Split features into: code ticket + test ticket + CI ticket + docs ticket. State blockers via native relationships (below), not prose.

Issue types

Native issue types are enabled on the org: Task, Bug, Feature (no Epic yet).

gh api repos/zharif/budget-tracker/issue-types --jq '.[].name'   # list types
gh issue create --title "..." --body "..." --type Bug             # create with type
gh issue edit 42 --type Task                                      # change type later
gh issue edit 42 --remove-type                                    # clear type

Convention:

• correctness / unexpected behavior → Bug
• new user-facing capability → Feature
• testing, CI, docs, release, refactor → Task

Priority & Effort (issue fields, org-level)

Priority and Effort are org-level issue fields (public preview), not labels and not project fields. They are set with the GraphQL setIssueFieldValue mutation, which takes the issue's node id (node_id, not the #number) and the field/option ids below.

Field & option ids (org zharif)

Priority options:

Effort options:

Set Priority + Effort

# node id of an issue (works by number)
gh api repos/zharif/budget-tracker/issues/42 --jq '.node_id'

# set both fields in one call
gh api graphql -f query='
mutation {
  setIssueFieldValue(input: {
    issueId: "<NODE_ID>",
    issueFields: [
      { fieldId: "IFSS_kgDOAZGOmg", singleSelectOptionId: "IFSSO_kgDOAr6iWg" },
      { fieldId: "IFSS_kgDOAZGOnQ", singleSelectOptionId: "IFSSO_kgDOAr6iXQ" }
    ]
  }) { issue { number } }
}'

Re-discover the ids (if the org regenerates them)

Field ids are stable but org-scoped. If setIssueFieldValue starts failing with "not found", re-query and refresh the tables above:

gh api graphql -f query='
query {
  repository(owner:"zharif", name:"budget-tracker") {
    issueFields(first: 50) {
      nodes {
        ... on IssueFieldSingleSelect { id name options { id name } }
        ... on IssueFieldText { id name }
        ... on IssueFieldNumber { id name }
        ... on IssueFieldDate { id name }
        ... on IssueFieldMultiSelect { id name options { id name } }
      }
    }
  }
}'

Relationships (native dependencies)

Native issue dependencies (blocking/blocked-by) and hierarchy (parent/sub-issue) are first-class on the issue — they show in the UI and gate automation. Prefer them over Blocked by: prose.

gh issue edit 42 --add-blocked-by 35          # 42 waits on 35
gh issue edit 42 --add-blocked-by 29 --add-blocked-by 30   # multiple blockers
gh issue edit 42 --remove-blocked-by 35       # unblock

gh issue edit 35 --add-blocking 42            # same edge, set from the blocker side
gh issue edit 42 --parent 41                  # 42 is a sub-issue of 41
gh issue edit 42 --add-sub-issue 43           # 43 becomes a sub-issue of 42

Read the graph: gh issue view 42 prints blocked-by / blocking / parent / sub-issues.

Convention: an issue is unblocked only when every blocked-by issue is closed. Keep the graph a DAG — the release-gate ticket (e.g. a pre-launch checklist) is usually the single sink.

Full recipe (copy-paste)

OWNER=zharif; REPO=budget-tracker
PRIORITY=IFSS_kgDOAZGOmg
EFFORT=IFSS_kgDOAZGOnQ
# priority: Urgent IFSSO_kgDOAr6iWA | High IFSSO_kgDOAr6iWQ | Medium IFSSO_kgDOAr6iWg | Low IFSSO_kgDOAr6iWw
# effort:   High IFSSO_kgDOAr6iXA | Medium IFSSO_kgDOAr6iXQ | Low IFSSO_kgDOAr6iXg

create_issue() {  # $1=title $2=type $3=priorityOpt $4=effortOpt, body on stdin
  local n
  n=$(gh issue create --title "$1" --body "$(cat)" --type "$2" \
      | grep -oE 'issues/[0-9]+' | tail -1 | grep -oE '[0-9]+')
  echo "$n"
}

set_fields() {  # $1=number $2=priorityOpt $3=effortOpt
  local nid
  nid=$(gh api "repos/$OWNER/$REPO/issues/$1" --jq '.node_id')
  gh api graphql -f query="mutation {
    setIssueFieldValue(input: {
      issueId: \"$nid\",
      issueFields: [
        { fieldId: \"$PRIORITY\", singleSelectOptionId: \"$2\" },
        { fieldId: \"$EFFORT\", singleSelectOptionId: \"$3\" }
      ]
    }) { issue { number } }
  }" --jq '.data.setIssueFieldValue.issue.number'
}

# usage:
# echo "## Goal ..." | create_issue "feat: attachments" "Feature" "IFSSO_kgDOAr6iWQ" "IFSSO_kgDOAr6iXA"
# set_fields 42 "IFSSO_kgDOAr6iWQ" "IFSSO_kgDOAr6iXA"
# gh issue edit 42 --add-blocked-by 41

Pull requests as a triage surface

PRs as a request surface: no. (Set to yes if this repo treats external PRs as feature requests; /triage reads this flag.)

When set to yes, PRs run through the same labels and states as issues, using the gh pr equivalents:

• Read a PR: gh pr view <number> --comments and gh pr diff <number> for the diff.
• List external PRs for triage: gh pr list --state open --json number,title,body,labels,author,authorAssociation,comments then keep only authorAssociation of CONTRIBUTOR, FIRST_TIME_CONTRIBUTOR, or NONE (drop OWNER/MEMBER/COLLABORATOR).
• Comment / label / close: gh pr comment, gh pr edit --add-label/--remove-label, gh pr close.

GitHub shares one number space across issues and PRs, so a bare #42 may be either — resolve with gh pr view 42 and fall back to gh issue view 42.

When a skill says "publish to the issue tracker"

Create a GitHub issue with the full anatomy: --type, then setIssueFieldValue for Priority/Effort, then --add-blocked-by edges. Don't stop at title + body.

When a skill says "fetch the relevant ticket"

Run gh issue view <number> --comments.

Wayfinding operations

Used by /wayfinder. The map is a single issue with child issues as tickets.

• Map: a single issue labelled wayfinder:map, holding the Notes / Decisions-so-far / Fog body. gh issue create --label wayfinder:map.
• Child ticket: an issue linked to the map as a GitHub sub-issue (gh api on the sub-issues endpoint). Where sub-issues aren't enabled, add the child to a task list in the map body and put Part of #<map> at the top of the child body. Labels: wayfinder:<type> (research/prototype/grilling/task). Once claimed, the ticket is assigned to the driving dev.
• Blocking: GitHub's native issue dependencies — the canonical, UI-visible representation. Add an edge with gh issue edit <child> --add-blocked-by <blocker> (preferred) or gh api --method POST repos/<owner>/<repo>/issues/<child>/dependencies/blocked_by -F issue_id=<blocker-db-id>. gh issue view <n> reports blocked-by (open blockers only — the live gate). A ticket is unblocked when every blocker is closed.
• Frontier query: list the map's open children (gh issue list --state open, scoped to the map's sub-issues / task list), drop any with an open blocker or an assignee; first in map order wins.
• Claim: gh issue edit <n> --add-assignee @me — the session's first write.
• Resolve: gh issue comment <n> --body "<answer>", then gh issue close <n>, then append a context pointer (gist + link) to the map's Decisions-so-far.