[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6EKJRED2E3611QKB4M5FFZX":3,"skill-same:01M6EKJRED2E3611QKB4M5FFZX":77},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":17,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":48,"updatedAt":49,"install":50,"resources":62},"01M6EKJRED2E3611QKB4M5FFZX","reproduce-and-fix-issues",null,"Reproduce triaged Slack bugs through a configured app-control adapter, verify existing fixes, and open a bounded draft pull request only after before-and-after proof. Use only from the configured Benny repro automation.","minghinmatthewlam\u002Fagent-guards","minghinmatthewlam","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F14224566?v=4","01M6EKJNHJ92TMD70DDV4AJFQA","01M6EKJNNSX01GNTK9NJ5RKHFM",46,"MIT","https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fautomations\u002Fbenny\u002Fskills\u002Freproduce-and-fix-issues\u002FSKILL.md",[],[18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35],"issues","reproduce and fix issues","reproduce","fix","adapter","slack","proof","app","control","draft","repro","only","use","open","verify","pull","pull request","automation","2026-11-10 10:12:30",false,"---\nname: reproduce-and-fix-issues\ndescription: Reproduce triaged Slack bugs through a configured app-control adapter, verify existing fixes, and open a bounded draft pull request only after before-and-after proof. Use only from the configured Benny repro automation.\ndisable-model-invocation: true\n---\n\n# Reproduce and fix issues\n\nWait for a trusted triage marker in the source thread. Reproduce the exact symptom through the target app's real UI. Verify an existing fix when one exists. Attempt a bounded fix only after a confirmed repro.\n\nLoad the external Benny configuration supplied by the automation. If the config, required actions, control adapter, or completed feature map is missing, fail closed.\n\n## Hard safety rules\n\n- Freeze the source channel and root thread coordinates before doing any work.\n- Never post a root message in the source channel.\n- Preflight the source parent before every source-thread post.\n- The coordinator is the only Slack poster.\n- Delegated analysis workers are read-only and return findings or media notes.\n- A fix-phase code worker may edit only when its environment provably excludes Slack credentials and every Slack write action. Otherwise the coordinator edits.\n- Every child prompt must explicitly forbid `SendSlackMessage`, `PostToSlack`, `chat.postMessage`, and all other Slack writes.\n- Never give a child a Slack token, posting instructions, source coordinates for posting, or permission to report externally.\n- If a child needs Slack write access to run, do not launch it.\n- Utility bots are evidence sources. They do not own the fix unless a person explicitly delegated the fix to them.\n- The exact discriminating symptom must appear twice through real UI interaction.\n- State inspection may confirm an observation. It must not inject or force the symptom.\n- No confirmed repro means no authored fix.\n- Existing pull requests or commits switch the run to verify mode. Do not author over them.\n- Use `github.com` pull request links.\n- Keep captures, recordings, logs, and tokens out of source control.\n- Use pstack's `principle-guard-the-context-window` for delegated analysis.\n- Apply pstack's `principle-sequence-verifiable-units`, `principle-fix-root-causes`, and `principle-prove-it-works` through repro, fix, and verification.\n\n## 1. Freeze source coordinates\n\nBefore making a work list or delegating:\n\n1. Require the trigger channel to equal the configured source channel.\n2. Set `SOURCE_THREAD_TS` to `trigger.thread_ts` when present. Otherwise use `trigger.ts`.\n3. Require a nonempty `SOURCE_THREAD_TS`.\n4. Store `SOURCE_CHANNEL_ID` and `SOURCE_THREAD_TS` as immutable values.\n5. Read the source thread and verify its root has those exact coordinates.\n6. Fetch the source permalink.\n\nNever replace these values with a reply timestamp, operations timestamp, or status-message timestamp.\n\nBefore every source-channel post:\n\n1. Read the thread by the immutable coordinates.\n2. Confirm the parent exists, is not deleted, and still belongs to the source channel.\n3. Send only with `channel=SOURCE_CHANNEL_ID` and `thread_ts=SOURCE_THREAD_TS`.\n4. Read the thread again and verify the new message is a reply.\n\nIf any check fails, post nothing. Never retry at the root or in a fallback channel.\n\n## 2. Wait for the triage contract\n\nWatch the source thread for the configured verdict budget. Stay silent while waiting.\n\nAccept a verdict only when:\n\n- Its author matches `slack.triage_identity_user_id`.\n- It is a reply under `SOURCE_THREAD_TS`.\n- It contains exactly one configured marker.\n\nPublic marker forms:\n\n```text\n[benny:bug]\n[benny:bug] tracker=https:\u002F\u002Ftracker.example\u002Fissue\u002F123\n[benny:performance]\n[benny:performance] tracker=https:\u002F\u002Ftracker.example\u002Fissue\u002F123\n[benny:other]\n```\n\nProceed only for `bug` or `performance`. Capture the optional tracker URL. Stop silently for `other`, a missing verdict, an untrusted author, conflicting markers, or a timeout.\n\nThis marker replaces private bot identities and free-form verdict matching.\n\n## 3. Apply ownership and fix-artifact gates\n\nRe-read the thread immediately before starting work.\n\n### Someone is explicitly fixing it\n\nStop when a person clearly claims the fix, gives a concrete implementation plan, or asks another agent to implement, patch, fix, or open a pull request.\n\nDo not treat these as fix ownership:\n\n- A bot summarizes evidence.\n- A tool looks up logs or tickets.\n- Someone asks a bot to diagnose, explain, inspect, or reproduce.\n- A bot posts a cause hypothesis without agreeing to implement it.\n\nJudge the requested action, not the presence of a bot.\n\n### A fix artifact already exists\n\nIf an open pull request or merged commit plausibly fixes this report, switch to `references\u002Fverify-existing-fix.md`.\n\nAn artifact may come from the thread, tracker issue, repository history, or pull request search. A claim without a commit or pull request is not a fix artifact.\n\nIf a person owns the work but has not produced an artifact, stop. Do not race them.\n\n## 4. Open an optional operations thread\n\nIf `slack.operations_channel_id` is configured, the coordinator may create one root status message there. This is the only allowed root post in the repro workflow.\n\nStore its coordinates as `OPERATIONS_CHANNEL_ID` and `OPERATIONS_THREAD_TS`. Never confuse them with the source coordinates.\n\nUse the configured plain Unicode status strings. Keep status text short:\n\n- Reproducing\n- Could not reproduce\n- Blocked\n- Reproduced\n- Verifying existing fix\n- Attempting bounded fix\n- Draft pull request opened\n- Fix did not land\n\nPrefer configured Cursor Slack actions. Use `BENNY_SLACK_BOT_TOKEN` only when the user configured it for a narrow missing capability such as editing this one status message. Never expose the token to a worker.\n\nIf no operations channel is configured, keep detailed status in the automation run output. Do not substitute a source-channel root message.\n\n## 5. Load and check the control adapter\n\nRead `references\u002Fcontrol-adapter.md` and the completed map at `control.feature_map_path`, then invoke the skill named by `control.skill_name`.\n\nFind the feature-map section that matches the reported user path. Read it before driving the app. If no section covers the feature, mark the run blocked instead of inventing a path or selector.\n\nRequire all seven capabilities:\n\n1. Bring up the configured target app and test environment.\n2. Navigate the mapped feature and exercise its documented states.\n3. Drive the real UI with clicks, typing, keys, scrolling, drag, resize, or navigation.\n4. Inspect state without mutating it.\n5. Capture screenshots.\n6. Start and stop a screen recording.\n7. Clean up processes, sessions, profiles, and temporary data.\n\nIf the adapter is absent or any required capability is missing, mark the operations status as blocked and stop. Do not pretend a screenshot, unit test, state mutation, or source reading is a UI repro.\n\n## 6. Study the report\n\nRead the full source thread and tracker issue when present.\n\nCollect:\n\n- Exact action path\n- Expected behavior\n- Observed behavior\n- Discriminating state where they diverge\n- Frequency\n- Version, environment, and platform\n- Attachments and error signatures\n- Candidate code area\n\nInspect screenshots and video. Use read-only parallel workers for code history, test ideas, blast-radius mapping, and media review when useful. Each worker gets a narrow question and the Slack-write prohibition.\n\nUse pstack's `how` skill to trace the action through the repository. Use `why` for regression history and defensive code. Form competing cause hypotheses and identify evidence that would separate them.\n\n## 7. Reproduce\n\nBring up the target app through the control adapter.\n\nConfirm the correct app, workspace, account, data set, and feature state before acting. Use stable app markers. Do not rely on window order or a familiar title alone.\n\nDrive the reported path through real UI actions.\n\nBefore calling it reproduced:\n\n1. Name the correct final state.\n2. Name the broken final state.\n3. Reach the point where they diverge.\n4. Observe the broken state.\n5. Reset enough state to make the second attempt independent.\n6. Repeat the same path and observe the same broken state again.\n7. Cross-check a real state value when possible.\n\nAn expected dialog, loading state, or setup step is not the bug. Capture the final state that distinguishes correct from broken behavior.\n\nUse the configured repro budget. If the symptom does not reproduce within it, report a clean `Could not reproduce` outcome. If the environment cannot provide a required capability, report `Blocked` and state what was missing.\n\n## 8. Capture and review evidence\n\nFor a successful repro:\n\n- Record the full path through the symptom.\n- Capture a screenshot of the broken final state.\n- Save a short note with the exact steps and observed state.\n- Keep artifacts in the configured temporary artifact directory.\n\nHave a read-only media reviewer answer one question: does the evidence visibly show the discriminating broken state?\n\nIf the answer is no or uncertain, the repro is not confirmed. Capture better evidence or use `Could not reproduce`.\n\nPost detailed evidence only in the operations thread when configured. Keep the source update concise.\n\n## 9. Report the repro outcome\n\nUpdate the operations status first.\n\nFor `Could not reproduce` or `Blocked`, post nothing in the source thread. The operations thread or run output carries the result.\n\nFor a confirmed repro, run the source preflight and post at most one unprompted source reply:\n\n- Say the issue reproduced.\n- Link the operations evidence thread when one exists.\n- Include at most three short findings.\n- Link the tracker issue when one exists.\n- Do not ping an owner by default.\n\nAttach evidence only when the configured Slack action keeps it inside the same source thread and the organization's retention policy allows it.\n\nWait for the configured rejection window. If a person shows that the setup or interpretation was wrong, correct the repro once. Do not start the fix phase until the window closes without a valid rejection.\n\n## 10. Verify an existing fix\n\nWhen a fix artifact exists, follow `references\u002Fverify-existing-fix.md`.\n\nVerification must show the symptom on the baseline and its absence on the patched build. Both paths use the real UI twice.\n\nDo not edit the existing fix, add a competing patch, or open a replacement pull request.\n\n## 11. Qualify a bounded fix\n\nAttempt a fix only when all of these hold:\n\n- The outcome is a plain confirmed repro.\n- Media review confirmed the broken final state.\n- No existing fix artifact appeared.\n- No person claimed the fix during the rejection window.\n- Runtime evidence identifies the root cause.\n- The likely change fits the configured fix budget and repository scope.\n- The control adapter can run both baseline and patched builds.\n\nIf any condition fails, keep the repro report and stop without a pull request.\n\nWhen the gate passes, update operations status to `Attempting bounded fix`.\n\n## 12. Root-cause and implement\n\nThe coordinator owns every Slack post, the final diff review, commits, and the pull request.\n\nRead-only workers may:\n\n- Trace code and history\n- Propose tests\n- Map blast radius\n- Review a diff\n- Review media\n\nThey do not edit, run external writes, post status, or own the fix.\n\nA tightly scoped code edit may be delegated during this phase only when tool isolation removes Slack credentials and every Slack write action from that worker. Its prompt must still carry the explicit Slack-write ban. The coordinator reviews the edit and runs or verifies the required tests. If tool isolation is uncertain, keep the edit in the coordinator.\n\nConfirm the mechanism with runtime evidence. Eliminate competing hypotheses before editing.\n\nFix the root cause with the smallest justified change.\n\n- Invoke pstack's `tdd` skill when there is a cheap local test target, and write the failing test before the fix.\n- State why TDD was skipped when the path is expensive, unclear, or integration-heavy.\n- Keep unrelated cleanup out.\n- Stop if the change grows beyond the configured effort or risk budget.\n\n## 13. Prove the fix\n\nKeep the original baseline evidence.\n\nOn the patched build:\n\n1. Run the same real UI path.\n2. Repeat it twice.\n3. Show that the broken state is gone.\n4. Show the expected state in its place.\n5. Capture an after recording and screenshot.\n6. Cross-check the same real state value used for the baseline.\n\nA compile, unit test, code review, or plausible diff is not after evidence.\n\nRun focused tests, then smoke the blast radius around the changed behavior. Cover nearby states, inputs, permissions, platforms, and failure paths that the change could affect. Stop without a pull request if a regression remains.\n\n## 14. Open a draft pull request\n\nOnly after before-and-after proof:\n\n- Review the final diff for unrelated changes and secrets.\n- Run the repository's required checks.\n- Create small ordered commits when the repository workflow allows it.\n- Open a draft pull request. Never merge or deploy from this workflow.\n- Link the configured tracker issue using the tracker's supported pull request syntax.\n- Use the configured public URL form, normally `https:\u002F\u002Fgithub.com\u002F{owner}\u002F{repo}\u002Fpull\u002F{number}`.\n- Include the repro steps, root cause, test result, before and after evidence, and blast-radius checks.\n- Run the pull request text and all Slack updates through pstack's `unslop` skill.\n\nIf pull request creation fails, do not claim success. Keep the commit or branch state in the run output and mark operations status `Fix did not land`.\n\nOn success, mark operations status `Draft pull request opened` and post one concise reply in the operations thread with the linked pull request. Do not create a second source-channel root or unprompted source reply.\n\n## 15. Follow-ups and cleanup\n\nWatch the configured operations thread for one follow-up window.\n\n- Answer a direct question from evidence already gathered.\n- Apply one concrete correction and rerun the repro once when it invalidates the setup.\n- Stay out of human coordination and side chatter.\n- Stop when asked.\n\nAlways call the control adapter's cleanup capability. Keep artifacts only as long as the configured retention policy allows.\n","# Reproduce and fix issues\n\nWait for a trusted triage marker in the source thread. Reproduce the exact symptom through the target app's real UI. Verify an existing fix when one exists. Attempt a bounded fix only after a confirmed repro.\n\nLoad the external Benny configuration supplied by the automation. If the config, required actions, control adapter, or completed feature map is missing, fail closed.\n\n## Hard safety rules\n\n- Freeze the source channel and root thread coordinates before doing any work.\n- Never post a root message in the source channel.\n- Preflight the source parent before every source-thread post.\n- The coordinator is the only Slack poster.\n- Delegated analysis workers are read-only and return findings or media notes.\n- A fix-phase code worker may edit only when its environment provably excludes Slack credentials and every Slack write action. Otherwise the coordinator edits.\n- Every child prompt must explicitly forbid `SendSlackMessage`, `PostToSlack`, `chat.postMessage`, and all other Slack writes.\n- Never give a child a Slack token, posting instructions, source coordinates for posting, or permission to report externally.\n- If a child needs Slack write access to run, do not launch it.\n- Utility bots are evidence sources. They do not own the fix unless a person explicitly delegated the fix to them.\n- The exact discriminating symptom must appear twice through real UI interaction.\n- State inspection may confirm an observation. It must not inject or force the symptom.\n- No confirmed repro means no authored fix.\n- Existing pull requests or commits switch the run to verify mode. Do not author over them.\n- Use `github.com` pull request links.\n- Keep captures, recordings, logs, and tokens out of source control.\n- Use pstack's `principle-guard-the-context-window` for delegated analysis.\n- Apply pstack's `principle-sequence-verifiable-units`, `principle-fix-root-causes`, and `principle-prove-it-works` through repro, fix, and verification.\n\n## 1. Freeze source coordinates\n\nBefore making a work list or delegating:\n\n1. Require the trigger channel to equal the configured source channel.\n2. Set `SOURCE_THREAD_TS` to `trigger.thread_ts` when present. Otherwise use `trigger.ts`.\n3. Require a nonempty `SOURCE_THREAD_TS`.\n4. Store `SOURCE_CHANNEL_ID` and `SOURCE_THREAD_TS` as immutable values.\n5. Read the source thread and verify its root has those exact coordinates.\n6. Fetch the source permalink.\n\nNever replace these values with a reply timestamp, operations timestamp, or status-message timestamp.\n\nBefore every source-channel post:\n\n1. Read the thread by the immutable coordinates.\n2. Confirm the parent exists, is not deleted, and still belongs to the source channel.\n3. Send only with `channel=SOURCE_CHANNEL_ID` and `thread_ts=SOURCE_THREAD_TS`.\n4. Read the thread again and verify the new message is a reply.\n\nIf any check fails, post nothing. Never retry at the root or in a fallback channel.\n\n## 2. Wait for the triage contract\n\nWatch the source thread for the configured verdict budget. Stay silent while waiting.\n\nAccept a verdict only when:\n\n- Its author matches `slack.triage_identity_user_id`.\n- It is a reply under `SOURCE_THREAD_TS`.\n- It contains exactly one configured marker.\n\nPublic marker forms:\n\n```text\n[benny:bug]\n[benny:bug] tracker=https:\u002F\u002Ftracker.example\u002Fissue\u002F123\n[benny:performance]\n[benny:performance] tracker=https:\u002F\u002Ftracker.example\u002Fissue\u002F123\n[benny:other]\n```\n\nProceed only for `bug` or `performance`. Capture the optional tracker URL. Stop silently for `other`, a missing verdict, an untrusted author, conflicting markers, or a timeout.\n\nThis marker replaces private bot identities and free-form verdict matching.\n\n## 3. Apply ownership and fix-artifact gates\n\nRe-read the thread immediately before starting work.\n\n### Someone is explicitly fixing it\n\nStop when a person clearly claims the fix, gives a concrete implementation plan, or asks another agent to implement, patch, fix, or open a pull request.\n\nDo not treat these as fix ownership:\n\n- A bot summarizes evidence.\n- A tool looks up logs or tickets.\n- Someone asks a bot to diagnose, explain, inspect, or reproduce.\n- A bot posts a cause hypothesis without agreeing to implement it.\n\nJudge the requested action, not the presence of a bot.\n\n### A fix artifact already exists\n\nIf an open pull request or merged commit plausibly fixes this report, switch to `references\u002Fverify-existing-fix.md`.\n\nAn artifact may come from the thread, tracker issue, repository history, or pull request search. A claim without a commit or pull request is not a fix artifact.\n\nIf a person owns the work but has not produced an artifact, stop. Do not race them.\n\n## 4. Open an optional operations thread\n\nIf `slack.operations_channel_id` is configured, the coordinator may create one root status message there. This is the only allowed root post in the repro workflow.\n\nStore its coordinates as `OPERATIONS_CHANNEL_ID` and `OPERATIONS_THREAD_TS`. Never confuse them with the source coordinates.\n\nUse the configured plain Unicode status strings. Keep status text short:\n\n- Reproducing\n- Could not reproduce\n- Blocked\n- Reproduced\n- Verifying existing fix\n- Attempting bounded fix\n- Draft pull request opened\n- Fix did not land\n\nPrefer configured Cursor Slack actions. Use `BENNY_SLACK_BOT_TOKEN` only when the user configured it for a narrow missing capability such as editing this one status message. Never expose the token to a worker.\n\nIf no operations channel is configured, keep detailed status in the automation run output. Do not substitute a source-channel root message.\n\n## 5. Load and check the control adapter\n\nRead `references\u002Fcontrol-adapter.md` and the completed map at `control.feature_map_path`, then invoke the skill named by `control.skill_name`.\n\nFind the feature-map section that matches the reported user path. Read it before driving the app. If no section covers the feature, mark the run blocked instead of inventing a path or selector.\n\nRequire all seven capabilities:\n\n1. Bring up the configured target app and test environment.\n2. Navigate the mapped feature and exercise its documented states.\n3. Drive the real UI with clicks, typing, keys, scrolling, drag, resize, or navigation.\n4. Inspect state without mutating it.\n5. Capture screenshots.\n6. Start and stop a screen recording.\n7. Clean up processes, sessions, profiles, and temporary data.\n\nIf the adapter is absent or any required capability is missing, mark the operations status as blocked and stop. Do not pretend a screenshot, unit test, state mutation, or source reading is a UI repro.\n\n## 6. Study the report\n\nRead the full source thread and tracker issue when present.\n\nCollect:\n\n- Exact action path\n- Expected behavior\n- Observed behavior\n- Discriminating state where they diverge\n- Frequency\n- Version, environment, and platform\n- Attachments and error signatures\n- Candidate code area\n\nInspect screenshots and video. Use read-only parallel workers for code history, test ideas, blast-radius mapping, and media review when useful. Each worker gets a narrow question and the Slack-write prohibition.\n\nUse pstack's `how` skill to trace the action through the repository. Use `why` for regression history and defensive code. Form competing cause hypotheses and identify evidence that would separate them.\n\n## 7. Reproduce\n\nBring up the target app through the control adapter.\n\nConfirm the correct app, workspace, account, data set, and feature state before acting. Use stable app markers. Do not rely on window order or a familiar title alone.\n\nDrive the reported path through real UI actions.\n\nBefore calling it reproduced:\n\n1. Name the correct final state.\n2. Name the broken final state.\n3. Reach the point where they diverge.\n4. Observe the broken state.\n5. Reset enough state to make the second attempt independent.\n6. Repeat the same path and observe the same broken state again.\n7. Cross-check a real state value when possible.\n\nAn expected dialog, loading state, or setup step is not the bug. Capture the final state that distinguishes correct from broken behavior.\n\nUse the configured repro budget. If the symptom does not reproduce within it, report a clean `Could not reproduce` outcome. If the environment cannot provide a required capability, report `Blocked` and state what was missing.\n\n## 8. Capture and review evidence\n\nFor a successful repro:\n\n- Record the full path through the symptom.\n- Capture a screenshot of the broken final state.\n- Save a short note with the exact steps and observed state.\n- Keep artifacts in the configured temporary artifact directory.\n\nHave a read-only media reviewer answer one question: does the evidence visibly show the discriminating broken state?\n\nIf the answer is no or uncertain, the repro is not confirmed. Capture better evidence or use `Could not reproduce`.\n\nPost detailed evidence only in the operations thread when configured. Keep the source update concise.\n\n## 9. Report the repro outcome\n\nUpdate the operations status first.\n\nFor `Could not reproduce` or `Blocked`, post nothing in the source thread. The operations thread or run output carries the result.\n\nFor a confirmed repro, run the source preflight and post at most one unprompted source reply:\n\n- Say the issue reproduced.\n- Link the operations evidence thread when one exists.\n- Include at most three short findings.\n- Link the tracker issue when one exists.\n- Do not ping an owner by default.\n\nAttach evidence only when the configured Slack action keeps it inside the same source thread and the organization's retention policy allows it.\n\nWait for the configured rejection window. If a person shows that the setup or interpretation was wrong, correct the repro once. Do not start the fix phase until the window closes without a valid rejection.\n\n## 10. Verify an existing fix\n\nWhen a fix artifact exists, follow `references\u002Fverify-existing-fix.md`.\n\nVerification must show the symptom on the baseline and its absence on the patched build. Both paths use the real UI twice.\n\nDo not edit the existing fix, add a competing patch, or open a replacement pull request.\n\n## 11. Qualify a bounded fix\n\nAttempt a fix only when all of these hold:\n\n- The outcome is a plain confirmed repro.\n- Media review confirmed the broken final state.\n- No existing fix artifact appeared.\n- No person claimed the fix during the rejection window.\n- Runtime evidence identifies the root cause.\n- The likely change fits the configured fix budget and repository scope.\n- The control adapter can run both baseline and patched builds.\n\nIf any condition fails, keep the repro report and stop without a pull request.\n\nWhen the gate passes, update operations status to `Attempting bounded fix`.\n\n## 12. Root-cause and implement\n\nThe coordinator owns every Slack post, the final diff review, commits, and the pull request.\n\nRead-only workers may:\n\n- Trace code and history\n- Propose tests\n- Map blast radius\n- Review a diff\n- Review media\n\nThey do not edit, run external writes, post status, or own the fix.\n\nA tightly scoped code edit may be delegated during this phase only when tool isolation removes Slack credentials and every Slack write action from that worker. Its prompt must still carry the explicit Slack-write ban. The coordinator reviews the edit and runs or verifies the required tests. If tool isolation is uncertain, keep the edit in the coordinator.\n\nConfirm the mechanism with runtime evidence. Eliminate competing hypotheses before editing.\n\nFix the root cause with the smallest justified change.\n\n- Invoke pstack's `tdd` skill when there is a cheap local test target, and write the failing test before the fix.\n- State why TDD was skipped when the path is expensive, unclear, or integration-heavy.\n- Keep unrelated cleanup out.\n- Stop if the change grows beyond the configured effort or risk budget.\n\n## 13. Prove the fix\n\nKeep the original baseline evidence.\n\nOn the patched build:\n\n1. Run the same real UI path.\n2. Repeat it twice.\n3. Show that the broken state is gone.\n4. Show the expected state in its place.\n5. Capture an after recording and screenshot.\n6. Cross-check the same real state value used for the baseline.\n\nA compile, unit test, code review, or plausible diff is not after evidence.\n\nRun focused tests, then smoke the blast radius around the changed behavior. Cover nearby states, inputs, permissions, platforms, and failure paths that the change could affect. Stop without a pull request if a regression remains.\n\n## 14. Open a draft pull request\n\nOnly after before-and-after proof:\n\n- Review the final diff for unrelated changes and secrets.\n- Run the repository's required checks.\n- Create small ordered commits when the repository workflow allows it.\n- Open a draft pull request. Never merge or deploy from this workflow.\n- Link the configured tracker issue using the tracker's supported pull request syntax.\n- Use the configured public URL form, normally `https:\u002F\u002Fgithub.com\u002F{owner}\u002F{repo}\u002Fpull\u002F{number}`.\n- Include the repro steps, root cause, test result, before and after evidence, and blast-radius checks.\n- Run the pull request text and all Slack updates through pstack's `unslop` skill.\n\nIf pull request creation fails, do not claim success. Keep the commit or branch state in the run output and mark operations status `Fix did not land`.\n\nOn success, mark operations status `Draft pull request opened` and post one concise reply in the operations thread with the linked pull request. Do not create a second source-channel root or unprompted source reply.\n\n## 15. Follow-ups and cleanup\n\nWatch the configured operations thread for one follow-up window.\n\n- Answer a direct question from evidence already gathered.\n- Apply one concrete correction and rerun the repro once when it invalidates the setup.\n- Stay out of human coordination and side chatter.\n- Stop when asked.\n\nAlways call the control adapter's cleanup capability. Keep artifacts only as long as the configured retention policy allows.\n",{"name":5,"description":7,"disable-model-invocation":41},true,"main","0c773e8ba99fe384310af3f9ee59741106a53d95","plugins\u002Fpstack\u002Fautomations\u002Fbenny\u002Fskills\u002Freproduce-and-fix-issues",3,"https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards","https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam","Builder. Less optimizing agents setup, more building","2026-11-08 05:41:31",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":41},[52,55,58],{"tool":53,"command":54},"npx","npx skills add minghinmatthewlam\u002Fagent-guards --skill reproduce-and-fix-issues",{"tool":56,"command":57},"bunx","bunx skills add minghinmatthewlam\u002Fagent-guards --skill reproduce-and-fix-issues",{"tool":59,"command":60},"pnpm","pnpm dlx skills add minghinmatthewlam\u002Fagent-guards --skill reproduce-and-fix-issues","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fautomations\u002Fbenny\u002Fskills\u002Freproduce-and-fix-issues\u002FSKILL.md",[63,69,73],{"path":64,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":67,"sourceHtmlUrl":68},"references\u002Fcontrol-adapter.md","REFERENCE","参考文档",5517,"https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fautomations\u002Fbenny\u002Fskills\u002Freproduce-and-fix-issues\u002Freferences\u002Fcontrol-adapter.md",{"path":70,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":71,"sourceHtmlUrl":72},"references\u002Ffeature-map.example.md",5646,"https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fautomations\u002Fbenny\u002Fskills\u002Freproduce-and-fix-issues\u002Freferences\u002Ffeature-map.example.md",{"path":74,"resourceType":65,"resourceTypeDesc":66,"sizeBytes":75,"sourceHtmlUrl":76},"references\u002Fverify-existing-fix.md",3149,"https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fplugins\u002Fpstack\u002Fautomations\u002Fbenny\u002Fskills\u002Freproduce-and-fix-issues\u002Freferences\u002Fverify-existing-fix.md",[78,108,133,153,174,193],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":89,"publishedAt":36},"01M6EKT039SVAX6PXWNJZNZ4EX","teach","Build a working mental model of code: the components and how they interact, then the interfaces, schemas, and function signatures. Use when asked to teach or explain how code works, walk through an architecture, deep-dive a subsystem, or understand a change, including code outside the current repo. For a concept with no code, use pstack:teach.","https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fskills\u002Fteach\u002FSKILL.md",[84],{"categoryNo":85,"categoryName":86,"taxonomyType":87,"taxonomyTypeDesc":88},"01JBSEEDCAT000000000000039","教师与教育","PROFESSION","适用职业",[80,90,91,92,93,94,95,30,96,97,98,99,100,101,102,103,104,105,106,107],"change","build","model","how","repo","understand","code","explain","with","concept","deep","for","mental model","signatures","pstack","no code","components","when",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":36},"01M6EKSX03CR18TFCATJ5ARTN7","skills-audit","Audit agent skills for triggering quality, correctness, context efficiency, redundancy, structure, failure guidance, and coverage gaps. Use when the user asks to review, improve, compare, simplify, or evaluate skills in global, repo-local, Claude, Codex, or custom skill paths.","https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fskills\u002Fskills-audit\u002FSKILL.md",[],[115,116,117,118,119,94,120,121,122,123,124,30,125,126,127,128,129,130,131,132],"audit","skills audit","coverage","structure","codex","quality","local","guidance","paths","improve","custom skill","simplify","coverage gaps","user","context","compare","review","efficiency",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":139,"publishedAt":36},"01M6EKSSTYVXDV0REZEF7J9X6F","repo-setup","Set up or refactor a repository so agents naturally follow its intended architecture and important mistakes fail mechanically. Use when the user invokes $repo-setup, asks to make a repo agent-friendly, or wants important repository rules enforced through structure, types, tooling, tests, or CI.","https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fskills\u002Frepo-setup\u002FSKILL.md",[],[94,140,141,142,118,143,144,145,146,147,148,30,149,150,151,128,152],"repo setup","setup","SET","types","tooling","repository","up","ci","tests","Rules","refactor","architecture","make",{"skillNo":154,"name":155,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":36},"01M6EKSPNRZKCDWWV9FK57PFPB","record-screen","Record a small MP4 while demonstrating or verifying a UI change, then attach the video as proof. Linux cloud sessions record the private virtual display; macOS records only the app window under test. Use for any repo whenever a UI change is verified or demoed.","https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fskills\u002Frecord-screen\u002FSKILL.md",[],[160,161,162,163,164,165,25,166,94,167,168,169,29,30,170,90,171,24,172,173],"record screen","record","screen","virtual","mp4","Video","as","records","linux","sessions","test","attach","cloud","ui",{"skillNo":175,"name":176,"nameZh":6,"description":177,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":178,"categories":179,"keywords":180,"publishedAt":36},"01M6EKSME0SDX0X052A8ZY0SMB","ori-pr","Take an OpenRouterIncubator\u002Fori or OpenRouterTeam\u002Fopenrouter-web PR from ready to merged. Matthew runs \u002Fori-pr once he has decided the PR is ready and understands the change. Asks perry for review once CI is green, handles perry's comments, and enqueues the merge once perry approves the head and CI is green, within quiet hours.","https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fskills\u002Fori-pr\u002FSKILL.md",[],[181,182,183,184,90,185,186,187,131,147,188,189,190,101,191,192],"pr","ori pr","take","ready","head","green","merge","perry","openrouter","web","true","comments",{"skillNo":194,"name":195,"nameZh":6,"description":196,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":197,"categories":198,"keywords":199,"publishedAt":36},"01M6EKSGFS2DZNXYFH7A9GJ4BD","new-task","Clarify a new task by stating the goal the agent believes the user wants, showing its current understanding, and asking only product-related or high-priority questions that could materially change the outcome. Use before planning or implementation when the task needs alignment.","https:\u002F\u002Fgithub.com\u002Fminghinmatthewlam\u002Fagent-guards\u002Fblob\u002Fmain\u002Fskills\u002Fnew-task\u002FSKILL.md",[],[200,201,202,29,90,203,204,30,205,206,207,208,128],"new task","task","alignment","implementation","clarify","product","planning","goal","outcome"]