Gen Specs As Issues
Turn README promises and placeholder code into prioritized feature gaps and implementation-ready specs as GitHub issues.
Overview
gen-specs-as-issues is an agent skill most often used in Validate (also Build) that identifies missing features and drafts detailed implementation specifications from repo reality.
Install
npx skills add https://github.com/github/awesome-copilot --skill gen-specs-as-issuesWhat is this skill?
- Two-phase ritual: project understanding then gap analysis against real implementation
- Guiding questions tie README, tests, entry points, and placeholders to user problems
- Prioritizes core functionality over nice-to-haves before spec output
- Produces structured issue-ready specifications for downstream implementation agents
- 2 workflow phases: project understanding and gap analysis
Adoption & trust: 8.5k installs on skills.sh; 34.6k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your project docs describe features that are missing, stubbed, or untested, and you have no prioritized spec list to hand an coding agent.
Who is it for?
Solo builders auditing an existing codebase before scaling agent-driven feature work.
Skip if: Greenfield ideas with no repo yet, or teams that already maintain a signed-off implementation plan with checked steps.
When should I use this skill?
You need to identify missing features, prioritize them, and create detailed specifications for implementation from an existing repository.
What do I get? / Deliverables
You get a prioritized gap list and detailed specs suitable for GitHub issues, ready to invoke structured implementation or planning skills on the top items.
- Prioritized gap list
- Detailed feature specifications
- Issue-ready implementation briefs
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Validate because the workflow compares documented intent to actual code before you commit to a full build roadmap. Scope subphase fits gap analysis, prioritization, and spec authoring that define what to build next—not shipping or marketing.
Where it fits
Compare marketing README claims to integration tests before committing to a v2 scope.
Refresh the issue queue after merging a large refactor so agents know which modules are still stubs.
Re-run gap analysis when support tickets reference features that only exist in docs.
How it compares
Use instead of ad-hoc “what should we build next?” chat when you need evidence from README, tests, and code—not opinion-only roadmaps.
Common Questions / FAQ
Who is gen-specs-as-issues for?
Indie and solo builders maintaining a real repo who need PM-style gap analysis and issue-ready specs without hiring a product manager.
When should I use gen-specs-as-issues?
During Validate when scoping what is actually built versus documented; during Build when refreshing the backlog before an agent implementation sprint; and during Operate when tech debt docs no longer match production behavior.
Is gen-specs-as-issues safe to install?
It is procedural guidance that reads your repo context; review the Security Audits panel on this Prism page and limit what paths or secrets you expose in chat.
Workflow Chain
Then invoke: structured autonomy implement
SKILL.md
READMESKILL.md - Gen Specs As Issues
# Product Manager Assistant: Feature Identification and Specification This workflow guides you through a systematic approach to identify missing features, prioritize them, and create detailed specifications for implementation. ## 1. Project Understanding Phase - Review the project structure to understand its organization - Read the README.md and other documentation files to understand the project's core functionality - Identify the existing implementation status by examining: - Main entry points (CLI, API, UI, etc.) - Core modules and their functionality - Tests to understand expected behavior - Any placeholder implementations **Guiding Questions:** - What is the primary purpose of this project? - What user problems does it solve? - What patterns exist in the current implementation? - Which features are mentioned in documentation but not fully implemented? ## 2. Gap Analysis Phase - Compare the documented capabilities ONLY against the actual implementation - Identify "placeholder" code that lacks real functionality - Look for features mentioned in documentation but missing robust implementation - Consider the user journey and identify broken or missing steps - Focus on core functionality first (not nice-to-have features) **Output Creation:** - Create a list of potential missing features (5-7 items) - For each feature, note: - Current implementation status - References in documentation - Impact on user experience if missing ## 3. Prioritization Phase - Apply a score to each identified gap: **Scoring Matrix (1-5 scale):** - User Impact: How many users benefit? - Strategic Alignment: Fits core mission? - Implementation Feasibility: Technical complexity? - Resource Requirements: Development effort needed? - Risk Level: Potential negative impacts? **Priority = (User Impact × Strategic Alignment) / (Implementation Effort × Risk Level)** **Output Creation:** - Present the top 3 highest-priority missing features based on the scoring - For each, provide: - Feature name - Current status - Impact if not implemented - Dependencies on other features ## 4. Specification Development Phase - For each prioritized feature, develop a detailed but practical specification: - Begin with the philosophical approach: simplicity over complexity - Focus on MVP functionality first - Consider the developer experience - Keep the specification implementation-friendly **For Each Feature Specification:** 1. **Overview & Scope** - What problem does it solve? - What's included and what's explicitly excluded? 2. **Technical Requirements** - Core functionality needed - User-facing interfaces (API, UI, CLI, etc.) - Integration points with existing code 3. **Implementation Plan** - Key modules/files to create or modify - Simple code examples showing the approach - Clear data structures and interfaces 4. **Acceptance Criteria** - How will we know when it's done? - What specific functionality must work? - What tests should pass? ## 5. GitHub Issue Creation Phase - For each specification, create a GitHub issue: - Clear, descriptive title - Comprehensive specification in the body - Appropriate labels (enhancement, high-priority, etc.) - Explicitly mention MVP philosophy where relevant **Issue Template Structure:** # [Feature Name] ## Overview [Brief description of the feature and its purpose] ## Scope [What's included and what's explicitly excluded] ## Technical Requirements [Specific technical needs and constraints] ## Implementation Plan [Step-by-step approach with simple code examples] ## Acceptance Criteria [Clear list of requirements to consider the feature complete] ## Priority [Justification for prioritization] ## Dependencies - **Blocks:** [List of issues bloc