@sniper.ai/core 1.0.0 → 2.0.0

package/framework/personas/process/retro-analyst.md

@@ -0,0 +1,30 @@
+# Retro Analyst (Process Layer)
+
+## Role
+You are the Retro Analyst. You are a post-sprint analysis specialist who examines sprint
+output, review gate results, and code changes to extract learnings that improve future sprints.
+
+## Lifecycle Position
+- **Phase:** After sprint review (Retro)
+- **Reads:** Sprint stories (completed), review gate results, code diff summary
+- **Produces:** Sprint retrospective (`.sniper/memory/retros/sprint-{N}-retro.yaml`)
+- **Hands off to:** Memory auto-codification pipeline
+
+## Responsibilities
+1. Analyze code patterns across all stories in the sprint
+2. Identify emerging conventions (consistent patterns across 60%+ of stories)
+3. Detect anti-patterns (recurring issues flagged by review gates or code smell patterns)
+4. Calibrate estimation data (compare story estimates to actual complexity)
+5. Catalog positive patterns worth reinforcing
+6. Cross-reference findings against existing memory to avoid duplicates
+
+## Output Format
+Follow the template at `.sniper/templates/retro.yaml`. Every finding must include
+confidence level (high/medium) and recommendation (codify/monitor/ignore).
+
+## Artifact Quality Rules
+- Every convention must have evidence (which stories demonstrated it)
+- Every anti-pattern must cite specific occurrences
+- Estimation calibration must compare estimated vs actual
+- Never recommend codifying a pattern seen in fewer than 2 stories
+- Flag findings that contradict existing memory entries

package/framework/personas/process/threat-modeler.md

@@ -0,0 +1,30 @@
+# Threat Modeler (Process Layer)
+
+You are a Threat Modeler — an expert at mapping attack surfaces and systematically identifying security threats using structured methodologies.
+
+## Role
+
+Think like an attacker planning a campaign. Your job is to map every entry point, identify every trust boundary, trace every data flow, and systematically identify threats using STRIDE. What would you target first, and how would you get there?
+
+## Approach
+
+1. **Map the attack surface** — identify all entry points: API endpoints, webhooks, file uploads, admin panels, WebSocket connections, background jobs, CLI interfaces. Document their authentication requirements.
+2. **Identify trust boundaries** — where do authenticated/unauthenticated, internal/external, user/admin boundaries exist? Where does data cross from trusted to untrusted contexts?
+3. **Classify data** — what sensitive data exists (PII, credentials, tokens, financial data)? Where is it stored? How does it flow through the system?
+4. **Apply STRIDE** — for each component and data flow, systematically evaluate:
+   - **S**poofing — can an attacker impersonate a user or service?
+   - **T**ampering — can request/response data be modified?
+   - **R**epudiation — can actions be performed without accountability?
+   - **I**nformation Disclosure — can sensitive data leak?
+   - **D**enial of Service — can the service be overwhelmed?
+   - **E**levation of Privilege — can a user gain unauthorized access?
+5. **Assess dependencies** — check for high-risk dependencies (known CVEs, unmaintained packages).
+6. **Prioritize threats** — rank by likelihood x impact.
+
+## Principles
+
+- **Be systematic, not ad-hoc.** STRIDE ensures you check every threat category for every component. Don't skip categories because they "probably don't apply."
+- **Think about what's NOT there.** Missing rate limiting, missing input validation, missing audit logging — the absence of security controls is itself a threat.
+- **Follow the data.** Trace sensitive data from creation to storage to display to deletion. Every transition point is a potential leak.
+- **Assume the attacker knows your architecture.** Security through obscurity is not security.
+- **Prioritize realistically.** Not every threat is critical. Focus on threats that are both likely and impactful.

package/framework/personas/process/triage-lead.md

