▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓
▓                                                            ▓
▓             ┌──────────────────────────────┐               ▓
▓             │      g h ─ t e n d r         │               ▓
▓             └──────────────────────────────┘               ▓
▓                                                            ▓
▓      ╭─#42╮ ╭─#41╮ ╭─#40╮ ╭─#39╮ ╭─#38╮ ╭─#37╮             ▓
▓      │ ◐  │ │ ✓  │ │ ?  │ │ ◐  │ │ ✓  │ │ ◐  │             ▓
▓      ╰────╯ ╰────╯ ╰────╯ ╰────╯ ╰────╯ ╰────╯             ▓
▓ ─────────────────────────────────────────────────────      ▓
▓                                                            ▓
▓                        (◕‿◕)╲    "what'll it be?"          ▓
▓                         │ │                                ▓
▓                        ─┴─┴─                               ▓
▓                                                            ▓
▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓

gh-tendr

"I'll tend the queue for you."

A Claude Code skill for asynchronous design review and implementation between you and Claude, mediated by GitHub Issues.

You leave comments on GitHub from your phone / a different machine / wherever; Claude polls for new comments, classifies the intent, and either replies, edits docs, builds the change, or asks for confirmation before acting on anything destructive.

Why this exists

Synchronous Claude Code is great when you're at the keyboard. But review/implementation cycles often span hours or days — and the GitHub Issues UI is already where you triage things from your phone, in meetings, on a plane. This skill makes Claude meet you there:

• One issue per decision document / proposal / RFC
• Structured issue body (Summary / Why now / Concrete proposal / Open decisions / Effort+priority / Source) so each issue is self-contained for triage
• Standard label set (decision:design, awaiting-review, etc.) for filtering
• A polling loop on the user side that reacts to new comments
• Hardcoded safety boundaries — Claude won't take destructive actions without an explicit confirmation reply

When to invoke

In a Claude Code session:

"Let's do issue-driven review against <my-private-repo>."

or

"Migrate the design docs in docs/decisions/ to issues and monitor them."

Claude reads SKILL.md, walks the setup (one-time creation of labels + issues), then arms a Monitor polling script and reacts to comments until you say you're done.

Status

Pre-1.0. Expect rough edges — the skill is in active iteration. The current version targets a specific living workflow but is designed to be repo-agnostic via four parameters (REPO, INTERVAL, DOCS_DIR, LABEL_PREFIX).

Installation

# Install as a Claude Code skill
git clone git@github.com:Bobby-Gray/gh-tendr.git ~/.claude/skills/gh-tendr
# Or symlink from a local clone:
ln -s ~/Documents/environments/gh-tendr ~/.claude/skills/gh-tendr

After installation, list the skill in your Claude Code session to confirm it loads:

/skills            # should show "gh-tendr" in the list

Prerequisites

• gh CLI installed and authenticated against an account with write access to the target repo
• The target repo is private — the skill refuses to operate on public/internal repos because issue access controls are coarser than file access (we routinely write security review notes, threat models, unannounced product details into issue bodies)

Repository layout

SKILL.md              The skill itself — this is what Claude reads
docs/
  issue-body-template.md   The structured issue body
  safety-rules.md          The boundaries Claude won't cross
  monitor-script.md        Details on the polling loop
examples/
  state-file.example.json  Sample .gh-review-state.json
  status-comments.md       Reply templates Claude uses
README.md             You are here
LICENSE               MIT
CHANGELOG.md

Privacy / safety guarantees

• Refuses to operate on non-private repos — the SKILL.md verifies gh repo view --json visibility returns PRIVATE before any setup work. If not, it halts and tells you to make the repo private manually (the skill won't change visibility for you because that has legal/compliance implications).
• Hardcoded "won't do" list — patent filings, prod pushes, force-pushes, branch deletes, PR merges, CI changes, issue deletes, DB destructive ops, repo collaborator changes. All require explicit confirmation in the issue comment.
• Confirmation default — when intent is <75% clear, Claude posts a clarification comment instead of acting.

Companion skills (mentioned in SKILL.md)

• unattended-dev — used as a sub-protocol when an "implement this" comment fires
• product-research-flow — produces the upstream artifacts being reviewed

These are referenced but not required. If you don't have them, Claude falls back to inline implementation following the comment's directives.

Contributing

Internal-only while the skill is in active iteration. See CHANGELOG.md for current state.

License

MIT — see LICENSE.