@yeongjaeyou/claude-code-config 0.5.0 → 0.5.2

package/.claude/commands/generate-llmstxt.md

@@ -0,0 +1,49 @@
+---
+description: Generate llms.txt from URL or local directory
+---
+
+# Generate llms.txt
+
+Generate well-structured llms.txt documentation following the llms.txt standard specification.
+
+## llms.txt Format
+
+```markdown
+# Title
+
+> Optional description
+
+## Section name
+
+- [Link title](URL): Brief description (10-15 words)
+```
+
+## Workflow
+
+### URL Input
+
+1. **Map URLs**: Use `firecrawl_map` to discover all URLs on the website
+2. **Scrape Content**: Use `firecrawl_scrape` for each URL (batch of 10-20)
+3. **Synthesize**: Extract key information and organize into sections
+4. **Generate**: Write llms.txt to current directory
+
+### Local Directory Input
+
+1. **Discover Files**: Use Glob to find all markdown/docs files recursively
+2. **Read Content**: Read relevant files (README, docs/, guides)
+3. **Synthesize**: Extract purpose, key concepts, APIs
+4. **Generate**: Write llms.txt to current directory
+
+## Guidelines
+
+- **Descriptions**: 10-15 words, specific to content (not generic)
+- **Sections**: Group by type (Documentation, API Reference, Examples, Tools)
+- **URLs**: Prefer official docs URLs over GitHub raw URLs
+- **Errors**: Note failed URLs/files, continue with others
+
+## Output
+
+Write `llms.txt` to current directory with summary:
+- Number of sources processed
+- Number of sections created
+- Any errors or warnings

package/.claude/skills/feature-implementer/SKILL.md

