| name | feature-planning |
| description | Deep feature research and implementation planning for AI coding agent projects. Use this skill whenever a user asks about a feature they want to implement, improve, add, or design — especially in the context of AI coding agents, CLI tools, terminal agents, or LLM-powered developer tools. Triggers on: "I want to add X feature", "how do I implement X", "can we improve X", "I want to build X into my agent", "feature request for X", "how does X work in these tools", or any phrasing that implies implementing/improving a capability. This skill clones 13 reference repos, spawns sub-agents for deep per-repo research, runs an ultra-QA interview with the user, then produces a comprehensive implementation plan with code, pseudocode, test cases, benchmarks, and direct repo links — so the user can go from idea to working implementation with total confidence.
|
Feature Planning Skill
Comprehensive feature research + implementation planning using 13 reference repos as the knowledge base.
Reference Repositories
| Alias | Repo URL | Stack | What it teaches |
|---|
oh-my-openagent | https://github.com/code-yeongyu/oh-my-openagent | TypeScript / OpenCode plugin | Multi-agent orchestration, model routing, tmux sessions, delegate-task patterns |
opencode | https://github.com/anomalyco/opencode | TypeScript / Bun monorepo | Open-source AI coding agent architecture, provider abstraction, TUI |
oh-my-pi | https://github.com/can1357/oh-my-pi | TypeScript + Rust / Bun | 40+ providers, 32 tools, LSP+DAP ops, benchmarked edits, IDE wiring |
codebuff | https://github.com/CodebuffAI/codebuff | TypeScript / multi-agent | File picker + planner + editor + reviewer pipeline, beats Codex on evals |
codex | https://github.com/openai/codex | TypeScript / Node | OpenAI Codex CLI, sandboxed execution, hardened tool use |
claude-code | https://github.com/claude-code-best/claude-code | TypeScript / Node | Anthropic Claude Code CLI — official coding agent, todo system, session compaction, sub-agents |
pi-agent-rust | https://github.com/Dicklesworthstone/pi_agent_rust | Rust 2024 edition | High-perf Rust agent, SQLite sessions, SSE streaming, WASM extension security |
oh-my-Codex | https://github.com/Yeachan-Heo/oh-my-Codex | TypeScript / Codex plugin | Codex extension with hooks, guards, permission modes, multi-agent tools |
oh-my-codex | https://github.com/Yeachan-Heo/oh-my-codex | TypeScript / Codex plugin | Codex extension with approval modes, sandbox config, tool gating |
gajae-code | https://github.com/Yeachan-Heo/gajae-code | TypeScript + Rust / Bun | Structured workflow pipeline (deep-interview → ralplan → ultragoal), tmux-native sessions, Telegram notification SDK |
kimchi | https://github.com/getkimchi/kimchi | TypeScript / Node + Bun | Multi-model orchestration, Ferment cross-session plans, LSP integration, remote teleport, RTK token optimization |
crush | https://github.com/charmbracelet/crush | Go / Charm ecosystem | Go-based TUI agent with Bubble Tea, session workspaces, shared multi-client sessions, MCP + LSP integration, Agent Skills standard, auto-provider updates |
Workflow (follow this order every time)
Phase 1 — Clone & Sub-agent Research
When the skill is triggered, immediately clone all 13 repos (shallow --depth=1) and spawn one research sub-agent per repo. Each sub-agent gets the full repo and the feature request — its job is to autonomously explore the entire repo to find everything relevant. The sub-agent decides what to read; nothing is off-limits and nothing is assumed to be the right place to look.
Each sub-agent should:
- Map the repo first — list all files and directories to understand the full shape before diving in. No assumptions about where things live.
- Follow the feature signal — search for keywords, types, patterns, and concepts related to the requested feature across every file, every directory, every language. If a Rust file has relevant logic, read it. If a config YAML has relevant keys, read it. If a test file shows how a concept is used, read it. If a benchmark shows performance constraints, read it.
- Trace implementations end-to-end — when a relevant function/type/module is found, follow its call chain in both directions (callers and callees) until the full picture is clear. Don't stop at the first hit.
- Extract everything useful — architecture patterns, API surfaces, data structures, config hooks, test patterns, benchmark approaches, error handling strategies, extension points, anything that could inform the feature design.
- Return a structured summary (see Sub-agent Report Format below)
The sub-agent must NOT limit itself to any predefined set of files or folders. If it finds something unexpected in an unusual location, it should read it. Thoroughness is the goal.
Run sub-agents in parallel. Collect all 13 reports before continuing.
for repo in \
"https://github.com/code-yeongyu/oh-my-openagent" \
"https://github.com/anomalyco/opencode" \
"https://github.com/can1357/oh-my-pi" \
"https://github.com/CodebuffAI/codebuff" \
"https://github.com/openai/codex" \
"https://github.com/claude-code-best/claude-code" \
"https://github.com/Dicklesworthstone/pi_agent_rust" \
"https://github.com/Yeachan-Heo/oh-my-Codex" \
"https://github.com/Yeachan-Heo/oh-my-codex" \
"https://github.com/Yeachan-Heo/gajae-code" \
"https://github.com/getkimchi/kimchi" \
"https://github.com/QwenLM/qwen-code" \
"https://github.com/charmbracelet/crush"; do
git clone --depth=1 "$repo" /tmp/feature-research/$(basename $repo)
done
Sub-agent Report Format
Each sub-agent returns a structured block:
## [repo-name] Research Report
### Relevance Score: [HIGH / MEDIUM / LOW / NONE]
### Why relevant: [1-2 sentences]
### Key Files
- path/to/file.ts — [what it does re: the feature]
### Relevant Code Snippets
[short excerpts with file:line references]
### Architecture Pattern
[how this repo approaches the feature domain]
### Direct Links
- https://github.com/[org]/[repo]/blob/main/[file]#L[line]
### Gaps / What's Missing
[what this repo doesn't cover that the user might need]
Phase 2 — Present Per-Repo Report to User
After collecting sub-agent reports, present a consolidated Research Report to the user with one section per repo. Format:
# Feature Research: [FEATURE NAME]
## Summary
[2-3 sentence overview of what you found across all repos]
---
## 1. oh-my-openagent
[sub-agent report content]
## 2. opencode
...
## 7. pi-agent-rust
...
---
## Cross-Repo Patterns
[What approaches are consistent across repos — these are proven patterns]
## Unique Insights
[Interesting divergences or novel approaches from individual repos]
Phase 3 — Ultra QA Interview
After presenting the research report, enter a deep QA loop with the user. Ask questions in rounds — never dump all questions at once. Use this question bank, picking the most relevant ones for the feature at hand:
Round 1 — Scope & Goal
- What is the exact outcome you want after implementing this? (demo it to me in words)
- Is this a new feature or improving an existing one? If existing, what's broken/missing?
- Which repo(s) are you building in / most inspired by?
- What stack? (TypeScript, Rust, Python, other)
Round 2 — Constraints & Context
- What existing code does this feature touch or depend on?
- Are there performance requirements? (latency targets, memory limits, throughput)
- Security constraints? (sandboxing, capability gating, trust levels)
- Will this need to work across multiple LLM providers or just one?
Round 3 — Design Preferences
- Do you prefer a plugin/extension architecture or embedded implementation?
- Should this be synchronous, async, or streaming?
- How should failures be handled? (silent fallback, hard error, user prompt)
- How will users configure or toggle this feature?
Round 4 — Testing & Quality
- What does a successful implementation look like? How will you verify it?
- Are there existing tests in the repos we can adapt?
- Any edge cases you're already worried about?
Round 5 — Stretch Goals
- What would a "10x better" version of this look like?
- Are there benchmark targets you want to hit?
- Future integrations you want to leave room for?
Keep asking follow-up questions until you have clear answers to at minimum Round 1 and Round 2. Rounds 3–5 can be inferred from research if the user is in a hurry.
Phase 4 — Comprehensive Implementation Plan
After the QA interview, produce the final plan. This is the deliverable the user keeps. It must include ALL of the following sections:
# Implementation Plan: [FEATURE NAME]
> Generated from research across 13 repos + user interview
> Goal: [User's stated goal in 1 sentence]
---
## 1. Executive Summary
[3-5 sentences: what we're building, why this approach, expected outcome]
---
## 2. Architecture Decision
### Chosen Approach
[Which pattern from the research repos we're following, and why]
### Alternatives Considered
| Approach | Source Repo | Pros | Cons | Decision |
|----------|-------------|------|------|----------|
---
## 3. Data Structures & Types
```typescript // or Rust, Python, etc.
// Core types for the feature
interface FeatureConfig {
// ...
}
4. Pseudocode — Core Algorithm
FUNCTION implementFeature(input):
// Step-by-step logic in plain pseudocode
// No language-specific syntax
// Shows all branches and edge cases
5. Implementation Code
File: [path/to/new-or-modified-file]
File: [path/to/another-file]
6. Configuration & Wiring
[How to register/hook the feature into the existing system]
[Config file changes, env vars, flags]
7. Repo References
Direct links to the most relevant code in each source repo:
8. Test Cases
Happy Path Tests
describe('[feature]', () => {
it('should [happy case 1]', async () => {
});
it('should [happy case 2]', async () => {
});
});
Edge Cases
it('should handle [edge case: empty input]', ...);
it('should handle [edge case: provider failure]', ...);
it('should handle [edge case: concurrent calls]', ...);
it('should handle [edge case: large payload]', ...);
it('should handle [edge case: timeout]', ...);
Integration Tests
9. Benchmarks
What to Measure
| Metric | Baseline | Target | How to Measure |
|---|
| Latency (p50) | - | [Xms] | [method] |
| Latency (p99) | - | [Xms] | [method] |
| Memory delta | - | [XMB] | [method] |
| Throughput | - | [X/s] | [method] |
Benchmark Code
10. Migration / Rollout
[If improving existing feature: how to migrate without breaking changes]
[Feature flags, gradual rollout, deprecation path]
11. Known Limitations & Future Work
12. Success Criteria Checklist
---
## Quality Standards
The plan must meet these bars before presenting to the user:
- **No broken links** — all GitHub links must point to real files in the cloned repos
- **No vague pseudocode** — every step in the pseudocode must be implementable
- **No placeholder tests** — every test case must have real setup/act/assert
- **Benchmark section is never empty** — even if targets are TBD, the measurement method must be specified
- **Every architectural choice has a "why"** referencing a source repo
- **The user should be able to hand this plan to a junior engineer and get working code back**
---
## References
See `references/repo-summaries.md` for static summaries of all 13 repos (useful when cloning is slow or unavailable).
