@codihaus/claude-skills 1.6.7 → 1.6.8

package/skills/dev-changelog/SKILL.md

@@ -39,255 +39,101 @@ plans/features/{feature}/
 └── docs-updates.md         # Documentation tasks
 ```
 
-## Workflow
+## Expected Outcome
 
-### Phase 0: Verify Review Passed
+Documentation of what was implemented after `/dev-review` passes.
 
-```
-1. Check: Did /dev-review pass?
-   → Look for review output
-   → Check git for recent review commits
+**Outputs:**
+- `summary.md` - What was built this session/PR
+- `implementation.md` - Cumulative status (updated)
+- `tech-debt.md` - Known issues, TODOs (updated)
+- `docs-updates.md` - Documentation tasks
 
-2. If review not done or failed:
-   → "Run /dev-review first"
-   → Exit
-```
+## Success Criteria
 
-### Phase 1: Gather Sources
+- Changes mapped to specs and use cases
+- Completion status clear (done/partial/not started)
+- Tech debt captured (TODOs, workarounds, gaps)
+- Documentation tasks identified
+- Easy to resume work later
+- Clear what's done, what's remaining
 
-```
-1. Git changes (source of truth)
-   git log --oneline {since}
-   git diff --stat {since}
+## Prerequisite
 
-2. PR/MR info (if available)
-   gh pr view {number}
+**Verify `/dev-review` passed:**
+- If review not done or failed → "Run /dev-review first"
 
