babysit-pr
Use after a pull request is open to watch its CI and review-bot comments until it is ready. Fixes real findings, replies with a…
@greenfield-incInstall SkillAgent Orchestration
Skill
/bug-intake
Use when the person reports broken behaviour or starts a session to file a bug. Reproduces and reports. Never fixes.
Claude Code
$ npx -y skills add greenfield-inc/Pane --skill bug-intake --agent claude-code
Codex
$ npx skills add greenfield-inc/Pane --skill bug-intake -a codex -y
Cursor
$ npx skills add greenfield-inc/Pane --skill bug-intake -a cursor -y
Gemini CLI
$ npx skills add greenfield-inc/Pane --skill bug-intake -a gemini-cli -y
GitHub Copilot
$ npx skills add greenfield-inc/Pane --skill bug-intake -a github-copilot -y
OpenCode
$ npx skills add greenfield-inc/Pane --skill bug-intake -a opencode -y
Windsurf
$ npx skills add greenfield-inc/Pane --skill bug-intake -a windsurf -y
SKILL.md
bug-intake.SKILL.mdname: bug-intake
description: Use when the person reports broken behaviour or starts a session to file a bug. Reproduces and reports. Never fixes.
Bug intake
The goal is a report someone else can act on. The first move is reproduction, not theory.
Steps
1. Restate the symptom in one sentence and confirm it with the person. Get the environment, the account or record involved, and when it started. 2. Reproduce it.
- If it needs the running app, reproduce it with the [`verify-app`](../verify-app/SKILL.md) skill, yourself or through a subagent given the steps to attempt, and collect screenshots, console output, and network failures.
- Otherwise give a fresh-context subagent one question at a time to answer with the [`gather-evidence`](../gather-evidence/SKILL.md) skill: find the failing test, collect logs, trace the code path, list touched files. Give it the question and a fresh context, not this conversation.
3. Interpret the evidence yourself. Classify the failure early: compile, logic, race, state, integration, environment, or interface. Write three to five ranked hypotheses before reading deeply, then test them against the code and its recent history. Compare a broken path with a working one when you can. Drop a theory once the evidence rules it out, and leave choosing the fix to whoever takes the report. If only diagnostic logging would settle it, say exactly what you would add and ask first. 4. Write the success definition: the bug is gone when what is observably true. 5. Choose a route:
- `direct-to-implementation`: obvious locus, contained change, tests exist. The report can serve as the whole task for an implementation session.
- `options-first`: unclear locus, or fixing it forces a design choice. It goes to a planning session.
- `cannot-reproduce`: say what was tried and what evidence would help. Stay in intake.
6. File the report wherever the person tracks work (a GitHub issue, Linear, or another tracker). With no tracker, save it as `index.html` in a bundle of its own in the format at [references/bug-report.md](references/bug-report.md), rendered with the [`page`](../page/SKILL.md) house standard, then stop.
Banned
- Fixes, patches, "quick" changes, refactors
- Writing a plan
- Presenting a hypothesis as the confirmed cause without evidence
If the person then says "fix it"
Hand it on. For `direct-to-implementation`, tell them to start an implementation session with the report as its source. For `options-first`, tell them to take the report to a planning session.
Read more
name: bug-intake description: Use when the person reports broken behaviour or starts a session to file a bug. Reproduces and reports. Never fixes.
Bug intake
The goal is a report someone else can act on. The first move is reproduction, not theory.
Steps
1. Restate the symptom in one sentence and confirm it with the person. Get the environment, the account or record involved, and when it started. 2. Reproduce it.
- If it needs the running app, reproduce it with the [`verify-app`](../verify-app/SKILL.md) skill, yourself or through a subagent given the steps to attempt, and collect screenshots, console output, and network failures.
- Otherwise give a fresh-context subagent one question at a time to answer with the [`gather-evidence`](../gather-evidence/SKILL.md) skill: find the failing test, collect logs, trace the code path, list touched files. Give it the question and a fresh context, not this conversation.
3. Interpret the evidence yourself. Classify the failure early: compile, logic, race, state, integration, environment, or interface. Write three to five ranked hypotheses before reading deeply, then test them against the code and its recent history. Compare a broken path with a working one when you can. Drop a theory once the evidence rules it out, and leave choosing the fix to whoever takes the report. If only diagnostic logging would settle it, say exactly what you would add and ask first. 4. Write the success definition: the bug is gone when what is observably true. 5. Choose a route:
- `direct-to-implementation`: obvious locus, contained change, tests exist. The report can serve as the whole task for an implementation session.
- `options-first`: unclear locus, or fixing it forces a design choice. It goes to a planning session.
- `cannot-reproduce`: say what was tried and what evidence would help. Stay in intake.
6. File the report wherever the person tracks work (a GitHub issue, Linear, or another tracker). With no tracker, save it as `index.html` in a bundle of its own in the format at [references/bug-report.md](references/bug-report.md), rendered with the [`page`](../page/SKILL.md) house standard, then stop.
Banned
- Fixes, patches, "quick" changes, refactors
- Writing a plan
- Presenting a hypothesis as the confirmed cause without evidence
If the person then says "fix it"
Hand it on. For `direct-to-implementation`, tell them to start an implementation session with the report as its source. For `options-first`, tell them to take the report to a planning session.
Stats
616
Stars
236
Forks
Active
Maintenance
TypeScript
Language
Last commit
Created
Added
59739 skills4 agents
Stars on GitHub
Momentum
- stars in total
- 597
Other skills on pane.
@greenfield-incInstall Skillbrief
Use when a problem, idea, or change of intent is worth capturing as a long-form page, or the person asks to write it up. Never…
@greenfield-incInstall Skillcodebase-design
Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening…
@greenfield-incInstall Skillcodebase-explorer
Explore the codebase to locate files, trace behavior, and document existing patterns with precise file references. Use when the…
@greenfield-incInstall Skillcold-read
Give a fresh agent something to walk through with zero context - a PR body, a landing page, a document, a process, instructions,…
@greenfield-incInstall Skillcreate-ticket
Capture work and evolving intent during discussion as one or more GitHub tickets, Grain briefs, or both. Use for ticket or issue…
@greenfield-incInstall SkillMore skills from other plugins.
agentmail
Use your assigned AgentMail inbox to read email tasks, explicitly send or reply, and check delivery. Provided automatically by…
@paperclipaiInstall Skilladr-create
Create a new Architecture Decision Record with sequential numbering and AgentDB registration
@ruvnetInstall SkillQuestions about bug-intake.
- Which coding agents can use bug-intake?
- bug-intake installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.