alpacalyzer-algo-trader: Command for Claude Code

Plan Feature Command

Decompose a high-level feature into well-formed, agent-sized GitHub issues with dependency ordering and Agent Metadata — ready for the orchestrator.

Usage

/plan-feature <feature_description>

Arguments:

• feature_description: A natural-language description of the feature to plan. Can be a sentence, a paragraph, or a reference to an existing issue/doc.

Argument Indexing

• Claude Code: Use $1 for the first argument (feature description, may be multi-word)
• OpenCode: Use $ARGUMENTS to get all arguments

Steps

1. Get Repo Info

git remote get-url origin

Parse owner and repo name.

2. Understand the Codebase Context

Read the key context files to understand what exists:

• AGENTS.md — architecture overview, component locations
• docs/architecture/overview.md — module structure, layering rules
• docs/principles.md — code invariants (if exists)

Scan the source directory to understand the current module structure.

3. Analyze the Feature

Break the feature description into concrete work items. For each, determine:

• What changes: Which files/modules are affected
• Scope: Is this a new module, modification to existing, or cross-cutting?
• Complexity: small (< 1 hour agent work), medium (1-3 hours), large (needs further decomposition)
• Dependencies: Does this require another piece to land first?
• Parallel safety: Can an agent work on this while other agents work on sibling issues?

4. Decomposition Rules

Follow these rules when breaking down work:

1. One issue = one agent session = one worktree. If a task requires touching more than 3-4 files across different modules, it's probably too big.
2. Large → split further. Any issue estimated as "large" must be decomposed into small/medium sub-issues. Agents work best with focused, bounded tasks.
3. Test-first is non-negotiable. Every issue must be testable. If you can't describe a test scenario, the issue is too vague.
4. Data models before consumers. If the feature needs new data models, that's issue #1. Code that uses those models depends on it.
5. Infrastructure before features. Config, schemas, migrations, shared utilities come before the features that use them.
6. Vertical slices over horizontal layers. Prefer "implement feature X end-to-end" over "add all database models, then add all API routes, then add all tests." But respect dependency ordering — if 3 features share a model, the model is its own issue.
7. Explicit acceptance criteria. Every issue needs concrete, checkable criteria. "Implement the thing" is not an acceptance criterion. "Function X returns Y when given Z" is.
8. No orphan issues. Every issue should be reachable from the dependency graph. If an issue has no dependents and no dependencies, question whether it belongs in this feature.