langertha-github-issues

name	langertha-github-issues
description	Langertha's PUBLIC issue tracker — real humans' bug reports and feature requests, hosted on GitHub (github.com/Getty/langertha) and reached with the `gh` CLI. Read this whenever GitHub, `gh`, public issues, pull requests, or user bug reports come up. NOT the AI/agent work board (that is karr). HARD RULE: never touch GitHub issues — not even read — unless the user explicitly tells you to.

Langertha GitHub User Issues (gh)

Langertha has two separate trackers. Do not confuse them.

Tracker	What it holds	Tool	Who writes it
karr	AI/agent work board — internal kanban in refs/karr/*	karr CLI	agents, internally
GitHub issues	PUBLIC user tickets — real humans' bug reports & feature requests	gh CLI	the community

karr is ours, internal, churned freely. GitHub issues are outward-facing and written by real people. They are a different universe — never route agent/internal work there, and never treat a GitHub issue as if it were a karr ticket.

THE HARD RULE — gh only on explicit instruction

Never invoke gh against issues/PRs on your own initiative — not even to read. No proactive listing, searching, viewing, commenting, editing, or closing of GitHub issues or pull requests. You touch this tracker only when the user explicitly tells you to (e.g. "look at GitHub issue #42", "reply to that bug report"). With no such instruction, stay out of gh issue/PR commands entirely.

Even with an instruction, every write (create / comment / edit / close) is published to a public tracker under the signed-in GitHub account — outward-facing and hard to take back. Confirm the exact wording before sending; when in doubt, show the draft and ask. Reading (view / list) needs the instruction but no extra confirmation.

Setup — authenticate first (each person, each machine)

gh acts under whoever is logged in, not a shared account. Nothing below works until:

gh auth login       # sign in to github.com (browser/token flow); once per machine
gh auth status      # confirm the signed-in account

If gh auth status errors, you are not logged in — there is no access until gh auth login is run (and only do so when the user actually wants gh used; see the hard rule). The repo's origin is github.com/Getty/langertha, so gh targets it by default; -R Getty/langertha makes it explicit.

Reading issues (only when instructed)

gh issue list                              # open issues on this repo
gh issue list -s all -S "tool calling"     # search; -s open|closed|all
gh issue list -l bug -A <user>             # filter by --label / --assignee
gh issue view 42                           # title + body of issue #42
gh issue view 42 -c                        # include comments

gh pr list / gh pr view <id> read pull requests the same way.

Writing issues (only when explicitly instructed — outward-facing)

gh issue comment 42 -b "Fixed in <sha>, thanks for the report."   # public comment
gh issue create -t "Title" -b "…"          # or -F FILE; omit -b/-t opens $EDITOR
gh issue edit 42 --title|--body|--add-label # edit a field
gh issue close 42 -c "Resolved in vX.Y"    # close, optional closing comment

Prefer -F/--body-file for anything multi-line so the published text is exactly what was reviewed. Same shape for gh pr comment|edit|close|merge.

Quick guard checklist

• Did the user explicitly ask me to touch GitHub / gh / a user issue? If not → do not run gh issue/PR commands at all.
• Is this a user ticket (GitHub), not an agent ticket (karr)? Right tool for the tracker.
• Writing? It is public and under the signed-in GitHub account → confirm the wording first.