engineering-intelligence 1.4.0 → 1.6.0

package/templates/canonical/skills/api-snapshot-testing-engine/SKILL.md

@@ -0,0 +1,75 @@
+---
+name: api-snapshot-testing-engine
+description: Captures pre-change API request/response snapshots, replays them post-change, and flags semantic response regressions.
+version: 1.0.0
+---
+
+# API Snapshot Testing Engine
+
+Use this skill when an API endpoint, route handler, controller, serializer, GraphQL resolver, RPC method, webhook, or response-shaping code changes.
+
+## Snapshot Root
+
+Store snapshots under:
+
+```text
+.engineering-intelligence/snapshots/
+```
+
+## Procedure
+
+1. **Select Snapshot Scenarios**
+   - Read `knowledge-base/04-api-documentation.md`, `service-graph.json`, route files, and existing API tests.
+   - Select representative requests for changed endpoints:
+     - happy path
+     - auth failure
+     - validation error
+     - downstream timeout or dependency failure
+     - edge-case response shape
+
+2. **Capture Pre-Change Snapshots**
+   - Before implementation edits when feasible, capture pre-change request/response pairs.
+   - If runtime capture is unavailable, extract examples from existing tests or API docs and mark confidence accordingly.
+
+3. **Replay Post-Change**
+   - After implementation, replay the same requests against the changed code or test harness.
+   - Diff status code, headers that are part of the contract, response shape, computed values, pagination metadata, error format, and auth behavior.
+
+4. **Classify Differences**
+   - `expected`: intentional change covered by acceptance criteria or API compatibility notes
+   - `compatible`: additive or non-contractual difference
+   - `regression-candidate`: semantic difference that may break callers
+   - `breaking`: incompatible response or status change without approval
+
+5. **Block On Unexplained Regressions**
+   - `regression-candidate` and `breaking` diffs block Definition of Done until resolved, approved, or recorded as open risk.
+
+## Output
+
+Write `.engineering-intelligence/snapshots/<unit>/snapshot-report.md`:
+
+```markdown
+# API Snapshot Report: <unit>
+
+## Snapshot Sources
+- pre-change: <runtime|test fixture|documentation|unavailable>
+- post-change: <runtime|test fixture|unavailable>
+
+## Replay Results
+| Scenario | Endpoint | Pre-Change | Post-Change | Classification | Evidence |
+|---|---|---|---|---|---|
+
+## Blocking Differences
+- <regression or breaking difference>
+
+## Approval / Rationale
+- <expected difference and evidence>
+```
+
+## Quality Gates
+
+- [ ] Changed API surfaces have snapshot scenarios or explicit unavailable rationale
+- [ ] Pre-change snapshots are captured before implementation when feasible
+- [ ] Post-change replay was performed or blocked with evidence
+- [ ] Semantic differences are classified
+- [ ] Unexplained regression candidates block completion

