Resolve Scrap Issues

Fetch the newest scrap issues (GitHub issues labeled maintainer-scrap), understand each one, validate whether it is still a real and actionable problem using web research and codebase inspection, and then drive each issue to closure: close the issues that need no action, and resolve the actionable ones — bundling them into a single pull request when there is more than one.

This skill extends understand-scrap-issues: Steps 1–3 are the same intake flow, and Steps 4 onward add validation and resolution.

Step 1: Fetch the Latest Scrap Issues

List the most recent open issues that carry the maintainer-scrap label. gh issue list returns issues in creation order (newest first), so limiting to 3 yields the 3 newest:

gh issue list --label maintainer-scrap --state open --limit 3 --json number,title,url,createdAt

If the result is empty, report that there are no open scrap issues and stop.

Step 2: Gather Each Issue's Content

For each scrap issue returned, read both the body and the discussion. Run these in parallel across the issues where practical:

gh issue view <issue_number>
gh issue view <issue_number> --comments

If an issue references related pull requests, commits, or files that are needed to understand it, gather that context as well.

Step 3: Understand and Summarize

For each scrap issue, explain the following based on its content:

1. Topic: A one-line summary of what the scrap note is about.
2. Background: The context, motivation, or problem the note captures and why it matters.
3. Details / Findings: The specific observations, problems, or content recorded in the note.
4. Proposed Solution / Next Steps: Any solution or actionable next step mentioned. If none is recorded, state explicitly that it is still undecided.

Keep each summary concise and focused. Present the issues in the order returned (newest first), with the issue number, title, and URL as a heading for each.

Step 4: Validate Each Issue

Decide, per issue, whether it still describes a real, actionable problem. Combine three angles:

• Web research (WebSearch / WebFetch): Verify any claim that depends on external facts — a tool's current file format, config schema, default location, scope support, deprecation, or recent behavior change. Prefer primary sources (official docs, release notes, source code) over blog posts, and cross-check non-trivial claims against at least one primary source. Capture exact URLs and version numbers; they will be cited. Run independent searches in parallel.
• Codebase inspection: Check whether the issue is already resolved, partially handled, or contradicted by the current code. Prefer targeted symbol and search tools over reading whole files. Apply the project rules in CLAUDE.md, .claude/rules/**, and docs/** (for example, the feature-change and frontmatter conventions).
• Issue discussion: Honor any maintainer decision already recorded in the comments (e.g., "won't do", "superseded by #N").

Classify each issue into exactly one bucket:

• No action needed — invalid, obsolete, already fixed, out of scope, a duplicate, or explicitly declined. Record the concrete reason and the evidence (URLs / file references / linked issue) behind it.
• Action needed — a real problem, gap, or worthwhile proposal that still applies, with a concrete fix in mind. An open design point is not a blocker: pick the option that best fits the project's existing conventions and the tool's documented behavior, and state the choice in the PR body.

Default to action. Leave an issue open only in two narrow cases: the facts the fix depends on cannot be established from any primary source or the code, or the fix would do real harm (edit .github/** or the release pipeline, add a new runtime dependency, contradict an explicit maintainer decision in the thread, or delete or overwrite user files outside the outputs rulesync already manages). In those cases, leave the issue open, report the missing fact or harm, and exclude it from both Step 5 and Step 6.