@codihaus/claude-skills 1.6.6 → 1.6.8

package/skills/dev-coding/SKILL.md

@@ -1,761 +1,235 @@
 ---
 name: dev-coding
-description: Implement features from specs with backend and frontend skills
-version: 1.7.0
+description: Implement features as a Principal Engineering Developer
+version: 2.0.0
 ---
 
 # /dev-coding - Implementation Skill
 
 > **Skill Awareness**: See `skills/_registry.md` for all available skills.
-> - **Before**: Ensure `/dev-specs` completed, `/dev-scout` for patterns
-> - **During**: Auto-loads `/dev-coding-backend`, `/dev-coding-frontend`
-> - **Reads**: `_quality-attributes.md` (Implementation Level)
+> - **Before**: Ensure `/dev-specs` completed
+> - **Reads**: Principles (references/), project specifics (tech-context.md), requirements (specs)
 > - **After**: Auto-triggers `/dev-test` to verify implementation
-> - **After test**: Suggest `/dev-review` for code review
+> - **Review**: Suggest `/dev-review` for code review
 
-Implement features based on specs. Orchestrates backend and frontend work.
+Work as a **Principal Engineering Developer**: apply universal principles with project-specific implementation.
 
 ## When to Use
 
-- Implement a use case from /dev-specs
-- Build feature end-to-end (API + UI)
-- Make changes defined in implementation plan
+- Implement use case from specs
+- Build feature (backend, frontend, or both)
+- Apply project patterns to new code
 
 ## Usage
 
 ```
+/dev-coding auth                     # Implement feature (will ask which UCs)
 /dev-coding UC-AUTH-001              # Implement specific UC
-/dev-coding auth                     # Implement all UCs for feature
-/dev-coding UC-AUTH-001 --backend    # Backend only
-/dev-coding UC-AUTH-001 --frontend   # Frontend only
 ```
 