package/templates/canonical/skills/context-budget-optimizer/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: context-budget-optimizer
+description: Minimizes AI IDE token usage by ranking, slicing, summarizing, and lazy-loading project intelligence while preserving required gates and output quality.
+version: 1.0.0
+---
+
+# Context Budget Optimizer
+
+Use this skill before broad intelligence reads in implementation, analysis, review, and synchronization workflows. The goal is to produce the same engineering output with fewer tokens by loading only the most relevant evidence.
+
+## Token Budget Policy
+
+Default budget allocation:
+
+| Budget Area | Target |
+|---|---:|
+| Intelligence context | <= 40% |
+| Source/test snippets | 30% |
+| Tool diagnostics | 20% |
+| User interaction and final answer | 10% |
+
+If the AI IDE exposes a context-window size, estimate against that. If not, use relative budgets and prefer compact artifacts over full documents.
+
+## Context Manifest
+
+Before loading full documents, create or update:
+
+```text
+.engineering-intelligence/context/context-manifest.md
+```
+
+Format:
+
+```markdown
+# Context Manifest
+
+## Scope
+- Request:
+- Candidate modules:
+- Risk:
+
+## Ranked Context
+| Rank | Artifact | Sections / Keys | Reason | Estimated Tokens | Load Mode |
+|---:|---|---|---|---:|---|
+| 1 | `.engineering-intelligence/context/module-map.md` | auth row | direct scope | 120 | slice |
+| 2 | `knowledge-base/04-api-documentation.md` | H2: Auth API | API contract | 500 | section |
+```
+
+## Procedure
+
+1. **Resolve Scope**
+   - Use the user request, changed files, graph proximity, and impact report.
+   - Identify candidate modules, services, APIs, schemas, tests, and risk areas.
+
+2. **Rank Artifacts**
+   - Load compact maps first: context maps, graph node summaries, `aidlc-state.md`, active unit, acceptance criteria.
+   - Rank knowledge docs by graph proximity and section confidence.
+   - Prefer H2 sections with high/medium confidence.
+   - Penalize stale or low-confidence sections unless they are required for risk.
+
+3. **Slice Before Full Read**
+   - Load only relevant H2 sections, table rows, graph nodes/edges, and file snippets.
+   - Do not load an entire knowledge document when a section or table row is enough.
+   - Do not load all skills. Invoke only skills triggered by the current change.
+
+4. **Lazy Loading**
+   - Defer expensive artifacts until a gate requires them.
+   - Examples:
+     - Load API docs only when API surfaces are touched.
+     - Load migration docs only when schema/persistence changes.
+     - Load security assessment only for security-sensitive paths.
+     - Load snapshots only when API replay applies.
+
+5. **Summarize And Cache**
+   - Write compact summaries to `.engineering-intelligence/context/context-manifest.md`.
+   - Store pointers to source evidence instead of copying long excerpts.
+   - Reuse manifest rankings during resume/checkpoint flows.
+
+6. **Escalate When Budget Is Insufficient**
+   - If critical context cannot fit, stop and report what was excluded, why it matters, and whether the user wants a narrower scope.
+
+## Rules
+
+- Never sacrifice required safety gates to save tokens.
+- Prefer evidence pointers over pasted content.
+- Prefer graph node/edge slices over full graph JSON.
+- Prefer section-level confidence metadata over full-document reads.
+- Keep initial intelligence loading under 40% of context budget whenever possible.
+- Lazy Loading is mandatory for large projects.
+
+## Quality Gates
+
+- [ ] Context Manifest exists for non-trivial workflows
+- [ ] Ranked context explains why each artifact was loaded
+- [ ] Initial context stayed within 40% budget or escalation was recorded
+- [ ] Full documents were avoided when slices were enough
+- [ ] Required gates still had enough evidence to run

package/templates/canonical/skills/context-sync-engine/SKILL.md

