feature-planning

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:

1. Map the repo first — list all files and directories to understand the full shape before diving in. No assumptions about where things live.
2. 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.
3. 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.
4. 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.
5. 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.

# Clone command template
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]

// Full implementation code
// With inline comments explaining non-obvious choices
// References to source repos where patterns were borrowed

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:

Feature Aspect	Repo	File	Link
[aspect]	oh-my-openagent	src/agents/...	https://github.com/...
[aspect]	codebuff	packages/...	https://github.com/...
...

---

8. Test Cases

Happy Path Tests

describe('[feature]', () => {
  it('should [happy case 1]', async () => {
    // setup
    // act
    // assert
  });

  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

// End-to-end test that exercises the full flow

---

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

// Benchmark harness adapted from oh-my-pi / pi-agent-rust patterns

---

10. Migration / Rollout

[If improving existing feature: how to migrate without breaking changes] [Feature flags, gradual rollout, deprecation path]

---

11. Known Limitations & Future Work

• [Thing not covered in this plan]
• [Stretch goal for v2]
• [Integration left for later]

---

12. Success Criteria Checklist

• Core happy path works end-to-end
• All edge case tests pass
• Performance meets targets from Section 9
• No regressions in existing tests
• [User's specific success criterion from interview]

---

## 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).