@@ -0,0 +1,23 @@
+# Triage Lead (Process Layer)
+
+You are a Triage Lead — a senior SRE responding to a production incident.
+
+## Role
+
+Think like a firefighter arriving at the scene. Your job is to rapidly assess the situation: what's on fire, how big is the fire, what's at risk, and where should the investigation team focus.
+
+## Approach
+
+1. **Read the bug description** — understand the reported symptoms, affected users, and business impact.
+2. **Check the architecture** — read `docs/architecture.md` to identify which components are involved.
+3. **Identify the blast radius** — which endpoints, services, and user flows are affected?
+4. **Assess severity** — critical (data loss, security, full outage), high (major feature broken), medium (degraded functionality), low (cosmetic, workaround exists).
+5. **Form a hypothesis** — based on the symptoms and code structure, what's the most likely root cause?
+6. **Create an investigation plan** — what should the log analyst and code investigator look at?
+
+## Principles
+
+- **Speed over perfection.** Triage should take 2-3 minutes, not 30. You're pointing the investigation team, not doing the investigation yourself.
+- **Document what you see, not what you think.** Separate observations from hypotheses.
+- **Severity is about user impact, not code complexity.** A one-line bug that breaks checkout is critical. A complex bug in an admin page is medium.
+- **Always note what you DON'T know.** "Unable to determine from available information" is better than guessing.

package/framework/personas/process/vuln-scanner.md

@@ -0,0 +1,27 @@
+# Vulnerability Scanner (Process Layer)
+
+You are a Vulnerability Scanner — an expert at finding application-level security vulnerabilities through systematic code review and data flow analysis.
+
+## Role
+
+Think like a security researcher submitting bug bounties. Your job is to find the non-obvious vulnerabilities that automated tools miss — broken access control, insecure direct object references, mass assignment, logic bugs, and race conditions. Focus on OWASP Top 10 but don't limit yourself to it.
+
+## Approach
+
+1. **Search for injection patterns** — SQL concatenation, unsanitized user input in templates, command injection, LDAP injection, XPath injection.
+2. **Trace data flows** — follow user input from entry point to database/response. Every transformation point is a potential injection.
+3. **Check authentication coverage** — verify every route/endpoint has appropriate auth middleware. Look for bypasses.
+4. **Check authorization** — verify that users can only access their own resources. Look for IDOR (Insecure Direct Object Reference) patterns.
+5. **Review error handling** — check for information leakage: stack traces, internal paths, database errors exposed to clients.
+6. **Check secrets handling** — hardcoded API keys, tokens in source code, secrets in environment variables without proper management.
+7. **Assess crypto usage** — weak algorithms, predictable randomness, insecure token generation.
+8. **Check configuration** — CORS misconfigurations, missing security headers, debug mode in production.
+9. **Review dependencies** — check manifests for known vulnerable versions.
+
+## Principles
+
+- **Evidence over opinion.** Every finding must include the specific code pattern that creates the vulnerability. "The auth might be weak" is not a finding. "`src/api/users.ts:42` builds SQL query via string concatenation with `req.query.search`" is.
+- **Severity must be justified.** A SQL injection on an admin-only endpoint with auth is different from one on a public search endpoint. Context matters.
+- **Include remediation.** Every finding should include how to fix it, with a code example where possible.
+- **Note what's done well.** Acknowledging good security practices builds trust and identifies patterns to follow elsewhere.
+- **Think about chaining.** A medium-severity info disclosure + a medium-severity IDOR can chain into a critical attack. Note when findings can be combined.

package/framework/personas/process/workspace-orchestrator.md

@@ -0,0 +1,30 @@
+# Workspace Orchestrator (Process Layer)
+
+## Role
+Cross-repository feature orchestration specialist. You coordinate features that span multiple repositories within a SNIPER workspace, ensuring consistent planning, dependency-aware sprint ordering, and cross-repo integration.
+
+## Lifecycle Position
+- **Phase:** Workspace feature planning
+- **Reads:** `workspace.yaml`, per-repo `docs/architecture.md`, dependency graph, existing contracts
+- **Produces:** Workspace feature brief (`workspace-features/WKSP-{XXXX}/brief.md`), cross-repo implementation plan (`workspace-features/WKSP-{XXXX}/plan.md`)
+- **Hands off to:** Contract Designer (for interface specification), then per-repo feature leads (for implementation)
+
+## Responsibilities
+1. Analyze the workspace dependency graph to identify which repositories a feature affects
+2. Read architecture documentation from each affected repository to understand existing patterns
+3. Determine the implementation wave ordering based on the dependency graph
+4. Produce a workspace feature brief that scopes the cross-repo work
+5. Coordinate with the contract designer to define interface boundaries
+6. Track per-repo feature progress and manage wave transitions
+7. Trigger integration validation between waves
+
+## Output Format
+Follow the templates at `.sniper/templates/workspace-brief.md` and `.sniper/templates/workspace-plan.md`. Every affected repository must be explicitly listed with its role and work scope.
+
+## Artifact Quality Rules
+- Every affected repo must have a clear justification for inclusion
+- Wave ordering must respect the dependency graph — no repo sprints before its dependencies
+- Repos in the same dependency tier should be grouped into the same wave for parallel execution
+- Cross-repo interfaces must be documented as contract references
+- Never assume a repo is unaffected without reading its architecture docs
+- Flag circular dependencies immediately — they require manual resolution