@@ -84,14 +84,24 @@ Queue → Worker → Process → DB Write → Notify
 | stripe | 12.x | payments module | Medium — breaking changes |
 ```
 
+### `context-manifest.md` — Token Budget And Relevance Plan
+
+```markdown
+# Context Manifest
+
+| Rank | Artifact | Sections / Keys | Reason | Estimated Tokens | Load Mode |
+|---:|---|---|---|---:|---|
+```
+
 ## Procedure
 
-1. **Context Relevance Selection** — Before reading broad intelligence, rank knowledge and context documents by graph proximity to the change scope:
+1. **Context Relevance Selection** — Use `context-budget-optimizer` before reading broad intelligence. Rank knowledge and context documents by graph proximity to the change scope:
    - direct graph neighbors first
    - critical-path maps next
    - impacted API/schema/security docs next
    - broad background docs last
    Estimate token cost and load in relevance order until roughly 40% of the available context budget is consumed. Reserve the rest for implementation, tests, diagnostics, and user interaction. If critical docs cannot fit, escalate with the missing docs and reason.
+   Write the ranking to `.engineering-intelligence/context/context-manifest.md`.
 
 2. **Check Impact** — Review the impact report and graph updates. Identify which context maps are affected.
 
@@ -125,6 +135,7 @@ Queue → Worker → Process → DB Write → Notify
 
 - [ ] Each map is under 150 lines
 - [ ] Relevant docs were ranked by graph proximity before broad loading
+- [ ] `context-manifest.md` was updated for non-trivial work
 - [ ] Context budget was preserved or an escalation was recorded
 - [ ] Updated entries reference real, existing paths
 - [ ] Only impact-affected maps were modified

package/templates/canonical/skills/contract-test-generator/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: contract-test-generator
+description: Generates consumer-driven contract test stubs for service boundaries based on API contracts and service graph topology.
+version: 1.0.0
+---
+
+# Contract Test Generator
+
+Use this skill when service boundaries, API clients, webhooks, events, GraphQL schemas, or RPC contracts change.
+
+## Procedure
+
+1. Read `service-graph.json`, `knowledge-base/04-api-documentation.md`, OpenAPI/GraphQL/protobuf schemas, and existing contract tests.
+2. Detect the project’s contract-test framework if any: Pact, Spring Cloud Contract, protobuf conformance tests, schema snapshots, custom integration harness, or plain test framework.
+3. Generate or recommend stubs matching the project’s exact test structure and assertion style.
+4. Cover canonical scenarios:
+   - happy path
+   - auth failure
+   - validation error
+   - downstream timeout
+   - unexpected response shape
+5. Feed generated stubs and commands into `testing-intelligence-engine`.
+
+## Output
+
+Write `.engineering-intelligence/aidlc/construction/<unit>/contract-test-plan.md`:
+
+```markdown
+# Contract Test Plan: <unit>
+
+| Boundary | Consumer | Provider | Scenario | Stub/Test Path | Status |
+|---|---|---|---|---|---|
+```
+
+## Quality Gates
+
+- [ ] Changed service boundaries are identified
+- [ ] Existing contract-test style is matched
+- [ ] Canonical failure scenarios are covered or explicitly not applicable
+- [ ] Contract tests are linked to acceptance criteria

package/templates/canonical/skills/convention-detector/SKILL.md

@@ -121,6 +121,19 @@ This capability does not modify product code.
    - **Exceptions**: specific files or modules that deviate (and possible reasons)
    - **Confidence**: how certain the detection is (based on sample size)
 
+   ## Convention Severity
+
+   Classify violations with these blocking rules:
+
+   | Severity | Meaning | Completion Rule |
+   |---|---|---|
+   | `critical` | Violates architectural boundary, security convention, data access rule, public API shape, or framework lifecycle rule | Blocks completion |
+   | `major` | Breaks dominant project structure, error handling, logging, import style, or test pattern in a way that creates maintenance risk | Must fix or record review finding |
+   | `minor` | Local naming/order/style mismatch that is mechanically fixable | Auto-correct when safe |
+   | `exception` | Existing legacy or documented exception | Record but do not block |
+
+   A pattern must exceed `>70%` adherence to be treated as a convention. Structural means the violation changes file placement, layer ownership, dependency direction, API envelope, persistence access, or lifecycle hook usage rather than simple naming.
+
 10. **Write conventions document** — Generate `knowledge-base/16-conventions.md` following the output format below.
 
 11. **Enhance coding patterns memory** — Update `.engineering-intelligence/memory/coding-patterns.md` with durable conventions that are unlikely to change.
@@ -167,8 +180,8 @@ Sample size: <N files analyzed across M modules>
 
 ## Convention Violations
 
-| Convention | Violation | Location | Severity |
-|---|---|---|---|
+| Convention | Violation | Location | Severity | Blocks Completion | Recommended Action |
+|---|---|---|---|---|---|
 | ... | ... | ... | ... |
 ```
 
@@ -185,6 +198,7 @@ Add a `## Conventions` section with only durable patterns that pass the durabili
 - [ ] Git conventions are extracted from actual git history (not assumed)
 - [ ] Each convention has an adherence rate and evidence citation
 - [ ] Exceptions to conventions are listed (not hidden)
