@crewpilot/agent 2.0.0 → 3.0.0

package/prompts/skills/assure-review-standards/SKILL.md

@@ -1,106 +1,106 @@
-# Code Review — Standards & Conventions
-
-> **Pillar**: Assure | **ID**: `assure-review-standards`
-
-## Purpose
-
-Focused code review that evaluates **coding standards, naming conventions, test patterns, and consistency** with the existing codebase. Separated from functional review so each can be delegated to a specialized subagent or run independently.
-
-## Activation Triggers
-
-- "standards review", "conventions check", "consistency review", "does this match our style"
-- Automatically invoked by autopilot-worker Phase 6 via subagent delegation (role: `standards-reviewer`)
-- Can be run standalone for targeted reviews
-
-## Methodology
-
-### Step 1 — Discover Codebase Conventions
-
-Before reviewing, establish the project's conventions by scanning:
-1. **Naming**: variable/function/class naming style (camelCase, snake_case, PascalCase)
-2. **File structure**: directory layout, module organization, barrel exports
-3. **Error handling**: how errors are thrown/caught/logged (Result types? try/catch? error codes?)
-4. **Test patterns**: test framework, file naming (`*.test.ts` vs `*.spec.ts`), describe/it structure, setup/teardown
-5. **Import style**: absolute vs relative, barrel imports, import ordering
-6. **Type patterns**: explicit types vs inference, use of `any`, union types vs enums
-
-Read `.editorconfig`, `.eslintrc`, `tsconfig.json`, or similar config files if they exist.
-
-### Step 2 — Convention Compliance Check
-
-For each changed file, check against the discovered conventions:
-
-| Category | What to Check |
-|----------|---------------|
-| **Naming** | Functions, variables, types, files match project style |
-| **Structure** | New files placed in correct directory, exports follow project pattern |
-| **Error handling** | Matches project's error handling style (not just "has error handling") |
-| **Tests** | Test file structure mirrors source, uses same describe/it/expect patterns |
-| **Types** | Follows project's type annotation style (strict types vs inference) |
-| **Imports** | Import ordering, relative vs absolute paths, no circular imports |
-| **Comments** | JSDoc where project uses JSDoc, no commented-out code |
-
-### Step 3 — Consistency Analysis
-
-1. Compare the diff against the 5 nearest files in the same directory
-2. Flag any deviation from the local style (even if technically valid)
-3. Check for copy-paste code that should be extracted
-4. Verify new code follows the same patterns as existing code in the same module
-
-### Step 4 — Pattern Detection Integration
-
-1. Query `catalyst_knowledge_search` (type: `pattern`) for known conventions and anti-patterns
-2. Check if any flagged deviation is a **repeat offense** from past reviews
-3. If repeat offense found, flag prominently:
-   ```
-   ⚠️ Recurring Convention Violation: {description}
-   Previously flagged in: {previous context}
-   Suggestion: Consider adding a lint rule or pre-commit hook.
-   ```
-
-### Synthesis
-
-1. Categorize findings: `convention-violation | inconsistency | repeat-offense | suggestion`
-2. Filter by confidence threshold
-3. Group by category
-4. If invoked as subagent, write output as artifact via `catalyst_artifact_write` (phase: `review-standards`)
-
-## Tools Required
-
-- `catalyst_knowledge_search` — Query known patterns and past convention violations
-- `catalyst_artifact_write` — Persist review findings as artifact (when run as subagent)
-- `catalyst_artifact_read` — Read prior analysis artifacts for context
-
-## Output Format
-
-```
-## [Catalyst → Standards Review]
-
-### Summary
-{N} findings across {files}: {violations} violations, {inconsistencies} inconsistencies, {repeat} repeat offenses
-
-### Convention Violations
-| Category | File:Line | Convention | Violation | Fix |
-|----------|-----------|------------|-----------|-----|
-| ...      | ...       | ...        | ...       | ... |
-
-### Inconsistencies
-| File:Line | Expected Pattern | Actual | Nearest Example |
-|-----------|------------------|--------|-----------------|
-| ...       | ...              | ...    | ...             |
-
-### Repeat Offenses
-| Issue | Previous Occurrence | Suggestion |
-|-------|---------------------|------------|
-| ...   | ...                 | ...        |
-
-### Verdict
-{PASS | PASS_WITH_WARNINGS | FAIL}
-Confidence: {N}/10
-```
-
-## Chains To
-
-- `assure-review-functional` — Companion skill for correctness/security/performance review
-- `assure-code-quality` — Full 4-pass review (superset of this skill)
-- `insights-pattern-detection` — Deep codebase-wide pattern analysis
+# Code Review — Standards & Conventions
+
+> **Pillar**: Assure | **ID**: `assure-review-standards`
+
+## Purpose
+
+Focused code review that evaluates **coding standards, naming conventions, test patterns, and consistency** with the existing codebase. Separated from functional review so each can be delegated to a specialized subagent or run independently.
+
+## Activation Triggers
+
+- "standards review", "conventions check", "consistency review", "does this match our style"
+- Automatically invoked by autopilot-worker Phase 6 via subagent delegation (role: `standards-reviewer`)
+- Can be run standalone for targeted reviews
+
+## Methodology
+
+### Step 1 — Discover Codebase Conventions
+
+Before reviewing, establish the project's conventions by scanning:
+1. **Naming**: variable/function/class naming style (camelCase, snake_case, PascalCase)
+2. **File structure**: directory layout, module organization, barrel exports
+3. **Error handling**: how errors are thrown/caught/logged (Result types? try/catch? error codes?)
+4. **Test patterns**: test framework, file naming (`*.test.ts` vs `*.spec.ts`), describe/it structure, setup/teardown
+5. **Import style**: absolute vs relative, barrel imports, import ordering
+6. **Type patterns**: explicit types vs inference, use of `any`, union types vs enums
+
+Read `.editorconfig`, `.eslintrc`, `tsconfig.json`, or similar config files if they exist.
+
+### Step 2 — Convention Compliance Check
+
+For each changed file, check against the discovered conventions:
+
+| Category | What to Check |
+|----------|---------------|
+| **Naming** | Functions, variables, types, files match project style |
+| **Structure** | New files placed in correct directory, exports follow project pattern |
+| **Error handling** | Matches project's error handling style (not just "has error handling") |
+| **Tests** | Test file structure mirrors source, uses same describe/it/expect patterns |
+| **Types** | Follows project's type annotation style (strict types vs inference) |
+| **Imports** | Import ordering, relative vs absolute paths, no circular imports |
+| **Comments** | JSDoc where project uses JSDoc, no commented-out code |
+
+### Step 3 — Consistency Analysis
+
+1. Compare the diff against the 5 nearest files in the same directory
+2. Flag any deviation from the local style (even if technically valid)
+3. Check for copy-paste code that should be extracted
+4. Verify new code follows the same patterns as existing code in the same module
+
+### Step 4 — Pattern Detection Integration
+
+1. Query `crewpilot_knowledge_search` (type: `pattern`) for known conventions and anti-patterns
+2. Check if any flagged deviation is a **repeat offense** from past reviews
+3. If repeat offense found, flag prominently:
+   ```
+   ⚠️ Recurring Convention Violation: {description}
+   Previously flagged in: {previous context}
+   Suggestion: Consider adding a lint rule or pre-commit hook.
+   ```
+
+### Synthesis
+
+1. Categorize findings: `convention-violation | inconsistency | repeat-offense | suggestion`
+2. Filter by confidence threshold
+3. Group by category
+4. If invoked as subagent, write output as artifact via `crewpilot_artifact_write` (phase: `review-standards`)
+
+## Tools Required
+
+- `crewpilot_knowledge_search` — Query known patterns and past convention violations
+- `crewpilot_artifact_write` — Persist review findings as artifact (when run as subagent)
+- `crewpilot_artifact_read` — Read prior analysis artifacts for context
+
+## Output Format
+
+```
+## [CrewPilot → Standards Review]
+
+### Summary
+{N} findings across {files}: {violations} violations, {inconsistencies} inconsistencies, {repeat} repeat offenses
+
+### Convention Violations
+| Category | File:Line | Convention | Violation | Fix |
+|----------|-----------|------------|-----------|-----|
+| ...      | ...       | ...        | ...       | ... |
+
+### Inconsistencies
+| File:Line | Expected Pattern | Actual | Nearest Example |
+|-----------|------------------|--------|-----------------|
+| ...       | ...              | ...    | ...             |
+
+### Repeat Offenses
+| Issue | Previous Occurrence | Suggestion |
+|-------|---------------------|------------|
+| ...   | ...                 | ...        |
+
+### Verdict
+{PASS | PASS_WITH_WARNINGS | FAIL}
+Confidence: {N}/10
+```
+
+## Chains To
+
+- `assure-review-functional` — Companion skill for correctness/security/performance review
+- `assure-code-quality` — Full 4-pass review (superset of this skill)
+- `insights-pattern-detection` — Deep codebase-wide pattern analysis

