@codihaus/claude-skills 1.6.5 → 1.6.7

package/skills/dev-coding/SKILL.md

@@ -1,761 +1,284 @@
 ---
 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
+## Role: Principal Engineering Developer
 
-4. Read architecture decisions
-   → plans/features/{feature}/architecture.md
+You have universal engineering principles and apply them to this specific project.
 
-5. Read quality attributes (Implementation Level)
-   → skills/_quality-attributes.md
-   → Focus on: query efficiency, memory, concurrency, 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
 
-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?
-```
+**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
 
-### Phase 3: Load Sub-Skills
+## Prerequisites
 
-**If backend work needed:**
-```
-Read: skills/dev-coding-backend/SKILL.md
-Read: skills/dev-coding-backend/references/{tech}.md (if exists)
+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)
 
-Tech detected from scout:
-- directus → directus.md
-- node → node.md
-- prisma → prisma.md
-```
+## Workflow
 
-**If frontend work needed:**
-```
-Read: skills/dev-coding-frontend/SKILL.md
-Read: skills/dev-coding-frontend/references/{tech}.md (if exists)
+### Phase 0: UC Selection
 
-Tech detected from scout:
-- nextjs → nextjs.md
-- vue → vue.md
-- react → react.md
-```
+If user specifies feature name (not specific UC):
 
-### Phase 4: Execute Backend (if needed)
+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
 
-Follow dev-coding-backend workflow:
+3. **Store plan** and proceed
 
-1. **Schema changes** (if needed)
-   - Create/modify collections, tables, models
-   - Run migrations
-   - Verify schema
+If user specifies UC (e.g., UC-AUTH-001): skip to Phase 1
 
-2. **API implementation**
-   - Create endpoints per spec
-   - Implement business logic
-   - Add validation, error handling
+### Phase 1: Load Principles
 
-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"}'
-   ```
+**Load once, use throughout:**
 
-4. **Document what was created**
-   - Endpoints available
-   - Request/response shapes
-   - Auth requirements
+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
 
-### Phase 5: Execute Frontend (if needed)
+2. **Read spec** (requirements)
+   - `plans/features/{feature}/specs/UC-*.md`
+   - Get: Requirements, acceptance criteria, files to modify
 
-Follow dev-coding-frontend workflow:
+3. **Read tech-context.md** (project specifics)
+   - `plans/brd/tech-context.md`
+   - Get: How THIS project implements patterns
+   - Project-specific rules and conventions
 
-1. **Components** (if needed)
-   - Create/modify UI components
-   - Follow project conventions from scout
+4. **Read codebase-context.md** (existing code)
+   - `plans/features/{feature}/codebase-context.md`
+   - Get: How this feature currently works, entry points
 
-2. **Pages/Routes** (if needed)
-   - Create page files
-   - Set up routing
+5. **Read architecture.md** (if exists)
+   - `plans/features/{feature}/architecture.md`
+   - Get: Feature-specific patterns
 
-3. **API Integration**
-   - Connect to backend (use info from Phase 3)
-   - Handle loading, error states
+6. **Create TODO list** from spec requirements
+   - Each requirement = one TODO
+   - Mark first as in_progress
 
-4. **Frontend verification**
-   - Visual check (Playwright screenshot or manual)
-   - Interaction test
+### Phase 2: Implement (Just-in-Time Discovery)
 
-### Phase 6: Integration Test
+For each requirement in TODO list:
 
-End-to-end verification:
+#### Step 1: Understand Requirement
 
-```
-1. Start from UI
-2. Perform user action
-3. Verify API called correctly
-4. Verify response handled
-5. Verify UI updated
-```
+**From spec (already loaded):**
+- What to build (requirement)
+- Where to build it (technical constraints)
+- Success criteria (acceptance criteria)
 
-**Methods:**
-- Playwright for automated
-- Manual walkthrough
-- curl + UI check
+#### Step 2: Apply Principles
 
-### Phase 6: Quality Checks
+**Think (using loaded principles):**
 
-Run through `_quality-attributes.md` Implementation Level checklists:
+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
 
-**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
-```
-
-**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
-```
+**You already know:**
+- Universal principles (from references/)
+- How THIS project works (from tech-context.md)
 
-### Phase 7: Auto-Test
+#### Step 3: Discover Details (As Needed)
 
-**CRITICAL: Testing runs after EVERY UC implementation (all modes).**
-
-Testing verifies each UC before proceeding to the next:
+**Just-in-time discovery:**
 
 ```
-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.
+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
 ```
 