-## Prerequisites
-
-Before using, ensure:
-1. `/debrief` completed → BRD exists
-2. `/dev-specs` completed → Implementation plan exists
-3. `/dev-scout` completed → Codebase patterns known
-
-## Output
-
-Updates to codebase:
-- New/modified files
-- Tests (if required)
-- Updated docs-graph
-
-Updates to specs:
-- Task status in `plans/features/{feature}/specs/`
-- Implementation notes
-
-## Workflow
-
-### Phase 0: Determine Scope & Select UCs
-
-**Before starting, determine which use cases to implement.**
-
-```
-Parse user input:
-- /dev-coding UC-AUTH-001 → Specific UC (skip to Phase 1)
-- /dev-coding auth        → Feature-level (need UC selection)
-```
-
-**If user specified feature name (not specific UC), show UC selection:**
-
-1. **List available UCs:**
-   ```
-   Available Use Cases for auth:
-     1. UC-AUTH-001: User Login
-     2. UC-AUTH-002: User Signup
-     3. UC-AUTH-003: Password Reset
-     4. UC-AUTH-004: Email Verification
-     5. UC-AUTH-005: Two-Factor Authentication
-   ```
-
-2. **Ask implementation mode** (use AskUserQuestion):
-   - **One by one (Recommended)**: Implement 1 UC, test, then ask for next
-   - **Multiple (custom selection)**: Select specific UCs (e.g., "1,3-5,7")
-   - **All at once**: Implement all UCs in sequence
-
-3. **Process selection:**
-   - **One by one**: Implement → Test → Ask to continue (safest, recommended)
-   - **Multiple**: Implement → Test each UC → Auto-continue (no prompts between)
-   - **All at once**: Implement → Test each UC → Auto-continue (no prompts)
-
-**Parsing examples:**
-| Input | Result |
-|-------|--------|
-| `1,3,5` | UCs 1, 3, 5 |
-| `1-3` | UCs 1, 2, 3 |
-| `1,3-5,7` | UCs 1, 3, 4, 5, 7 |
-| `all` | All UCs |
-
-**After selection, store plan:**
-```
-implementationPlan = {
-  mode: "one-by-one" | "multiple" | "all",
-  ucs: [UC-AUTH-001, UC-AUTH-003, ...],
-  currentIndex: 0
-}
-```
-
-**Flow Visualization:**
-
-```
-Mode: ONE BY ONE (Recommended)
-─────────────────────────────
-UC #1: Implement → Test → ✓ Pass → [ASK USER: Continue?]
-                                         ↓ Yes
-UC #2: Implement → Test → ✓ Pass → [ASK USER: Continue?]
-                                         ↓ Yes
-UC #3: Implement → Test → ✓ Pass → Done
-
-
-Mode: MULTIPLE / ALL AT ONCE
-────────────────────────────
-UC #1: Implement → Test → ✓ Pass → [Auto-continue]
-                                         ↓
-UC #2: Implement → Test → ✓ Pass → [Auto-continue]
-                                         ↓
-UC #3: Implement → Test → ✓ Pass → Done
-```
-
-**Key Point:** Testing (Phase 7) is a checkpoint after each UC in ALL modes.
-- "One by one": Test passes → Ask user before next UC
-- "Multiple/All": Test passes → Automatically start next UC
-
-### Phase 1: Load Context
-
-```
-1. Read UC spec
-   → plans/features/{feature}/specs/{UC-ID}/README.md
-
-2. Read scout for patterns
-   → plans/features/{feature}/scout.md OR plans/scout/README.md
-
-3. Read stack.md and stack knowledge (CRITICAL)
-   → plans/scout/stack.md
-   → Check "Stack Knowledge References" section
-   → Read each referenced knowledge/stacks/*.md file
-   → Use "For /dev-coding" sections for implementation patterns
-
-   Examples:
-   - Directus project → Read knowledge/stacks/directus/_index.md
-   - Nuxt project → Read knowledge/stacks/nuxt/_index.md
-   - Next.js project → Read knowledge/stacks/nextjs/_index.md
-
-4. Read architecture decisions
-   → plans/features/{feature}/architecture.md
-
-5. Read quality attributes (Implementation Level)
-   → skills/_quality-attributes.md
-   → Focus on: query efficiency, memory, concurrency, error handling
-
-6. Read docs-graph for dependencies
-   → plans/docs-graph.json
-
-7. Check: Are dependencies complete?
-   → If UC depends on another UC, verify it's done
-   → Warn if not, let user decide to proceed
-```
-
-### Phase 2: Determine Work Type
-
-Based on spec, determine what's needed:
-
-| Spec Contains | Work Type | Skill to Load |
-|---------------|-----------|---------------|
-| API endpoints, schema | Backend | dev-coding-backend |
-| UI components, pages | Frontend | dev-coding-frontend |
-| Both | Full-stack | Backend first, then Frontend |
-
-```
-Read spec → Extract:
-- API changes needed?
-- Schema/DB changes needed?
-- UI components needed?
-- Pages/routes needed?
-```
-
-### Phase 3: Load Sub-Skills
-
-**If backend work needed:**
-```
-Read: skills/dev-coding-backend/SKILL.md
-Read: skills/dev-coding-backend/references/{tech}.md (if exists)
-
-Tech detected from scout:
-- directus → directus.md
-- node → node.md
-- prisma → prisma.md
-```
-
-**If frontend work needed:**
-```
-Read: skills/dev-coding-frontend/SKILL.md
-Read: skills/dev-coding-frontend/references/{tech}.md (if exists)
-
-Tech detected from scout:
-- nextjs → nextjs.md
-- vue → vue.md
-- react → react.md
-```
-
-### Phase 4: Execute Backend (if needed)
-
-Follow dev-coding-backend workflow:
+## Role: Principal Engineering Developer
 
-1. **Schema changes** (if needed)
-   - Create/modify collections, tables, models
-   - Run migrations
-   - Verify schema
+You have universal engineering principles and apply them to this specific project.
 
-2. **API implementation**
-   - Create endpoints per spec
-   - Implement business logic
-   - Add validation, error handling
+**Workflow:**
+1. Load principles (references/) + project specifics (tech-context.md)
+2. Discover details just-in-time (Glob/Grep/Read as needed)
+3. Apply principles based on what requirement needs
+4. Validate against acceptance criteria
 