@@ -0,0 +1,317 @@
+---
+name: feature-planner
+description: Creates phase-based feature plans with quality gates and incremental delivery structure. Use when planning features, organizing work, breaking down tasks, creating roadmaps, or structuring development strategy. Keywords: plan, planning, phases, breakdown, strategy, roadmap, organize, structure, outline.
+---
+
+# Feature Planner
+
+## Purpose
+Generate structured, phase-based plans where:
+- Each phase delivers complete, runnable functionality
+- Quality gates enforce validation before proceeding
+- User approves plan before any work begins
+- Progress tracked via markdown checkboxes
+- Each phase is 1-4 hours maximum
+
+## Planning Workflow
+
+### Step 1: Requirements Analysis
+1. Read relevant files to understand codebase architecture
+2. Identify dependencies and integration points
+3. Assess complexity and risks
+4. Determine appropriate scope (small/medium/large)
+
+### Step 2: Phase Breakdown with TDD Integration
+Break feature into 3-7 phases where each phase:
+- **Test-First**: Write tests BEFORE implementation
+- Delivers working, testable functionality
+- Takes 1-4 hours maximum
+- Follows Red-Green-Refactor cycle
+- Has measurable test coverage requirements
+- Can be rolled back independently
+- Has clear success criteria
+
+**Phase Structure**:
+- Phase Name: Clear deliverable
+- Goal: What working functionality this produces
+- **Test Strategy**: What test types, coverage target, test scenarios
+- Tasks (ordered by TDD workflow):
+  1. **RED Tasks**: Write failing tests first
+  2. **GREEN Tasks**: Implement minimal code to make tests pass
+  3. **REFACTOR Tasks**: Improve code quality while tests stay green
+- Quality Gate: TDD compliance + validation criteria
+- Dependencies: What must exist before starting
+- **Coverage Target**: Specific percentage or checklist for this phase
+
+### Step 3: Plan Document Creation
+Use plan-template.md to generate: `docs/plans/PLAN_<feature-name>.md`
+
+Include:
+- Overview and objectives
+- Architecture decisions with rationale
+- Complete phase breakdown with checkboxes
+- Quality gate checklists
+- Risk assessment table
+- Rollback strategy per phase
+- Progress tracking section
+- Notes & learnings area
+
+### Step 4: User Approval
+**CRITICAL**: Use AskUserQuestion to get explicit approval before proceeding.
+
+Ask:
+- "Does this phase breakdown make sense for your project?"
+- "Any concerns about the proposed approach?"
+- "Should I proceed with creating the plan document?"
+
+Only create plan document after user confirms approval.
+
+### Step 5: Document Generation
+1. Create `docs/plans/` directory if not exists
+2. Generate plan document with all checkboxes unchecked
+3. Add clear instructions in header about quality gates
+4. Inform user of plan location and next steps
+
+## Quality Gate Standards
+
+Each phase MUST validate these items before proceeding to next phase:
+
+**Build & Compilation**:
+- [ ] Project builds/compiles without errors
+- [ ] No syntax errors
+
+**Test-Driven Development (TDD)**:
+- [ ] Tests written BEFORE production code
+- [ ] Red-Green-Refactor cycle followed
+- [ ] Unit tests: ≥80% coverage for business logic
+- [ ] Integration tests: Critical user flows validated
+- [ ] Test suite runs in acceptable time (<5 minutes)
+
+**Testing**:
+- [ ] All existing tests pass
+- [ ] New tests added for new functionality
+- [ ] Test coverage maintained or improved
+
+**Code Quality**:
+- [ ] Linting passes with no errors
+- [ ] Type checking passes (if applicable)
+- [ ] Code formatting consistent
+
+**Functionality**:
+- [ ] Manual testing confirms feature works
+- [ ] No regressions in existing functionality
+- [ ] Edge cases tested
+
+**Security & Performance**:
+- [ ] No new security vulnerabilities
+- [ ] No performance degradation
+- [ ] Resource usage acceptable
+
+**Documentation**:
+- [ ] Code comments updated
+- [ ] Documentation reflects changes
+
+## Progress Tracking Protocol
+
+Add this to plan document header:
+
+```markdown
+**CRITICAL INSTRUCTIONS**: After completing each phase:
+1. ✅ Check off completed task checkboxes
+2. 🧪 Run all quality gate validation commands
+3. ⚠️ Verify ALL quality gate items pass
+4. 📅 Update "Last Updated" date
+5. 📝 Document learnings in Notes section
+6. ➡️ Only then proceed to next phase
+
+⛔ DO NOT skip quality gates or proceed with failing checks
+```
+
+## Phase Sizing Guidelines
+
+**Small Scope** (2-3 phases, 3-6 hours total):
+- Single component or simple feature
+- Minimal dependencies
+- Clear requirements
+- Example: Add dark mode toggle, create new form component
+
+**Medium Scope** (4-5 phases, 8-15 hours total):
+- Multiple components or moderate feature
+- Some integration complexity
+- Database changes or API work
+- Example: User authentication system, search functionality
+
+**Large Scope** (6-7 phases, 15-25 hours total):
+- Complex feature spanning multiple areas
+- Significant architectural impact
+- Multiple integrations
+- Example: AI-powered search with embeddings, real-time collaboration
+
+## Risk Assessment
+
+Identify and document:
+- **Technical Risks**: API changes, performance issues, data migration
+- **Dependency Risks**: External library updates, third-party service availability
+- **Timeline Risks**: Complexity unknowns, blocking dependencies
+- **Quality Risks**: Test coverage gaps, regression potential
+
+For each risk, specify:
+- Probability: Low/Medium/High
+- Impact: Low/Medium/High
+- Mitigation Strategy: Specific action steps
+
+## Rollback Strategy
+
+For each phase, document how to revert changes if issues arise.
+Consider:
+- What code changes need to be undone
+- Database migrations to reverse (if applicable)
+- Configuration changes to restore
+- Dependencies to remove
+
+## Test Specification Guidelines
+
+### Test-First Development Workflow
+
+**For Each Feature Component**:
+1. **Specify Test Cases** (before writing ANY code)
+   - What inputs will be tested?
+   - What outputs are expected?
+   - What edge cases must be handled?
+   - What error conditions should be tested?
+
+2. **Write Tests** (Red Phase)
+   - Write tests that WILL fail
+   - Verify tests fail for the right reason
+   - Run tests to confirm failure
+   - Commit failing tests to track TDD compliance
+
+3. **Implement Code** (Green Phase)
+   - Write minimal code to make tests pass
+   - Run tests frequently (every 2-5 minutes)
+   - Stop when all tests pass
+   - No additional functionality beyond tests
+
+4. **Refactor** (Blue Phase)
+   - Improve code quality while tests remain green
+   - Extract duplicated logic
+   - Improve naming and structure
+   - Run tests after each refactoring step
+   - Commit when refactoring complete
+
+### Test Types
+
+**Unit Tests**:
+- **Target**: Individual functions, methods, classes
+- **Dependencies**: None or mocked/stubbed
+- **Speed**: Fast (<100ms per test)
+- **Isolation**: Complete isolation from external systems
+- **Coverage**: ≥80% of business logic
+
+**Integration Tests**:
+- **Target**: Interaction between components/modules
+- **Dependencies**: May use real dependencies
+- **Speed**: Moderate (<1s per test)
+- **Isolation**: Tests component boundaries
+- **Coverage**: Critical integration points
+
+**End-to-End (E2E) Tests**:
+- **Target**: Complete user workflows
+- **Dependencies**: Real or near-real environment
+- **Speed**: Slow (seconds to minutes)
+- **Isolation**: Full system integration
+- **Coverage**: Critical user journeys
+
+### Test Coverage Calculation
+
+**Coverage Thresholds** (adjust for your project):
+- **Business Logic**: ≥90% (critical code paths)
+- **Data Access Layer**: ≥80% (repositories, DAOs)
+- **API/Controller Layer**: ≥70% (endpoints)
+- **UI/Presentation**: Integration tests preferred over coverage
+
+**Coverage Commands by Ecosystem**:
+```bash
+# JavaScript/TypeScript
+jest --coverage
+nyc report --reporter=html
+
+# Python
+pytest --cov=src --cov-report=html
+coverage report
+
+# Java
+mvn jacoco:report
+gradle jacocoTestReport
+
+# Go
+go test -cover ./...
+go tool cover -html=coverage.out
+
+# .NET
+dotnet test /p:CollectCoverage=true /p:CoverageReporter=html
+reportgenerator -reports:coverage.xml -targetdir:coverage
+
+# Ruby
+bundle exec rspec --coverage
+open coverage/index.html
+
+# PHP
+phpunit --coverage-html coverage
+```
+
+### Common Test Patterns
+
+**Arrange-Act-Assert (AAA) Pattern**:
+```
+test 'description of behavior':
+  // Arrange: Set up test data and dependencies
+  input = createTestData()
+
+  // Act: Execute the behavior being tested
+  result = systemUnderTest.method(input)
+
+  // Assert: Verify expected outcome
+  assert result == expectedOutput
+```
+
+**Given-When-Then (BDD Style)**:
+```
+test 'feature should behave in specific way':
+  // Given: Initial context/state
+  given userIsLoggedIn()
+
+  // When: Action occurs
+  when userClicksButton()
+
+  // Then: Observable outcome
+  then shouldSeeConfirmation()
+```
+
+**Mocking/Stubbing Dependencies**:
+```
+test 'component should call dependency':
+  // Create mock/stub
+  mockService = createMock(ExternalService)
+  component = new Component(mockService)
+
+  // Configure mock behavior
+  when(mockService.method()).thenReturn(expectedData)
+
+  // Execute and verify
+  component.execute()
+  verify(mockService.method()).calledOnce()
+```
+
+### Test Documentation in Plan
+
+**In each phase, specify**:
+1. **Test File Location**: Exact path where tests will be written
+2. **Test Scenarios**: List of specific test cases
+3. **Expected Failures**: What error should tests show initially?
+4. **Coverage Target**: Percentage for this phase
+5. **Dependencies to Mock**: What needs mocking/stubbing?
+6. **Test Data**: What fixtures/factories are needed?
+
+## Supporting Files Reference
+- [plan-template.md](plan-template.md) - Complete plan document template