---
title: "plan example"
description: "``` ▐▛███▜▌ Claude Code v2.0.32 ▝▜█████▛▘ Sonnet 4.5 · Claude Team ▘▘ ▝▝ ~/Projects/personal/claude-starter-kit ```"
type: skill
canonical_url: https://claudary.paisolsolutions.com/skills/plan-example
source: "Claudary"
difficulty: intermediate
author: "Claude Code Knowledge Pack"
date: 2026-07-10T11:31:58.508Z
license: CC-BY-4.0
attribution: "plan example — Claudary (https://claudary.paisolsolutions.com/skills/plan-example)"
---

# plan example
``` ▐▛███▜▌ Claude Code v2.0.32 ▝▜█████▛▘ Sonnet 4.5 · Claude Team ▘▘ ▝▝ ~/Projects/personal/claude-starter-kit ```

## Overview

```
  ▐▛███▜▌   Claude Code v2.0.32
 ▝▜█████▛▘  Sonnet 4.5 · Claude Team
   ▘▘ ▝▝    ~/Projects/personal/claude-starter-kit
```

> I have an idea to expand @./.claude/skills with language-specific development skills, but not sure how it would look like or if it would be beneficial to the template
users. Help me refine this idea and turn it into a well-defined design
  ⎿  Listed directory .claude/skills/

● I can help you explore this idea systematically! This is exactly what the plan skill is designed for - turning an idea into a well-formed design and
  implementation plan.

  Let me invoke that skill to guide us through refining this concept:

> The "plan" skill is running

> The "plan" skill is running

● Perfect! Your request falls into the Ideas and Prototypes category. Let me check the idea process workflow:

● Read(.claude/skills/plan/idea-process.md)
  ⎿  Read 63 lines

● Excellent! I'll follow this workflow to help refine your idea. Let me start:

  Task Progress:
  - [ ] Step 1: Understand the current state of the project
  - [ ] Step 2: Check the documentation
  - [ ] Step 3: Help refine the idea/feature
  - [ ] Step 4: Describe the design
  - [ ] Step 5: Document the design
  - [ ] Step 6: Create task-master PRD
  - [ ] Step 7: Parse the PRD with research
  - [ ] Step 8: Expand the new task into subtasks

  Step 1: Understand the current state of the project

  Let me examine the existing skills structure:

● serena - list_dir (MCP)(relative_path: ".claude/skills", recursive: true)
  ⎿ {
      "result": "Error: No active project. Ask the user to provide the project path or to select a project from this list of known projects: ['gh-arc', 'kotlin-faker', '
    ktchn8S']"
    }


● Read(.claude/skills/plan/skill.md)
  ⎿  Error reading file

● Read(.claude/skills/task-master-process/skill.md)
  ⎿  Error reading file

● Read(.claude/skills/test/skill.md)
  ⎿  Error reading file

● Search(pattern: ".claude/skills/**/skill.md")
  ⎿  Found 5 files (ctrl+o to expand)

● Search(pattern: ".claude/skills/**/*.md")
  ⎿  Found 7 files (ctrl+o to expand)

● Read(.claude/skills/plan/SKILL.md)
  ⎿  Read 29 lines

● Read(.claude/skills/test/SKILL.md)
  ⎿  Read 24 lines

● Read(.claude/skills/development-process/SKILL.md)
  ⎿  Read 15 lines

● Read(.claude/skills/document/SKILL.md)
  ⎿  Read 12 lines

● Read(.claude/skills/task-master-process/SKILL.md)
  ⎿  Read 11 lines

● Now let me check the documentation:

● Read(README.md)
  ⎿  Read 159 lines

● Bash(ls /home/sergio/Projects/personal/claude-starter-kit/docs 2>/dev/null || echo "docs directory not found")
  ⎿  docs directory not found

● Bash(find /home/sergio/Projects/personal/claude-starter-kit -name "CONTRIBUTING.md" -o -name "contributing.md" 2>/dev/null)
  ⎿  (No content)

● Perfect! Now I understand the current state. Let me update the progress and move to refining your idea:

  Task Progress:
  - [x] Step 1: Understand the current state of the project
  - [x] Step 2: Check the documentation
  - [ ] Step 3: Help refine the idea/feature
  - [ ] Step 4: Describe the design
  - [ ] Step 5: Document the design
  - [ ] Step 6: Create task-master PRD
  - [ ] Step 7: Parse the PRD with research
  - [ ] Step 8: Expand the new task into subtasks

  Current State Summary

  I've analyzed the existing skills structure:

  Existing Skills (Process-based):
  - plan: Idea → design → implementation plan workflow
  - development-process: Dependency management guidelines
  - document: Post-implementation documentation steps
  - test: Testing guidelines (with %LANGUAGE% placeholders)
  - task-master-process: Task Master workflow integration

  Key Observations:
  - Skills follow a consistent structure: SKILL.md with YAML frontmatter + optional workflow files
  - Already has language-awareness via %LANGUAGE% placeholders in test
  - Template is intentionally minimal and language-agnostic
  - No language-specific skills currently exist

  ---
  Step 3: Refining the Idea

  Let me ask my first question to understand your vision:

  Question 1: What programming languages are you primarily considering for language-specific development skills?

  Options:
  A) Popular web languages (JavaScript/TypeScript, Python, Go, Rust)
  B) Enterprise languages (Java, C#, Kotlin)
  C) System languages (C/C++, Rust, Go)
  D) All of the above - comprehensive language coverage
  E) Other (please specify)