-3. **Backend verification**
-   ```bash
-   # Test API works
-   curl -X POST http://localhost:3000/api/auth/login \
-     -H "Content-Type: application/json" \
-     -d '{"email":"test@test.com","password":"test"}'
-   ```
+**Principles:**
+- See `references/backend-principles.md` for API, data, security principles
+- See `references/frontend-principles.md` for UI, component, state principles
+- See `tech-context.md` for how THIS project implements them
 
-4. **Document what was created**
-   - Endpoints available
-   - Request/response shapes
-   - Auth requirements
-
-### Phase 5: Execute Frontend (if needed)
-
-Follow dev-coding-frontend workflow:
-
-1. **Components** (if needed)
-   - Create/modify UI components
-   - Follow project conventions from scout
-
-2. **Pages/Routes** (if needed)
-   - Create page files
-   - Set up routing
-
-3. **API Integration**
-   - Connect to backend (use info from Phase 3)
-   - Handle loading, error states
+## Prerequisites
 
-4. **Frontend verification**
-   - Visual check (Playwright screenshot or manual)
-   - Interaction test
+1. `/dev-specs {feature}` completed → specs exist
+2. `plans/brd/tech-context.md` exists → patterns known
+3. `plans/features/{feature}/codebase-context.md` exists (optional, helpful)
+
+## Expected Outcome
+
+Implemented feature that meets all acceptance criteria from spec.
+
+**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
+
+## Role: Principal Engineering Developer
+
+You have universal engineering knowledge and apply it to this specific project.
 
-### Phase 6: Integration Test
+**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
 
-End-to-end verification:
+## Implementation Approach
 
-```
-1. Start from UI
-2. Perform user action
-3. Verify API called correctly
-4. Verify response handled
-5. Verify UI updated
-```
+**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
 
-**Methods:**
-- Playwright for automated
-- Manual walkthrough
-- curl + UI check
+**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
 
-### Phase 6: Quality Checks
+**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
 
-Run through `_quality-attributes.md` Implementation Level checklists:
+**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`
 
-**From quality attributes:**
-```
-[ ] Scalability
-    - No N+1 queries (use joins/includes)
-    - Select only needed fields
-    - Limit result sets
-    - Connection pooling used
-
-[ ] Maintainability
-    - Functions do one thing
-    - Names describe intent
-    - No magic numbers/strings
-
-[ ] Performance
-    - Database queries optimized
-    - Heavy computation cached or async
-    - No unnecessary re-renders (frontend)
-
-[ ] Security
-    - All input validated
-    - SQL injection prevented
-    - XSS prevented
-    - No hardcoded secrets
-
-[ ] Reliability
-    - Errors caught and handled
-    - User-friendly error messages
-    - Timeouts on external calls
-
-[ ] Testability
-    - Pure functions where possible
-    - Dependencies injected
-```
+## Just-in-Time Discovery
 
-**Project-specific:**
-```
-[ ] Code follows project conventions (from scout)
-[ ] No linting errors
-[ ] No type errors
-[ ] Tests pass (if project has tests)
-[ ] No console.log / debug code left
-```
+Don't pre-load everything. Discover when needed:
 
-### Phase 7: Auto-Test
+**Examples:**
+- 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}`
 
-**CRITICAL: Testing runs after EVERY UC implementation (all modes).**
+**Don't:**
+- ❌ Pre-read all files
+- ❌ List all components upfront
+- ❌ Memorize function names (look up when needed)
 
