@crewpilot/agent 1.0.0 → 3.0.0

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

@@ -0,0 +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 `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

package/prompts/skills/assure-vulnerability-scan/SKILL.md

@@ -98,7 +98,7 @@ Critical findings MUST be remediated before code is shipped.
 ## Output Format
 
 ```
-## [Catalyst → Vulnerability Scan]
+## [CrewPilot → Vulnerability Scan]
 
 ### Attack Surface
 - Entry points: {N}

package/prompts/skills/autopilot-meeting/SKILL.md

@@ -14,14 +14,17 @@ Specifically supports the **PM workflow**: customer meeting → epics → user s
 
 ## Tools Required
 
-- `catalyst_board_create` — create issues / user stories on board
-- `catalyst_board_create_epic` — create epics to group related stories
-- `catalyst_board_create_subtask` — create subtasks linked to a parent story
-- `catalyst_board_move` — update issue status for status updates
-- `catalyst_board_comment` — log blockers and decisions on existing issues
-- `catalyst_board_assign` — assign tasks to people mentioned in transcript
-- `catalyst_knowledge_store` — store decisions, customer context, and action items
-- `catalyst_worker_start` — optionally kick off autopilot for created tasks
+- `crewpilot_board_create` — create issues / user stories on board
+- `crewpilot_board_create_epic` — create epics to group related stories
+- `crewpilot_board_create_subtask` — create subtasks linked to a parent story
+- `crewpilot_board_move` — update issue status for status updates
+- `crewpilot_board_comment` — log blockers and decisions on existing issues
+- `crewpilot_board_assign` — assign tasks to people mentioned in transcript
+- `crewpilot_knowledge_store` — store decisions, customer context, and action items
+- `crewpilot_worker_start` — optionally kick off autopilot for created tasks
+- `mcp_workiq_accept_eula` — (optional) accept Work IQ EULA before first query
+- `mcp_workiq_ask_work_iq` — (optional, requires Work IQ extension) fetch meeting transcript and details from M365
+- `crewpilot_artifact_write` — persist extracted meeting data as artifacts
 
 ## Methodology
 
@@ -51,6 +54,30 @@ digraph autopilot_meeting {
 
 ### Phase 1 — Transcript Ingestion
 
+**Work IQ integration (zero-copy flow):** If the user specifies a meeting by name/date/subject (e.g. "parse yesterday's sprint planning" or "check my meeting discussion"):
+
+1. **Accept EULA first**: Call `mcp_workiq_accept_eula` with `eulaUrl: "https://github.com/microsoft/work-iq-mcp"`. This is idempotent — safe to call every time.
+2. **Query the meeting**: Call `mcp_workiq_ask_work_iq` with a focused question. Use targeted queries for better results:
+   - "What was discussed in the {meeting name} meeting on {date}?"
+   - "Summarize the transcript from my meeting with {person} on {date}"
+   - "What action items came out of the {project} meeting?"
+   - "What decisions were made in the {topic} meeting?"
+3. If Work IQ is available, the transcript, attendees, and action items are fetched automatically — no manual paste needed.
+4. **Cross-meeting context**: Query for prior decisions related to the same topic:
+   - "What decisions were made about {topic} in previous meetings?"
+   - "What was discussed about {feature/project} in earlier meetings this month?"
+   - This surfaces continuity across meetings — ensures new items don't contradict prior agreements.
+5. **Speaker identity enrichment**: Query the org chart for real names and roles:
+   - "Who is {speaker name}? What is their role and team?"
+   - Map speaker labels to real identities for accurate assignee attribution and RACI context.
+6. **Linked document references**: Query for documents referenced or shared during the meeting:
+   - "What documents, specs, or design docs were shared in the {meeting name} meeting?"
+   - "Find SharePoint/OneDrive documents related to {topic} shared recently"
+   - Attach linked docs to the relevant stories as context references.
+7. If `mcp_workiq_ask_work_iq` is unavailable or errors, fall back to the manual flow below.
+
+> **Data sensitivity**: Meeting transcripts may contain confidential information or PII. Do not include raw transcript excerpts with names or customer-identifying details in board items — summarize and anonymize.
+
 Accept transcript in any format:
 - Pasted text (most common)
 - File path to `.vtt`, `.txt`, or `.md` file (read via tools)
@@ -278,13 +305,13 @@ Execute in this order:
 
 **Step 1: Create Epics**
 For each epic:
-1. Call `catalyst_board_create_epic` with title, description, labels
+1. Call `crewpilot_board_create_epic` with title, description, labels
 2. Note the created epic issue ID
 
 **Step 2: Create User Stories**
 For each story:
 1. Build the full description with Summary, User Story statement, Acceptance Criteria, Technical Notes, Customer Context (if applicable), Dependencies
-2. Call `catalyst_board_create` with:
+2. Call `crewpilot_board_create` with:
    - title
    - structured description (see format below)
    - assignee
@@ -344,7 +371,7 @@ Investigate and fix: {symptom description — 1-2 sentences}
 
 **Step 3: Create Subtasks**
 For each story's subtasks:
-1. Call `catalyst_board_create_subtask` with:
+1. Call `crewpilot_board_create_subtask` with:
    - parent_id: the story's issue ID
    - title: `[Backend] Implement user authentication endpoint`
    - description: implementation details
@@ -353,13 +380,13 @@ For each story's subtasks:
 
 **Step 4: Status Updates, Blockers, Decisions**
 Same as before:
-- STATUS_UPDATE → `catalyst_board_comment` or `catalyst_board_move`
-- BLOCKER → `catalyst_board_comment` or create blocker issue
-- DECISION → `catalyst_knowledge_store` with type: "decision"
+- STATUS_UPDATE → `crewpilot_board_comment` or `crewpilot_board_move`
+- BLOCKER → `crewpilot_board_comment` or create blocker issue
+- DECISION → `crewpilot_knowledge_store` with type: "decision"
 - ACTION_ITEM → board issue or knowledge store
 
 **Step 5: Autopilot (optional)**
-If user requested autopilot → call `catalyst_worker_start` for each created story
+If user requested autopilot → call `crewpilot_worker_start` for each created story
 
 ### Phase 6 — Summary
 
@@ -377,7 +404,7 @@ Blockers:         {N} logged
 Decisions:        {N} stored in knowledge base
 Autopilot:        {N} workflows started (if any)
 
-Board: Use catalyst_board_view to see the full board
+Board: Use crewpilot_board_view to see the full board
 
 Dependency chain:
   Story #{X} → blocks → Story #{Y}