How do I install the Bug Session skill?

Run npx skillmds@latest add garyld1962/bug-session-4 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Bug Session safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Bug Session?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Bug Session free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Bug Session?

garyld1962 (@garyld1962) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Bug Session by garyld1962 — Agent Skill

Name: Bug Session
Author: garyld1962

Bug Session

Capture several reported bugs, inspect relevant code, and turn them into distinct actionable GitHub issues. Use for a bug intake session; use triage to diagnose one existing bug and execute-plan to implement fixes.

garyld1962 b449811 2 files · 2.9 KB Updated Sep 17, 2026

File contents

Bug session

Workflow

Confirm the target repository from context and run gh-readiness before remote work. Capture each symptom separately, including actual/expected behavior and available reproduction steps. Ask at most two or three focused questions per unclear bug.
Read the relevant code, tests, domain vocabulary and existing issues. Distinguish confirmed behavior from a hypothesis; do not invent a root cause. Investigate locally unless delegated investigation is already authorized and available.
Group duplicates; separate independently fixable bugs and order dependent fixes. Search open/recent issues before creating anything. Reuse an existing issue only when its scope matches, and report the match.
Draft a portable issue for each bug: descriptive title, user impact, actual versus expected behavior, reproduction, relevant environment, acceptance and dependencies. Keep implementation file/module guesses out of the problem statement; put verified technical evidence in a clearly marked investigation note when useful.
A request to file/create the issues authorizes creation once the repository and scope are clear. Otherwise return drafts. Use connected GitHub tools first or a configured CLI; pass multiline bodies as structured data or through --body-file.
Create dependencies first, use returned issue numbers in later bodies, and return links plus any remaining uncertainties. On partial failure, preserve a creation ledger and check it before retrying so issues are not duplicated.

Examples

"File issues for these three mobile bugs" → investigate, separate, deduplicate, create in the named repository, and return the real links.
"Help me describe this crash" → return a supported issue draft.

Closed decisions and open decisions

The user's expected behavior is authoritative unless conflicting evidence needs clarification. Ask only about unresolved behavior or issue grouping that changes scope.

Do not

Do not fix code during intake, invent issue IDs, report creation without a successful response, or make a separate approval round for issue creation already requested.

Codex integration

Use $bug-session explicitly or let its description match the request. Resolve sibling skills inside this plugin. Read AGENTS.md before repository edits; honor the current host's tool access and delegation rules. Do not require another platform's runtime.

---name: bug-session-4description: Capture several reported bugs, inspect relevant code, and turn them into distinct actionable GitHub issues. Use for a bug intake session; use triage to diagnose one existing bug and execute-plan to implement fixes.---# Bug session## Workflow1. Confirm the target repository from context and run gh-readiness before remote work. Capture each symptom separately, including actual/expected behavior and available reproduction steps. Ask at most two or three focused questions per unclear bug.2. Read the relevant code, tests, domain vocabulary and existing issues. Distinguish confirmed behavior from a hypothesis; do not invent a root cause. Investigate locally unless delegated investigation is already authorized and available.3. Group duplicates; separate independently fixable bugs and order dependent fixes. Search open/recent issues before creating anything. Reuse an existing issue only when its scope matches, and report the match.4. Draft a portable issue for each bug: descriptive title, user impact, actual versus expected behavior, reproduction, relevant environment, acceptance and dependencies. Keep implementation file/module guesses out of the problem statement; put verified technical evidence in a clearly marked investigation note when useful.5. A request to file/create the issues authorizes creation once the repository and scope are clear. Otherwise return drafts. Use connected GitHub tools first or a configured CLI; pass multiline bodies as structured data or through --body-file.6. Create dependencies first, use returned issue numbers in later bodies, and return links plus any remaining uncertainties. On partial failure, preserve a creation ledger and check it before retrying so issues are not duplicated.## Examples- "File issues for these three mobile bugs" → investigate, separate, deduplicate, create in the named repository, and return the real links.- "Help me describe this crash" → return a supported issue draft.## Closed decisions and open decisionsThe user's expected behavior is authoritative unless conflicting evidence needsclarification. Ask only about unresolved behavior or issue grouping that changes scope.## Do notDo not fix code during intake, invent issue IDs, report creation without a successfulresponse, or make a separate approval round for issue creation already requested.## Codex integrationUse `$bug-session` explicitly or let its description match the request. Resolve siblingskills inside this plugin. Read AGENTS.md before repository edits; honor the currenthost's tool access and delegation rules. Do not require another platform's runtime.

Frequently asked questions