codeplanner

Files (1)

• SKILL.md

SKILL.md (first lines)

---
allowed-tools: Bash(git:*), Bash(tree:*), Bash(ls:*), Bash(grep:*), Bash(cat:*), Bash(find:*), Bash(gh:*), mcp__memory-server_*, FileSystem
description: Plan and analyze code tasks with comprehensive project understanding
argument-hint: github ticket id | task description
hooks:
  PreToolUse:
    - matcher: "TodoWrite"
      hooks:
        - type: command
          command: sh
          args:
            - "-c"
            - |
              echo 'codePlanner does not use TODO lists. Capture the plan in taskFindings.md instead.' >&2
              exit 2
---

# Purpose

Understand the code and requirements we are working on. Supports single or
multiple requirements with separate reports for each.

## Grok supervises Composer

Parent writes the plan. Composer may gather, not decide.

Delegate Phase 1 and Step 3.2 (tree, git context, relevant file reads) to Task
(`explore` or `generalPurpose`, `model: composer-2.5-fast`). Ask for a file map
plus relevant excerpts — not a plan, not a complexity score.

Parent keeps: requirement parsing, complexity score, architecture, acceptance
criteria, Validation section, and writing `taskFindings.md`. Never let Composer
write the plan file.

## Arguments

- One or more requirements: Can be GitHub ticket IDs, task descriptions, or a
  mix. Multiple requirements should be comma-separated or on separate lines.

---

# Phase 1: Project Context (Run Once)

Gather shared context before processing any requirements.

## Commands to run

- Current directory: `pwd`
- Project structure: `tree -L 3 -I 'node_modules|.git'`

### Git context (if applicable)

- Git status: `git status 2>/dev/null || echo "Not a git repository"`
- Current branch:
  `git branch --show-current 2>/dev/null || echo "Not a git repository"`
- Recent commits:
  `git log --oneline -5 2>/dev/null || echo "Not a git repository"`
- Remote info: `git remote -v 2>/dev/null || echo "Not a git repository"`
- Git files: `git ls-files 2>/dev/null || echo "Not a git repository"`

### Memory lookup

- Check memory-server for any project-level memories relevant to the codebase.

### Output

Store this context mentally - it applies to ALL requirements.

---

# Phase 2: Parse Requirements

From $ARGUMENT, extract the list of requirements.

- Split by comma, newline, or explicit numbering (1. 2. 3.)
- Each item becomes a separate requirement to process
- If only one requirement exists, treat it as a list of one

**Example inputs:**

- Single: `123` or `Add dark mode`
- Multiple: `123, 456, Add caching` or `123\n456\nAdd caching`

---

# Phase 3: Process Each Requirement (Loop)

For EACH requirement in the list, execute the following steps independently.

## Step 3.1: Understand the Requirement

- If GitHub Ticket ID: fetch details using `gh issue view <id>` or the GitHub
  Project Work Planner skill
- If task description: parse and understand the ask
- If both: combine ticket details with additional context

## Step 3.2: Read Relevant Code

- Read code files relevant to THIS specific requirement
- Understand adjacent files structure and style if creating new files
- If requirement involves bugs: use **triage** agent to investigate

## Step 3.3: Intelligence Gathering (per-requirement)

- Memory server: check for memories specific to this requirement's domain
- Web search: use **web-search-specialist** agent if needed for this requirement

## Step 3.4: Determine Output Location

- Directory name: Short name, max 3 words in kebab-case
- Check if upgrading existing functionality:
  - For upgrades: move existing docs to versioned directory (v1) and write new
    in `taskNotes/{directory-name}/`
  - For new: create fresh directory
- Path: `taskNotes/{directory-name}/taskFindings.md`

## Step 3.5: Create Plan

Write the plan in the following format. Enter plan mode ONLY in interactive mode —

From PrashamTrivedi/CursorPlugin, MIT.

More from PrashamTrivedi/CursorPlugin