-Testing verifies each UC before proceeding to the next:
+## How Principles Work
 
 ```
-1. Load dev-test skill
-   → Read skills/dev-test/SKILL.md
-
-2. Determine test URL
-   → From project config or spec
-   → Default: http://localhost:3000/{path}
-
-3. Run E2E test for CURRENT UC
-   → Navigate to page
-   → Execute user flow from spec
-   → Capture errors
-
-4. Run regression tests (if previous UCs exist)
-   → Quick smoke test of previously completed UCs
-   → Ensures new UC didn't break existing functionality
-   → Example: UC-AUTH-002 (Signup) shouldn't break UC-AUTH-001 (Login)
-
-   Regression approach:
-   - If only 1-2 previous UCs: Full test
-   - If 3+ previous UCs: Critical path only (login flow, main actions)
-   - Skip if UCs are completely independent
-
-5. Analyze results
-   → Console errors?
-   → Network failures?
-   → Visual issues?
-   → Regression failures?
-
-6. Handle results:
-   - All pass (current + regression) → Proceed to Phase 8 (Complete)
-   - Current UC fails → Fix current UC and re-test
-   - Regression fails → Fix regression issue (may need to update previous UC)
-
-   IMPORTANT: Do NOT proceed to next UC until:
-   - Current UC passes all tests
-   - Previous UCs still work (regression pass)
-   This ensures quality and prevents cascading failures.
+Universal Principles (references/)
+    +
+Project Specifics (tech-context.md)
+    =
+Implementation
 ```
 
-**Test Flow:**
+**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
 
-```typescript
-// 1. Navigate
-await mcp__playwright__browser_navigate({ url: testUrl });
+## After Implementation
 
-// 2. Execute user flow
-// (based on UC spec steps)
+**When all UCs complete:**
+- Auto-trigger `/dev-test` (if available)
+- If tests fail: Fix issues, re-run
+- If tests pass: Suggest `/dev-review`
 
-// 3. Collect errors
-const consoleErrors = await mcp__playwright__browser_console_messages({
-  level: 'error'
-});
-const networkRequests = await mcp__playwright__browser_network_requests({});
+**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)
 
-// 4. Report or fix
-if (hasErrors) {
-  // Fix and re-test (max 3 iterations)
-}
-```
-
-**On Test Failure:**
-
-```markdown
-⚠️ **Testing found issues:**
+## How Principles Work
 
-1. [Console] TypeError in LoginForm.tsx:45
-2. [Network] POST /api/auth/login returned 500
-
-**Auto-fixing...** (if straightforward)
-**Or reporting for manual fix** (if complex)
 ```
-
-### Phase 8: Complete
-
-**This phase runs after each UC is implemented AND tested.**
-
-1. **Update spec status**
-   ```markdown
-   <!-- In specs/{UC-ID}/README.md -->
-   > **Status**: Complete
-   > **Completed**: {date}
-   > **Tested**: ✓ Pass (Phase 7)
-   ```
-
-2. **Document changes**
-   ```markdown
-   ## Implementation Notes
-
-   ### Files Changed
-   - `src/api/auth/login.ts` - Created login endpoint
-   - `src/components/LoginForm.tsx` - Created form component
-
-   ### Deviations from Spec
-   - Added rate limiting (not in spec, but security best practice)
-
-   ### Test Results
-   - E2E flow: ✓ Pass
-   - Console errors: None
-   - API responses: All 2xx
-
-   ### Next Steps
-   - UC-AUTH-002 can now proceed (depends on this)
-   ```
-
-3. **Update docs-graph** (automatic via hook)
-
-4. **Continue with next UC (if applicable)**
-   ```
-   IMPORTANT: This step only runs if Phase 7 (Testing) passed.
-   If tests fail, fix issues and re-test before continuing.
-
-   Check implementationPlan from Phase 0:
-
-   If more UCs remaining:
-     Mode "one-by-one":
-       → Show: "✓ UC-AUTH-001 implemented and tested successfully!"
-       → Show: "Remaining: UC-AUTH-002, UC-AUTH-003, UC-AUTH-004"
-       → Ask (AskUserQuestion): "Continue with UC-AUTH-002?"
-          Options:
-          - Yes (continue with next UC)
-          - No (stop here, can resume later)
-          - Select different UCs (return to Phase 0)
-       → Yes: currentIndex++, restart from Phase 1
-       → No: Show summary, stop
-       → Select: Return to Phase 0 for new selection
-
-     Mode "multiple" or "all":
-       → Show: "✓ UC-AUTH-001 implemented and tested successfully!"
-       → Automatically: currentIndex++
-       → Restart from Phase 1 with next UC
-       → No user prompt until all selected UCs complete
-
-   If all UCs complete:
-     → Show summary (see below)
-     → Suggest /dev-review {feature}
-   ```
-
-**Summary Output (all UCs complete):**
-```markdown
-✅ All Use Cases Implemented
-
-**Completed:**
-- UC-AUTH-001: User Login ✓
-- UC-AUTH-003: Password Reset ✓
-- UC-AUTH-004: Email Verification ✓
-
-**Stats:**
-- Files changed: 12
-- Tests: All passing
-- Duration: ~45 minutes
-
-**Next Steps:**
-- Run `/dev-review auth` for code review
-- Create PR when ready
+Universal Principles (references/)
+    +
+Project Specifics (tech-context.md)
+    =
+Implementation
 ```
 
