lov-gh-tidy

lov-gh-tidy

Interactive GitHub repo triage — issues, PRs, branches, labels in one pass.

Prerequisites

• gh CLI installed and authenticated (gh auth status)
• Current directory is a git repo with a GitHub remote

Workflow

Step 1: Scan

Run all of these in parallel to gather repo state:

# Open issues
gh issue list --state open --limit 100 --json number,title,author,createdAt,labels,comments

Open PRs

gh pr list --state open --limit 100 --json number,title,author,createdAt,labels,reviewDecision,mergeable,headRefName

Remote branches (exclude main/master/develop)

git branch -r --no-merged origin/main | grep -v 'HEAD|main$|master$|develop$'

Labels

gh label list --limit 100 --json name,description,color

### Step 2: Summarize

Present a concise table for each category that has items:

**Issues:**
| # | Title | Author | Age | Comments | Labels |
|---|-------|--------|-----|----------|--------|

**PRs:**
| # | Title | Author | Age | Mergeable | Review |
|---|-------|--------|-----|-----------|--------|

**Stale branches** (no commits in 30+ days):
List branch names with last commit date.

**Orphan labels** (not used by any issue/PR):
List label names.

For each item, provide a brief analysis:
- Issues: Is it actionable? Feature request vs bug? Has it been addressed?
- PRs: Are there conflicts? Is the code valuable? What does the diff look like?
- Branches: Is the work merged? Abandoned?

### Step 3: Triage

Use `AskUserQuestion` to ask the user how to handle each item. Group by category.

For issues, offer: Close with thank-you / Close as wontfix / Keep open / Add label
For PRs, offer: Review & merge / Close without merge / Keep open
For branches, offer: Delete / Keep
For labels, offer: Delete / Keep

**Important:** Always show your analysis and reasoning for each item before asking. Don't just present options without context.

### Step 4: Execute

Execute all chosen actions via `gh` CLI:

```bash
# Close issue with comment
gh issue close <N> --comment "message"

# Merge PR (prefer squash)
gh pr merge <N> --squash

# Close PR without merge
gh pr close <N> --comment "message"

# Delete remote branch
git push origin --delete <branch>

# Delete label
gh label delete <name> --yes

Step 5: Report

Show a summary of what was done:

GitHub Tidy Report
==================
Issues:  2 closed, 1 kept
PRs:     1 merged, 0 closed
Branches: 3 deleted
Labels:  0 deleted

Rules

• Always show analysis before asking for decisions — explain WHY you suggest an action
• For PR merges with conflicts, resolve conflicts locally first, then push and merge
• When closing issues/PRs from external contributors, always leave a polite thank-you comment
• Never force-push or delete protected branches
• Skip categories with zero items — don't show empty tables
• For large repos (50+ items), batch the triage questions by category

Runtime context (shared)

Before running, read this Skill package's skill.yaml, provided by the host as the skill-runtime/v1 context. Field resolution order is: current request, project context, personal Preferences, brand Profile, general defaults.

• Use only fields declared in the Manifest; Profile stores public brand facts, Preferences stores personal work preferences.
• required: true When a field is missing, ask the user one focused question according to the Manifest's question configuration; save the answer only after the user explicitly agrees.
• Errors provide a copyable context_id, field path and source; diagnostic content avoids secrets, full private paths and raw configuration.

General feedback loop

When the user raises modification feedback during a Skill-driven task, the following must be executed before continuing with the current artifact:

1. First determine whether the feedback is task-specific(this time only) or reusable(reusable across tasks).
2. task-specific modify only the current task, do not change the Skill.
3. reusable first determine the scope: domain rules first update the corresponding canonical Skill; rules applicable to all Skills first update the shared specification.
4. After completing the rule update, version, lint and distribution verification, then apply the modification to the current task.
5. reusable modification invalidates prior "confirm", "continue", "send it"; after completing the current artifact modification and read-back, you must stop and wait for the user's next instruction, and must not automatically proceed to publishing, committing or other external writes.