--- name: propose-action description: Review a GitHub issue or PR by number and propose a concrete action plan — either a reasoned recommendation not to action it, or the code and test changes required to action it. Use when the user asks to "propose an action" for an issue/PR, "look at issue/PR #N", or invokes /propose-action with an issue or PR number. Ends by asking whether to proceed, proceed with modifications, or abandon. --- # Propose Action ## When to use - The user asks to review a GitHub issue or PR and recommend what to do about it. - The user invokes `/propose-action `. This skill **plans only** for steps 1–5 — it does not edit code, run tests, commit, push, or comment on the issue/PR during the proposal phase. Implementation happens after the user approves the plan in step 5's closing question. Once the user has approved and you have carried out the agreed actions, step 6 produces a ready-to-paste reply to the issue/PR aligned with what was actually done — but never posts it. ## Arguments - `` (required) — the GitHub issue or PR number. Bare integer, or `#N`, or a full GitHub URL are all acceptable forms. If the number is missing, ambiguous, or does not resolve to an issue/PR in the current repository, stop and ask the user to clarify. ## Workflow ### 1. Identify the target - Determine the current repository: `gh repo view --json nameWithOwner -q .nameWithOwner`. - Resolve the number to either an issue or a PR. GitHub numbers them in the same namespace, so try PR first, then issue: - `gh pr view --json number,title,state,author,body,headRefName,baseRefName,isDraft,mergeable,additions,deletions,changedFiles,labels,comments,reviews` - If that fails, `gh issue view --json number,title,state,author,body,labels,comments,assignees` - Record whether the target is an **issue** or a **PR** — the two branches below differ. ### 2a. If the target is an issue Gather context in parallel: - The issue body and all comments (from the `gh issue view` JSON above). - `gh issue view --json linkedPullRequests` — check for linked PRs that may already address it. - Identify the files or subsystems the issue points at. Search the repo (`Grep`, `Glob`, `Read`) for the relevant code. Do not guess — read the actual files the issue describes. - If the issue references specific OIDs, error messages, function names, or SNMP behaviours, locate them in the source. ### 2b. If the target is a PR Gather context in parallel: - PR body, comments, and reviews (from the `gh pr view` JSON above). - `gh pr diff ` — the full diff. - `gh pr view --json files -q '.files[].path'` — changed files. - Read the **current** version of each changed file on the base branch so you understand what the PR is replacing, not just what it adds. - If the PR closes or references an issue (via `Fixes #N`, `Closes #N`, etc.), also fetch that issue for context. - Check CI status if available: `gh pr checks `. ### 3. Form a judgement Decide which of these recommendations fits, and be willing to recommend **against** actioning: - **Do not action** — the issue is invalid, already fixed, out of scope, based on a misunderstanding, a duplicate, or the PR is the wrong approach / would regress behaviour / conflicts with project direction. Explain *why* clearly, citing the code or prior commits that support the conclusion. - **Action as-is** — the issue is valid and the fix is clear, or the PR is correct and should be merged as submitted. - **Action with modifications** — the issue is valid but the obvious fix is wrong; or the PR has the right idea but needs specific changes before it can be merged. - **Needs more information** — the report is plausible but underspecified. List the exact questions to ask the reporter / author before any code change is possible. Base the judgement on what the code actually does today, not on what the issue/PR claims. If the two disagree, surface the disagreement. ### 4. Draft the proposal Structure the written proposal in this order. Keep it concrete — name files, line numbers, function names, and the specific behaviours being changed. 1. **Target** — `Issue #N: ` or `PR #N: <title>`, plus one sentence on its state (open/closed/draft/merged, CI status for PRs). 2. **Summary of the report** — one short paragraph in your own words describing what the reporter is asking for or proposing. Do not just quote the body. 3. **Findings** — what the code currently does, whether the report is accurate, and any related context (linked issues/PRs, prior commits, existing tests covering this area). Cite `file:line` locations. 4. **Recommendation** — one of the four options from step 3, stated plainly in a sentence or two. 5. **Proposed changes** (omit if the recommendation is *do not action* or *needs more information*): - **Code** — for each file to change, list the edit as a bullet: `path/to/file.js:<line-range> — <what changes and why>`. For non-trivial edits, include a short before/after sketch (a few lines, not a full diff). - **Tests** — list tests to **add**, **modify**, or **delete**, each with the file and a one-line description of what the test asserts. If no test changes are needed, say so explicitly and justify (e.g. "covered by existing test at `test/x.test.js:42`"). - **Docs / README** — note any README or inline-doc updates required. Release-note bullets are handled by `/prepare-release`; do not pre-empt them here. 6. **Risks and unknowns** — anything that could make the plan wrong: behaviours you could not verify, edge cases the tests would not catch, compatibility concerns, or assumptions about the reporter's environment. 7. **Out of scope** — closely-related issues you noticed while investigating but are **not** proposing to fix in this action. Keeps the scope honest. ### 5. Closing question End the response with exactly one question, offering three choices: > Proceed with this plan as-is, proceed with modifications (tell me what to change), or abandon it? Do not start implementing until the user answers. If the user says "proceed", begin implementing the plan in the next turn. If the user asks for modifications, revise the proposal and ask the same question again. If the user says to abandon, stop and skip step 6. ### 6. Ready-to-paste issue/PR reply After the agreed actions have been carried out (code edits, tests, docs, or a reasoned decision not to action), produce a single ready-to-paste reply for the issue/PR. This is the **last** thing you output, rendered in a fenced block or delimited by `---` so the user can copy it cleanly. The reply must be aligned with **what actually happened**, not with the original plan — if the user asked for modifications during implementation, reflect the modified outcome. If a step was skipped or failed, say so honestly; do not describe work that was not done. Tailor the content to the recommendation from step 3: - **Action as-is / with modifications** — acknowledge the report, give the user a short, concrete summary of the fix (with the key code change or snippet inline if it helps them adopt it), point at the files/sections that changed (e.g. "updated in `README.md` under *Scalar providers*"), and note when it will ship (e.g. "will land in the next release" — do not invent a version number unless `package.json` has already been bumped). If there's a workaround the reporter can apply before the release, include it. - **Do not action** — explain the reasoning in the reporter's terms, citing the code or prior history that supports the decision. Be respectful: the reporter put effort into the report. Offer an alternative path if one exists (a different API, a related issue, a config change). If the issue should be closed, say so; do not close it yourself. - **Needs more information** — list the specific questions you need answered, each as its own bullet. Explain briefly *why* each is needed so the reporter can see what would unblock progress. Style: - Match the tone of prior replies in this repository if they are visible in the issue/PR thread — don't suddenly adopt a different register. - Write as the maintainer would: first person, conversational, no corporate voice, no marketing copy, no emoji unless the repo's existing replies use them. - Do not include a signature, do not add attribution trailers (no "generated by", no `Co-Authored-By`), do not tag the reporter more than once. - Keep it focused — one screen of text is almost always enough. If the reply needs code blocks, prefer short, complete snippets over long diffs. Hand the reply to the user with one sentence above it saying where to paste it (e.g. "Ready-to-paste reply for issue #297:"). Do **not** run `gh issue comment` / `gh pr comment` / `gh issue close` / `gh pr merge` — the user posts it. ## Rules - **Never** edit files, run tests, or modify git state during steps 1–5. Planning only. - **Never** post a comment on the issue/PR, add labels, request reviews, merge, or close — not in step 6, not ever within this skill. Those are the user's decision. - **Never** fabricate line numbers or function names — if you cite `file:line`, you must have read it. - If `gh` is not authenticated or the number does not exist, stop and report the error verbatim. - If the issue/PR is in a different repository than the current working directory, stop and confirm with the user before proceeding — the plan would target the wrong codebase. - Keep the proposal focused. A plan that touches ten files for a one-line bug is a signal to re-read the issue, not to write a bigger plan.