-## Communication Protocol
-
-### When to Ask
+**Apply what the requirement needs:**
+- API work → backend-principles.md + tech-context.md
+- UI work → frontend-principles.md + tech-context.md
+- Both → use both references + tech-context.md
 
-| Situation | Action |
-|-----------|--------|
-| Spec unclear | Ask for clarification |
-| Multiple valid approaches | Present options, ask preference |
-| Stuck > 15 min | Document attempts, ask for help |
-| Spec seems wrong | Flag it, propose alternative |
-| Scope creep detected | Stop, suggest CR |
+## Example Flow
 
-### How to Ask
+**Requirement:** "Add password reset endpoint"
 
-```markdown
-**Blocker**: {What's blocking}
+1. **Think:** API work → backend-principles.md (validation, security) + tech-context.md (how we do APIs)
+2. **Discover:** Where are endpoints? → Glob, Read similar endpoint
+3. **Implement:** Follow pattern + apply principles
+4. **Validate:** Check acceptance criteria
 
-**Tried**:
-1. {Attempt 1} → {Result}
-2. {Attempt 2} → {Result}
+## Quality
 
-**Options**:
-A) {Option A} - {Tradeoff}
-B) {Option B} - {Tradeoff}
+Apply principles from references/ during implementation. See `_quality-attributes.md` for project-specific quality checklists.
 
-**Recommendation**: {Your suggestion}
-```
-
-### Scope Creep Protocol
+## Tools
 
-| Deviation | Action |
-|-----------|--------|
-| Tiny (typo) | Fix silently |
-| Small (edge case) | Ask + proceed |
-| Medium (new field) | Document + ask |
-| Large (approach wrong) | Stop + create CR |
+| Tool | Purpose | When |
+|------|---------|------|
+| `Read` | Load spec, tech-context.md, files | Phase 1, as needed |
+| `Glob` | Find files by pattern | Just-in-time discovery |
+| `Grep` | Search for code patterns | Just-in-time discovery |
+| `Edit` | Modify existing files | Implementation |
+| `Write` | Create new files | Implementation |
+| `Bash` | Run tests, git commands | Testing, committing |
+| `TodoWrite` | Track implementation progress | Throughout |
 
-## Dependency Handling
+## Anti-Patterns
 
