@sniper.ai/core 1.0.0

package/framework/templates/prd.md

@@ -0,0 +1,69 @@
+# Product Requirements Document: {project_name}
+
+> **Status:** Draft
+> **Author:** Planning Team — Product Manager
+> **Date:** {date}
+> **Source:** `docs/brief.md`, `docs/personas.md`, `docs/risks.md`
+
+## 1. Problem Statement
+<!-- Specific problem, who has it, evidence it's real, current alternatives -->
+
+## 2. Solution Overview
+<!-- High-level description of the product solution -->
+
+## 3. User Stories
+
+### P0 — Critical (Must Ship)
+| ID | As a... | I want to... | So that... | Acceptance Criteria |
+|----|---------|-------------|-----------|-------------------|
+| US-001 | | | | |
+
+### P1 — Important (Should Ship)
+| ID | As a... | I want to... | So that... | Acceptance Criteria |
+|----|---------|-------------|-----------|-------------------|
+| US-010 | | | | |
+
+### P2 — Nice to Have (Could Ship)
+| ID | As a... | I want to... | So that... | Acceptance Criteria |
+|----|---------|-------------|-----------|-------------------|
+| US-020 | | | | |
+
+## 4. Functional Requirements
+<!-- Detailed functional requirements organized by feature area -->
+
+### 4.1 {Feature Area 1}
+- FR-001:
+- FR-002:
+
+## 5. Non-Functional Requirements
+| Category | Requirement | Target |
+|----------|------------|--------|
+| Performance | | |
+| Security | | |
+| Scalability | | |
+| Availability | | |
+| Accessibility | | |
+
+## 6. Success Metrics
+| Metric | Target | Measurement Method |
+|--------|--------|-------------------|
+| | | |
+
+## 7. Scope Boundaries
+
+### In Scope (v1)
+-
+
+### Explicitly Out of Scope
+-
+
+## 8. Dependencies & Integrations
+<!-- External services, APIs, third-party tools required -->
+
+## 9. Constraints
+<!-- Technical, business, regulatory, timeline constraints -->
+
+## 10. Risks & Mitigations
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|------------|
+| | | | |

package/framework/templates/risks.md

@@ -0,0 +1,64 @@
+# Risk Assessment: {project_name}
+
+> **Status:** Draft
+> **Author:** Discovery Team — Risk Researcher
+> **Date:** {date}
+
+## Executive Risk Summary
+<!-- 2-3 sentence overview of the project's risk profile -->
+
+## Technical Feasibility
+
+### Architecture Risks
+| Risk | Likelihood | Impact | Mitigation |
+|------|-----------|--------|------------|
+| | | | |
+
+### Integration Risks
+<!-- Third-party dependencies, API stability, vendor lock-in -->
+
+### Scalability Risks
+<!-- Performance bottlenecks, data growth, concurrent user limits -->
+
+## Compliance & Regulatory
+
+### Regulatory Requirements
+<!-- GDPR, HIPAA, SOC 2, PCI-DSS, industry-specific regulations -->
+
+### Data Privacy Risks
+<!-- PII handling, data residency, consent management -->
+
+## Operational Risks
+
+### Deployment & Infrastructure
+<!-- Cloud dependency, disaster recovery, monitoring gaps -->
+
+### Team & Resource Risks
+<!-- Skill gaps, key-person dependencies, timeline pressure -->
+
+## Security Risks
+
+### Attack Surface
+<!-- Authentication, authorization, injection vectors, data exposure -->
+
+### Third-Party Risk
+<!-- Supply chain, dependency vulnerabilities, vendor security posture -->
+
+## Risk Matrix
+
+| # | Risk | Likelihood (1-5) | Impact (1-5) | Score | Priority | Mitigation Strategy |
+|---|------|-------------------|---------------|-------|----------|---------------------|
+| 1 | | | | | | |
+| 2 | | | | | | |
+| 3 | | | | | | |
+
+## Assumptions Requiring Validation
+<!-- List assumptions from the brief that carry risk if wrong -->
+1.
+2.
+3.
+
+## Open Questions
+<!-- Unresolved items that affect risk assessment -->
+1.
+2.

package/framework/templates/security.md

