Doodle Feature Creator

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

   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.