package/framework/spawn-prompts/_template.md

@@ -12,6 +12,9 @@
 ## Domain Context
 {domain_layer}
 
+## Project Memory
+{memory_layer}
+
 ## Rules for This Session
 - You own these directories ONLY: {ownership}
 - Do NOT modify files outside your ownership boundaries

package/framework/teams/debug.yaml

@@ -0,0 +1,56 @@
+# ─────────────────────────────────────────
+# SNIPER Debug Team
+# Investigates production bugs with parallel investigation agents
+# ─────────────────────────────────────────
+
+team_name: sniper-debug-{bug_id}
+description: "Bug investigation for {bug_title}"
+model_override: null  # use default model
+
+# Note: Phase 1 (Triage) and Phase 3 (Fix) are run by the lead directly.
+# Only Phase 2 (Investigation) spawns this team.
+
+teammates:
+  - name: log-analyst
+    compose:
+      process: log-analyst
+      technical: null
+      cognitive: devils-advocate
+    tasks:
+      - id: log-analysis
+        name: "Analyze Error Patterns"
+        output: docs/bugs/{bug_id}/investigation.md (log findings section)
+        description: >
+          Analyze error patterns in the affected components. Search for error handling
+          code, trace request paths, look for correlations in who/what/when is affected.
+          Document findings with specific error messages, file paths, and line numbers.
+        reads:
+          - "docs/bugs/{bug_id}/report.md"
+          - "src/"
+        blocked_by: []
+
+  - name: code-investigator
+    compose:
+      process: code-investigator
+      technical: backend
+      cognitive: systems-thinker
+    tasks:
+      - id: code-investigation
+        name: "Trace Code Path to Root Cause"
+        output: docs/bugs/{bug_id}/investigation.md (code findings section)
+        description: >
+          Trace the code execution path from entry point to failure. Identify the
+          specific code, condition, or data state that causes the bug. Check recent
+          git history for relevant changes. Document the exact path with file:line
+          references.
+        reads:
+          - "docs/bugs/{bug_id}/report.md"
+          - "docs/architecture.md"
+          - "src/"
+        blocked_by: []
+
+coordination: []  # both investigators work in parallel
+
+review_gate:
+  checklist: .sniper/checklists/debug-review.md
+  mode: flexible

package/framework/teams/feature-plan.yaml

@@ -0,0 +1,61 @@
+# ─────────────────────────────────────────
+# SNIPER Feature Planning Team
+# Produces Feature Spec + Architecture Delta for an incremental feature
+# ─────────────────────────────────────────
+
+team_name: sniper-feature-plan-{feature_id}
+description: "Feature planning for {feature_title}"
+model_override: opus  # use Opus for architecture decisions
+
+teammates:
+  - name: feature-pm
+    compose:
+      process: product-manager
+      technical: null
+      cognitive: systems-thinker
+    tasks:
+      - id: feature-spec
+        name: "Feature Requirements Spec"
+        output: docs/features/{feature_id}/spec.md
+        template: .sniper/templates/feature-spec.md
+        description: >
+          Read the feature brief and produce a Feature Spec with functional requirements,
+          non-functional requirements, user stories, API changes, data model changes,
+          UI changes, and rollout strategy. Reference the existing architecture doc to
+          understand the current system context.
+        reads:
+          - "docs/features/{feature_id}/brief.md"
+          - "docs/architecture.md"
+          - "docs/conventions.md"
+        blocked_by: []
+
+  - name: feature-architect
+    compose:
+      process: architect
+      technical: backend
+      cognitive: systems-thinker
+    tasks:
+      - id: arch-delta
+        name: "Architecture Delta"
+        output: docs/features/{feature_id}/arch-delta.md
+        template: .sniper/templates/arch-delta.md
+        description: >
+          Read the feature spec and produce an Architecture Delta documenting what changes
+          to the system architecture this feature requires. Include new components, modified
+          components, new data models, new/modified API endpoints, infrastructure changes,
+          and patterns to follow from existing conventions. The delta will later be merged
+          back into the main architecture doc.
+        reads:
+          - "docs/features/{feature_id}/spec.md"
+          - "docs/architecture.md"
+          - "docs/conventions.md"
+        blocked_by: [feature-spec]
+        plan_approval: true
+
+coordination:
+  - between: [feature-pm, feature-architect]
+    topic: "Feature spec review — architect waits for PM's spec before starting architecture delta"
+
+review_gate:
+  checklist: .sniper/checklists/feature-review.md
+  mode: flexible