@@ -0,0 +1,90 @@
+# Security Assessment: {project_name}
+
+> **Status:** Draft
+> **Author:** Planning Team — Security Analyst
+> **Date:** {date}
+
+## Security Overview
+<!-- 2-3 sentence summary of the project's security posture and key concerns -->
+
+## Authentication & Authorization
+
+### Authentication Model
+<!-- OAuth 2.0 / JWT / Session-based / API Keys / Multi-factor -->
+
+### Authorization Model
+<!-- RBAC / ABAC / ACL — describe roles, permissions, and access levels -->
+
+### Session Management
+<!-- Token lifecycle, refresh strategy, revocation, concurrent sessions -->
+
+## Data Security
+
+### Data Classification
+| Data Type | Classification | Storage | Encryption | Retention |
+|-----------|---------------|---------|------------|-----------|
+| | | | | |
+
+### Encryption Requirements
+- **At Rest:** <!-- AES-256, database-level, field-level -->
+- **In Transit:** <!-- TLS 1.3, certificate pinning -->
+- **Key Management:** <!-- KMS, rotation policy -->
+
+### PII Handling
+<!-- What PII is collected, how it's stored, who can access it, deletion policy -->
+
+## API Security
+
+### Input Validation
+<!-- Validation strategy, sanitization, schema enforcement -->
+
+### Rate Limiting
+<!-- Per-endpoint limits, burst handling, API key tiers -->
+
+### OWASP Top 10 Mitigations
+| Vulnerability | Risk Level | Mitigation |
+|--------------|-----------|------------|
+| Injection | | |
+| Broken Authentication | | |
+| Sensitive Data Exposure | | |
+| XML External Entities | | |
+| Broken Access Control | | |
+| Security Misconfiguration | | |
+| Cross-Site Scripting | | |
+| Insecure Deserialization | | |
+| Known Vulnerabilities | | |
+| Insufficient Logging | | |
+
+## Infrastructure Security
+
+### Network Architecture
+<!-- VPC, subnets, security groups, WAF, CDN -->
+
+### Secrets Management
+<!-- Vault, environment variables, rotation policy -->
+
+### Logging & Monitoring
+<!-- Security event logging, alerting, SIEM integration -->
+
+## Compliance Requirements
+<!-- Applicable frameworks: SOC 2, GDPR, HIPAA, PCI-DSS, etc. -->
+
+## Threat Model
+
+### Attack Surface
+<!-- Entry points, trust boundaries, data flows -->
+
+### Key Threats
+| Threat | Likelihood | Impact | Mitigation |
+|--------|-----------|--------|------------|
+| | | | |
+
+## Recommendations
+<!-- Prioritized security recommendations for implementation -->
+1.
+2.
+3.
+
+## Open Questions
+1.
+2.

package/framework/templates/sprint-review.md

@@ -0,0 +1,32 @@
+# Sprint {number} Review
+
+> **Date:** {date}
+> **Stories Completed:** {count}/{total}
+> **Team:** {teammate list}
+
+## Stories Delivered
+| Story | Status | Notes |
+|-------|--------|-------|
+| | Complete / Partial / Blocked | |
+
+## Test Results
+- **Tests passed:** {count}
+- **Tests failed:** {count}
+- **Coverage:** {percentage}
+
+## Code Quality
+- Linting: Pass / Fail
+- Type checking: Pass / Fail
+- Security scan: Pass / Fail
+
+## Technical Debt Introduced
+<!-- Any shortcuts taken, refactoring needed, or known issues -->
+
+## Blockers Encountered
+<!-- What blocked progress and how it was resolved -->
+
+## Lessons Learned
+<!-- What went well, what didn't, what to change next sprint -->
+
+## Next Sprint Candidates
+<!-- Suggested stories for the next sprint -->

package/framework/templates/story.md

@@ -0,0 +1,37 @@
+# Story {epic}.{number}: {title}
+
+> **Epic:** {epic title} (`docs/epics/{epic}.md`)
+> **Complexity:** S | M | L | XL
+> **Priority:** P{0|1|2}
+> **File Ownership:** {directories this story touches}
+> **Dependencies:** {story dependencies or "None"}
+
+## Description
+<!-- What this story implements, in user-facing terms -->
+
+## Embedded Context
+
+### From PRD
+<!-- COPY the relevant requirements and user stories from docs/prd.md -->
+
+### From Architecture
+<!-- COPY the relevant architecture sections (data models, API contracts, patterns) -->
+
+### From UX Spec
+<!-- COPY relevant screen descriptions, user flows, component specs (if frontend story) -->
+
+## Acceptance Criteria
+<!-- Testable assertions in Given/When/Then format -->
+1. **Given** ... **When** ... **Then** ...
+2. **Given** ... **When** ... **Then** ...
+
+## Test Requirements
+- [ ] Unit tests:
+- [ ] Integration tests:
+- [ ] E2E tests (if applicable):
+
+## Implementation Notes
+<!-- Specific patterns, libraries, or approaches to use -->
+
+## Out of Scope
+<!-- What this story does NOT include, to prevent scope creep -->