-When UC depends on another:
+❌ Reading every file upfront (discover as needed)
+❌ Categorizing work as "backend" or "frontend" (just apply what's needed)
+❌ Memorizing function names (look them up when needed)
+❌ Ignoring principles (universal + project-specific)
+❌ Not validating against acceptance criteria (that's success)
+❌ Pre-loading all components (wasteful, discover when needed)
 
-```
-1. Check docs-graph for dependencies
-2. For each dependency:
-   - Is UC marked complete? → OK
-   - Is code actually there? → Check (more reliable)
-3. If dependency missing:
-   - Warn user
-   - Ask: Proceed anyway? / Do dependency first?
-```
+## Edge Cases
 
-## Tools Used
+**No tech-context.md:**
+- Error: "Run /dev-scout first to document patterns"
 
-| Tool | Purpose |
-|------|---------|
-| `Read` | Load specs, scout, sub-skills |
-| `Write` | Create new files |
-| `Edit` | Modify existing files |
-| `Bash` | Run commands, curl tests |
-| `Glob` | Find files |
-| `Grep` | Search code |
-| `mcp__playwright__*` | UI verification |
-| `Context7` | Look up library documentation |
+**No spec:**
+- Error: "Run /dev-specs {feature} first to create implementation plan"
 
-### Context7 for Implementation
+**Spec references non-existent pattern:**
+- Discover pattern via Grep/Glob
+- If truly doesn't exist, implement following best practices
+- Note deviation in implementation notes
 
-When coding, use Context7 to look up library APIs:
+## Success Criteria
 
-```
-1. Resolve library
-   → mcp__context7__resolve-library-id({
-       libraryName: "zod",
-       query: "form validation schema"
-     })
-
-2. Query specific API
-   → mcp__context7__query-docs({
-       libraryId: "/colinhacks/zod",
-       query: "custom error messages"
-     })
-```
+Implementation successful when:
+- ✅ All acceptance criteria met
+- ✅ All files from checklist created/modified
+- ✅ Patterns from tech-context.md followed
+- ✅ Tests passing (if applicable)
+- ✅ Code quality checks passed
+- ✅ No security vulnerabilities
 
-**Use for:**
-- Library APIs you're less familiar with
-- Framework-specific patterns
-- Error handling approaches
-- Best practices
+## References
 
-## Integration
-
-| Skill | Relationship |
-|-------|--------------|
-| `/dev-specs` | Reads implementation plan from |
-| `/dev-scout` | Reads patterns/conventions from |
-| `/dev-coding-backend` | Loads for API/schema work |
-| `/dev-coding-frontend` | Loads for UI work |
-| `/dev-test` | Auto-triggers after implementation |
-| `/utils/docs-graph` | Auto-updates on file changes |
-| `/dev-review` | Review after testing passes |
-
-## Example Flows
-
-### Example 1: Specific UC (Skip Selection)
-```
-User: /dev-coding UC-AUTH-001
-
-1. Load UC-AUTH-001 spec
-   → Backend: POST /api/auth/login
-   → Frontend: LoginForm component, /login page
-
-2. Check dependencies
-   → None for UC-AUTH-001 (it's first)
-
-3. Load dev-coding-backend
-   → Create login endpoint
-   → Test with curl ✓
-
-4. Load dev-coding-frontend
-   → Create LoginForm component
-   → Create /login page
-   → Connect to API
-
-5. Integration test
-   → Fill form → Submit → Verify redirect ✓
-
-6. Quality checks
-   → Lint ✓, Types ✓, No debug code ✓
-
-7. Auto-test (dev-test)
-   → Navigate to /login
-   → Fill form, submit
-   → Check console: No errors ✓
-   → Check network: All 2xx ✓
-   → Visual check: Form renders ✓
-
-8. Complete
-   → Update spec status (with test results)
-   → Document changes
-   → Suggest: "Run /dev-review before committing"
-   → Note: "UC-AUTH-002 (Signup) is now unblocked"
-```
-
-### Example 2: One by One Mode (Recommended)
-```
-User: /dev-coding auth
-
-📋 Available Use Cases for auth:
-  1. UC-AUTH-001: User Login
-  2. UC-AUTH-002: User Signup
-  3. UC-AUTH-003: Password Reset
-
-? Which use cases would you like to implement?
-  ◉ One by one (Recommended) ← User selects this
-  ○ Multiple (custom selection)
-  ○ All at once
-
-───────────────────────────────────────────────
-🔨 UC-AUTH-001: User Login
-───────────────────────────────────────────────
-
-Phase 1-6: Implement backend + frontend
-Phase 7: Auto-test
-  ✓ Navigate to /login
-  ✓ Fill form and submit
-  ✓ No console errors
-  ✓ API returns 200
-  ✓ Redirect to /dashboard works
-
-Phase 8: Complete
-  ✓ UC-AUTH-001 implemented and tested successfully!
-
-  Remaining: UC-AUTH-002, UC-AUTH-003
-
-  ? Continue with UC-AUTH-002? ← Prompt after testing passes
-    ◉ Yes (continue)
-    ○ No (stop here)
-    ○ Select different UCs
-
-User selects: Yes
-
-───────────────────────────────────────────────
-🔨 UC-AUTH-002: User Signup
-───────────────────────────────────────────────
-
-Phase 1-6: Implement backend + frontend
-Phase 7: Auto-test
-  ✓ Navigate to /signup
-  ✓ Fill registration form
-  ✓ Submit and verify
-  ✗ Console error: "Email validation failed"
-
-  ⚠️  Tests failed. Fixing...
-  → Updated validation logic
-  → Re-testing...
-  ✓ All tests pass
-
-Phase 8: Complete
-  ✓ UC-AUTH-002 implemented and tested successfully!
-
-  Remaining: UC-AUTH-003
-
-  ? Continue with UC-AUTH-003?
-    ◉ Yes
-    ○ No (stop here)
-    ○ Select different UCs
-
-User selects: No
-
-───────────────────────────────────────────────
-Summary
-───────────────────────────────────────────────
-✅ Completed:
-- UC-AUTH-001: User Login ✓
-- UC-AUTH-002: User Signup ✓
-
-⏸️  Pending:
-- UC-AUTH-003: Password Reset
-
-💡 Next steps:
-- Run /dev-review auth
-- Resume later with: /dev-coding UC-AUTH-003
-```
-
-**Key Points in "One by One" Mode:**
-1. Each UC is **fully implemented** (Phases 1-6)
-2. Each UC is **fully tested** (Phase 7) before prompting
-3. User gets a **checkpoint** to review/test manually if desired
-4. User **chooses** whether to continue or stop
-5. If tests fail, they're **fixed before** asking to continue
-6. Can **resume later** from any UC
-
-### Potential Issues with "One by One" Testing
-
-While "one by one" is the safest mode, be aware of these considerations:
-
-| Issue | Description | Mitigation |
-|-------|-------------|------------|
-| **Integration gaps** | UCs tested individually might miss cross-UC interactions | After all UCs complete, run full integration test |
-| **Shared state** | Later UCs might depend on state from earlier UCs | Use cumulative testing (don't reset DB between UCs) |
-| **Conflicting changes** | UC #3 might need different approach than UC #1 implemented | May need to refactor earlier UCs (acceptable tradeoff) |
-| **Performance at scale** | Individual UCs work, but all together cause issues | Final integration test should include load testing |
-| **Git commit strategy** | Should each UC be committed separately? | Depends on team workflow (see below) |
-
-**Best Practice - Cumulative Testing:**
-```
-UC #1: Test in isolation ✓
-UC #2: Test UC #2 + verify UC #1 still works ✓
-UC #3: Test UC #3 + verify UC #1, UC #2 still work ✓
-```
-
-This ensures each UC works both **independently** and **together**.
-
-**Implementation in Phase 7:**
-```javascript
-// For UC #2 onwards, add regression checks
-Phase 7: Auto-Test
-1. Test current UC (UC-AUTH-002: Signup) ✓
-2. Regression: Quick test of previous UCs
-   → UC-AUTH-001 (Login) still works? ✓
-3. All pass → Continue
-```
-
-**Git Strategy for "One by One":**
-
-| Strategy | When to Use | Commits |
-|----------|-------------|---------|
-| **Commit each UC** | When UCs are independent, team reviews incrementally | 1 commit per UC |
-| **Commit all together** | When UCs are tightly coupled, want atomic feature | 1 commit after all UCs |
-| **Hybrid** | Mix of both - commit stable UCs, batch dependent ones | Flexible |
-
-**Recommended Git Flow:**
-```
-One by One Mode:
-UC #1 complete → Commit → Continue?
-UC #2 complete → Commit → Continue?
-UC #3 complete → Commit → Done
-
-Multiple/All Mode:
-UC #1 complete → Auto-continue (no commit)
-UC #2 complete → Auto-continue (no commit)
-UC #3 complete → Single commit for all → Done
-```
+- `references/backend-principles.md` - Universal API, data, security principles
+- `references/frontend-principles.md` - Universal UI, component, state principles
 
-This gives "one by one" the advantage of **incremental commits** that are easier to review and revert.
+These provide general software engineering wisdom. Combine with tech-context.md for project-specific implementation.