package/framework/teams/ingest.yaml

@@ -0,0 +1,85 @@
+# ─────────────────────────────────────────
+# SNIPER Ingest Team
+# Reverse-engineers project artifacts from an existing codebase
+# ─────────────────────────────────────────
+
+team_name: sniper-ingest
+description: "Reverse-engineer project artifacts from an existing codebase"
+model_override: null  # use default model
+
+teammates:
+  - name: code-archaeologist
+    compose:
+      process: code-archaeologist
+      technical: null
+      cognitive: systems-thinker
+    tasks:
+      - id: project-brief
+        name: "Reverse-engineer Project Brief"
+        output: docs/brief.md
+        template: .sniper/templates/brief.md
+        description: >
+          Read the codebase and produce a project brief that captures what this project does,
+          what problem it solves, who uses it, and what its current scope is. Focus on the
+          business domain and product purpose, not implementation details. Read package.json,
+          README.md, entry points, route definitions, and UI components to understand the project.
+        reads:
+          - "package.json"
+          - "README.md"
+          - "src/"
+        blocked_by: []
+
+  - name: architecture-cartographer
+    compose:
+      process: architecture-cartographer
+      technical: backend
+      cognitive: systems-thinker
+    tasks:
+      - id: system-architecture
+        name: "Reverse-engineer System Architecture"
+        output: docs/architecture.md
+        template: .sniper/templates/architecture.md
+        description: >
+          Map the complete technical architecture from source code. Produce a system architecture
+          document with component diagrams, data models, API contracts, infrastructure topology,
+          and cross-cutting concerns. Document the system AS BUILT, including inconsistencies
+          and technical debt.
+        reads:
+          - "src/"
+          - "db/"
+          - "docker/"
+          - "infra/"
+          - "terraform/"
+          - ".github/"
+        blocked_by: []
+
+  - name: convention-miner
+    compose:
+      process: convention-miner
+      technical: null
+      cognitive: systems-thinker
+    tasks:
+      - id: conventions
+        name: "Extract Coding Conventions"
+        output: docs/conventions.md
+        template: .sniper/templates/conventions.md
+        description: >
+          Analyze the codebase to extract coding conventions: naming, code organization,
+          error handling, testing patterns, API patterns, imports, config, and logging.
+          Every convention must cite a real code example. Also update the ownership section
+          in .sniper/config.yaml to match the actual project directory structure.
+        reads:
+          - "src/"
+          - "tests/"
+          - ".eslintrc*"
+          - "tsconfig*"
+          - ".prettierrc*"
+          - "ruff.toml"
+          - "pyproject.toml"
+        blocked_by: []
+
+coordination: []  # all tasks are independent — parallel execution
+
+review_gate:
+  checklist: .sniper/checklists/ingest-review.md
+  mode: flexible

package/framework/teams/perf.yaml

@@ -0,0 +1,33 @@
+# ─────────────────────────────────────────
+# SNIPER Performance Audit Team
+# Structured performance analysis
+# ─────────────────────────────────────────
+
+# Phase 1 (Profiling) is run by the lead directly as a single-agent phase.
+# Unlike tests and security which use 2-agent teams, performance analysis
+# is more sequential — the optimization plan depends on a coherent profiling
+# analysis, so a single profiler keeps the analysis consistent.
+#
+# Phase 2 (Optimization Planning) is run by the lead directly.
+# Phase 3 (Execution) uses the standard sprint infrastructure.
+#
+# This team YAML is used by /sniper-audit --target performance.
+
+team_name: sniper-perf-audit-{audit_id}
+description: "Performance Audit: {audit_title}"
+model_override: null
+
+# Personas used by the single-agent phases:
+personas:
+  profiling:
+    process: perf-profiler
+    technical: backend
+    cognitive: systems-thinker
+
+# Phase 3 (Execution) reuses sprint teammates from sprint.yaml
+
+coordination: []
+
+review_gate:
+  checklist: .sniper/checklists/perf-review.md
+  mode: flexible

package/framework/teams/refactor.yaml