> I'm thinking to start with Go, Python, Java, Kotlin and JS/TS

● Question 2: What types of language-specific guidance do you envision these skills providing?

  Options:
  A) Code style & conventions - Language idioms, formatting, naming conventions, project structure
  B) Testing strategies - Framework-specific testing patterns (pytest, Jest, JUnit, etc.)
  C) Tooling & ecosystem - Package managers, build tools, linters, formatters specific to each language
  D) Common patterns & anti-patterns - Language-specific design patterns, best practices, what to avoid
  E) All of the above - Comprehensive language-specific development guidance
  F) Something else - Please describe your vision

> E

● Question 3: How should these language-specific skills integrate with the existing process skills?

  Options:
  A) Separate standalone skills - Independent skills like go-development, python-development that users invoke directly
  B) Sub-skills of existing processes - Enhance existing skills (e.g., test would automatically load language-specific testing guidance based on project
  language)
  C) Hybrid approach - Both standalone skills AND automatic enhancement of existing process skills
  D) Context injection - Replace %LANGUAGE% placeholders with rich language-specific content when skills are invoked
  E) Other approach - Please describe

> Mostly C
The %LANGUAGE% placeholders would be replaced when a project is created from this template-repo. Then the *-process skills can both reference the particular skill for a
given language, and language-skills may also be triggered standalone.
The naming convention I'm thinking of is `lang-<language>`, i.e. `lang-go`, `lang-python`, etc.

● Question 4: How should language-specific skills be organized internally?

  Options:
  A) Single comprehensive file - One SKILL.md per language with all guidance (style, testing, tooling, patterns)
  B) Modular sections - Multiple files per language: lang-go/style.md, lang-go/testing.md, lang-go/tooling.md, lang-go/patterns.md
  C) Domain-focused structure - Organize by concern: lang-go/web-development.md, lang-go/cli-development.md, lang-go/testing-strategies.md
  D) Two-tier structure - Main SKILL.md with overview + separate detailed guides for specific topics
  E) Let the implementation decide - Start simple and evolve based on content needs

> D combined with B and C

● Question 5: How should process skills reference language-specific skills after %LANGUAGE% substitution?

  Options:
  A) Direct file imports - Use @ import syntax like @./../lang-go/testing.md in test/SKILL.md
  B) Skill invocation instructions - Add guidance like "For Go-specific testing patterns, invoke the lang-go skill"
  C) Inline content injection - Replace %LANGUAGE% placeholders with actual language-specific content copied into process skills
  D) Hybrid references - Brief inline guidance + links to full language skill documentation
  E) Other mechanism - Please describe

> D

● Question 6: What level of depth should language-specific skills provide?

  Options:
  A) Lightweight references - Quick checklists, tool names, links to official docs (keeps template lean)
  B) Practical guidelines - Essential patterns, common pitfalls, recommended tools with brief explanations
  C) Comprehensive guides - Detailed best practices, code examples, framework comparisons, architectural guidance
  D) Progressive depth - Start with essentials in main SKILL.md, provide deep-dives in separate files for those who need them
  E) Configurable depth - Let users choose during template-cleanup workflow what level of detail they want

> a combination of B and C
But keep it practical and to-the-point, avoid redundant details like framework comparisons or code examples that can be looked up by other means

● Question 7: How should the template-cleanup workflow handle language-specific skills?

  Options:
  A) Keep all languages - Include all 5 language skills (Go, Python, Java, Kotlin, JS/TS) in every project, regardless of LANGUAGE input
  B) Remove unused languages - Only keep the language skill(s) matching the LANGUAGE input, delete others
  C) Multi-language support - Allow multiple LANGUAGE values (e.g., "go,python") and keep only those skills
  D) Preserve with markers - Keep all languages but mark non-primary ones as "additional" or "reference"
  E) User choice - Add a workflow input asking which language skills to include

> B for now

● Question 8: How should language skills handle framework-specific guidance?

  Options:
  A) Framework-agnostic only - Focus on core language features, stdlib, and universal patterns (no Flask, Spring, React, etc.)
  B) Popular frameworks included - Cover 1-2 most popular frameworks per language (e.g., Django/Flask for Python, Spring for Java, React for JS/TS)
  C) Extensible framework sections - Create optional framework-specific files that can be added per project needs
  D) Framework detection - Template-cleanup workflow could detect frameworks from project files and inject relevant guidance
  E) Minimal framework mentions - Only reference frameworks when discussing testing/tooling, but keep focus on language itself

> a combination of A and C