+- [ ] Convention violations include severity and blocking decision
 - [ ] `knowledge-base/16-conventions.md` exists and follows the output format
 - [ ] `coding-patterns.md` is enhanced with a Conventions section
 - [ ] Only patterns with >70% adherence are classified as conventions

package/templates/canonical/skills/dead-code-detector/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: dead-code-detector
+description: Detects unused exports, unreachable code paths, zombie dependencies, and stale modules by combining static analysis with git history.
+version: 1.0.0
+---
+
+# Dead Code Detector
+
+Use this skill during initialization, major refactors, dependency cleanup, and technical-debt reviews.
+
+## Procedure
+
+1. Scan imports/exports, route registrations, job registrations, dependency injection containers, and public entry points.
+2. Identify unused exports, unreferenced files, unreachable branches, feature flags that are always on/off, and manifest dependencies with no import/use evidence.
+3. Cross-reference `git-intelligence-engine` for stale modules, low ownership, and no recent changes.
+4. Avoid false positives for framework-discovered files, reflection, migrations, generated code, and public package exports.
+5. Produce candidates, not automatic deletions.
+
+## Output
+
+Write or update `knowledge-base/12-technical-debt.md`:
+
+```markdown
+## Dead Code Candidates
+| Candidate | Type | Confidence | Evidence | Safe Removal Steps |
+|---|---|---|---|---|
+```
+
+## Quality Gates
+
+- [ ] Static references were checked
+- [ ] Framework dynamic entry points were considered
+- [ ] Git staleness was included
+- [ ] Findings include confidence and safe-removal steps

package/templates/canonical/skills/engineering-change-review/SKILL.md

@@ -67,6 +67,16 @@ Review completed engineering work for correctness, completeness, and alignment w
 | Change record | Does the CHG record accurately reflect the work? |
 | Impact report | Was the impact report referenced correctly? |
 
+### 6. Rollback Readiness
+
+| Check | What to Verify |
+|---|---|
+| Medium+ rollback | Medium, high, and critical risk changes include rollback instructions |
+| Data rollback | Migration rollback, compensating SQL, or irreversible approval is recorded |
+| Feature flags | Flag rollback is documented where applicable |
+| Infrastructure | IaC or deployment rollback is documented where applicable |
+| CHG alignment | CHG record rollback section matches operations readiness |
+
 ## Finding Severity Scale
 
 | Severity | Symbol | Meaning | Action Required |
@@ -80,7 +90,7 @@ Review completed engineering work for correctness, completeness, and alignment w
 ## Procedure
 
 1. **Read Context** — Load the impact report, implementation diff, and test results.
-2. **Review Each Dimension** — Walk through all five review dimensions above.
+2. **Review Each Dimension** — Walk through all six review dimensions above.
 3. **Score Findings** — Assign severity to each finding.
 4. **Check Intelligence** — Verify graph, knowledge, memory, and context were appropriately synced.
 5. **Write Report** — Generate the review report.
@@ -129,6 +139,11 @@ Write `.engineering-intelligence/reports/REV-XXX-<slug>.md`:
 
 ## Stale Intelligence Risks
 - <areas where docs may drift from code>