package/framework/templates/ux-spec.md

@@ -0,0 +1,54 @@
+# UX Specification: {project_name}
+
+> **Status:** Draft
+> **Author:** Planning Team — UX Designer
+> **Date:** {date}
+> **Source:** `docs/prd.md`, `docs/personas.md`
+
+## 1. Information Architecture
+<!-- Page hierarchy and navigation structure -->
+
+## 2. Screen Inventory
+| Screen | Purpose | User Stories | Key Components |
+|--------|---------|-------------|----------------|
+| | | | |
+
+## 3. User Flows
+
+### 3.1 {Flow Name}
+<!-- Step-by-step with decision points, error paths -->
+```
+Step 1: User does X
+  → Success: Go to Step 2
+  → Error: Show error message, stay on current screen
+Step 2: ...
+```
+
+## 4. Component Hierarchy
+<!-- Reusable UI components and their variants -->
+
+### 4.1 {Component Name}
+- **States:** default, hover, active, disabled, loading, error
+- **Props/Variants:**
+- **Accessibility:**
+
+## 5. Interaction Patterns
+<!-- Loading states, transitions, empty states, error states -->
+
+### Loading States
+### Empty States
+### Error States
+### Confirmation Dialogs
+
+## 6. Responsive Strategy
+| Breakpoint | Width | Layout Changes |
+|-----------|-------|---------------|
+| Mobile | < 768px | |
+| Tablet | 768-1024px | |
+| Desktop | > 1024px | |
+
+## 7. Accessibility Requirements
+- **WCAG Level:** AA
+- **Keyboard Navigation:**
+- **Screen Reader Support:**
+- **Color Contrast:**

package/framework/workflows/discover-only.md

@@ -0,0 +1,39 @@
+# Discovery-Only Workflow
+
+Run just the discovery phase for research and analysis.
+
+## When to Use
+- Exploring a new project idea before committing
+- Market research or competitive analysis
+- Validating feasibility before full planning
+- User research for an existing product
+
+## Execution
+
+### Step 1: Initialize (if not already done)
+```
+/sniper-init
+```
+Minimal config — just project name and description needed.
+
+### Step 2: Run Discovery
+```
+/sniper-discover
+```
+- Spawns 3-teammate discovery team
+- Produces: project brief, risk assessment, user personas
+- Auto-advances (flexible gate)
+
+### Step 3: Review Artifacts
+```
+/sniper-review
+```
+Review the discovery artifacts. Decide whether to:
+- Proceed to full planning (`/sniper-plan`)
+- Iterate on discovery (re-run `/sniper-discover` with feedback)
+- Shelve the project (no further action needed)
+
+## Notes
+- Discovery artifacts are useful standalone — no need to continue the lifecycle
+- Domain pack context improves discovery quality significantly
+- The analyst teammate benefits from web search for competitive research

package/framework/workflows/full-lifecycle.md

@@ -0,0 +1,56 @@
+# Full Lifecycle Workflow
+
+Run the complete SNIPER lifecycle from discovery through implementation.
+
+## When to Use
+- New greenfield projects
+- Major product rewrites
+- Projects requiring full planning and governance
+
+## Execution Order
+
+### Step 1: Initialize
+```
+/sniper-init
+```
+Configure project name, type, stack, and domain pack.
+
+### Step 2: Discover (Phase 1)
+```
+/sniper-discover
+```
+- Spawns 3-teammate discovery team (analyst, risk-researcher, user-researcher)
+- Produces: `docs/brief.md`, `docs/risks.md`, `docs/personas.md`
+- Gate: FLEXIBLE (auto-advance, review async)
+
+### Step 3: Plan (Phase 2)
+```
+/sniper-plan
+```
+- Spawns 4-teammate planning team (PM, architect, UX, security)
+- Uses Opus model for higher quality output
+- Produces: `docs/prd.md`, `docs/architecture.md`, `docs/ux-spec.md`, `docs/security.md`
+- Gate: STRICT — human MUST approve before proceeding
+
+### Step 4: Solve (Phase 3)
+```
+/sniper-solve
+```
+- Single agent (scrum master) — NOT a team
+- Produces: `docs/epics/*.md`, `docs/stories/*.md`
+- Gate: FLEXIBLE (auto-advance, review async)
+
+### Step 5: Sprint (Phase 4 — repeating)
+```
+/sniper-sprint
+```
+- Select stories for the sprint
+- Spawns implementation team based on story requirements
+- Produces: source code, tests
+- Gate: STRICT — human reviews code before merge
+- Repeat for each sprint until all stories are complete
+
+## Recovery
+- If any phase produces poor output, re-run the phase command
+- Completed files persist on disk — only the conversation resets
+- Sprint failures only affect the current sprint's stories