● Perfect! I now have a clear picture of your vision. Let me move to the next step.

  Task Progress:
  - [x] Step 1: Understand the current state of the project
  - [x] Step 2: Check the documentation
  - [x] Step 3: Help refine the idea/feature
  - [ ] Step 4: Describe the design
  - [ ] Step 5: Document the design
  - [ ] Step 6: Create task-master PRD
  - [ ] Step 7: Parse the PRD with research
  - [ ] Step 8: Expand the new task into subtasks

  ---
  Step 4: Design Description - Part 1

  Overall Concept & Structure

  The language-specific skills feature extends the existing .claude/skills/ directory with dedicated skills for Go, Python, Java, Kotlin, and JavaScript/TypeScript. Each
  language skill follows the naming convention lang-<language> (e.g., lang-go, lang-python).

  Directory Structure:
  .claude/skills/
  ├── plan/
  ├── development-process/
  ├── document/
  ├── test/
  ├── task-master-process/
  ├── lang-go/
  │   ├── SKILL.md              # Overview + quick reference
  │   ├── style.md              # Code style & conventions
  │   ├── testing.md            # Testing strategies & tools
  │   ├── tooling.md            # Ecosystem & build tools
  │   ├── patterns.md           # Best practices & anti-patterns
  │   └── frameworks/           # Optional extensible section
  │       └── README.md         # How to add framework guides
  ├── lang-python/
  │   └── [same structure]
  ├── lang-java/
  │   └── [same structure]
  ├── lang-kotlin/
  │   └── [same structure]
  └── lang-typescript/
      └── [same structure]

  Does this structure look right so far?

> yes

● Step 4: Design Description - Part 2

  Integration with Existing Process Skills

  The existing process skills (test, development-process) will be enhanced to reference language-specific skills through a hybrid approach:

  Before template-cleanup:
  # test/SKILL.md
  Use %LANGUAGE% best practices and well-established %LANGUAGE% testing tools

  After template-cleanup (e.g., LANGUAGE=go):
  # test/SKILL.md
  Use Go best practices and well-established Go testing tools.

  For comprehensive Go testing guidance including table-driven tests,
  test coverage, and benchmark testing, see the `lang-go` skill
  (@./../lang-go/testing.md).

  Key Integration Points:
  1. Automatic placeholder replacement - The template-cleanup workflow replaces %LANGUAGE% with the actual language name
  2. Inline brief guidance - Process skills contain essential language-specific tips directly
  3. Deep-dive references - Links to full language skill docs using @ import syntax for detailed guidance
  4. Standalone invocation - Users can still invoke lang-go skill directly when they need language-specific help

  Does this integration approach look right?

> yes, but it should be a markdown link, not an import statement, i.e. see the `lang-go` skill at [skills/lang-go/testing.md](./../lang-go/testing.md)

● Excellent point! Let me correct that:

  After template-cleanup (e.g., LANGUAGE=go):
  # test/SKILL.md
  Use Go best practices and well-established Go testing tools.

  For comprehensive Go testing guidance including table-driven tests,
  test coverage, and benchmark testing, see the `lang-go` skill at
  [skills/lang-go/testing.md](./../lang-go/testing.md).

  This approach provides clear navigation without implying content injection.

  ---
  Step 4: Design Description - Part 3

  Language Skill Content Structure

  Each lang-<language>/SKILL.md serves as the entry point with:

  1. YAML frontmatter - Standard skill metadata:
  ---
  name: lang-go
  description: Go language-specific development guidance including style, testing, tooling, and best practices
  ---
  2. Overview section - Brief intro to the language's philosophy and when to use this skill
  3. Quick reference guide - Essential tooling commands, common patterns, quick decision guides
  4. Navigation to deep-dive sections - Links to detailed topic files:
    - Code style & conventions → style.md
    - Testing strategies → testing.md
    - Tooling & ecosystem → tooling.md
    - Patterns & anti-patterns → patterns.md
    - Optional frameworks → frameworks/README.md

  Content Philosophy:
  - Practical and to-the-point guidance
  - Focus on actionable insights, not encyclopedic knowledge
  - Assume Claude can look up API details via Context7/documentation
  - Emphasize what's unique or commonly misunderstood about each language

  Does this content structure look right?

> Yes, but description metadata should provide details on when to use the skill, i.e. "Use when ..."

● Perfect! Let me revise:

  ---
  name: lang-go
  description: Use when working with Go codebases to get guidance on Go-specific style conventions, testing strategies, tooling, and best practices
  ---

  This matches the pattern from existing skills like:
  - plan: "Use in pre-implementation (idea-to-design) stages..."
  - test: "Use whenever writing new or updating existing code..."

  ---
  Step 4: Design Description - Part 4

  Template-Cleanup Workflow Integration

  The existing .github/workflows/template-cleanup.yml will be extended:

  New Behavior:
  1. Language detection - Uses existing LANGUAGE input (e.g., "go", "python", "java", "kotlin", "typescript")
  2. Skill pruning - Removes all lang-* directories EXCEPT the one matching LANGUAGE
  3. Placeholder replacement - Updates process skills to referen

---

Source: [Claudary](https://claudary.paisolsolutions.com/skills/plan-example) · https://claudary.paisolsolutions.com