[Feature]: Complementary features from oh-my-speckit

### Prerequisites

- [x] I have searched existing issues and discussions to avoid duplicates
- [x] This feature request is specific to oh-my-opencode (not OpenCode core)
- [x] I have read the [documentation](https://github.com/code-yeongyu/oh-my-opencode#readme)

### Problem Description

Not a traditional "problem," but an exciting discovery!
I independently developed [oh-my-speckit](https://github.com/lofidonut3/oh-my-speckit) during Jan 20-24, 2026, and was genuinely amazed when v3.0.0's Prometheus/Atlas system was released today—we arrived at remarkably similar solutions (~95% philosophical alignment) from completely different starting points!
**The convergent evolution is fascinating.** My repository was created on Jan 21 (3 days before v3.0.0 release), and seeing this overlap today felt like discovering a parallel universe where we both independently solved the same problems in nearly identical ways.
**Both systems converged on:**
- Planning vs Execution separation
- Iterative clarification phases
- Specialized agent delegation
- Verification mechanisms
- Parallel execution strategies
**This alignment validates both approaches!** However, I noticed 5 features in oh-my-speckit that don't exist in v3.0.0 yet, which could complement the Category/Skill system:
1. **Constitution System** - Missing in v3.0.0
2. **Spec-Code Auto-Sync** - Missing in v3.0.0
3. **GitHub Issues Integration** - Missing in v3.0.0
4. **Research/Evaluate Phase Split** - v3.0.0 has single Metis phase
5. **Physical Parallelization Option** - v3.0.0 has logical delegation only
**Use case:** Projects that need stronger governance (Constitution), spec-code consistency enforcement (Auto-Sync), team collaboration beyond AI (GitHub Issues), unbiased research (Research/Evaluate split), and debugging-friendly parallelization (tmux).

### Proposed Solution

1. Constitution System
**What**: Project-level principles that guide all decision-making throughout the workflow.
**How it works**:
---
principles:
- "Mobile-first design"
- "80% test coverage minimum"
- "No vendor lock-in"
---
Every agent (Prometheus, Atlas, etc.) consults the constitution before making architectural decisions.
Benefits:
- Ensures consistency across clarify → research → evaluate → plan phases
- Provides context without repeating requirements
- Acts as "project DNA" for long-term maintenance
---
2. Spec-Code Auto-Sync
What: Automatic spec.md updates when code changes are committed.
How it works: Pre-commit hook that:
1. Compares code diff against spec.md
2. Detects mismatches (new functions, changed behavior, etc.)
3. Prompts agent to update spec.md before allowing commit
Benefits:
- Prevents spec drift (code evolves, docs stay stale)
- Enforces "spec is source of truth" discipline
- Reduces manual documentation burden
---
3. GitHub Issues Integration
What: /speckit.taskstoissues command converts tasks.md into dependency-ordered GitHub Issues.
How it works:
/speckit.taskstoissues
# → Analyzes tasks.md
# → Creates GitHub Issues with:
# - Proper dependencies (blocks/blocked-by)
# - Labels (frontend, backend, etc.)
# - Milestones
# - Assignable format
Benefits:
- Seamless transition from AI planning → team project management
- Team visibility (non-AI team members see progress)
- GitHub Projects integration for tracking
---
4. Research/Evaluate Phase Split
What: Separate speckit.research (pure data gathering) from speckit.evaluate (decision-making), instead of v3.0.0's single Metis phase.
How it works:
- speckit.research: Agent collects competitive analysis, market trends, technical constraints (no opinions)
- speckit.evaluate: Agent makes decisions using Constitution + Research data
Comparison:
- v3.0.0: Metis (gap analyzer) - single-phase pre-planning
- oh-my-speckit: specify → clarify → research → evaluate → plan
Benefits:
- Prevents confirmation bias (agent doesn't evaluate while researching)
- Clearer audit trail for architectural decisions
- Better separation of concerns
---
5. Physical Parallelization Option
What: tmux-based multi-terminal execution (/orchestrate skill) as an alternative to v3.0.0's logical delegate_task.
How it works: Spawns actual tmux sessions for each parallel task instead of logical background agents.
Benefits:
- True isolation for tasks that need it
- Easier debugging (each worker has dedicated, visible terminal)
- User preference option (some prefer watching parallel terminals)
Note: v3.0.0's delegate_task is excellent—this just provides an alternative for specific debugging/monitoring use cases.
---
Implementation Path
These could be implemented as:
1. Optional plugins - Users opt-in via oh-my-opencode.json
2. Built-in features - Integrated into Prometheus/Atlas workflow
3. Skill additions - Loadable via existing skill system
I'm excited to contribute implementations if these align with the project's direction!

### Alternatives Considered

```markdown
I considered these alternatives before proposing:
1. **For Constitution**: Using AGENTS.md or README.md
- **Why it doesn't work**: These are documentation, not enforced principles. Agents don't consistently consult them before decisions.
2. **For Spec-Code Sync**: Manual reminders in prompts
- **Why it doesn't work**: Easy to forget. No enforcement. Specs drift over time.
3. **For GitHub Issues**: Manual task → issue conversion
- **Why it doesn't work**: Time-consuming. Error-prone. Loses dependency information.
4. **For Research/Evaluate**: Single-phase analysis (like Metis)
- **Why it doesn't work**: Risk of confirmation bias. Agent might cherry-pick data to support initial assumptions.
5. **For Physical Parallelization**: Using only logical `delegate_task`
- **Why it doesn't work for some cases**: Harder to debug. Can't see what each worker is doing in real-time. Less transparent.
Full implementation exists at: https://github.com/lofidonut3/oh-my-speckit

### Doctor Output (Optional)

```shell

```

### Additional Context

Full working implementation: https://github.com/lofidonut3/oh-my-speckit
Questions for Maintainers
1. Do these features align with oh-my-opencode's vision?
2. Would you prefer these as separate plugins or integrated features?
3. What are your thoughts on the philosophical overlap? (I'm still amazed we built such similar systems independently!)
---
**P.S.**: The convergent evolution here is wild—I honestly thought I was onto something unique until I saw v3.0.0 today. Great minds think alike, I suppose! 😊 Looking forward to hearing your thoughts and potentially collaborating on these features.

### Feature Type

Other

### Contribution

- [x] I'm willing to submit a PR for this feature
- [x] I can help with testing
- [x] I can help with documentation