Doodle Feature Creator

Overview

This skill enables creating and managing experimental features in the Doodle project. The Doodle project is a feature-based, language-agnostic experimental playground where each feature lives in its own folder under features/ and can use any appropriate programming language.

Core Philosophy: Flexibility over rigidity. Features adapt to their needs rather than conforming to strict templates.

When to Use This Skill

Invoke this skill when the user:

1. •

   Explicitly mentions "doodle"

   • •"calculator doodle 만들어줘"
   • •"Create a new doodle for..."
2. •

   Requests adding to features folder

   • •"features/에 새 프로젝트 추가"
   • •"Add a new feature to the project"
3. •

   Specifies a language for experimental work

   • •"Python으로 웹스크래퍼 만들어줘"
   • •"Go로 CLI 도구 구현하고 싶어"
4. •

   Continues work on existing features

   • •"hellojava에 기능 추가해줘"
   • •"calculator-js 개선하자"

Quick Start Workflow

When a user requests a new feature:

1. •

   Check for existing feature

   bash

   ls features/ | grep feature-name
   

   • •If exists: Continue working in that folder
   • •If new: Create appropriate structure
2. •

   Determine language and structure

   • •From explicit user request: "in Python", "using Go"
   • •From feature name suffix: "calculator-js", "algorithms-python"
   • •Default: Ask user or infer from context
3. •

   Create feature folder

   • •Naming: {feature-name}-{language} (e.g., web-server-go)
   • •Java often omits suffix: hellojava, collections-utils
4. •

   Start with TDD

   • •Write test files first
   • •Define expected behavior
   • •Implement to make tests pass
5. •

   Create comprehensive README

   • •Follow structure in references/project_conventions.md
   • •Include language, purpose, usage, tests

Core Capabilities

1. Feature Folder Management

When creating or working with features:

Check if feature exists:

# Look for existing feature folder
ls features/ | grep {feature-name}

If exists:

• •Inform user: "Feature folder already exists, continuing work..."
• •Work within existing structure
• •Add or modify files as needed

If new:

• •Create folder with appropriate naming
• •Set up language-specific structure
• •Initialize with tests and README

2. Language-Specific Structure Creation

Adapt structure based on language. Reference references/project_conventions.md for patterns:

JavaScript:

• •package.json with test script
• •Implementation file(s)
• •test.js with custom runner
• •Minimal dependencies

Python:

• •test_{feature}.py (often combined impl + tests)
• •No external dependencies preferred
• •Use stdlib for simplicity

Go:

• •go.mod with module path
• •Package directory structure
• •*_test.go test files
• •Standard Go testing

Java/Gradle:

• •Multi-module Gradle project
• •settings.gradle.kts, app/build.gradle.kts
• •Standard src/main/java and src/test/java layout
• •JUnit 5 for testing

Key Principle: Consult references/language_examples.md for concrete examples, but adapt as needed for the specific feature.

3. TDD Implementation

Always follow Test-Driven Development:

1. •

   Write tests first

   • •Define what the feature should do
   • •Create test cases for expected behavior
   • •Include edge cases
2. •

   Implement functionality

   • •Make tests pass
   • •Keep implementation simple
   • •Follow language idioms
3. •

   Refactor

   • •Improve code quality
   • •Keep tests green
   • •Document as you go

4. README Generation

Every feature must have a comprehensive README. Use this structure:

# Feature Name (Language)

**Language**: {Language}
**Purpose**: {Brief description}
**Status**: 🚧 In Progress / ✅ Complete

## Overview
{What this feature does and why}

## Features
- [ ] Feature 1
- [ ] Feature 2

## Quick Start
### Prerequisites
- {Language version, tools}