package/prompts/skills/assure-threat-model/SKILL.md

@@ -1,182 +1,182 @@
-# Threat Model — STRIDE
-
-> **Pillar**: Assure | **ID**: `assure-threat-model`
-
-## Purpose
-
-Systematic threat modeling using the STRIDE framework. Identifies threats across Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Produces a threat register with risk scores and mitigations that informs design decisions and security reviews.
-
-## Activation Triggers
-
-- "threat model", "stride", "threat analysis", "security architecture"
-- "what could go wrong", "attack vectors", "threat register"
-- Label-gated: automatically invoked by autopilot-worker Phase 2.5d when `needs-threat-model` or `security-sensitive` label detected
-- Routed from `security-auditor` subagent role for architecture-level security analysis
-
-## Methodology
-
-### Process Flow
-
-```dot
-digraph threat_model {
-    rankdir=TB;
-    node [shape=box];
-
-    scope [label="Phase 1\nScope & Data Flow"];
-    decompose [label="Phase 2\nComponent Decomposition"];
-    stride [label="Phase 3\nSTRIDE Analysis"];
-    risk [label="Phase 4\nRisk Assessment"];
-    mitigate [label="Phase 5\nMitigation Planning"];
-    register [label="Phase 6\nThreat Register", shape=doublecircle];
-
-    scope -> decompose;
-    decompose -> stride;
-    stride -> risk;
-    risk -> mitigate;
-    mitigate -> register;
-}
-```
-
-### Phase 1 — Scope & Data Flow
-
-1. Define the system boundary — what's being threat-modeled (entire system, single feature, or API surface)
-2. Identify actors: end users, admins, external services, background jobs
-3. Map data flows:
-   - User input → processing → storage → output
-   - Service-to-service communication
-   - External API calls
-4. Identify trust boundaries:
-   - Authenticated vs unauthenticated zones
-   - Internal vs external network
-   - Client-side vs server-side
-   - Different privilege levels
-5. **(Optional) Fetch security context from M365**: If `mcp_workiq_ask_work_iq` is available, query for relevant compliance and security context:
-   - Call `mcp_workiq_accept_eula` with `eulaUrl: "https://github.com/microsoft/work-iq-mcp"` (idempotent)
-   - **Compliance requirements**: `mcp_workiq_ask_work_iq` → "What compliance requirements, security policies, or regulatory constraints apply to {system/feature}? Check emails, docs, and Teams messages."
-   - **Past security discussions**: `mcp_workiq_ask_work_iq` → "What security concerns or vulnerabilities have been discussed about {system/feature} in recent emails and meetings?"
-   - **Architecture decisions**: `mcp_workiq_ask_work_iq` → "What architecture or security design decisions were made about {system/feature} in meetings or design docs?"
-   - Feed this context into the STRIDE analysis to ensure threats are evaluated against the organization's actual compliance posture and known security concerns.
-   - If unavailable, proceed without — the threat model works from code analysis alone.
-
-### Phase 2 — Component Decomposition
-
-1. List each component in the data flow:
-   - Frontend (SPA, mobile app, CLI)
-   - API gateway / load balancer
-   - Application server(s)
-   - Database(s)
-   - Cache layer
-   - Message queue / event bus
-   - External services / third-party APIs
-   - File storage / CDN
-2. For each component, note:
-   - Technology stack
-   - Authentication mechanism
-   - Data stored/processed
-   - Network exposure (public, internal, VPN)
-
-### Phase 3 — STRIDE Analysis
-
-For each component and each data flow crossing a trust boundary, evaluate all six STRIDE categories:
-
-| Category | Threat | Key Questions |
-|----------|--------|---------------|
-| **S**poofing | Identity impersonation | Can an attacker pretend to be another user/service? Is authentication enforced at every entry point? Are tokens/sessions properly validated? |
-| **T**ampering | Data modification | Can data be modified in transit or at rest? Are inputs validated? Is there integrity checking (HMAC, checksums)? Can request parameters be manipulated? |
-| **R**epudiation | Deniability of actions | Are actions logged with sufficient detail? Can a user deny performing an action? Are audit logs tamper-proof? |
-| **I**nformation Disclosure | Data exposure | Can sensitive data leak through error messages, logs, API responses, or side channels? Is PII/secrets encrypted at rest and in transit? |
-| **D**enial of Service | Availability threats | Are there rate limits? Can a single request exhaust resources (memory, CPU, disk)? Are there circuit breakers? Can an attacker trigger expensive operations? |
-| **E**levation of Privilege | Unauthorized access | Can a regular user access admin functions? Are authorization checks at every layer (not just frontend)? Can parameters be manipulated to bypass access controls? |
-
-### Phase 4 — Risk Assessment
-
-For each identified threat, assess:
-
-1. **Likelihood** (1-5): How easy is this to exploit?
-   - 1 = Requires deep insider knowledge + sophisticated tools
-   - 3 = Moderately skilled attacker with publicly available tools
-   - 5 = Trivial exploitation, automated scanners can find it
-2. **Impact** (1-5): What's the damage if exploited?
-   - 1 = Minor inconvenience, no data loss
-   - 3 = Service disruption, limited data exposure
-   - 5 = Full data breach, system compromise, regulatory impact
-3. **Risk Score** = Likelihood × Impact (1-25)
-   - 1-6: Low → Accept or monitor
-   - 7-14: Medium → Mitigate within normal development
-   - 15-25: High/Critical → Block release until mitigated
-
-### Phase 5 — Mitigation Planning
-
-For each threat with risk score ≥ 7:
-
-1. Propose a specific mitigation (not generic "add security")
-2. Classify the mitigation:
-   - **Prevent**: Eliminate the threat entirely (e.g., parameterized queries for SQLi)
-   - **Detect**: Monitor and alert (e.g., anomaly detection for DoS)
-   - **Respond**: Limit damage (e.g., circuit breakers, rate limits)
-   - **Transfer**: Shift risk (e.g., use managed service with SLA)
-3. Estimate implementation effort: Low / Medium / High
-4. Identify which phase of the worker pipeline should implement the mitigation:
-   - Phase 4 (Implementation): Code-level fixes
-   - Phase 5 (Change Mgmt): Configuration changes
-   - Phase 7 (Deploy Guard): Operational checks
-
-### Phase 6 — Threat Register
-
-Compile all findings into a structured threat register and:
-1. Store via `catalyst_knowledge_store` (type: `threat-model`) for future reference
-2. Write as artifact via `catalyst_artifact_write` (phase: `threat-model`)
-3. Feed high-risk items into the Phase 3 plan as mandatory implementation steps
-
-## Tools Required
-
-- `catalyst_knowledge_store` — Store threat model for future reference
-- `catalyst_knowledge_search` — Query past threat models and security findings
-- `catalyst_artifact_write` — Persist threat register as workflow artifact
-- `catalyst_artifact_read` — Read analysis/architecture artifacts for context
-- `catalyst_metrics_complexity` — Identify complex code that may have more attack surface
-- `mcp_workiq_accept_eula` — (optional) Accept Work IQ EULA before first query
-- `mcp_workiq_ask_work_iq` — (optional) Query M365 for compliance requirements, security discussions, and architecture decisions
-
-## Output Format
-
-```
-## [Catalyst → Threat Model (STRIDE)]
-
-### Scope
-**System**: {what's being modeled}
-**Actors**: {user types}
-**Trust Boundaries**: {boundary list}
-
-### Data Flow Diagram
-```
-{text-based data flow: Actor → Component → Data Store → Output}
-```
-
-### Threat Register
-
-| ID | STRIDE | Component | Threat | Likelihood | Impact | Risk | Mitigation | Effort |
-|----|--------|-----------|--------|------------|--------|------|------------|--------|
-| T1 | S      | Auth API  | ...    | 4          | 5      | 20   | ...        | Medium |
-| T2 | T      | ...       | ...    | 3          | 3      | 9    | ...        | Low    |
-| ...| ...    | ...       | ...    | ...        | ...    | ...  | ...        | ...    |
-
-### Risk Summary
-- **Critical** (15-25): {count} threats → Must mitigate before release
-- **Medium** (7-14): {count} threats → Mitigate within sprint
-- **Low** (1-6): {count} threats → Accept/monitor
-
-### Recommended Mitigations (Priority Order)
-1. {T-ID}: {mitigation} — {effort} — Phase {N}
-2. {T-ID}: {mitigation} — {effort} — Phase {N}
-3. ...
-
-### Confidence: {N}/10
-```
-
-## Chains To
-
-- `assure-vulnerability-scan` — Complements STRIDE with OWASP/CWE code-level scanning
-- `assure-review-functional` — Security pass covers code-level implementation of mitigations
-- `strategize-architecture-planner` — Architecture decisions should reference the threat model
-- `insights-knowledge-base` — Past threat models inform future analysis
+# Threat Model — STRIDE
+
+> **Pillar**: Assure | **ID**: `assure-threat-model`
+
+## Purpose
+
+Systematic threat modeling using the STRIDE framework. Identifies threats across Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Produces a threat register with risk scores and mitigations that informs design decisions and security reviews.
+
+## Activation Triggers
+
+- "threat model", "stride", "threat analysis", "security architecture"
+- "what could go wrong", "attack vectors", "threat register"
+- Label-gated: automatically invoked by autopilot-worker Phase 2.5d when `needs-threat-model` or `security-sensitive` label detected
+- Routed from `security-auditor` subagent role for architecture-level security analysis
+
+## Methodology
+
+### Process Flow
+
+```dot
+digraph threat_model {
+    rankdir=TB;
+    node [shape=box];
+
+    scope [label="Phase 1\nScope & Data Flow"];
+    decompose [label="Phase 2\nComponent Decomposition"];
+    stride [label="Phase 3\nSTRIDE Analysis"];
+    risk [label="Phase 4\nRisk Assessment"];
+    mitigate [label="Phase 5\nMitigation Planning"];
+    register [label="Phase 6\nThreat Register", shape=doublecircle];
+
+    scope -> decompose;
+    decompose -> stride;
+    stride -> risk;
+    risk -> mitigate;
+    mitigate -> register;
+}
+```
+
+### Phase 1 — Scope & Data Flow
+
+1. Define the system boundary — what's being threat-modeled (entire system, single feature, or API surface)
+2. Identify actors: end users, admins, external services, background jobs
+3. Map data flows:
+   - User input → processing → storage → output
+   - Service-to-service communication
+   - External API calls
+4. Identify trust boundaries:
+   - Authenticated vs unauthenticated zones
+   - Internal vs external network
+   - Client-side vs server-side
+   - Different privilege levels
+5. **(Optional) Fetch security context from M365**: If `mcp_workiq_ask_work_iq` is available, query for relevant compliance and security context:
+   - Call `mcp_workiq_accept_eula` with `eulaUrl: "https://github.com/microsoft/work-iq-mcp"` (idempotent)
+   - **Compliance requirements**: `mcp_workiq_ask_work_iq` → "What compliance requirements, security policies, or regulatory constraints apply to {system/feature}? Check emails, docs, and Teams messages."
+   - **Past security discussions**: `mcp_workiq_ask_work_iq` → "What security concerns or vulnerabilities have been discussed about {system/feature} in recent emails and meetings?"
+   - **Architecture decisions**: `mcp_workiq_ask_work_iq` → "What architecture or security design decisions were made about {system/feature} in meetings or design docs?"
+   - Feed this context into the STRIDE analysis to ensure threats are evaluated against the organization's actual compliance posture and known security concerns.
+   - If unavailable, proceed without — the threat model works from code analysis alone.
+
+### Phase 2 — Component Decomposition
+
+1. List each component in the data flow:
+   - Frontend (SPA, mobile app, CLI)
+   - API gateway / load balancer
+   - Application server(s)
+   - Database(s)
+   - Cache layer
+   - Message queue / event bus
+   - External services / third-party APIs
+   - File storage / CDN
+2. For each component, note:
+   - Technology stack
+   - Authentication mechanism
+   - Data stored/processed
+   - Network exposure (public, internal, VPN)
+
+### Phase 3 — STRIDE Analysis
+
+For each component and each data flow crossing a trust boundary, evaluate all six STRIDE categories:
+
+| Category | Threat | Key Questions |
+|----------|--------|---------------|
+| **S**poofing | Identity impersonation | Can an attacker pretend to be another user/service? Is authentication enforced at every entry point? Are tokens/sessions properly validated? |
+| **T**ampering | Data modification | Can data be modified in transit or at rest? Are inputs validated? Is there integrity checking (HMAC, checksums)? Can request parameters be manipulated? |
+| **R**epudiation | Deniability of actions | Are actions logged with sufficient detail? Can a user deny performing an action? Are audit logs tamper-proof? |
+| **I**nformation Disclosure | Data exposure | Can sensitive data leak through error messages, logs, API responses, or side channels? Is PII/secrets encrypted at rest and in transit? |
+| **D**enial of Service | Availability threats | Are there rate limits? Can a single request exhaust resources (memory, CPU, disk)? Are there circuit breakers? Can an attacker trigger expensive operations? |
+| **E**levation of Privilege | Unauthorized access | Can a regular user access admin functions? Are authorization checks at every layer (not just frontend)? Can parameters be manipulated to bypass access controls? |
+
+### Phase 4 — Risk Assessment
+
+For each identified threat, assess:
+
+1. **Likelihood** (1-5): How easy is this to exploit?
+   - 1 = Requires deep insider knowledge + sophisticated tools
+   - 3 = Moderately skilled attacker with publicly available tools
+   - 5 = Trivial exploitation, automated scanners can find it
+2. **Impact** (1-5): What's the damage if exploited?
+   - 1 = Minor inconvenience, no data loss
+   - 3 = Service disruption, limited data exposure
+   - 5 = Full data breach, system compromise, regulatory impact
+3. **Risk Score** = Likelihood × Impact (1-25)
+   - 1-6: Low → Accept or monitor
+   - 7-14: Medium → Mitigate within normal development
+   - 15-25: High/Critical → Block release until mitigated
+
+### Phase 5 — Mitigation Planning
+
+For each threat with risk score ≥ 7:
+
+1. Propose a specific mitigation (not generic "add security")
+2. Classify the mitigation:
+   - **Prevent**: Eliminate the threat entirely (e.g., parameterized queries for SQLi)
+   - **Detect**: Monitor and alert (e.g., anomaly detection for DoS)
+   - **Respond**: Limit damage (e.g., circuit breakers, rate limits)
+   - **Transfer**: Shift risk (e.g., use managed service with SLA)
+3. Estimate implementation effort: Low / Medium / High
+4. Identify which phase of the worker pipeline should implement the mitigation:
+   - Phase 4 (Implementation): Code-level fixes
+   - Phase 5 (Change Mgmt): Configuration changes
+   - Phase 7 (Deploy Guard): Operational checks
+
+### Phase 6 — Threat Register
+
+Compile all findings into a structured threat register and:
+1. Store via `crewpilot_knowledge_store` (type: `threat-model`) for future reference
+2. Write as artifact via `crewpilot_artifact_write` (phase: `threat-model`)
+3. Feed high-risk items into the Phase 3 plan as mandatory implementation steps
+
+## Tools Required
+
+- `crewpilot_knowledge_store` — Store threat model for future reference
+- `crewpilot_knowledge_search` — Query past threat models and security findings
+- `crewpilot_artifact_write` — Persist threat register as workflow artifact
+- `crewpilot_artifact_read` — Read analysis/architecture artifacts for context
+- `crewpilot_metrics_complexity` — Identify complex code that may have more attack surface
+- `mcp_workiq_accept_eula` — (optional) Accept Work IQ EULA before first query
+- `mcp_workiq_ask_work_iq` — (optional) Query M365 for compliance requirements, security discussions, and architecture decisions
+
+## Output Format
+
+```
+## [CrewPilot → Threat Model (STRIDE)]
+
+### Scope
+**System**: {what's being modeled}
+**Actors**: {user types}
+**Trust Boundaries**: {boundary list}
+
+### Data Flow Diagram
+```
+{text-based data flow: Actor → Component → Data Store → Output}
+```
+
+### Threat Register
+
+| ID | STRIDE | Component | Threat | Likelihood | Impact | Risk | Mitigation | Effort |
+|----|--------|-----------|--------|------------|--------|------|------------|--------|
+| T1 | S      | Auth API  | ...    | 4          | 5      | 20   | ...        | Medium |
+| T2 | T      | ...       | ...    | 3          | 3      | 9    | ...        | Low    |
+| ...| ...    | ...       | ...    | ...        | ...    | ...  | ...        | ...    |
+
+### Risk Summary
+- **Critical** (15-25): {count} threats → Must mitigate before release
+- **Medium** (7-14): {count} threats → Mitigate within sprint
+- **Low** (1-6): {count} threats → Accept/monitor
+
+### Recommended Mitigations (Priority Order)
+1. {T-ID}: {mitigation} — {effort} — Phase {N}
+2. {T-ID}: {mitigation} — {effort} — Phase {N}
+3. ...
+
+### Confidence: {N}/10
+```
+
+## Chains To
+
+- `assure-vulnerability-scan` — Complements STRIDE with OWASP/CWE code-level scanning
+- `assure-review-functional` — Security pass covers code-level implementation of mitigations
+- `strategize-architecture-planner` — Architecture decisions should reference the threat model
+- `insights-knowledge-base` — Past threat models inform future analysis