package/framework/workflows/quick-feature.md

@@ -0,0 +1,44 @@
+# Quick Feature Workflow
+
+Fast-track a single feature without full lifecycle planning.
+
+## When to Use
+- Adding a feature to an existing codebase
+- Feature is well-understood and doesn't need discovery or planning
+- Architecture already exists
+- Just need implementation + tests
+
+## Prerequisites
+- Existing codebase with established patterns
+- Clear feature requirements (from user, issue, or brief description)
+- Architecture document or existing code to follow patterns from
+
+## Execution
+
+### Step 1: Write a Story
+Either:
+- Write a story file manually at `docs/stories/quick-{name}.md`
+- Or describe the feature to the lead and have it generate a story using the template
+
+The story must include:
+- Feature description and acceptance criteria
+- File ownership (which directories to modify)
+- Test requirements
+- Any relevant context from existing architecture
+
+### Step 2: Sprint with Single Story
+```
+/sniper-sprint
+```
+Select only the quick feature story. The command will:
+1. Spawn only the teammates needed for this story
+2. Skip unnecessary roles (e.g., no QA if it's a small change)
+3. Execute the implementation
+
+### Step 3: Review
+Gate: STRICT — always review code before merge, even for quick features.
+
+## Notes
+- Skips Phases 1-3 entirely
+- Best for S/M complexity features
+- For L/XL features, use the full lifecycle — the planning is worth it

package/framework/workflows/sprint-cycle.md

@@ -0,0 +1,47 @@
+# Sprint Cycle Workflow
+
+Execute a single implementation sprint with an Agent Team.
+
+## When to Use
+- Stories already exist in `docs/stories/`
+- Architecture and planning are complete
+- Ready to implement a batch of stories
+
+## Prerequisites
+- `docs/architecture.md` exists and is approved
+- Story files exist in `docs/stories/`
+- Config state shows phase is `solve` (completed) or `sprint`
+
+## Execution
+
+### Step 1: Select Stories
+The `/sniper-sprint` command will:
+1. List all stories from `docs/stories/` that are not yet implemented
+2. Prompt you to select stories for this sprint (or accept a suggested batch)
+3. Determine which teammates are needed based on story file ownership
+
+### Step 2: Team Composition
+Based on selected stories, the command:
+1. Reads `.sniper/teams/sprint.yaml` for available teammate definitions
+2. Selects only the teammates needed (e.g., skip infra-dev if no infra stories)
+3. Composes spawn prompts with story context embedded
+4. Assigns file ownership boundaries from `config.yaml`
+
+### Step 3: Sprint Execution
+1. Creates team `sniper-sprint-{N}`
+2. Creates tasks with dependencies (QA blocked until implementation done)
+3. Spawns teammates with their composed prompts
+4. Lead enters delegate mode — coordinates, does not code
+5. Facilitates API contract alignment between backend/frontend
+6. Monitors progress, intervenes on blocks
+
+### Step 4: Sprint Review
+1. All tasks must be marked complete
+2. Run `/sniper-review` to check the sprint review checklist
+3. Present code diff summary and test results to human
+4. Gate: STRICT — human must approve
+
+### Step 5: Post-Sprint
+1. Update config state (increment sprint number, mark stories as complete)
+2. Clean up the agent team
+3. Proceed to next sprint or declare MVP complete

package/package.json

@@ -0,0 +1,30 @@
+{
+  "name": "@sniper.ai/core",
+  "version": "1.0.0",
+  "description": "SNIPER framework core — personas, teams, templates, checklists, and workflows",
+  "type": "module",
+  "exports": {
+    "./package.json": "./package.json",
+    "./framework/*": "./framework/*"
+  },
+  "files": [
+    "framework"
+  ],
+  "keywords": [
+    "sniper",
+    "ai",
+    "claude",
+    "framework",
+    "agent",
+    "personas"
+  ],
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "https://github.com/sniperai/sniper.git",
+    "directory": "packages/core"
+  },
+  "publishConfig": {
+    "access": "public"
+  }
+}