Submit
All skills
Skillintermediate

plan example

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

Claude Code Knowledge Pack7/10/2026

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:

  • 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

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:

  • 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 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

● 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.

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

  1. Overview section - Brief intro to the language's philosophy and when to use this skill
  2. Quick reference guide - Essential tooling commands, common patterns, quick decision guides
  3. 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