Stats
Actions
Tags
From tp-git
Load all open issues from GitHub and create structured technical specifications for implementation.
How this skill is triggered — by the user, by Claude, or both
Slash command
/tp-git:git-issuesWhen to use
Use when the user says 'load issues', 'fetch issues', 'get GitHub issues', 'list issues', or 'pull issues from GitHub'. IMMEDIATELY when the user says 'analyze issue', 'analyze GitHub issue', 'create spec for issue', 'technical specification', or 'break down this issue'. BEFORE implementing any GitHub issue — load and analyze it first to create a technical spec.
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
IF loading all open issues → fetch from GitHub CLI, save to specs/issues/
IF loading all open issues → fetch from GitHub CLI, save to specs/issues/ IF analyzing a specific issue → locate or fetch it, then produce a spec document IF repository has no open issues → report empty state IF issue file is missing locally → fetch from GitHub first IF issue is a bug fix → emphasize test plan and reproduction steps in the spec IF issue is a feature → emphasize technical approach and implementation plan in the spec IF gh CLI is unavailable → report error and suggest installation
Fetch all open issues from the current GitHub repository and write each as a structured markdown file. Take any issue (by number) and produce a detailed technical specification. Both workflows use gh CLI and the ./specs/issues/ directory.
One file per issue, consistently formatted. A specification is a contract between problem and solution — precise enough to implement without ambiguity, concise enough to review in one pass.
List all open issues: gh issue list --limit 100
For each issue, fetch full details:
gh issue view <number> --json number,title,body,state,createdAt,updatedAt,author,labels,assignees,url
Create output directory: mkdir -p ./specs/issues
Save each issue as <number-padded-to-3-digits>-<kebab-case-title>.md
# Issue #<number>: <title>
**Status:** <state>
**Created:** <createdAt>
**Updated:** <updatedAt>
**Author:** <author.name> (@<author.login>)
**URL:** <url>
## Description
<body>
## Labels
<labels or "None">
## Assignees
<assignees or "None">
./specs/issues/ for a matching <NNN>-<title>.md filegh issue view <number> and save to that path./specs/issues/<NNN>-<kebab-case-title>.specs.md# Technical Specification for Issue #<number>
## Issue Summary
- Title, Description, Labels, Priority assessment
## Problem Statement
[1-2 paragraphs]
## Technical Approach
[Detailed approach with rationale]
## Implementation Plan
1. Step one
2. Step two
## Test Plan
- Unit tests
- Integration tests
## Files to Modify
- path: changes needed
## Files to Create
- path: purpose
## Success Criteria
- [ ] Measurable condition
## Out of Scope
- What this spec explicitly excludes
./specs/issues/<NNN>-<title>.md — one file per open issue (load)./specs/issues/<NNN>-<title>.specs.md — specification document (analyze)Separating analysis from implementation prevents premature commitment to an approach. The spec serves as a reviewable artifact before any code is written.
Produces specification documents consumed by downstream implementation processes. The Implementation Plan and Files to Modify sections drive task sequencing.
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub git-fg/taches-principled --plugin tp-git