Create Github Issues For Unmet Specification Requirements

Create GitHub issues for unmet specification requirements

Analyze a specification file, verify which requirements are not implemented, search GitHub for existing coverage, and create one actionable GitHub Issue per unmet requirement using the repository's feature request template when possible.

When a caller supplies ${file}, treat it as the specification source path.

When to invoke

• "Create GitHub Issues for unmet requirements in this spec."
• "Turn unimplemented specification requirements into issues."
• "File issues for missing acceptance criteria."
• "Check the spec against the codebase and create issues."
• "Use feature_request.yml for these missing requirements."

Prerequisites and context

• A specification file path or selected specification content is required.
• GitHub repository access must be available for issue search and creation.
• Use feature_request.yml when the repository provides it; fall back to a normal issue body only when the template is unavailable.

Procedure

1. Analyze the specification file to extract all requirement IDs, descriptions, acceptance criteria, and relevant context.
2. Search the codebase for related implementation patterns, route names, types, functions, tests, configuration, and documentation.
3. Check related specification files in /spec/ when present so the requirement is not already refined or superseded elsewhere.
4. Classify each requirement as implemented, partially implemented, unimplemented, or uncertain. Verify that partial implementation is not enough to satisfy the acceptance criteria.
5. Search existing issues using search_issues or the GitHub CLI equivalent before creating anything.
6. Create one new issue per unimplemented requirement using create_issue or the GitHub CLI equivalent.
7. Use the feature_request.yml template fields when available; otherwise create a markdown body with the same information.
8. Report created issues, skipped duplicates, implemented requirements, and uncertain cases.

Requirement and issue mapping

Duplicate and implementation checks

• Search existing issues by requirement ID, key phrases from the requirement, and likely feature names.
• Treat an open issue with the same requirement ID as a duplicate unless the user explicitly asks for a new tracking issue.
• Treat a closed issue as evidence, not proof; inspect whether it actually satisfies the requirement.
• Search the codebase for related code patterns and tests before claiming a requirement is unimplemented.
• If implementation evidence is ambiguous, create an issue only when the missing behavior is clear; otherwise report uncertainty and the evidence needed.

Output template

## GitHub requirement issue creation

**Status:** created | partial | blocked
**Specification:** `<specification file>`

| Requirement | Implementation status | Existing issue search | Action |
| --- | --- | --- | --- |
| `REQ-001` | unimplemented | no duplicate found | created `<issue URL>` |
| `REQ-002` | implemented | not searched | skipped |
| `REQ-003` | partial | duplicate `<issue URL>` | skipped duplicate |

### Issue body used
```markdown
## Requirement
`<REQ-ID>` — <description>

## Implementation guidance
- <files, modules, or approach>

## Acceptance criteria
- [ ] <criterion>

## Evidence
- <implementation search evidence or gap>
```

### Validation
- Existing issues searched: yes | no
- `feature_request.yml` used: yes | fallback

Quality gate

• Every requirement from the specification was extracted or explicitly marked unparseable.
• Codebase implementation status was checked before issue creation.
• Existing issues were searched by requirement ID and key phrases to avoid duplicates.
• Each new issue maps to exactly one unimplemented requirement.
• Issue title contains the requirement ID and brief description.
• Issue body includes detailed requirement context, implementation guidance, and acceptance criteria.
• feature_request.yml was used when available, with fallback noted when not available.
• Created, skipped, duplicate, implemented, partial, and uncertain requirements are all reported.