Agent skill · writing content · aiskillstore
gh-ticket
Create or update comprehensive GitHub issues that capture ALL context, requirements, and implementation details. Use when creating or updating tickets, issues, feature requests, or bug reports. Ensures no context is lost between ticket creation and implementation - the moment you ask for a ticket, there's maximum context available that will be lost if not captured now.
Why this skill is useful
Provides a structured template for creating comprehensive GitHub issues, ensuring critical context and requirements are captured effectively.
What it needs
About 12k tokens when loaded. Last updated 2026-08-07. 405 stars on the source repository.
What this skill does
GitHub Ticket (Create or Update) Why This Skill Exists The moment you decide to create a ticket, you have MAXIMUM CONTEXT. You just investigated the problem You understand the codebase state You know the requirements You have the error messages fresh You understand the dependencies If you don't capture this NOW, it's lost forever. The implementer (even if it's you later) will have to re-discover everything. The Cost of Vague Tickets Vague Ticket Cost -------------- ------ "Fix auth bug" Implementer spends 2 hours finding which bug "Add user settings" 5 back-and-forth clarifications "Improve performance" Implementation doesn't match intent "Handle edge case" Which edge case? What behavior? Every minute spent writing a good ticket saves 10 minutes of implementation confusion. --- When to Use This Skill Creating a new GitHub issue Updating an existing issue with new context/requirements Expanding a vague issue into a comprehensive spec Adding implementation details discovered during investigation --- Ticket Process (Create or Update) Phase 1: Context Capture (DO THIS FIRST) Before writing anything, gather ALL available context: Step 1: Dump Current Context Ask yourself and document: Step 2: Gather Technical Evidence Step 3: Check for Related Context --- Phase 2: Requirements Extraction CRITICAL: Extract EVERY requirement as a checkbox item. Functional Requirements What must the implementation DO? Rules for writing requirements: Start with a verb (Create, Add, Update, Remove, Fix, Handle) Be specific (not "handle errors" but "return 400 with validation message when email invalid") One requirement per checkbox If it's complex, break it down Edge Cases What edge cases must be handled? Acceptance Criteria How do we KNOW it's done? --- Phase 3: Implementation Guidance Give the implementer a head start with everything you know. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills aiskillstore/gh-ticket