Skip to content

Commit 78730dc

Browse files
quangdang46claude
quangdang46
and
claude
committed
docs: add oh-my-claudecode + oh-my-codex to research, update skill to 9 repos
Research additions: - oh-my-claudecode (HIGH): hook-based defense-in-depth, 11 lifecycle events, worker RBAC, OMC_SECURITY=strict master switch, verification tiers (LIGHT/STANDARD/THOROUGH), SSRF guard, execution mode mutual exclusion, session isolation - oh-my-codex (MEDIUM): pass-through wrapper translating upstream permission flags per CLI backend (Codex/Gemini/Claude), madmax auto-isolation, MCP path traversal defense, workflow exclusivity Skill update: - feature-planning: expanded from 7 to 9 reference repos - Added oh-my-claudecode and oh-my-codex to repo table and clone script Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1 parent 8b2f659 commit 78730dc

2 files changed

Lines changed: 428 additions & 2 deletions

File tree

‎.agents/skills/feature-planning/SKILL.md‎

Lines changed: 337 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,337 @@
1+
---
2+
name: feature-planning
3+
description: >
4+
Deep feature research and implementation planning for AI coding agent projects. Use this skill
5+
whenever a user asks about a feature they want to implement, improve, add, or design — especially
6+
in the context of AI coding agents, CLI tools, terminal agents, or LLM-powered developer tools.
7+
Triggers on: "I want to add X feature", "how do I implement X", "can we improve X", "I want to
8+
build X into my agent", "feature request for X", "how does X work in these tools", or any phrasing
9+
that implies implementing/improving a capability. This skill clones 7 reference repos, spawns
10+
sub-agents for deep per-repo research, runs an ultra-QA interview with the user, then produces a
11+
comprehensive implementation plan with code, pseudocode, test cases, benchmarks, and direct repo
12+
links — so the user can go from idea to working implementation with total confidence.
13+
---
14+
15+
# Feature Planning Skill
16+
17+
Comprehensive feature research + implementation planning using 9 reference repos as the knowledge base.
18+
19+
## Reference Repositories
20+
21+
| Alias | Repo URL | Stack | What it teaches |
22+
|-------|----------|-------|-----------------|
23+
| `oh-my-openagent` | https://github.com/code-yeongyu/oh-my-openagent | TypeScript / OpenCode plugin | Multi-agent orchestration, model routing, tmux sessions, delegate-task patterns |
24+
| `opencode` | https://github.com/anomalyco/opencode | TypeScript / Bun monorepo | Open-source AI coding agent architecture, provider abstraction, TUI |
25+
| `oh-my-pi` | https://github.com/can1357/oh-my-pi | TypeScript + Rust / Bun | 40+ providers, 32 tools, LSP+DAP ops, benchmarked edits, IDE wiring |
26+
| `codebuff` | https://github.com/CodebuffAI/codebuff | TypeScript / multi-agent | File picker + planner + editor + reviewer pipeline, beats Claude Code on evals |
27+
| `codex` | https://github.com/openai/codex | TypeScript / Node | OpenAI Codex CLI, sandboxed execution, hardened tool use |
28+
| `claude-code` | https://github.com/claude-code-best/claude-code | TypeScript / Bun | CCB — decompiled Claude Code with Pipe IPC, ACP, remote control, monitoring |
29+
| `pi-agent-rust` | https://github.com/Dicklesworthstone/pi_agent_rust | Rust 2024 edition | High-perf Rust agent, SQLite sessions, SSE streaming, WASM extension security |
30+
| `oh-my-claudecode` | https://github.com/Yeachan-Heo/oh-my-claudecode | TypeScript / Claude Code plugin | Claude Code extension with hooks, guards, permission modes, multi-agent tools |
31+
| `oh-my-codex` | https://github.com/Yeachan-Heo/oh-my-codex | TypeScript / Codex plugin | Codex extension with approval modes, sandbox config, tool gating |
32+
33+
---
34+
35+
## Workflow (follow this order every time)
36+
37+
### Phase 1 — Clone & Sub-agent Research
38+
39+
When the skill is triggered, immediately clone all 9 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.
40+
41+
Each sub-agent should:
42+
43+
1. **Map the repo first** — list all files and directories to understand the full shape before diving in. No assumptions about where things live.
44+
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.
45+
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.
46+
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.
47+
5. **Return a structured summary** (see **Sub-agent Report Format** below)
48+
49+
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.
50+
51+
Run sub-agents in parallel. Collect all 9 reports before continuing.
52+
53+
```bash
54+
# Clone command template
55+
for repo in \
56+
"https://github.com/code-yeongyu/oh-my-openagent" \
57+
"https://github.com/anomalyco/opencode" \
58+
"https://github.com/can1357/oh-my-pi" \
59+
"https://github.com/CodebuffAI/codebuff" \
60+
"https://github.com/openai/codex" \
61+
"https://github.com/claude-code-best/claude-code" \
62+
"https://github.com/Dicklesworthstone/pi_agent_rust" \
63+
"https://github.com/Yeachan-Heo/oh-my-claudecode" \
64+
"https://github.com/Yeachan-Heo/oh-my-codex"; do
65+
git clone --depth=1 "$repo" /tmp/feature-research/$(basename $repo)
66+
done
67+
```
68+
69+
#### Sub-agent Report Format
70+
71+
Each sub-agent returns a structured block:
72+
73+
```
74+
## [repo-name] Research Report
75+
76+
### Relevance Score: [HIGH / MEDIUM / LOW / NONE]
77+
### Why relevant: [1-2 sentences]
78+
79+
### Key Files
80+
- path/to/file.ts — [what it does re: the feature]
81+
82+
### Relevant Code Snippets
83+
[short excerpts with file:line references]
84+
85+
### Architecture Pattern
86+
[how this repo approaches the feature domain]
87+
88+
### Direct Links
89+
- https://github.com/[org]/[repo]/blob/main/[file]#L[line]
90+
91+
### Gaps / What's Missing
92+
[what this repo doesn't cover that the user might need]
93+
```
94+
95+
---
96+
97+
### Phase 2 — Present Per-Repo Report to User
98+
99+
After collecting sub-agent reports, present a consolidated **Research Report** to the user with one section per repo. Format:
100+
101+
```
102+
# Feature Research: [FEATURE NAME]
103+
104+
## Summary
105+
[2-3 sentence overview of what you found across all repos]
106+
107+
---
108+
109+
## 1. oh-my-openagent
110+
[sub-agent report content]
111+
112+
## 2. opencode
113+
...
114+
115+
## 7. pi-agent-rust
116+
...
117+
118+
---
119+
120+
## Cross-Repo Patterns
121+
[What approaches are consistent across repos — these are proven patterns]
122+
123+
## Unique Insights
124+
[Interesting divergences or novel approaches from individual repos]
125+
```
126+
127+
---
128+
129+
### Phase 3 — Ultra QA Interview
130+
131+
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:
132+
133+
**Round 1 — Scope & Goal**
134+
- What is the exact outcome you want after implementing this? (demo it to me in words)
135+
- Is this a new feature or improving an existing one? If existing, what's broken/missing?
136+
- Which repo(s) are you building in / most inspired by?
137+
- What stack? (TypeScript, Rust, Python, other)
138+
139+
**Round 2 — Constraints & Context**
140+
- What existing code does this feature touch or depend on?
141+
- Are there performance requirements? (latency targets, memory limits, throughput)
142+
- Security constraints? (sandboxing, capability gating, trust levels)
143+
- Will this need to work across multiple LLM providers or just one?
144+
145+
**Round 3 — Design Preferences**
146+
- Do you prefer a plugin/extension architecture or embedded implementation?
147+
- Should this be synchronous, async, or streaming?
148+
- How should failures be handled? (silent fallback, hard error, user prompt)
149+
- How will users configure or toggle this feature?
150+
151+
**Round 4 — Testing & Quality**
152+
- What does a successful implementation look like? How will you verify it?
153+
- Are there existing tests in the repos we can adapt?
154+
- Any edge cases you're already worried about?
155+
156+
**Round 5 — Stretch Goals**
157+
- What would a "10x better" version of this look like?
158+
- Are there benchmark targets you want to hit?
159+
- Future integrations you want to leave room for?
160+
161+
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.
162+
163+
---
164+
165+
### Phase 4 — Comprehensive Implementation Plan
166+
167+
After the QA interview, produce the final plan. This is the deliverable the user keeps. It must include ALL of the following sections:
168+
169+
---
170+
171+
```markdown
172+
# Implementation Plan: [FEATURE NAME]
173+
> Generated from research across 9 repos + user interview
174+
> Goal: [User's stated goal in 1 sentence]
175+
176+
---
177+
178+
## 1. Executive Summary
179+
[3-5 sentences: what we're building, why this approach, expected outcome]
180+
181+
---
182+
183+
## 2. Architecture Decision
184+
### Chosen Approach
185+
[Which pattern from the research repos we're following, and why]
186+
187+
### Alternatives Considered
188+
| Approach | Source Repo | Pros | Cons | Decision |
189+
|----------|-------------|------|------|----------|
190+
191+
---
192+
193+
## 3. Data Structures & Types
194+
195+
```typescript // or Rust, Python, etc.
196+
// Core types for the feature
197+
interface FeatureConfig {
198+
// ...
199+
}
200+
```
201+
202+
---
203+
204+
## 4. Pseudocode — Core Algorithm
205+
206+
```
207+
FUNCTION implementFeature(input):
208+
// Step-by-step logic in plain pseudocode
209+
// No language-specific syntax
210+
// Shows all branches and edge cases
211+
```
212+
213+
---
214+
215+
## 5. Implementation Code
216+
217+
### File: [path/to/new-or-modified-file]
218+
```typescript
219+
// Full implementation code
220+
// With inline comments explaining non-obvious choices
221+
// References to source repos where patterns were borrowed
222+
```
223+
224+
### File: [path/to/another-file]
225+
```typescript
226+
// ...
227+
```
228+
229+
---
230+
231+
## 6. Configuration & Wiring
232+
[How to register/hook the feature into the existing system]
233+
[Config file changes, env vars, flags]
234+
235+
---
236+
237+
## 7. Repo References
238+
239+
Direct links to the most relevant code in each source repo:
240+
241+
| Feature Aspect | Repo | File | Link |
242+
|----------------|------|------|------|
243+
| [aspect] | oh-my-openagent | src/agents/... | https://github.com/... |
244+
| [aspect] | codebuff | packages/... | https://github.com/... |
245+
| ... | | | |
246+
247+
---
248+
249+
## 8. Test Cases
250+
251+
### Happy Path Tests
252+
```typescript
253+
describe('[feature]', () => {
254+
it('should [happy case 1]', async () => {
255+
// setup
256+
// act
257+
// assert
258+
});
259+
260+
it('should [happy case 2]', async () => {
261+
// ...
262+
});
263+
});
264+
```
265+
266+
### Edge Cases
267+
```typescript
268+
it('should handle [edge case: empty input]', ...);
269+
it('should handle [edge case: provider failure]', ...);
270+
it('should handle [edge case: concurrent calls]', ...);
271+
it('should handle [edge case: large payload]', ...);
272+
it('should handle [edge case: timeout]', ...);
273+
```
274+
275+
### Integration Tests
276+
```typescript
277+
// End-to-end test that exercises the full flow
278+
```
279+
280+
---
281+
282+
## 9. Benchmarks
283+
284+
### What to Measure
285+
| Metric | Baseline | Target | How to Measure |
286+
|--------|----------|--------|----------------|
287+
| Latency (p50) | - | [Xms] | [method] |
288+
| Latency (p99) | - | [Xms] | [method] |
289+
| Memory delta | - | [XMB] | [method] |
290+
| Throughput | - | [X/s] | [method] |
291+
292+
### Benchmark Code
293+
```typescript
294+
// Benchmark harness adapted from oh-my-pi / pi-agent-rust patterns
295+
```
296+
297+
---
298+
299+
## 10. Migration / Rollout
300+
[If improving existing feature: how to migrate without breaking changes]
301+
[Feature flags, gradual rollout, deprecation path]
302+
303+
---
304+
305+
## 11. Known Limitations & Future Work
306+
- [ ] [Thing not covered in this plan]
307+
- [ ] [Stretch goal for v2]
308+
- [ ] [Integration left for later]
309+
310+
---
311+
312+
## 12. Success Criteria Checklist
313+
- [ ] Core happy path works end-to-end
314+
- [ ] All edge case tests pass
315+
- [ ] Performance meets targets from Section 9
316+
- [ ] No regressions in existing tests
317+
- [ ] [User's specific success criterion from interview]
318+
```
319+
320+
---
321+
322+
## Quality Standards
323+
324+
The plan must meet these bars before presenting to the user:
325+
326+
- **No broken links** — all GitHub links must point to real files in the cloned repos
327+
- **No vague pseudocode** — every step in the pseudocode must be implementable
328+
- **No placeholder tests** — every test case must have real setup/act/assert
329+
- **Benchmark section is never empty** — even if targets are TBD, the measurement method must be specified
330+
- **Every architectural choice has a "why"** referencing a source repo
331+
- **The user should be able to hand this plan to a junior engineer and get working code back**
332+
333+
---
334+
335+
## References
336+
337+
See `references/repo-summaries.md` for static summaries of all 9 repos (useful when cloning is slow or unavailable).

0 commit comments

Comments
 (0)