You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm building a Next.js application where GitHub Issues is the single source of truth for project tracking.
We use:
Epics (parent issues) for feature groupings
Sub-issues for individual tasks
Milestones for phase tracking
Labels for metadata (type, area, priority, phase)
GitHub Actions for automation
We've built custom scripts that handle issue creation, PR workflows, and enforce our metadata requirements.
However, maintaining these scripts is ongoing work, and we'd love to align with OpenSpec's structured approach.
The challenge: OpenSpec's artifact workflow (proposal → specs → design → tasks) is exactly what we need for planning, but we need those artifacts to flow into GitHub Issues rather than remaining as local files.
Use Case
Our current workflow:
Create planning document (markdown)
Convert to GitHub Epic + Sub-issues (via custom scripts)
Issue creation with full metadata (labels, milestone, assignee, project board)
GraphQL mutations for sub-issue relationships
PR creation with template compliance
Branch management and cleanup
I'm willing to:
Generalize these into a TypeScript implementation
Build this as a standalone package first (openspec-github-bridge)
Contribute upstream if the approach aligns with OpenSpec's direction
Open Questions
Does this fit with the plugin architecture being discussed in Enhancement: Plugins #453? Should this be a plugin vs core feature?
Hook system design: Should hooks be config-based (yaml) or code-based (TypeScript config file)? Or both?
Abstraction level: Should GitHub be a specific adapter, or should there be a generic "issue tracker" interface that supports GitHub, Linear, Jira, etc.?
Source of truth: Once exported to GitHub, should OpenSpec track that relationship? Or is it a one-way export where GitHub becomes authoritative?
Existing work: Is anyone already building this? I saw Ecosystem & Integration #436 requests similar functionality - happy to collaborate.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
RFC: GitHub Issues Integration - Hooks & Adapters
Problem Statement
I'm building a Next.js application where GitHub Issues is the single source of truth for project tracking.
We use:
We've built custom scripts that handle issue creation, PR workflows, and enforce our metadata requirements.
However, maintaining these scripts is ongoing work, and we'd love to align with OpenSpec's structured approach.
The challenge: OpenSpec's artifact workflow (proposal → specs → design → tasks) is exactly what we need for planning, but we need those artifacts to flow into GitHub Issues rather than remaining as local files.
Use Case
Our current workflow:
What we'd like with OpenSpec:
/opsx:new→ create structured artifacts/opsx:ff→ generate proposal, specs, design, tasksProposed Approach
1. Event/Hook System
Allow users to run custom code on OpenSpec lifecycle events:
openspec/config.yaml
This would enable integrations without modifying OpenSpec core.
2. GitHub Adapter (Optional Built-in)
A configurable adapter that creates GitHub Issues from artifacts:
3. CLI Command
What I'm Offering
I have working bash scripts that do this today:
I'm willing to:
Open Questions
Related
Looking forward to feedback. Happy to iterate on the approach based on maintainer guidance.
Beta Was this translation helpful? Give feedback.
All reactions