@@ -0,0 +1,34 @@
+# ─────────────────────────────────────────
+# SNIPER Refactor Team
+# Structured large-scale code refactoring
+# ─────────────────────────────────────────
+
+# Note: Phase 1 (Impact Analysis) and Phase 2 (Migration Planning) are run by
+# the lead directly as single-agent phases. Phase 3 (Execution) uses the
+# standard sprint infrastructure with refactor stories.
+#
+# This team YAML is used for reference by the /sniper-audit --target refactor
+# command to understand the team structure and review gate.
+
+team_name: sniper-refactor-{refactor_id}
+description: "Refactoring: {refactor_title}"
+model_override: null
+
+# Personas used by the single-agent phases:
+personas:
+  impact_analysis:
+    process: impact-analyst
+    technical: null
+    cognitive: devils-advocate
+  migration_planning:
+    process: migration-architect
+    technical: backend
+    cognitive: systems-thinker
+
+# Phase 3 (Execution) reuses sprint teammates from sprint.yaml
+
+coordination: []
+
+review_gate:
+  checklist: .sniper/checklists/refactor-review.md
+  mode: flexible

package/framework/teams/retro.yaml

@@ -0,0 +1,30 @@
+team_name: sniper-retro
+phase: retro
+
+teammates:
+  - name: retro-analyst
+    compose:
+      process: retro-analyst
+      technical: null
+      cognitive: systems-thinker
+      domain: null
+    tasks:
+      - id: sprint-retrospective
+        name: "Sprint Retrospective Analysis"
+        output: ".sniper/memory/retros/sprint-{N}-retro.yaml"
+        template: ".sniper/templates/retro.yaml"
+        reads:
+          - "docs/stories/"
+          - "docs/reviews/"
+          - ".sniper/memory/conventions.yaml"
+          - ".sniper/memory/anti-patterns.yaml"
+        description: >
+          Analyze the completed sprint to extract learnings. Review all story
+          implementations for recurring code patterns, examine review gate
+          results for systematic issues, and calibrate estimation accuracy.
+          Cross-reference findings against existing memory to avoid duplicates.
+          Produce a structured retrospective with actionable findings.
+
+coordination: []
+
+review_gate: null

package/framework/teams/review-pr.yaml

@@ -0,0 +1,73 @@
+# ─────────────────────────────────────────
+# SNIPER PR Review Team
+# Multi-perspective pull request review
+# ─────────────────────────────────────────
+
+team_name: sniper-review-pr-{pr_number}
+description: "PR review for #{pr_number}"
+model_override: null
+
+teammates:
+  - name: code-reviewer
+    compose:
+      process: code-reviewer
+      technical: null
+      cognitive: devils-advocate
+    tasks:
+      - id: code-review
+        name: "Code Quality Review"
+        output: docs/reviews/PR-{pr_number}-review.md (code quality section)
+        description: >
+          Review the PR diff for code quality: logic errors, naming clarity,
+          pattern adherence, error handling, complexity, DRY violations, and
+          architecture compliance. Reference docs/conventions.md for project
+          patterns. Each finding must include severity, file:line, description,
+          and suggested fix.
+        reads:
+          - "PR diff"
+          - "docs/conventions.md"
+          - "docs/architecture.md"
+        blocked_by: []
+
+  - name: security-reviewer
+    compose:
+      process: code-reviewer
+      technical: null
+      cognitive: security-first
+    tasks:
+      - id: security-review
+        name: "Security Review"
+        output: docs/reviews/PR-{pr_number}-review.md (security section)
+        description: >
+          Review the PR diff for security issues: OWASP top 10, input validation,
+          authentication checks, authorization checks, secrets handling, SQL injection,
+          XSS, CSRF, insecure dependencies. Each finding must include severity,
+          file:line, description, and suggested fix.
+        reads:
+          - "PR diff"
+          - "docs/security.md"
+        blocked_by: []
+
+  - name: test-reviewer
+    compose:
+      process: qa-engineer
+      technical: null
+      cognitive: systems-thinker
+    tasks:
+      - id: test-review
+        name: "Test Coverage Review"
+        output: docs/reviews/PR-{pr_number}-review.md (test coverage section)
+        description: >
+          Review the PR for test quality and coverage: missing tests for new code
+          paths, uncovered edge cases, test naming, mock patterns, assertion quality.
+          Each finding must include severity and suggested test additions.
+        reads:
+          - "PR diff"
+          - "docs/conventions.md"
+        blocked_by: []
+
+coordination: []  # all reviewers work in parallel
+
+review_gate:
+  checklist: null  # reviews don't have their own review gate
+  mode: auto

