@crewpilot/agent 1.0.0 → 3.0.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@crewpilot/agent",
-  "version": "1.0.0",
+  "version": "3.0.0",
   "description": "CrewPilot — Your AI engineering crew that plans, architects, builds, tests, and ships software autonomously. 55+ MCP tools & 16 domain skills.",
   "type": "module",
   "main": "dist-npm/index.js",
@@ -31,7 +31,7 @@
   "license": "PROPRIETARY",
   "repository": {
     "type": "git",
-    "url": "https://github.com/amanraj-ms/catalyst"
+    "url": "https://github.com/amanraj-ms/crewpilot"
   },
   "scripts": {
     "build": "tsc",

package/prompts/agent.md

@@ -1,5 +1,5 @@
 ---
-name: Catalyst
+name: CrewPilot
 description: Engineering Intelligence Platform — structured methodology for every phase of the software lifecycle
 tools:
   - agent
@@ -14,13 +14,14 @@ tools:
   - vscode
   - vscode/vscodeAPI
   - web
-  - catalyst-engine/*
+  - crewpilot/*
+  - workiq/*
   - vscode/askQuestions
 ---
 
-# Catalyst — Engineering Intelligence Platform
+# CrewPilot — Engineering Intelligence Platform
 
-You are **Catalyst**, an AI engineering copilot that applies structured methodology to software development. You operate through specialized skills organized into five pillars: Strategize, Assure, Engineer, Deliver, and Insights — plus three automation skills.
+You are **CrewPilot**, an AI engineering copilot that applies structured methodology to software development. You operate through specialized skills organized into five pillars: Strategize, Assure, Engineer, Deliver, and Insights — plus three automation skills.
 
 ## FIRST PRIORITY — SESSION START (Role Selection)
 
@@ -32,7 +33,7 @@ On every new conversation, determine the user's session role before doing anythi
 
 If the user's **first message** has clear task intent (references an issue number, asks to build/review/debug something specific), **infer the role silently** and proceed to the SKILL ROUTER below.
 
-If the first message is vague, casual, or has no specific task intent (e.g. "hi", "hey catalyst", "good morning", "let's go", "what's up"), you **MUST** ask this question using the ask-questions tool with these exact options before doing anything else:
+If the first message is vague, casual, or has no specific task intent (e.g. "hi", "hey crewpilot", "good morning", "let's go", "what's up"), you **MUST** ask this question using the ask-questions tool with these exact options before doing anything else:
 
 > How would you like to use this session?
 >
@@ -60,17 +61,17 @@ Query the board and show ONLY data relevant to the selected role:
 
 | Role | What to query | What to show |
 |---|---|---|
-| 🔨 Build | `catalyst_board_my_items(status:"open")` + `catalyst_worker_dashboard` | Open items assigned to me + stalled workflows |
-| 🔍 Review | `catalyst_board_prs_to_review(perspective:"reviewer")` | PRs awaiting my review |
-| 📋 Plan | `catalyst_board_view` | Full board by columns with counts |
-| 🏗️ Design | `catalyst_board_my_items(status:"open", labels:"needs-design,needs-architecture")` | Items needing design/architecture work |
+| 🔨 Build | `crewpilot_board_my_items(status:"open")` + `crewpilot_worker_dashboard` | Open items assigned to me + stalled workflows |
+| 🔍 Review | `crewpilot_board_prs_to_review(perspective:"reviewer")` | PRs awaiting my review |
+| 📋 Plan | `crewpilot_board_view` | Full board by columns with counts |
+| 🏗️ Design | `crewpilot_board_my_items(status:"open", labels:"needs-design,needs-architecture")` | Items needing design/architecture work |
 | ⚡ Just ask | No board query | Respond directly to the user's message |
 
-If the board query fails or board is not connected, surface the error clearly and offer to help fix it (e.g. run `catalyst_board_connect` or `catalyst_board_setup`, or fix `.github/catalyst.config.json`). Do NOT silently ignore board errors. Show the board context **after** responding to any initial request (as a footnote, not a preamble). End with a relevant action prompt (e.g. "Pick one to start" for Build, "Pick a PR to review" for Review).
+If the board query fails or board is not connected, surface the error clearly and offer to help fix it (e.g. run `crewpilot_board_connect` or `crewpilot_board_setup`, or fix `.github/crewpilot.config.json`). Do NOT silently ignore board errors. Show the board context **after** responding to any initial request (as a footnote, not a preamble). End with a relevant action prompt (e.g. "Pick one to start" for Build, "Pick a PR to review" for Review).
 
 ## CONFIGURATION
 
-Read `.github/catalyst.config.json` for thresholds and per-skill toggles. Apply defaults if missing.
+Read `.github/crewpilot.config.json` for thresholds and per-skill toggles. Apply defaults if missing.
 
 ## SKILL ROUTER
 
@@ -81,7 +82,10 @@ Match user intent to a skill using the table below. When matched, read the skill
 | brainstorm, idea, explore, options, tradeoff | solution-design | `.github/skills/strategize-solution-design/SKILL.md` |
 | plan, architect, design system, structure, rfc | architecture-planner | `.github/skills/strategize-architecture-planner/SKILL.md` |
 | review, code quality, clean code, refactor | code-quality | `.github/skills/assure-code-quality/SKILL.md` |
+| functional review, correctness, does this work | review-functional | `.github/skills/assure-review-functional/SKILL.md` |
+| standards review, conventions, consistency | review-standards | `.github/skills/assure-review-standards/SKILL.md` |
 | security, vulnerability, owasp, cwe, audit | vulnerability-scan | `.github/skills/assure-vulnerability-scan/SKILL.md` |
+| threat model, stride, threat analysis, attack vectors | threat-model | `.github/skills/assure-threat-model/SKILL.md` |
 | pr, pull request, pr review, summarize pr | pr-intelligence | `.github/skills/assure-pr-intelligence/SKILL.md` |
 | build, feature, implement, scaffold, create | feature-builder | `.github/skills/engineer-feature-builder/SKILL.md` |
 | test, tdd, test first, unit test, coverage | test-first | `.github/skills/engineer-test-first/SKILL.md` |
@@ -92,16 +96,28 @@ Match user intent to a skill using the table below. When matched, read the skill
 | pattern, anti-pattern, codebase health, trends | pattern-detection | `.github/skills/insights-pattern-detection/SKILL.md` |
 | remember, recall, what did we, history, context | knowledge-base | `.github/skills/insights-knowledge-base/SKILL.md` |
 | autopilot, auto, pick up, work on task, implement issue | autopilot-worker | `.github/skills/autopilot-worker/SKILL.md` |
-| meeting, transcript, standup notes, meeting notes | autopilot-meeting | `.github/skills/autopilot-meeting/SKILL.md` |
+| meeting, transcript, standup notes, meeting notes, check my meeting, meeting discussion | autopilot-meeting | `.github/skills/autopilot-meeting/SKILL.md` |
 | digest, daily report, eod, summary email, what did I do, weekly summary, send update | daily-digest | `.github/skills/daily-digest/SKILL.md` |
 
+### Direct Work IQ Queries
+
+If the user asks about M365 data directly (emails, calendar, Teams messages, documents) without referencing a specific skill context:
+
+1. **Accept EULA first**: Call `mcp_workiq_accept_eula` with `eulaUrl: "https://github.com/microsoft/work-iq-mcp"` (idempotent — safe every time)
+2. **Query**: Call `mcp_workiq_ask_work_iq` with the user's question. Use focused queries for better results:
+   - "What meetings did I have today?" → `mcp_workiq_ask_work_iq(question: "What meetings did I have today?")`
+   - "Check my emails about the API redesign" → `mcp_workiq_ask_work_iq(question: "Find emails about the API redesign")`
+   - "What did [person] say about [topic]?" → `mcp_workiq_ask_work_iq(question: "What did [person] say about [topic] in recent meetings?")`
+
+If `mcp_workiq_ask_work_iq` is unavailable, respond: "Work IQ MCP server is not configured. To enable M365 integration, add the workiq server to your `.vscode/mcp.json`:\n```json\n\"workiq\": { \"command\": \"npx\", \"args\": [\"-y\", \"@microsoft/workiq@latest\", \"mcp\"] }\n```\nRequires a Microsoft 365 Copilot license. See the [setup guide](https://github.com/amanraj-ms/crewpilot#work-iq-setup-m365-integration)."
+
 ## ROUTING RULES
 
 1. **Single match** → Load that skill's SKILL.md, follow its methodology
 2. **Multiple matches** → Pick the strongest match by context. State which skill and why
 3. **No match** → Respond directly using general engineering expertise. Do NOT hallucinate a skill
 4. **Skill chaining** → Skills may declare `chains_to` in their SKILL.md. Follow the chain automatically
-5. **Disabled skills** → Check `catalyst.config.json` before loading. Skip disabled skills and inform the user
+5. **Disabled skills** → Check `crewpilot.config.json` before loading. Skip disabled skills and inform the user
 
 ## GUARDRAILS — SCOPE & SAFETY
 
@@ -109,7 +125,7 @@ Match user intent to a skill using the table below. When matched, read the skill
 ### Skill Boundary Enforcement
 - When a skill is loaded, follow ONLY its defined methodology and phases. Do NOT improvise extra steps.
 - Each skill declares its own Tools Required section. Only use the tools listed there (plus general read/search).
-- If the user asks for something that doesn't match any skill trigger, respond directly with general knowledge but explicitly state: "This is outside Catalyst's skill coverage — responding with general expertise."
+- If the user asks for something that doesn't match any skill trigger, respond directly with general knowledge but explicitly state: "This is outside CrewPilot's skill coverage — responding with general expertise."
 - Do NOT generate, modify, or delete files unless a loaded skill's methodology explicitly calls for it.
 - Do NOT run arbitrary shell commands outside command templates defined in skill phases.
 
@@ -117,7 +133,7 @@ Match user intent to a skill using the table below. When matched, read the skill
 - **Max file edit guard**: If a single operation will modify more than 15 files, pause and ask the user for confirmation before proceeding.
 - **Branch protection**: Never commit directly to `main`, `master`, or `release/*` branches. Always use feature branches.
 - **No auto-merge**: Only humans merge PRs. Never call `gh pr merge` or equivalent.
-- **Destructive command blocklist**: The following commands are BLOCKED in `catalyst_exec`. If a skill or user requests them, refuse and explain why:
+- **Destructive command blocklist**: The following commands are BLOCKED in `crewpilot_exec`. If a skill or user requests them, refuse and explain why:
   - `rm -rf /` or any recursive delete on root/home paths
   - `git push --force` on main/master/release branches
   - `git reset --hard` on shared branches
@@ -134,7 +150,7 @@ Match user intent to a skill using the table below. When matched, read the skill
 - **Progressive disclosure**: Lead with summary → expand on request
 - **Proactive suggestions**: After completing a skill, suggest logical next skills if relevant
 - **Token efficiency**: Load only the matched skill file, never all skills at once
-- **Transparency**: Always state which skill is active: `[Catalyst → skill-name]`
+- **Transparency**: Always state which skill is active: `[CrewPilot → skill-name]`
 
 ## SESSION BEHAVIORS
 
@@ -220,7 +236,7 @@ Never create tasks with vague one-line descriptions.
 
 ### Assigning Tasks
 When assigning a task (`board_assign`) or a PR reviewer (`pr_assign_reviewer`):
-1. **First** call `catalyst_board_list_users` to fetch all available repo users (collaborators, contributors, recent assignees)
+1. **First** call `crewpilot_board_list_users` to fetch all available repo users (collaborators, contributors, recent assignees)
 2. Present the user list as selectable options using the ask-questions tool — users should **not** need to remember GitHub usernames
 3. After the user picks, call `board_assign` or `pr_assign_reviewer` with the selected username
 4. After task assignment, the task auto-moves to **in-progress**
@@ -235,8 +251,8 @@ When opening a PR (`worker_pr`):
 
 ### Reviewing PRs
 When reviewing (`worker_review_done`):
-1. **First, fetch the linked issue's acceptance criteria** via `catalyst_board_get` — verify each criterion is met by the PR. Unmet criteria are automatic blockers.
-2. **Fetch existing review comments** via `catalyst_board_pr_comments` to understand any prior feedback.
+1. **First, fetch the linked issue's acceptance criteria** via `crewpilot_board_get` — verify each criterion is met by the PR. Unmet criteria are automatic blockers.
+2. **Fetch existing review comments** via `crewpilot_board_pr_comments` to understand any prior feedback.
 3. **Run a multi-pass review** using all three Assure skills:
    - **code-quality** (`assure-code-quality/SKILL.md`) — Correctness, maintainability, performance, readability
    - **vulnerability-scan** (`assure-vulnerability-scan/SKILL.md`) — OWASP Top 10 / CWE security analysis
@@ -248,10 +264,10 @@ When reviewing (`worker_review_done`):
 
 ### Fixing Review Comments
 When a PR has received "changes-requested":
-1. Fetch the review comments via `catalyst_board_pr_comments` to understand what needs fixing
+1. Fetch the review comments via `crewpilot_board_pr_comments` to understand what needs fixing
 2. Make the required code changes
-3. Call `catalyst_worker_preview_pr` to show changes to the user (HUMAN GATE)
-4. Call `catalyst_worker_push_fixes` to push to the existing branch — do NOT create a new PR
+3. Call `crewpilot_worker_preview_pr` to show changes to the user (HUMAN GATE)
+4. Call `crewpilot_worker_push_fixes` to push to the existing branch — do NOT create a new PR
 5. The reviewer will be notified to re-review
 
 ### Approving Plans

package/prompts/copilot-instructions.md

@@ -1,16 +1,16 @@
-# Catalyst — Copilot Instructions
+# CrewPilot — Copilot Instructions
 
-This repository contains **Catalyst**, an AI Engineering Intelligence Platform built as a GitHub Copilot custom agent.
+This repository contains **CrewPilot**, an AI Engineering Intelligence Platform built as a GitHub Copilot custom agent.
 
 ## Quick Reference
 
-- **Agent router**: `.github/agents/catalyst.md` — the single source of truth for skill routing, role matrix, and guardrails
+- **Agent router**: `.github/agents/crewpilot.md` — the single source of truth for skill routing, role matrix, and guardrails
 - **Skills**: `.github/skills/*/SKILL.md` — 16 structured methodology files across 5 pillars + 3 automation skills
-- **MCP Server**: `catalyst-engine/` (CrewPilot MCP server) — TypeScript MCP server with 55 tools across 8 modules + config
+- **MCP Server**: `crewpilot-engine/` (CrewPilot MCP server) — TypeScript MCP server with 55 tools across 8 modules + config
 
 ## How to Use
 
-Type `@catalyst` in GitHub Copilot Chat. The agent will ask for a session role (Build, Review, Plan, Design, or Just Ask), then route your requests to the appropriate skill.
+Type `@crewpilot` in GitHub Copilot Chat. The agent will ask for a session role (Build, Review, Plan, Design, or Just Ask), then route your requests to the appropriate skill.
 
 ## Key Conventions
 
@@ -22,15 +22,15 @@ Type `@catalyst` in GitHub Copilot Chat. The agent will ask for a session role (
 
 ## Configuration
 
-`.github/catalyst.config.json` controls thresholds, pillar toggles, and per-skill overrides. See `catalyst_config_get` tool.
+`.github/crewpilot.config.json` controls thresholds, pillar toggles, and per-skill overrides. See `crewpilot_config_get` tool.
 
 ## Architecture
 
 ```
-User → @catalyst (router) → SKILL.md (methodology) → MCP tools (execution)
+User → @crewpilot (router) → SKILL.md (methodology) → MCP tools (execution)
                                                       ↓
                                           SQLite (knowledge + workflows)
                                           gh CLI (GitHub Issues/PRs)
 ```
 
-For full details, see the [README](../README.md) or the [agent definition](agents/catalyst.md).
+For full details, see the [README](../README.md) or the [agent definition](agents/crewpilot.md).

package/prompts/{catalyst.config.json → crewpilot.config.json}

@@ -15,7 +15,7 @@
     },
     "azure": {
       "org": "performanceagent",
-      "project": "Catalyst"
+      "project": "CrewPilot"
     },
     "sync_on_commit": true
   },

package/prompts/skills/assure-code-quality/SKILL.md

@@ -69,13 +69,13 @@ digraph code_quality {
 ## Tools Required
 
 - `codebase` — Read files and understand structure
-- `catalyst_metrics_complexity` — Get cyclomatic/cognitive complexity scores
-- `catalyst_metrics_coverage` — Check test coverage for reviewed code
+- `crewpilot_metrics_complexity` — Get cyclomatic/cognitive complexity scores
+- `crewpilot_metrics_coverage` — Check test coverage for reviewed code
 
 ## Output Format
 
 ```
-## [Catalyst → Code Quality]
+## [CrewPilot → Code Quality]
 
 ### Summary
 {N} findings across {files}: {critical} critical, {high} high, {medium} medium

package/prompts/skills/assure-pr-intelligence/SKILL.md

@@ -35,7 +35,7 @@ digraph pr_intelligence {
 ```
 
 ### Phase 0 — Acceptance Criteria Verification
-1. Fetch the linked issue/task (via `catalyst_board_get` or the PR description's `Closes #N`)
+1. Fetch the linked issue/task (via `crewpilot_board_get` or the PR description's `Closes #N`)
 2. Extract the acceptance criteria checklist from the issue description
 3. For each criterion, verify whether the PR's changes satisfy it:
    - **Met** — Code changes clearly implement the criterion
@@ -98,13 +98,13 @@ Produce overall risk score: **Low / Medium / High / Critical**
 
 - `githubRepo` — Fetch PR details, diff, commit history
 - `codebase` — Understand impacted areas in the broader codebase
-- `catalyst_git_diff` — Get precise diff data
-- `catalyst_git_log` — Understand commit narrative
+- `crewpilot_git_diff` — Get precise diff data
+- `crewpilot_git_log` — Understand commit narrative
 
 ## Output Format
 
 ```
-## [Catalyst → PR Intelligence]
+## [CrewPilot → PR Intelligence]
 
 ### Summary
 **What**: {one paragraph}

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

@@ -0,0 +1,114 @@
+# Code Review — Functional
+
+> **Pillar**: Assure | **ID**: `assure-review-functional`
+
+## Purpose
+
+Focused code review that evaluates **correctness, security, and performance** — the functional aspects that determine whether code works safely and efficiently. Separated from standards review so each can be delegated to a specialized subagent or run independently.
+
+## Activation Triggers
+
+- "functional review", "correctness review", "does this code work", "security review", "performance review"
+- Automatically invoked by autopilot-worker Phase 6 via subagent delegation (role: `code-reviewer`)
+- Can be run standalone for targeted reviews
+
+## Methodology
+
+### Pass 1 — Correctness
+
+1. Trace the primary execution path against acceptance criteria
+2. Identify logic errors, off-by-one, null/undefined risks, race conditions
+3. Check edge cases: empty inputs, boundary values, error paths
+4. Verify resource cleanup (connections, file handles, subscriptions)
+5. Verify error handling: are errors caught, logged, and surfaced appropriately?
+6. Confidence-gate: only report findings ≥ threshold
+
+### Pass 2 — Security (OWASP Top 10 Quick Check)
+
+1. **Injection** (A03): SQL, NoSQL, OS command, LDAP injection vectors
+2. **Broken Auth** (A07): hardcoded credentials, weak session management
+3. **Sensitive Data Exposure** (A02): secrets in code, unencrypted PII, overly broad API responses
+4. **XSS** (A03): unescaped user input in HTML/templates
+5. **Insecure Deserialization** (A08): untrusted JSON/YAML parsing without validation
+6. **Broken Access Control** (A01): missing authorization checks, IDOR vulnerabilities
+7. **Security Misconfiguration** (A05): debug mode in prod, overly permissive CORS, default credentials
+8. Flag any `eval()`, `dangerouslySetInnerHTML`, `exec()`, or equivalent patterns
+
+### Pass 3 — Performance
+
+1. Identify O(n²) or worse patterns in hot paths
+2. Flag await-in-loops and N+1 query patterns
+3. Check for unnecessary allocations in loops
+4. Look for missing caching opportunities on repeated computations
+5. Identify blocking calls that could be async
+6. Run `crewpilot_metrics_complexity` on changed files — flag functions above threshold
+
+### Pass 4 — Requirements Alignment (optional, requires Work IQ)
+
+If M365 context is available (via prior `analysis` artifact or direct query), validate the code changes against stated requirements:
+
+1. Read the `analysis` artifact from the workflow (if running as subagent with a `workflow_id`) to retrieve M365 requirements context
+2. If no artifact exists but `mcp_workiq_ask_work_iq` is available, query: "What requirements and acceptance criteria were stated for {feature/issue title} in recent meetings and emails?"
+3. For each stated requirement, check the code changes:
+   - **Implemented**: requirement is fully addressed by the code ✓
+   - **Partial**: requirement is partially addressed — note what's missing
+   - **Not addressed**: requirement has no corresponding implementation
+4. Cross-reference acceptance criteria from the board issue against the actual behavior of the code
+5. Flag any requirement gaps as `medium` severity findings
+
+> **Note**: This pass is skipped if no M365 context is available and no board issue acceptance criteria exist. It does not block the review.
+
+### Synthesis
+
+1. Rank all findings by severity: `critical > high > medium > low`
+2. Filter by `severity_floor` from config
+3. Group by file/function
+4. Provide specific fix suggestions with code snippets
+5. If invoked as subagent, write output as artifact via `crewpilot_artifact_write` (phase: `review-functional`)
+
+## Tools Required
+
+- `crewpilot_metrics_complexity` — Get cyclomatic/cognitive complexity scores
+- `crewpilot_metrics_coverage` — Check test coverage for reviewed code
+- `crewpilot_artifact_write` — Persist review findings as artifact (when run as subagent)
+- `crewpilot_artifact_read` — Read prior analysis artifacts for context (includes M365 requirements context)
+- `mcp_workiq_ask_work_iq` — (optional) Query M365 for stated requirements when no analysis artifact exists
+
+## Output Format
+
+```
+## [CrewPilot → Functional Review]
+
+### Summary
+{N} findings across {files}: {critical} critical, {high} high, {medium} medium
+
+### Correctness
+| Severity | File:Line | Issue | Suggested Fix |
+|----------|-----------|-------|---------------|
+| ...      | ...       | ...   | ...           |
+
+### Security
+| Severity | OWASP Cat | File:Line | Issue | Mitigation |
+|----------|-----------|-----------|-------|------------|
+| ...      | ...       | ...       | ...   | ...        |
+
+### Performance
+| Severity | File:Line | Issue | Suggested Fix |
+|----------|-----------|-------|---------------|
+| ...      | ...       | ...   | ...           |
+
+### Requirements Alignment (if M365 context available)
+| Requirement | Status | Evidence | Gap |
+|-------------|--------|----------|-----|
+| ...         | ✓/⚠️/❌ | ...      | ... |
+
+### Verdict
+{PASS | PASS_WITH_WARNINGS | FAIL}
+Confidence: {N}/10
+```
+
+## Chains To
+
+- `assure-review-standards` — Companion skill for conventions/consistency review
+- `assure-code-quality` — Full 4-pass review (superset of this skill)
+- `assure-vulnerability-scan` — Deep security audit (more thorough than Pass 2 here)

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

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