-3. Specs (intent)
-   plans/features/{feature}/specs/*.md
+## Sources to Gather
 
-4. Use cases (context)
-   plans/brd/use-cases/{feature}/*.md
+**Git (source of truth):**
+- `git log --oneline {since}` - Commits made
+- `git diff --stat {since}` - Files changed
+- `gh pr view {number}` - PR info (if available)
 
-5. Previous implementation status
-   plans/features/{feature}/implementation.md
-```
+**Intent & Context:**
+- specs/*.md - What was intended
+- use-cases/*.md - Business context
+- implementation.md (previous) - Track cumulative status
 
-### Phase 2: Analyze Changes
+## Analysis
 
-Map git changes to specs and use cases:
+**Map git changes to specs and use cases:**
 
-```
 For each changed file:
-1. What component is this? (API, UI, model, etc.)
-2. Which spec item does it fulfill?
-3. Which use case does it support?
-4. Is it complete or partial?
-```
-
-**Mapping table:**
+- What component? (API, UI, model, etc.)
+- Which spec item does it fulfill?
+- Which use case does it support?
+- Complete or partial?
 
-| File Changed | Type | Spec Item | Use Case | Status |
-|--------------|------|-----------|----------|--------|
-| `api/billing/checkout.ts` | API | SPEC-PAY-001 | UC-PAY-001 | Complete |
-| `components/CheckoutForm.tsx` | UI | SPEC-PAY-001 | UC-PAY-001 | Complete |
-| `api/billing/subscription.ts` | API | SPEC-PAY-004 | UC-PAY-002 | Partial |
+**Extract tech debt:**
+- TODOs in changed files (grep for TODO/FIXME/HACK/XXX)
+- Incomplete spec items (spec says X, implementation does Y)
+- Known issues from commits (WIP, temporary, workaround)
+- Review comments not addressed
 
-### Phase 3: Extract Tech Debt
+**Identify doc updates needed:**
 
-Scan for incomplete items:
-
-```
-1. TODOs in changed files
-   grep -r "TODO\|FIXME\|HACK\|XXX" {changed_files}
-
-2. Incomplete spec items
-   → Spec says X, implementation does Y
-
-3. Known issues from commits
-   → "WIP:", "temporary", "workaround"
-
-4. Review comments not addressed
-   → From /dev-review output
-```
-
-### Phase 4: Identify Documentation Updates
-
-Based on what changed:
-
-| Change Type | Doc Update Needed |
-|-------------|-------------------|
+| Change Type | Doc Update |
+|-------------|------------|
 | New API endpoint | API Reference |
 | New UI feature | User Guide |
 | New config option | Configuration docs |
 | Breaking change | Migration guide |
 | New component | Component docs |
 
-### Phase 5: Generate Outputs
-
-#### summary.md (per session/PR)
-
-```markdown
-# Summary: {Feature} - {Date/PR}
-
-> **PR**: #{number} or commit range
-> **Author**: {who}
-> **Review**: Passed
-
-## What Was Built
-
-### API Changes
-- `POST /api/billing/checkout` - Process payment
-- `GET /api/billing/invoices` - List invoices
-
-### UI Changes
-- CheckoutForm component
-- InvoiceList component
-- PaymentSuccess page
-
-### Data Changes
-- Added Invoice model
-- Added Payment model
-- Migration: 20240118_add_billing_tables
-
-## Spec Items Completed
-
-| Spec | Title | Status |
-|------|-------|--------|
-| SPEC-PAY-001 | Checkout Flow | ✅ Complete |
-| SPEC-PAY-002 | Payment Processing | ✅ Complete |
-| SPEC-PAY-004 | Subscription Mgmt | ⚠️ Partial |
-
-## Use Cases Addressed
-
-| UC | Title | Coverage |
-|----|-------|----------|
-| UC-PAY-001 | Checkout | Full |
-| UC-PAY-002 | Subscribe | Create only |
-
-## Commits
-
-- `abc1234` feat(billing): add checkout endpoint
-- `def5678` feat(billing): add CheckoutForm component
-- `ghi9012` feat(billing): add invoice model
-
-## Next Steps
-
-1. Complete subscription upgrade/downgrade (SPEC-PAY-004)
-2. Add refund functionality (SPEC-PAY-005)
-3. Update API documentation
-```
-
-#### implementation.md (cumulative status)
+## Output Files
 
-```markdown
-# Implementation Status: {Feature}
+**summary.md** (per session/PR):
+- What was built (API, UI, data changes)
+- Spec items completed (with status)
+- Use cases addressed (coverage)
+- Commits list
+- Next steps
 
-> **Last Updated**: {date}
-> **Overall Progress**: 60% (3/5 specs complete)
+**implementation.md** (cumulative):
+- Overall progress percentage
+- Completed items (with PR reference)
+- In progress items (what's done, what's remaining)
+- Not started items (with blockers if any)
+- History (date, PR, summary)
 
-## Completed ✅
+**tech-debt.md** (updated):
+- High/Medium/Low priority issues
+- Location, impact, notes for each
+- Code TODOs with file:line references
 
-| Item | Spec | UC | Implemented In |
-|------|------|----|----------------|
-| Checkout | SPEC-PAY-001 | UC-PAY-001 | PR #123 |
-| Payments | SPEC-PAY-002 | UC-PAY-001 | PR #123 |
-| Invoices | SPEC-PAY-003 | UC-PAY-003 | PR #125 |
+**docs-updates.md** (updated):
+- Required updates (API Reference, User Guide, Configuration)
+- Examples to add (code snippets)
+- Screenshots needed
 
-## In Progress ⚠️
-
-| Item | Spec | UC | Done | Remaining |
-|------|------|----|------|-----------|
-| Subscriptions | SPEC-PAY-004 | UC-PAY-002 | Create/cancel | Upgrade/downgrade |
-
-## Not Started ❌
-
-| Item | Spec | UC | Blocked By |
-|------|------|----|------------|
-| Refunds | SPEC-PAY-005 | UC-PAY-004 | - |
-| Usage billing | SPEC-PAY-006 | UC-PAY-005 | Phase 2 |
-
-## History
-
-| Date | PR | Summary |
-|------|----|---------|
-| 2024-01-18 | #123 | Checkout + payments |
-| 2024-01-20 | #125 | Invoice generation |
-```
-
-#### tech-debt.md
-
-```markdown
-# Tech Debt: {Feature}
-
-> **Last Updated**: {date}
-
-## High Priority
-
-| Issue | Location | Impact | Notes |
-|-------|----------|--------|-------|
-| No retry on payment failure | `billing/stripe.ts:45` | Users see errors | Add exponential backoff |
-
-## Medium Priority
-
-| Issue | Location | Impact | Notes |
-|-------|----------|--------|-------|
-| Hardcoded tax rate | `billing/invoice.ts:23` | Wrong tax for some regions | Make configurable |
-| No pagination | `api/invoices.ts:12` | Slow for many invoices | Add cursor pagination |
-
-## Low Priority
-
-| Issue | Location | Impact | Notes |
-|-------|----------|--------|-------|
-| TODO: Add logging | `billing/checkout.ts:78` | Hard to debug | Add structured logging |
-
-## Code TODOs
-
-```
-billing/stripe.ts:45: TODO: Add retry logic for failed payments
-billing/invoice.ts:23: TODO: Make tax rate configurable
-billing/checkout.ts:78: TODO: Add logging
-```
-```
-
-#### docs-updates.md
-
-```markdown
-# Documentation Updates: {Feature}
-
-> **Last Updated**: {date}
-
-## Required Updates
-
-### API Reference
-- [ ] Add `POST /api/billing/checkout` endpoint
-- [ ] Add `GET /api/billing/invoices` endpoint
-- [ ] Add `POST /api/billing/subscriptions` endpoint
-
-### User Guide
-- [ ] Add "Making a Purchase" section
-- [ ] Add "Managing Your Subscription" section
-- [ ] Add "Viewing Invoices" section
-
-### Configuration
-- [ ] Document `STRIPE_SECRET_KEY` env var
-- [ ] Document `STRIPE_WEBHOOK_SECRET` env var
-
-## Examples to Add
-
-### API Examples
-```bash
-# Checkout
-curl -X POST /api/billing/checkout \
-  -H "Authorization: Bearer {token}" \
-  -d '{"planId": "pro", "paymentMethodId": "pm_xxx"}'
-```
+## Resume Flow
 
-### UI Screenshots Needed
-- [ ] Checkout form
-- [ ] Payment success page
-- [ ] Invoice list
-```
+When returning to work later:
+1. Read implementation.md → See what's done, what's remaining
+2. Read tech-debt.md → See known issues
+3. Read summary.md (latest) → See where you left off
+4. Continue with `/dev-specs` or `/dev-coding`
 
 ## Integration with /dev-review
 

package/skills/dev-coding/SKILL.md

@@ -48,161 +48,112 @@ You have universal engineering principles and apply them to this specific projec
 2. `plans/brd/tech-context.md` exists → patterns known
 3. `plans/features/{feature}/codebase-context.md` exists (optional, helpful)
 
-## Workflow
+## Expected Outcome
 
-### Phase 0: UC Selection
+Implemented feature that meets all acceptance criteria from spec.
 
-If user specifies feature name (not specific UC):
+**What "done" looks like:**
+- All requirements from spec completed
+- All acceptance criteria pass
+- Patterns from tech-context.md followed
+- Files from spec checklist created/modified
+- No security vulnerabilities
+- Tests passing (if applicable)
+- Code quality maintained
 
-1. **List available UCs** from specs/README.md
-2. **Ask implementation mode:**
-   - One by one (Recommended): Implement → Test → Ask next
-   - Multiple: Select UCs (e.g., "1,3-5") → Implement all
-   - All at once: Implement all UCs
-
-3. **Store plan** and proceed
-
-If user specifies UC (e.g., UC-AUTH-001): skip to Phase 1
-
-### Phase 1: Load Principles
-
-**Load once, use throughout:**
-
-1. **Load universal principles** (optional, as needed)
-   - `references/backend-principles.md` (if doing API/data work)
-   - `references/frontend-principles.md` (if doing UI work)
-   - General software engineering wisdom
-
-2. **Read spec** (requirements)
-   - `plans/features/{feature}/specs/UC-*.md`
-   - Get: Requirements, acceptance criteria, files to modify
-
-3. **Read tech-context.md** (project specifics)
-   - `plans/brd/tech-context.md`
-   - Get: How THIS project implements patterns
-   - Project-specific rules and conventions
-
-4. **Read codebase-context.md** (existing code)
-   - `plans/features/{feature}/codebase-context.md`
-   - Get: How this feature currently works, entry points
-
-5. **Read architecture.md** (if exists)
-   - `plans/features/{feature}/architecture.md`
-   - Get: Feature-specific patterns
-
-6. **Create TODO list** from spec requirements
-   - Each requirement = one TODO
-   - Mark first as in_progress
-
-### Phase 2: Implement (Just-in-Time Discovery)
-
-For each requirement in TODO list:
-
-#### Step 1: Understand Requirement
-
-**From spec (already loaded):**
-- What to build (requirement)
-- Where to build it (technical constraints)
-- Success criteria (acceptance criteria)
-
-#### Step 2: Apply Principles
-
-**Think (using loaded principles):**
-
-Ask yourself what this requirement needs:
-- API work? → Apply API principles + project's API pattern
-- UI work? → Apply component principles + project's UI pattern
-- Data work? → Apply data access principles + project's data pattern
-- Form work? → Apply validation principles + project's validation pattern
-- Full-stack? → Apply multiple principles as needed
-
-**You already know:**
-- Universal principles (from references/)
-- How THIS project works (from tech-context.md)
-
-#### Step 3: Discover Details (As Needed)
-
-**Just-in-time discovery:**
+## Role: Principal Engineering Developer
 
-```
-Need to find something? Use tools:
-- Where's the pattern used? → Grep for it
-- Where does similar code live? → Glob pattern
-- How does this work? → Read the file
-- How did we do X before? → Search for example
-```
+You have universal engineering knowledge and apply it to this specific project.
+
+**You know:**
+- Universal principles (references/backend-principles.md, frontend-principles.md)
+- Project-specific patterns (tech-context.md)
+- Business requirements (specs/*.md)
+- How to verify success (acceptance criteria)
+
+**You can:**
+- Discover details just-in-time (Glob/Grep/Read as needed)
+- Apply principles based on what requirement needs
+- Validate against acceptance criteria
+- Fix and iterate until passing
+
+## Implementation Approach
+
+**1. Load Context (once):**
+- Read spec → Get requirements, acceptance criteria, files to modify
+- Read tech-context.md → Get project patterns (API, data, UI, validation, etc.)
+- Read codebase-context.md → Get feature-specific implementation
+- Read architecture.md (if exists) → Get architecture decisions
+- Load universal principles (references/) as needed
+
+**2. Plan Work:**
+- If feature name given (not specific UC): Ask implementation mode
+  - One by one: Implement → Test → Ask next (Recommended)
+  - Multiple: Select UCs → Implement all
+  - All at once: Implement all UCs
+- Create TODO list from spec requirements
+
+**3. Implement (for each requirement):**
+- **Understand:** What to build, where to build it, success criteria
+- **Apply:** Use principles + project patterns based on what requirement needs
+  - API work? → Apply API principles + project's API pattern
+  - UI work? → Apply component principles + project's UI pattern
+  - Data work? → Apply data access principles + project's data pattern
+  - Full-stack? → Apply multiple principles as needed
+- **Discover:** Find details just-in-time (Glob/Grep/Read)
+- **Build:** Create/modify files following patterns and conventions
+- **Validate:** Check acceptance criteria, fix if needed
+- **Test:** Write/run tests if applicable
+
+**4. Complete:**
+- Verify all acceptance criteria met
+- Verify all files from checklist done
+- Update spec with status
+- Git commit (if requested)
+- Move to next UC or trigger `/dev-test`
+
+## Just-in-Time Discovery
+
+Don't pre-load everything. Discover when needed:
 
 **Examples:**
-- "Where's the API wrapper?" → Glob: `**/api.*`, `**/request.*`
-- "Where are schemas?" → Remember from tech-context.md: `schemas/`
-- "How did we validate before?" → Read: `schemas/user.ts` for pattern
-- "Where's the auth composable?" → Glob: `composables/use-auth.*`
+- Need API wrapper location? → Glob: `**/api.*`, `**/request.*`
+- Need schema location? → Check tech-context.md or Glob: `**/schemas/*`
+- Need validation example? → Read existing validation file
+- Need composable location? → Glob: `composables/use-*.{ts,js}`
 
 **Don't:**
-- ❌ Pre-load all files (wasteful)
-- ❌ List all components (discover when needed)
-
-#### Step 4: Implement
+- ❌ Pre-read all files
+- ❌ List all components upfront
+- ❌ Memorize function names (look up when needed)
 
-1. Create/modify files (from spec checklist)
-2. Apply principles (from references/ + tech-context.md)
-3. Use discovered details (function names, locations)
-4. Follow conventions (from tech-context.md)
-
-#### Step 5: Validate
-
-**Check against acceptance criteria:**
-- [ ] Happy path works?
-- [ ] Error cases handled?
-- [ ] Edge cases covered?
-
-**If passes:** Mark TODO completed, move to next
-**If fails:** Fix issues, re-validate
-
-#### Step 6: Self-Test (Optional)
-
-If requirement is testable:
-- Write/update tests
-- Run tests
-- Fix failures
-
-### Phase 3: Complete UC
-
-After all requirements implemented:
-
-1. **Final validation:**
-   - Review all acceptance criteria
-   - Check file checklist completed
-   - Verify patterns followed
-
-2. **Update spec:**
-   - Mark requirements completed
-   - Add implementation notes if deviated
-   - Update status
-
-3. **Git commit** (if user requests)
-   - Follow git conventions from tech-context.md
-   - Reference UC in commit message
-
-4. **Next UC:**
-   - If "one by one": Ask user to continue
-   - If "multiple" or "all": Auto-continue to next UC
-
-### Phase 4: Run Tests
-
-After all UCs in plan completed:
-
-1. **Auto-trigger `/dev-test`** (if available)
-   - Runs test suite
-   - Reports results
+## How Principles Work
 
-2. **If tests fail:**
-   - Review failures
-   - Fix issues
-   - Re-run tests
+```
+Universal Principles (references/)
+    +
+Project Specifics (tech-context.md)
+    =
+Implementation
+```
 
-3. **If tests pass:**
-   - Suggest `/dev-review` for code review
+**Apply what the requirement needs:**
+- API endpoint? → backend-principles.md + tech-context.md (API patterns)
+- UI component? → frontend-principles.md + tech-context.md (component patterns)
+- Form validation? → Both + tech-context.md (validation pattern)
+- Full-stack feature? → Use all as needed
+
+## After Implementation
+
+**When all UCs complete:**
+- Auto-trigger `/dev-test` (if available)
+- If tests fail: Fix issues, re-run
+- If tests pass: Suggest `/dev-review`
+
+**For each UC complete:**
+- Update spec status
+- Commit if requested (follow git conventions from tech-context.md)
+- Continue to next UC (based on implementation mode)
 
 ## How Principles Work