/cg-devplan

name: cg-devplan
description: Generate a structured development plan (devplan) for software projects. Use this skill whenever the user wants to plan a new app, feature, or project — including phrases like "plan this app", "create a devplan", "help me architect", "I want to build X", "let's plan out Y", "write a development plan", or any request that involves scoping, structuring, or roadmapping a software project before implementation. Also trigger when the user describes an app idea (even casually) and expects a structured plan as output. This skill is specifically designed for indie developers building macOS, iOS, Android, Windows, and cross-platform desktop/mobile applications.

Devplan Skill

Generate development plans that Claude Code can directly follow to build a project. The devplan is not a tutorial for the developer — it is an instruction document for Claude Code.

Who is this for

Indie developers who work with Claude Code. They describe an app idea in a few sentences, answer some clarifying questions, and receive a devplan file they drop into their project root. Then they tell Claude Code "follow this plan" and development begins.

Core philosophy

The devplan must be:

• **An instruction document for Claude Code**, not a guide for the developer
• **Architecture-focused**, not code-focused — describe what to build and how to structure it, never include code snippets
• **Platform-aware** — account for real constraints of the target platform (sandboxing, permissions, API limitations, store requirements)
• **Atomic in phases** — each phase should be completable in a single Claude Code session
• **Opinionated about quality** — bake in engineering standards so the developer doesn't repeat them every time
• **Testable by default** — every phase has test criteria, not as afterthought but as definition of done

Workflow

Step 1: Collect the brief

The user provides a short description of what they want to build (3-10 sentences is typical). Accept whatever they give — don't demand a specific format.

**Important:** Determine whether this is a greenfield project or a feature addition to an existing codebase. If existing code is present, read the codebase first and document the current state before planning changes.

Step 2: Ask clarifying questions

Before writing anything, ask questions to fill gaps. Ask only what you genuinely need — don't ask things you can reasonably infer. Typical gaps to probe:

• **Target platform(s)**: macOS, iOS, Android, Windows, cross-platform? Which framework if cross-platform (Tauri, Electron, Flutter, React Native)?
• **Core interaction model**: Menu bar app? Floating window? Full window? Widget? System tray? Background service?
• **Data story**: Local-only? Cloud sync? What kind of data, how much, how sensitive?
• **Distribution**: App Store, direct download, both? Open source?
• **Existing constraints**: Must it integrate with specific APIs, tools, or ecosystems? Any hard tech stack preferences?
• **Multi-language support**: Will the app need localization? Even if the user says "no" or "just English for now", note this decision in the plan — retrofitting localization into a codebase that wasn't designed for it is painful. If yes, which languages? This affects string architecture from day one.
• **Theming / appearance**: Dark mode only? Light + dark? User-customizable themes? System appearance following? This must be decided upfront because it shapes the entire styling architecture.
• **Prior art / inspiration**: Any existing app this is inspired by or competing with?

Do NOT ask about:

• Time estimates — they are meaningless with AI-assisted development
• Team size — assume solo indie dev with Claude Code
• Budget — irrelevant at planning stage
• Detailed UI mockups — architecture first, UI emerges from implementation

Step 3: Generate the devplan

Write the devplan as a markdown file. The structure is below.

---

Devplan structure

# [App Name] — Development Plan

## Overview
What the app does in 2-3 sentences. Who it's for. Why it exists.

## Current State (if adding to existing project)
- What exists: [brief description of current codebase, key modules, patterns in use]
- What changes: [which areas this plan modifies or extends]
- What must not break: [existing functionality that must be preserved]
(Omit this section for greenfield projects.)

## Platform & Stack
- Target: [macOS / iOS / Android / cross-platform]
- Framework: [SwiftUI / UIKit / Jetpack Compose / Tauri / Flutter / etc.]
- Language: [Swift / Kotlin / Rust / Dart / TypeScript / etc.]
- Key dependencies: [list only critical ones with brief reason — log each choice in DECISIONS.md]
- Architecture: [MVVM / MVC / Clean Architecture / etc. — pick one and justify briefly]
- Design pattern notes: [Strategy, Observer, Coordinator — only if project warrants specific patterns]
- Localization: [None / Prepared for future / Active — list languages. If "prepared for future": all user-facing strings must go through a localization layer from day one, even if only one language ships initially]
- Theming: [Dark only / Light+Dark / System-following / User-customizable. All colors, fonts, spacing, and visual tokens must be defined in a central theme system — no hardcoded colors or font names anywhere in the codebase]

## Data Model
Core entities and their relationships. No code — describe in plain language.
- What are the main data objects?
- How do they relate to each other? (one-to-many, many-to-many, etc.)
- Where is data persisted? (SQLite, Core Data, SwiftData, Room, file system, UserDefaults/SharedPreferences)
- What is the migration strategy when the schema changes?
- What data is sensitive and needs encryption or secure storage?

## Constraints & Platform Considerations
Real, actionable constraints the developer will hit. Examples:
- macOS: Sandbox restrictions, entitlements needed, Accessibility API permissions, notarization requirements
- iOS: App St