+
+## Rollback Readiness
+| Area | Status | Evidence |
+|---|---|---|
+| Code rollback | ✅/⚠️/❌ | <CHG or operations-readiness evidence> |
 ```
 
 ## Rules
@@ -141,7 +156,7 @@ Write `.engineering-intelligence/reports/REV-XXX-<slug>.md`:
 
 ## Quality Gates
 
-- [ ] All five review dimensions were evaluated
+- [ ] All six review dimensions were evaluated
 - [ ] Each finding has severity, location, and evidence
 - [ ] Test execution was verified (not assumed)
 - [ ] Intelligence sync status was checked

package/templates/canonical/skills/engineering-intelligence-skill/SKILL.md

@@ -32,15 +32,17 @@ Classify the incoming request before starting:
 
 ### 1. Pre-Flight: Read Intelligence
 
-Read these artifacts and identify relevant context:
-- `knowledge-base/` — architecture, APIs, runtime flow relevant to the change
-- `.engineering-intelligence/aidlc/` — active AI-DLC state, plan, audit, open questions, construction units
-- `.engineering-intelligence/memory/` — decisions, constraints, patterns that apply
-- `.engineering-intelligence/context/` — module map, critical paths, dangerous areas near the change
-- `.engineering-intelligence/graph/` — dependency and service relationships
+Use `context-budget-optimizer` before loading broad intelligence. Do not read all of `knowledge-base/` or all graph JSON by default. Build `.engineering-intelligence/context/context-manifest.md`, then load only relevant slices:
+- `knowledge-base/` — only H2 sections relevant to the changed modules, APIs, schemas, or risk areas
+- `.engineering-intelligence/aidlc/` — `aidlc-state.md`, active checkpoint, active unit, acceptance criteria, and execution-plan rows relevant to the request
+- `.engineering-intelligence/memory/` — only matching decisions, constraints, conventions, regression patterns, and ADR references
+- `.engineering-intelligence/context/` — module/service/runtime rows near the change scope
+- `.engineering-intelligence/graph/` — only relevant nodes/edges by graph proximity
 
 **If intelligence is missing or stale**: Run `initialize-intelligence-skill` first.
 
+Token rule: keep initial intelligence loading under 40% of the available context budget whenever possible. Lazy-load safety-gate evidence only when the trigger applies.
+
 #### Pre-Flight Freshness Gate
 
 Before impact analysis or code edits:
@@ -49,7 +51,9 @@ Before impact analysis or code edits:
 2. Run `staleness-detector` scoped to those modules and related knowledge/context/memory artifacts.
 3. If any freshness score is below `60`, run `incremental-sync-engine` for the stale artifacts before editing product code, or explicitly mark stale context in the impact report with the affected documents and scores.
 4. If any score is below `50`, implementation is blocked until incremental sync runs or the user explicitly accepts stale-context risk.
-5. Skip stale H2 sections that carry low confidence metadata unless they are refreshed or verified against source.
+5. Use the `staleness-detector` **Pre-Implementation Drift Trigger** decision: `Proceed`, `Sync before implementation`, or `Block implementation`.
+6. Carry that exact decision into the impact report's freshness-gate line.
+7. Skip stale H2 sections that carry low confidence metadata unless they are refreshed or verified against source.
 
 ### 2. Impact Analysis: Write Report
 
@@ -139,7 +143,12 @@ When TDD delivery mode is selected:
 - Use environmental backpressure: analyze failed diagnostics, fix, and rerun the relevant command until it passes or a blocker is recorded
 - Run `type-safety-engine` for typed projects or record why no type system applies
 - Run `api-backward-compatibility-engine` when API, event, webhook, SDK, route, or schema contracts changed
+- Run `api-snapshot-testing-engine` when API response behavior can be replayed or sampled
 - Run `database-migration-safety-engine` when schema, ORM model, migration, index, or data persistence contracts changed
+- Run `security-audit-engine` in targeted dependency-risk mode when package manifests add or upgrade dependencies; critical CVEs block completion
+- Run `environment-variable-auditor` when environment variable reads, validation schemas, deployment config, or CI secrets change
+- Run `adr-compliance-checker` when accepted ADRs or architecture decisions apply to the changed area
+- Run `llm-prompt-injection-guard` when user-controlled data reaches prompts, RAG, agent tools, LLM calls, or durable AI memory
 - Write `.engineering-intelligence/aidlc/construction/<unit>/build-and-test/build-and-test-summary.md` for non-trivial units
 - **Never claim validation passed unless it actually ran and passed**
 - Record partial or failed validation honestly
@@ -199,9 +208,21 @@ Create `.changes/CHG-XXX-<summary>.md`:
 - Freshness gate: <passed|synced|stale risk accepted>
 - Type safety: <passed|failed|not applicable>
 - API compatibility: <passed|failed|not applicable>
+- API snapshots: <passed|failed|not applicable>
 - Migration safety: <passed|failed|not applicable>
+- Dependency security: <passed|failed|not applicable>
+- Environment variables: <passed|failed|not applicable>
+- ADR compliance: <passed|failed|not applicable>
+- LLM prompt injection: <passed|failed|not applicable>
 - Convention enforcement: <passed|findings>
 
+## Rollback
+- Code rollback: <git revert command or branch rollback>
+- Data rollback: <down migration / compensating operation / N/A with justification>
+- Feature flag rollback: <toggle / N/A with justification>
+- Infrastructure rollback: <IaC rollback / N/A with justification>
+- Irreversible steps requiring approval: <list or none>
+
 ## Related Reports
 - IMP-XXX: <link to impact report>
 - REV-XXX: <link to review report, if applicable>
@@ -242,6 +263,12 @@ Summarize to the user:
 - [ ] Acceptance criteria are mapped to validation evidence
 - [ ] Acceptance Criteria Verification Matrix has no unmapped criteria unless recorded as open items
 - [ ] Type safety, API compatibility, and migration safety gates ran when applicable
+- [ ] API snapshot replay ran for changed API behavior when feasible
+- [ ] Dependency security ran for new or upgraded packages
+- [ ] Environment variable audit ran when config/env usage changed
+- [ ] ADR compliance checked applicable accepted decisions
+- [ ] LLM prompt injection guard ran for LLM/user-input paths
+- [ ] Medium-and-above risk changes include rollback instructions or explicit N/A justification
 - [ ] Environmental backpressure was used for validation failures
 - [ ] Change record references the correct impact report
 - [ ] High-risk changes went through review gate
@@ -249,6 +276,6 @@ Summarize to the user:
 
 ## Cross-References
 
-- Depends on: `initialize-intelligence-skill` (prerequisite), `change-detection-engine`, `impact-analysis-engine`, `graph-engine`, `staleness-detector`
-- Uses during execution: `testing-intelligence-engine`, `type-safety-engine`, `api-backward-compatibility-engine`, `database-migration-safety-engine`, `incremental-sync-engine`, `change-history-engine`
+- Depends on: `initialize-intelligence-skill` (prerequisite), `context-budget-optimizer`, `change-detection-engine`, `impact-analysis-engine`, `graph-engine`, `staleness-detector`
+- Uses during execution: `testing-intelligence-engine`, `api-snapshot-testing-engine`, `type-safety-engine`, `api-backward-compatibility-engine`, `database-migration-safety-engine`, `security-audit-engine`, `environment-variable-auditor`, `adr-compliance-checker`, `llm-prompt-injection-guard`, `incremental-sync-engine`, `change-history-engine`
 - Optional: `engineering-change-review` (for high-risk), `refactoring-planner` (for refactors), `convention-detector` (for convention compliance)

package/templates/canonical/skills/environment-variable-auditor/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: environment-variable-auditor
+description: Audits environment variable usage against examples, validation schemas, CI secrets, and deployment configuration.
+version: 1.0.0
+---
+
+# Environment Variable Auditor
+
+Use this skill when code adds, removes, or changes environment variables, configuration schemas, deployment manifests, or CI/CD secrets.
+
+## Procedure
+
+1. Detect environment variable reads:
+   - Node: `process.env.*`
+   - Python: `os.environ`, `os.getenv`
+   - Go: `os.Getenv`
+   - Ruby: `ENV[]`
+   - Java/Kotlin/C#: equivalent environment APIs
+2. Compare against `.env.example`, `.env.sample`, README setup docs, deployment manifests, CI secret declarations, and validation schemas such as Zod, envalid, pydantic, dotenv-safe, or custom config loaders.
+3. Flag:
+   - missing example entries
+   - missing validation/default
+   - stale example vars no longer used
+   - required vars not present in CI/deployment docs
+   - secrets accidentally committed or documented with real values
+4. Block completion for newly required production env vars without docs and validation.
+
+## Output
+
+Write `.engineering-intelligence/aidlc/construction/<unit>/environment-variable-audit.md`:
+
+```markdown
+# Environment Variable Audit: <unit>
+
+| Variable | Usage | Example Present | Validation Present | Deployment/CI Present | Risk |
+|---|---|---|---|---|---|
+
+## Required Fixes
+- <missing or stale env handling>
+```
+
+## Quality Gates
+
+- [ ] Env reads were scanned
+- [ ] Example files and validation schemas were checked
+- [ ] CI/deployment declarations were checked when present
+- [ ] New required env vars are documented and validated

package/templates/canonical/skills/impact-analysis-engine/SKILL.md

@@ -41,9 +41,11 @@ Determine what can break before changing code. Produce a reusable impact report
    - Query paths referencing changed schema fields from schema-to-query mapping
    - API clients or contract tests affected by additive, deprecated, or breaking API changes
 
-5. **Trace Transitive Impact** — Follow 2nd and 3rd order effects through the graph. Identify files that are indirectly affected by consumers of the directly affected modules. Walk the dependency chain until impact attenuates or reaches a service boundary.
+5. **Traverse Sensitive Data Paths** — Query `data-flow-graph.json` for sensitive-source to sensitive-sink reachability involving the changed scope. Sensitive data propagation to unencrypted channels, logs, analytics events, prompt/RAG memory, or unvalidated sinks escalates risk and becomes a security finding in the impact report.
 
-6. **Score Risk** — Assign risk based on:
+6. **Trace Transitive Impact** — Follow 2nd and 3rd order effects through the graph. Identify files that are indirectly affected by consumers of the directly affected modules. Walk the dependency chain until impact attenuates or reaches a service boundary.
+
+7. **Score Risk** — Assign risk based on:
 
 | Factor | Low | Medium | High | Critical |
 |---|---|---|---|---|
@@ -55,7 +57,7 @@ Determine what can break before changing code. Produce a reusable impact report
 | **Change coupling** | None | Low (1-2 coupled files) | Medium (3-5 coupled files) | High (6+ coupled files) |
 | **Hot path** | Cold path | Normal | Critical path | Revenue/security/SLO path |
 
-7. **Identify Validation Needs** — Map impact to required validation:
+8. **Identify Validation Needs** — Map impact to required validation:
 
 | Impact Area | Validation Required |
 |---|---|
@@ -66,9 +68,9 @@ Determine what can break before changing code. Produce a reusable impact report
 | UI change | Visual regression, accessibility |
 | Infrastructure | Deploy to staging, smoke test |
 
-8. **Map Intelligence Artifacts** — Determine which intelligence artifacts need synchronization after the change is implemented.
+9. **Map Intelligence Artifacts** — Determine which intelligence artifacts need synchronization after the change is implemented.
 
-> **Surprise Impact Detection**: Flag any dependency discovered during analysis that is NOT in the current graph — these are surprise impacts that should be added to the graph. Surprise impacts indicate missing edges or nodes and must be reported in the Unknowns section of the impact report.
+> **Surprise Impact Detection**: Flag any dependency discovered during analysis that is NOT in the current graph. Submit the edge to `graph-engine` incremental mode as an `inferred` edge with evidence so the graph learns from the surprise. Surprise impacts must also be reported in the Unknowns section of the impact report until the graph update is complete.
 
 ## Output Format
 
@@ -105,6 +107,7 @@ Write `.engineering-intelligence/reports/IMP-XXX-<slug>.md`:
 |---|---|---|
 | API <name> | additive | api-backward-compatibility-engine |
 | Table.column | schema-to-query impact | database-migration-safety-engine |
+| Sensitive data path | unencrypted sink | security-audit-engine |
 
 ## Risk Assessment
 - Overall risk: <level>
@@ -145,6 +148,8 @@ Write `.engineering-intelligence/reports/IMP-XXX-<slug>.md`:
 - [ ] Direct and indirect impact are separated
 - [ ] Type-level dependencies are traced for typed languages
 - [ ] API and schema/query impact are classified when relevant
+- [ ] Sensitive data path traversal was performed for data-flow changes
+- [ ] Surprise impacts were submitted to graph-engine incremental mode
 - [ ] Risk score is justified with evidence
 - [ ] Validation requirements are specific (not generic)
 - [ ] Report ends with the "did not modify product code" statement

package/templates/canonical/skills/llm-prompt-injection-guard/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: llm-prompt-injection-guard
+description: Detects user-input-to-LLM prompt injection paths, unsafe RAG ingestion, unvalidated LLM outputs, and poisoned AI memory/documentation flows.
+version: 1.0.0
+---
+
+# LLM Prompt Injection Guard
+
+Use this skill for AI-augmented applications, RAG pipelines, agent tools, prompt builders, chat handlers, knowledge ingestion, or any code that sends user-controlled data to an LLM.
+
+## Procedure
+
+1. Detect LLM calls, prompt templates, tool outputs, embedding pipelines, document ingestion, and agent memory writes.
+2. Trace user-controlled sources into prompts, system messages, tool descriptions, retrieval documents, logs, knowledge-base files, and memory files.
+3. Flag missing controls:
+   - no prompt boundary separation
+   - no input sanitization or quoting
+   - no output schema validation
+   - tool results trusted without validation
+   - externally sourced content written into durable memory without provenance
+   - secrets or policies exposed to user-influenced context
+4. Require adversarial tests for high-risk LLM paths.
+
+## Output
+
+Write `.engineering-intelligence/reports/LLM-PROMPT-INJECTION-<slug>.md`:
+
+```markdown
+# LLM Prompt Injection Review: <summary>
+
+## Data Paths
+| Source | LLM / Memory Sink | Control Present | Risk | Evidence |
+|---|---|---|---|---|
+
+## Findings
+- <prompt injection or output validation risk>
+
+## Required Tests
+- <adversarial test cases>
+```
+
+## Quality Gates
+
+- [ ] LLM calls and memory/document ingestion paths were inventoried
+- [ ] User-controlled sources were traced to LLM and durable-memory sinks
+- [ ] Output validation was checked
+- [ ] High-risk paths have adversarial tests or blocking findings

package/templates/canonical/skills/memory-sync-engine/SKILL.md

@@ -24,6 +24,10 @@ Maintain durable, long-lived engineering memory. Memory is for decisions and pat
 | `technology-decisions.md` | Stack choices, framework versions, deprecation timelines, migration plans | Dependency updates, technology migrations |
 | `regression-patterns.md` | Recurring bug categories and proven regression test templates | Bugfixes that reveal reusable failure patterns |
 
+## Regression Pattern Ownership
+
+Testing Intelligence Engine owns detection and proposal of regression patterns during bugfix validation. Memory Sync owns durable persistence to `.engineering-intelligence/memory/regression-patterns.md` after confirming the pattern is reusable and evidence-backed. Testing Intelligence must not directly persist durable memory unless it is explicitly running through Memory Sync.
+
 ## Staleness Detection Rules
 
 A memory entry may be stale if:

package/templates/canonical/skills/operations-readiness-engine/SKILL.md

@@ -8,6 +8,8 @@ version: 1.0.0
 
 Use this skill when a change affects deployment, infrastructure, runtime behavior, SLOs, data migrations, incident response, or production monitoring.
 
+For medium-and-above risk changes, use the rollback planning section even when the change is not deployment-bound. Rollback planning is a release safety gate, not only an infrastructure concern.
+
 ## Procedure
 
 1. Identify deployment target, environment variables, infrastructure files, CI/CD gates, and runtime services.