-**Test Flow:**
+**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.*`
 
-```typescript
-// 1. Navigate
-await mcp__playwright__browser_navigate({ url: testUrl });
+**Don't:**
+- ❌ Pre-load all files (wasteful)
+- ❌ List all components (discover when needed)
 
-// 2. Execute user flow
-// (based on UC spec steps)
+#### Step 4: Implement
 
-// 3. Collect errors
-const consoleErrors = await mcp__playwright__browser_console_messages({
-  level: 'error'
-});
-const networkRequests = await mcp__playwright__browser_network_requests({});
+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)
 
-// 4. Report or fix
-if (hasErrors) {
-  // Fix and re-test (max 3 iterations)
-}
-```
+#### Step 5: Validate
 
-**On Test Failure:**
+**Check against acceptance criteria:**
+- [ ] Happy path works?
+- [ ] Error cases handled?
+- [ ] Edge cases covered?
 
-```markdown
-⚠️ **Testing found issues:**
+**If passes:** Mark TODO completed, move to next
+**If fails:** Fix issues, re-validate
 
-1. [Console] TypeError in LoginForm.tsx:45
-2. [Network] POST /api/auth/login returned 500
+#### Step 6: Self-Test (Optional)
 
-**Auto-fixing...** (if straightforward)
-**Or reporting for manual fix** (if complex)
-```
+If requirement is testable:
+- Write/update tests
+- Run tests
+- Fix failures
 
-### 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
-```
+### Phase 3: Complete UC
 
-## Communication Protocol
+After all requirements implemented:
 
-### When to Ask
+1. **Final validation:**
+   - Review all acceptance criteria
+   - Check file checklist completed
+   - Verify patterns followed
 
-| 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 |
+2. **Update spec:**
+   - Mark requirements completed
+   - Add implementation notes if deviated
+   - Update status
 
-### How to Ask
+3. **Git commit** (if user requests)
+   - Follow git conventions from tech-context.md
+   - Reference UC in commit message
 
-```markdown
-**Blocker**: {What's blocking}
+4. **Next UC:**
+   - If "one by one": Ask user to continue
+   - If "multiple" or "all": Auto-continue to next UC
 
-**Tried**:
-1. {Attempt 1} → {Result}
-2. {Attempt 2} → {Result}
+### Phase 4: Run Tests
 
-**Options**:
-A) {Option A} - {Tradeoff}
-B) {Option B} - {Tradeoff}
+After all UCs in plan completed:
 
-**Recommendation**: {Your suggestion}
-```
-
-### Scope Creep Protocol
+1. **Auto-trigger `/dev-test`** (if available)
+   - Runs test suite
+   - Reports results
 
-| Deviation | Action |
-|-----------|--------|
-| Tiny (typo) | Fix silently |
-| Small (edge case) | Ask + proceed |
-| Medium (new field) | Document + ask |
-| Large (approach wrong) | Stop + create CR |
+2. **If tests fail:**
+   - Review failures
+   - Fix issues
+   - Re-run tests
 
-## Dependency Handling
+3. **If tests pass:**
+   - Suggest `/dev-review` for code review
 
-When UC depends on another:
+## How Principles Work
 
 ```
-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?
+Universal Principles (references/)
+    +
+Project Specifics (tech-context.md)
+    =
+Implementation
 ```
 
-## Tools Used
-
-| 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 |
-
-### Context7 for Implementation
+**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
 
-When coding, use Context7 to look up library APIs:
+## Example Flow
 
-```
-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"
-     })
-```
+**Requirement:** "Add password reset endpoint"
 
-**Use for:**
-- Library APIs you're less familiar with
-- Framework-specific patterns
-- Error handling approaches
-- Best practices
+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
 
-## Integration
+## Quality
 
-| 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 |
+Apply principles from references/ during implementation. See `_quality-attributes.md` for project-specific quality checklists.
 
-## 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"
-```
+## Tools
 
-### 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
-```
+| 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 |
 
-**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
+## Anti-Patterns
 
-### Potential Issues with "One by One" Testing
+❌ 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)
 
-While "one by one" is the safest mode, be aware of these considerations:
+## Edge Cases
 
-| 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) |
+**No tech-context.md:**
+- Error: "Run /dev-scout first to document patterns"
 
-**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 ✓
-```
+**No spec:**
+- Error: "Run /dev-specs {feature} first to create implementation plan"
 
-This ensures each UC works both **independently** and **together**.
+**Spec references non-existent pattern:**
+- Discover pattern via Grep/Glob
+- If truly doesn't exist, implement following best practices
+- Note deviation in implementation notes
 
-**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
-```
+## Success Criteria
 
-**Git Strategy for "One by One":**
+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
 
-| 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 |
+## References
 
-**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.