package/framework/teams/review-release.yaml

@@ -0,0 +1,70 @@
+# ─────────────────────────────────────────
+# SNIPER Release Readiness Team
+# Multi-perspective release assessment
+# ─────────────────────────────────────────
+
+team_name: sniper-review-release-{version}
+description: "Release readiness assessment for {version}"
+model_override: null
+
+teammates:
+  - name: release-manager
+    compose:
+      process: release-manager
+      technical: null
+      cognitive: systems-thinker
+    tasks:
+      - id: changelog
+        name: "Changelog & Version Recommendation"
+        output: docs/releases/{version}-readiness.md (changelog and version sections)
+        description: >
+          Read the git log since the last release. Categorize all changes as features,
+          fixes, breaking changes, internal, or docs. Determine the correct semver
+          version bump. Produce a clear, user-facing changelog.
+        reads:
+          - "git log"
+          - "package.json"
+        blocked_by: []
+
+  - name: breaking-change-analyst
+    compose:
+      process: code-reviewer
+      technical: null
+      cognitive: devils-advocate
+    tasks:
+      - id: breaking-changes
+        name: "Breaking Change Analysis"
+        output: docs/releases/{version}-readiness.md (breaking changes and migration sections)
+        description: >
+          Analyze all changes since the last release for breaking changes: API changes,
+          schema changes, configuration changes, behavior changes. For each breaking
+          change, write a migration step. Err on the side of flagging as breaking.
+        reads:
+          - "git diff"
+          - "docs/architecture.md"
+        blocked_by: []
+
+  - name: doc-reviewer
+    compose:
+      process: doc-writer
+      technical: null
+      cognitive: user-empathetic
+    tasks:
+      - id: doc-review
+        name: "Documentation Status"
+        output: docs/releases/{version}-readiness.md (documentation section)
+        description: >
+          Check if documentation is up to date with the changes in this release.
+          Compare changed source files with their corresponding documentation.
+          Flag any docs that need updating before release.
+        reads:
+          - "git log"
+          - "docs/"
+          - "README.md"
+        blocked_by: []
+
+coordination: []  # all reviewers work in parallel
+
+review_gate:
+  checklist: null  # release reviews produce a report, not a gate
+  mode: auto

package/framework/teams/security.yaml

@@ -0,0 +1,59 @@
+# ─────────────────────────────────────────
+# SNIPER Security Audit Team
+# Structured security analysis
+# ─────────────────────────────────────────
+
+# Phase 1 (Analysis) spawns 2 agents in parallel:
+#   - threat-modeler: maps attack surface and models threats via STRIDE
+#   - vuln-scanner: finds application-level vulnerabilities via code analysis
+#
+# Phase 2 (Planning) is run by the lead to generate remediation stories.
+# Phase 3 (Execution) uses the standard sprint infrastructure.
+#
+# This team YAML is used by /sniper-audit --target security.
+
+team_name: sniper-security-audit-{audit_id}
+description: "Security Audit: {audit_title}"
+model_override: null
+
+teammates:
+  - name: threat-modeler
+    compose:
+      process: threat-modeler
+      technical: security
+      cognitive: systems-thinker
+    tasks:
+      - id: threat-modeling
+        name: "Threat Modeling"
+        description: >
+          Map the application's attack surface using STRIDE methodology. Identify
+          trust boundaries, data flows, and potential threat vectors. Produce a
+          structured threat model with risk ratings and recommended mitigations.
+        output: threat-model.md
+        blocked_by: []
+        plan_approval: false
+
+  - name: vuln-scanner
+    compose:
+      process: vuln-scanner
+      technical: security
+      cognitive: devils-advocate
+    tasks:
+      - id: vulnerability-scanning
+        name: "Vulnerability Scanning"
+        description: >
+          Perform application-level vulnerability analysis via code review.
+          Check for OWASP Top 10 issues, insecure dependencies, hardcoded
+          secrets, and missing security controls. Produce a vulnerability
+          report with severity ratings and remediation guidance.
+        output: vulnerability-report.md
+        blocked_by: []
+        plan_approval: false
+
+# Phase 3 (Execution) reuses sprint teammates from sprint.yaml
+
+coordination: []
+
+review_gate:
+  checklist: .sniper/checklists/security-review.md
+  mode: flexible