### Installation
```bash
cd features/{feature-name}
{install commands}

Running Tests

{test command}

Usage

{Code examples}

Test Coverage

{Description of tests}

Project Structure

{feature-name}/
├── ...

Future Plans

• • ...

Development Notes

{Any special considerations}

Adapt sections based on feature complexity and language.

### 5. Naming Conventions

Follow established patterns from `references/project_conventions.md`:

**Feature Folders:**
- Lowercase kebab-case
- Language suffix: `-js`, `-python`, `-go`
- Java often plain: `hellojava`, `collections-utils`
- Examples: `calculator-js`, `ascii-art-go`, `algorithms-python`

**Files:**
- JavaScript: camelCase or snake_case for files
- Python: snake_case for everything
- Go: lowercase package names
- Java: PascalCase for classes, match package structure

**Packages/Modules:**
- Go: `github.com/homveloper/doodle/features/{feature-name}`
- Java: Match folder name (no hyphens): `hellojava`, `collectionsutils`

### 6. CI/CD Awareness

Be aware of GitHub Actions testing:

**Currently Supported:**
- Node.js: 18.x, 20.x, 22.x
- Python: 3.9, 3.10, 3.11, 3.12

**Can Be Added:**
- Go testing
- Java/Gradle testing

When appropriate, suggest adding CI/CD support for new languages.

## Workflow

When handling a feature request:

1. **Understand the request**
   - What feature?
   - Which language? (explicit or infer)
   - New or existing?

2. **Check existing features**
   - Look in `features/` folder
   - Check for similar or same-named features
   - Decide: new feature or continue existing

3. **Determine structure**
   - Consult `references/project_conventions.md` for patterns
   - Look at `references/language_examples.md` for similar examples
   - Adapt based on feature requirements

4. **Create files**
   - Start with test files (TDD)
   - Create implementation files
   - Add configuration files (package.json, go.mod, etc.)
   - Generate comprehensive README

5. **Verify setup**
   - Ensure test commands work
   - Check file structure makes sense
   - Confirm README is complete

6. **Communicate clearly**
   - Tell user what was created
   - Show file structure
   - Explain next steps
   - Provide test command

## Best Practices

### Flexibility First
- Don't force rigid templates
- Adapt to feature needs
- Use references as guides, not rules
- Each feature is an experiment

### TDD Always
- Tests define behavior
- Write tests before implementation
- Keep tests simple and clear
- Run tests frequently

### Minimal Dependencies
- Prefer standard library
- Zero dependencies ideal for simple features
- Document why external deps are needed
- Keep it simple

### Complete Documentation
- README is mandatory
- Include usage examples
- Document prerequisites
- Explain design decisions

### Language Idioms
- Follow language-specific conventions
- Use established patterns
- Write idiomatic code
- Respect language best practices

## Common Scenarios

### Scenario 1: Brand New Feature

User: "Go로 HTTP 서버 doodle 만들어줘"

Steps:

1. •Check features/http-server-go doesn't exist
2. •Create features/http-server-go/
3. •Create go.mod
4. •Create server/ package with server.go and server_test.go
5. •Write tests first (TDD)
6. •Implement basic HTTP server
7. •Create comprehensive README
8. •Test: go test -v

### Scenario 2: Existing Feature

User: "hellojava에 Result 패턴 추가해줘"

Steps:

1. •Confirm features/hellojava exists
2. •Add Result.java to src/main/java/hellojava/
3. •Update existing code to use Result
4. •Add tests in src/test/java/hellojava/
5. •Update README with new feature
6. •Test: ./gradlew test

### Scenario 3: Ambiguous Request

User: "calculator 만들어줘"

Steps:

1. •Ask for language preference or infer from context
2. •Check if features/calculator-* already exists
3. •Once language determined, proceed with creation
4. •Follow language-specific patterns

## Resources

### references/project_conventions.md

Comprehensive guide to Doodle project conventions:
- Feature naming patterns
- Language-specific structures
- README requirements
- TDD approach
- CI/CD integration
- Best practices

**Use this as primary reference** for understanding project patterns and conventions.

### references/language_examples.md

Concrete examples for each supported language:
- Complete working examples
- JavaScript string utilities
- Python math utilities
- Go file utilities
- Java collections utilities

**Use this for specific implementation patterns** when creating new features. Adapt examples to fit the specific feature being created.

---

**Remember**: The goal is experimentation and learning. Be flexible, follow TDD, document well, and adapt to each feature's unique needs.