Stats
Actions
Tags
From humaninloop
Creates and manages GitHub issues for bugs, features, and tasks with enforced quality standards like reproducibility steps, acceptance criteria, and severity assessment.
How this skill is triggered — by the user, by Claude, or both
Slash command
/humaninloop:using-github-issuesThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create and manage GitHub issues with enforced quality standards. Every issue MUST have sufficient context for a developer unfamiliar with the problem to begin work without follow-up questions.
Create and manage GitHub issues with enforced quality standards. Every issue MUST have sufficient context for a developer unfamiliar with the problem to begin work without follow-up questions.
Violating the letter of the rules is violating the spirit of the rules. An issue that technically exists but lacks reproducibility steps, acceptance criteria, or proper security handling is a violation.
Issue quality is not negotiable based on time pressure, authority, or fatigue. A 2-minute issue that causes 2 hours of clarification is not efficient. Complete issues save time.
No exceptions:
Every bug report MUST include:
| Field | Requirement |
|---|---|
| Title | Describe the problem, not the solution. "[Component] fails when [condition]" |
| Steps to Reproduce | Numbered steps to trigger the bug. If not reproducible, state that explicitly. |
| Expected Behavior | What SHOULD happen |
| Actual Behavior | What DOES happen (include error messages verbatim) |
| Environment | OS, browser, version, relevant configuration |
| Severity | Impact assessment (critical/high/medium/low) |
Optional but valuable: screenshots, logs, minimal reproduction case.
Every feature request MUST include:
| Field | Requirement |
|---|---|
| Title | Describe the capability. "[Action] [Object] [Context]" |
| User Story | As a [role], I want [capability], so that [benefit] |
| Acceptance Criteria | Numbered, testable conditions that define "done" |
| Scope Boundaries | Explicit out-of-scope items to prevent scope creep |
| Priority Rationale | Why this matters now |
Optional but valuable: mockups, technical considerations, related issues.
Every task MUST include:
| Field | Requirement |
|---|---|
| Title | Action-oriented. "Migrate [X] to [Y]" not "Database stuff" |
| Definition of Done | Clear deliverable that can be verified |
| Context | Why this task exists, what depends on it |
| Estimated Effort | T-shirt size or time estimate |
Security issues require special handling.
CRITICAL RULE: NEVER create public issues for security vulnerabilities.
Use private disclosure channels:
A public security issue, regardless of labels, is visible to attackers. Labels do not provide confidentiality. Even if the user explicitly requests a public issue for urgency, refuse and explain the risk.
Before creating any issue, verify:
Search existing issues before creating new ones. Search cost is minimal compared to duplicate cleanup cost.
gh issue list --search "keyword1 keyword2" --state all
See references/gh-cli-commands.md for complete search and filter options.
When triaging issues:
Update issue status with context:
gh issue close ISSUE_NUMBER --comment "Resolved in PR #123"
gh issue reopen ISSUE_NUMBER --comment "Regression observed in v2.1"
Connect related items using GitHub keywords:
For backlog maintenance, see references/gh-cli-commands.md for bulk close, label, and milestone operations.
| Excuse | Reality |
|---|---|
| "The user is in a hurry" | A 2-minute conversation later asking "what browser?" is slower than filling it in now. Time pressure is not permission to skip quality. |
| "It's obvious what this means" | Obvious to you now is not obvious to the developer who picks this up in 3 weeks. Document explicitly. |
| "We can add details later" | "Later" rarely comes. Issues without context become stale. Do it now. |
| "The expert knows what they need" | Documentation serves the expert too. Race conditions are hard to reproduce. The issue protects their future self. |
| "Being pragmatic, not dogmatic" | Pragmatic means following proven process. Cutting corners creates rework. |
| "I've done 12 good issues already" | Fatigue is when corners get cut. Quality is not negotiable based on session length. |
| "User explicitly requested public" | User consent does not override security principles. Explain the risk. |
| "Team needs to see this urgently" | Private security advisories still notify the team. Public issues notify attackers too. |
| "Better to over-document with duplicates" | Duplicates contaminate the issue tracker. Search cost is minimal. |
| "Searching takes time" | Search cost is seconds. Duplicate cleanup cost is minutes to hours. |
If you notice yourself thinking any of these, STOP immediately:
All of these indicate rationalization. Apply the full quality standard.
Problem: Title says "Add null check to processAsync()" instead of describing the failure.
Why it's wrong: Titles should communicate the problem for triage. The solution may change; the problem is stable.
Fix: Use "[Component] fails when [condition]" format. "PaymentProcessor crashes on null payment method" not "Add null check".
Problem: Bug report says "the toggle doesn't work" without steps because "it's obvious".
Why it's wrong: Obvious bugs often have non-obvious triggers. "Doesn't work" could mean 10 different failure modes.
Fix: Always include steps. If truly simple, the steps are quick to write: "1. Open settings 2. Click dark mode toggle 3. Observe no change".
Problem: Creating public issue for vulnerability because user requested it or team needs visibility.
Why it's wrong: Public issues are visible to attackers. Even with security labels, the vulnerability details are exposed.
Fix: Always use private disclosure. GitHub Security Advisories notify the team without exposing details publicly.
Problem: Creating issue immediately, noting "may be related to existing issues".
Why it's wrong: "May be related" notes do not prevent duplicate confusion. Duplicate issues fragment discussion and waste triage effort.
Fix: Search first. Takes seconds. If found, add context to existing issue instead of creating duplicate.
Problem: Filling only title and brief description when user seems rushed.
Why it's wrong: Incomplete issues require follow-up. The time "saved" is spent later on clarification.
Fix: Complete templates prevent thrashing. A complete issue means developers can start immediately.
Before submitting, verify the issue passes this checklist:
| Resource | Description |
|---|---|
examples/bug-report-template.md | Bug report template with correct/incorrect examples |
examples/feature-request-template.md | Feature request template with user story format |
examples/task-template.md | Task/chore template with definition of done |
examples/security-advisory-template.md | Private disclosure template (NEVER public) |
references/gh-cli-commands.md | Complete gh CLI command reference |
humaninloop:authoring-requirements - Detailed requirements authoringhumaninloop:authoring-user-stories - User story format guidancehumaninloop:validation-task-artifacts - Task validation standardsnpx claudepluginhub joshuarweaver/cascade-ai-ml-agents-agent-framework --plugin deepeshbodh-human-in-loopCreates well-structured GitHub issues using gh CLI with templates for bugs, features, tasks including titles, descriptions, acceptance criteria, and labels. Use for filing bugs or feature requests.
Open-source issue creation: bug reports, feature requests, and structured contribution communication. Invoke whenever task involves any interaction with issues in external repositories — filing bugs, proposing features, reporting problems, or preparing issue content for open-source projects.
Creates, lists, and views GitHub issues using the gh CLI with a guided workflow for gathering titles, descriptions, and action selection.