skills/i2oland/dotfiles/drift-detection

drift-detection

SKILL.md

Drift Detection

Roleplay as a specification alignment specialist that monitors for drift between specifications and implementation during development.

DriftDetection { Activation { When to use this skill: - Monitor implementation phases for spec alignment - Detect scope creep (implementing more than specified) - Identify missing features (specified but not implemented) - Flag contradictions (implementation conflicts with spec) - Log drift decisions to spec README for traceability }

CorePhilosophy { Principle: Drift is Information, Not Failure

Insights {
  Drift isn't inherently bad -- it's valuable feedback:
  - **Scope creep** may indicate incomplete requirements
  - **Missing items** may reveal unrealistic timelines
  - **Contradictions** may surface spec ambiguities
  - **Extra work** may be necessary improvements
}

Goal: Awareness and conscious decision-making, not rigid compliance

}

DriftTypes { | Type | Description | Example | | --------------- | ---------------------------------------- | ------------------------------------- | | Scope Creep | Implementation adds features not in spec | Added pagination not specified in PRD | | Missing | Spec requires feature not implemented | Error handling specified but not done | | Contradicts | Implementation conflicts with spec | Spec says REST, code uses GraphQL | | Extra | Unplanned work that may be valuable | Added caching for performance | }

DetectionProcess { Step1_LoadSpecificationContext { Read the spec documents to understand requirements

  Extract from documents:
  - **PRD**: Acceptance criteria, user stories, requirements
  - **SDD**: Components, interfaces, architecture decisions
  - **PLAN**: Phase deliverables, task objectives
}

Step2_AnalyzeImplementation {
  For the current implementation phase, examine:
  1. Files modified in this phase
  2. Functions/components added
  3. Tests written (what do they verify?)
  4. Optional annotations in code (`// Implements: PRD-1.2`)
}

Step3_CompareAndCategorize {
  ForEachSpecRequirement {
    | Requirement     | Implementation               | Status         |
    | --------------- | ---------------------------- | -------------- |
    | User login      | `src/auth/login.ts`          | Aligned        |
    | Password reset  | Not found                    | Missing        |
    | Session timeout | Different value (30m vs 15m) | Contradicts    |
  }

  ForEachImplementationArtifact {
    | Implementation | Spec Reference | Status         |
    | -------------- | -------------- | -------------- |
    | Rate limiting  | Not in spec    | Extra          |
    | Pagination     | Not in spec    | Scope Creep    |
  }
}

Step4_ReportFindings {
  Present drift findings to user with clear categorization
}

}

DetectionStrategies { Strategy1_AcceptanceCriteriaMapping { Purpose: Map PRD acceptance criteria to implementation evidence

  Process {
    1. Extract acceptance criteria from PRD
    2. Search implementation for matching behavior
    3. Verify through test assertions
  }

  SearchPatterns {
    ```bash
    # Search for login implementation
    grep -r "login\|authenticate\|access.token" src/

    # Search for test coverage
    grep -r "should.*login\|given.*registered.*user" tests/
    ```
  }
}

Strategy2_InterfaceContractValidation {
  Purpose: Compare SDD interfaces with actual implementation

  Commands {
    ```bash
    # Find actual interface
    grep -A 20 "interface UserService\|class UserService" src/

    # Compare method signatures
    ```
  }
}

Strategy3_ArchitecturePatternVerification {
  Purpose: Verify SDD architectural decisions in code

  Process {
    1. Check for expected classes/patterns
    2. Verify no violations of architectural boundaries
    3. Confirm dependency injection and layering
  }

  Commands {
    ```bash
    # Find repositories
    find src -name "*Repository*"

    # Check for direct DB calls outside repositories
    grep -r "prisma\.\|db\.\|query(" src/ --include="*.ts" | grep -v Repository
    ```
  }
}

Strategy4_PLANTaskCompletion {
  Purpose: Verify PLAN tasks against implementation

  Commands {
    ```bash
    # Find route
    grep -r "POST.*\/api\/users\|router.post.*users" src/

    # Find validation
    grep -r "email.*valid\|password.*strength" src/
    ```
  }
}

}

CodeAnnotations { Note: Optional -- aids drift detection but not required

Examples {
  ```typescript
  // Implements: PRD-1.2 - User can reset password
  async function resetPassword(email: string) {
    // ...
  }

  // Implements: SDD-3.1 - Repository pattern for data access
  class UserRepository {
    // ...
  }

  // Extra: Performance optimization not in spec
  const memoizedQuery = useMemo(() => {
    // ...
  }, [deps]);
  ```
}

AnnotationFormat {
  - `// Implements: [DOC]-[SECTION]` - Links to spec requirement
  - `// Extra: [REASON]` - Acknowledges unspecified work

  Annotations are **optional** -- drift detection works through heuristics when not present.
}

}

HeuristicDetection { FindingImplementedRequirements { 1. Test file analysis: Test descriptions often mention requirements typescript describe("User Authentication", () => { it("should allow password reset via email", () => { // This likely implements the password reset requirement }); });

  2. **Function/class naming**: Names often reflect requirements
     - `handlePasswordReset` --> Password reset feature
     - `UserRepository` --> Repository pattern from SDD

  3. **Comment scanning**: Look for references to tickets, specs
     - `// JIRA-1234`, `// Per spec section 3.2`
}

FindingMissingRequirements {
  1. Search for requirement keywords in implementation
  2. Check test coverage for spec acceptance criteria
  3. Verify API endpoints match spec interfaces
}

FindingContradictions {
  1. Compare configuration values (timeouts, limits, flags)
  2. Verify API contracts (method names, parameters, responses)
  3. Check architecture patterns (layers, dependencies)
}

}

DriftLogging { Principle: All drift decisions are logged to the spec README for traceability

DriftLogFormat {
  Add to spec README under `## Drift Log` section:
  ```markdown
  ## Drift Log

  | Date       | Phase   | Drift Type  | Status       | Notes                             |
  | ---------- | ------- | ----------- | ------------ | --------------------------------- |
  | 2026-01-04 | Phase 2 | Scope creep | Acknowledged | Added pagination not in spec      |
  | 2026-01-04 | Phase 2 | Missing     | Updated      | Added validation per spec         |
  | 2026-01-04 | Phase 3 | Contradicts | Deferred     | Session timeout differs from spec |
  ```
}

StatusValues {
  | Status           | Meaning                                 | Action Taken                   |
  | ---------------- | --------------------------------------- | ------------------------------ |
  | **Acknowledged** | Drift noted, proceeding anyway          | Implementation continues as-is |
  | **Updated**      | Spec or implementation changed to align | Drift resolved                 |
  | **Deferred**     | Decision postponed                      | Will address in future phase   |
}

}

UserInteraction { AtPhaseCompletion { When drift is detected, present options: ``` Drift Detected in Phase [N]

  Found [N] drift items:

  1. Scope Creep: Added pagination (not in spec)
     Location: src/api/users.ts:45

  2. Missing: Email validation (PRD-2.3)
     Expected: Input validation for email format

  Options:
  1. Acknowledge and continue (log drift, proceed)
  2. Update implementation (implement missing, remove extra)
  3. Update specification (modify spec to match reality)
  4. Defer decision (mark for later review)
  ```
}

LoggingDecision {
  After user decision, update the drift log in the spec README
}

}

DriftSeverityAssessment { HighSeverity { Definition: Address Immediately - Security requirement missing - Core functionality not implemented - Breaking API contract change - Data integrity issue }

MediumSeverity {
  Definition: Address Before Release
  - Non-critical feature missing
  - Performance requirement unmet
  - Documentation mismatch
  - Test coverage gap
}

LowSeverity {
  Definition: Track for Future
  - Style/preference differences
  - Nice-to-have features
  - Optimization opportunities
  - Documentation improvements
}

}

IntegrationPoints { CalledBy { - /implement -- At end of each phase for alignment check - /validate (Mode C) -- For comparison validation }

WorksAlongside {
  - `skill({ name: "specification-validation" })` -- Comprehensive spec quality checks
  - `skill({ name: "implementation-verification" })` -- Technical correctness of implementation
  - `skill({ name: "constitution-validation" })` -- Governance compliance for drifted code
  - `skill({ name: "specification-management" })` -- Read spec metadata and locate documents
}

}

ReportFormats { PhaseDriftReport { ``` Drift Analysis: Phase [N]

  Spec: [NNN]-[name]
  Phase: [Phase name]
  Files Analyzed: [N]

  ALIGNMENT SUMMARY
    Aligned:     [N] requirements
    Missing:     [N] requirements
    Contradicts: [N] items
    Extra:       [N] items

  DETAILS:

  Missing Requirements:
  1. [Requirement from spec]
     Source: PRD Section [X]
     Status: Not found in implementation

  Contradictions:
  1. [What differs]
     Spec: [What spec says]
     Implementation: [What code does]
     Location: [file:line]

  Extra Work:
  1. [What was added]
     Location: [file:line]
     Justification: [Why it was added, if known]

  RECOMMENDATIONS:
  - [Priority action 1]
  - [Priority action 2]
  ```
}

SummaryReport_MultiPhase {
  ```
  Drift Summary: [NNN]-[name]

  Overall Alignment: [X]%

  | Phase | Aligned | Missing | Contradicts | Extra |
  |-------|---------|---------|-------------|-------|
  | 1     | 5       | 0       | 0           | 1     |
  | 2     | 8       | 2       | 1           | 0     |
  | 3     | 3       | 0       | 0           | 2     |

  Drift Decisions Made: [N]
  - Acknowledged: [N]
  - Updated: [N]
  - Deferred: [N]

  Outstanding Items:
  - [Item 1]
  - [Item 2]
  ```
}

}

ValidationChecklist { Before completing drift detection: - [ ] Loaded all spec documents (PRD, SDD, PLAN) - [ ] Analyzed all files modified in phase - [ ] Categorized all drift items by type - [ ] Presented findings to user - [ ] Logged decision to spec README - [ ] Updated drift log with status } }

Weekly Installs
1
First Seen
12 days ago
Installed on
amp1
cline1
opencode1
cursor1
kimi-cli1
codex1