@sniper.ai/core 1.0.0

package/framework/commands/sniper-status.md

@@ -0,0 +1,276 @@
+# /sniper-status -- Show Lifecycle Status and Artifact State
+
+You are executing the `/sniper-status` command. Your job is to read the current project state and display a comprehensive, formatted status report. This is a READ-ONLY command -- do NOT modify any files.
+
+---
+
+## Step 0: Pre-Flight -- Read Configuration
+
+1. Read `.sniper/config.yaml`
+2. If the file does not exist:
+   ```
+   ERROR: .sniper/config.yaml not found.
+   SNIPER has not been initialized in this project.
+   Run /sniper-init to set up the framework.
+   ```
+   Then STOP.
+3. If the file exists but `project.name` is empty:
+   ```
+   WARNING: SNIPER config exists but project name is not set.
+   The framework may be partially initialized. Run /sniper-init to complete setup.
+   ```
+   Continue anyway and show what is available.
+
+---
+
+## Step 1: Read Project Identity
+
+Extract from config.yaml:
+- `project.name`
+- `project.type`
+- `project.description`
+- `stack` (all fields)
+- `domain_pack`
+
+---
+
+## Step 2: Read Lifecycle State
+
+Extract from config.yaml:
+- `state.current_phase`
+- `state.phase_history` (array of completed phases)
+- `state.current_sprint`
+- `state.artifacts` (status of each artifact)
+
+---
+
+## Step 3: Check Artifact Files on Disk
+
+For each artifact, check whether the actual file exists on disk and has content. Compare the file-on-disk status with the state recorded in config.yaml:
+
+| Artifact      | Config Key       | Expected Path(s)                    |
+|--------------|-----------------|-------------------------------------|
+| Brief         | `brief`          | `docs/brief.md`                     |
+| PRD           | `prd`            | `docs/prd.md`                       |
+| Architecture  | `architecture`   | `docs/architecture.md`              |
+| UX Spec       | `ux_spec`        | `docs/ux-spec.md`                   |
+| Security      | `security`       | `docs/security.md`                  |
+| Epics         | `epics`          | `docs/epics/*.md`                   |
+| Stories       | `stories`        | `docs/stories/*.md`                 |
+| Risks         | (not in config)  | `docs/risks.md`                     |
+| Personas      | (not in config)  | `docs/personas.md`                  |
+
+For epics and stories, count the number of `.md` files in the directory.
+
+Determine each artifact's effective status:
+- `missing` -- file does not exist on disk
+- `empty` -- file exists but has no substantive content (only template markers)
+- `draft` -- file exists with content, config says draft or null
+- `approved` -- config says approved
+- `out of sync` -- config says one status but disk state contradicts it (e.g., config says approved but file is missing)
+
+---
+
+## Step 4: Read Sprint Details (if applicable)
+
+If `state.current_phase` is `sprint` or if `state.current_sprint` > 0:
+
+1. Check for story files in `docs/stories/`
+2. For each story file, read its header to determine status:
+   - Look for status markers in the story content (e.g., `Status: complete`, `Status: in-progress`, `Status: pending`)
+   - If no status marker, assume `pending`
+3. Count stories by status
+4. Check for any stories assigned to the current sprint
+
+---
+
+## Step 5: Read Review Gate Configuration
+
+Extract `review_gates` from config.yaml:
+- `after_discover`
+- `after_plan`
+- `after_solve`
+- `after_sprint`
+
+---
+
+## Step 6: Compute Progress Estimate
+
+Based on the current state, estimate overall progress:
+
+| State                                | Progress          |
+|-------------------------------------|-------------------|
+| No phase started                     | 0% -- Not started |
+| discover phase active                | 5-15%             |
+| discover complete, plan active       | 15-35%            |
+| plan complete, solve active          | 35-45%            |
+| solve complete, sprint active        | 45-90%            |
+| All stories complete                 | 90-100%           |
+
+For sprint phase, calculate more precisely:
+- Count total stories
+- Count completed stories
+- Sprint progress = (completed / total) as a percentage of the 45-90% range
+
+---
+
+## Step 7: Display Status Report
+
+Print the following formatted report. Use the actual values from the steps above.
+
+```
+============================================
+  SNIPER Status Report
+============================================
+
+  Project:      {name}
+  Type:         {type}
+  Description:  {description}
+  Domain Pack:  {domain_pack or "none"}
+
+--------------------------------------------
+  Lifecycle Phase
+--------------------------------------------
+
+  Current Phase:  {phase or "NOT STARTED"}
+  Sprint:         {current_sprint or "N/A"}
+  Progress:       {estimated_progress}
+
+  Phase Progression:
+    [x] discover  {completed_date or "-- pending"}     {gate_mode}
+    [x] plan      {completed_date or "-- pending"}     {gate_mode}
+    [ ] solve     {status}                              {gate_mode}
+    [ ] sprint    {status}                              {gate_mode}
+
+  Use [x] for completed phases, [>] for the active phase, [ ] for pending phases.
+
+--------------------------------------------
+  Phase History
+--------------------------------------------
+
+  {For each entry in phase_history:}
+  Phase: {phase}
+    Started:    {started_at}
+    Completed:  {completed_at}
+    Approved by: {approved_by}
+    Gate mode:  {gate_mode}
+    Results:    {pass_count} pass, {warn_count} warn, {fail_count} fail
+
+  {If phase_history is empty:}
+  No phases completed yet.
+
+--------------------------------------------
+  Artifacts
+--------------------------------------------
+
+  | Artifact       | Config Status | On Disk        | Path                     |
+  |---------------|---------------|----------------|--------------------------|
+  | Brief          | {status}      | {disk_status}  | docs/brief.md            |
+  | Risks          | --            | {disk_status}  | docs/risks.md            |
+  | Personas       | --            | {disk_status}  | docs/personas.md         |
+  | PRD            | {status}      | {disk_status}  | docs/prd.md              |
+  | Architecture   | {status}      | {disk_status}  | docs/architecture.md     |
+  | UX Spec        | {status}      | {disk_status}  | docs/ux-spec.md          |
+  | Security       | {status}      | {disk_status}  | docs/security.md         |
+  | Epics          | {status}      | {count} files  | docs/epics/              |
+  | Stories        | {status}      | {count} files  | docs/stories/            |
+
+  For "Config Status" show: null, draft, approved
+  For "On Disk" show: missing, empty, has content, {N} files
+
+--------------------------------------------
+  Sprint Details
+--------------------------------------------
+
+  {If in sprint phase or current_sprint > 0:}
+
+  Sprint #{current_sprint}
+
+  | Story                    | Status       | Complexity | Owner    |
+  |-------------------------|-------------|------------|----------|
+  | {story_name}             | {status}     | {S/M/L/XL} | {owner}  |
+  | ...                      | ...          | ...        | ...      |
+
+  Progress: {completed}/{total} stories ({percentage}%)
+
+  {If not in sprint phase:}
+  No active sprint.
+
+--------------------------------------------
+  Review Gates
+--------------------------------------------
+
+  | Gate             | Mode       | Status                    |
+  |-----------------|------------|---------------------------|
+  | after_discover   | {mode}     | {passed/pending/N/A}      |
+  | after_plan       | {mode}     | {passed/pending/N/A}      |
+  | after_solve      | {mode}     | {passed/pending/N/A}      |
+  | after_sprint     | {mode}     | {passed/pending/N/A}      |
+
+  Legend:
+    strict   = Human must explicitly approve before advancing
+    flexible = Auto-advance, human reviews async
+    auto     = No review required
+
+--------------------------------------------
+  Tech Stack
+--------------------------------------------
+
+  Language:         {language}
+  Frontend:         {frontend}
+  Backend:          {backend}
+  Database:         {database}
+  Cache:            {cache}
+  Infrastructure:   {infrastructure}
+  Test Runner:      {test_runner}
+  Package Manager:  {package_manager}
+
+============================================
+  What's Next
+============================================
+
+  {Generate contextual next-step suggestions based on current state:}
+
+  {If not started:}
+  -> Run /sniper-discover to begin Phase 1: Discovery & Analysis
+
+  {If in discover phase:}
+  -> Discovery is in progress. When complete, run /sniper-review to evaluate artifacts.
+
+  {If discover complete, plan not started:}
+  -> Run /sniper-plan to begin Phase 2: Planning & Architecture
+
+  {If in plan phase:}
+  -> Planning is in progress. When complete, run /sniper-review to evaluate artifacts.
+  -> Note: This gate is STRICT -- human approval required.
+
+  {If plan complete, solve not started:}
+  -> Run /sniper-solve to begin Phase 3: Epic Sharding & Story Creation
+
+  {If in solve phase:}
+  -> Story creation is in progress. When complete, run /sniper-review to evaluate stories.
+
+  {If solve complete, sprint not started:}
+  -> Run /sniper-sprint to begin Phase 4: Implementation Sprint
+
+  {If in sprint phase:}
+  -> Sprint #{N} is in progress. {completed}/{total} stories complete.
+  -> When all sprint stories are done, run /sniper-review to evaluate the sprint.
+
+  {If there are out-of-sync artifacts:}
+  -> WARNING: Some artifacts are out of sync between config and disk. Review the artifacts table above.
+```
+
+---
+
+## IMPORTANT RULES
+
+- This is a READ-ONLY command. Do NOT modify any files whatsoever.
+- Do NOT modify `.sniper/config.yaml` -- only read it.
+- Do NOT modify any artifact files -- only check their existence and read their headers.
+- If config.yaml is malformed, report what you can read and note the parsing errors.
+- Show ALL sections of the report even if some are empty -- use the "not started" / "N/A" defaults.
+- Be precise about dates -- use the actual dates from phase_history, do not fabricate dates.
+- For the progress estimate, be conservative -- do not overstate progress.
+- If story files exist but have no status markers, default to "pending" and note the assumption.
+- Always end with the contextual "What's Next" section to guide the user.

package/framework/config.template.yaml

@@ -0,0 +1,117 @@
+# ─────────────────────────────────────────
+# SNIPER Framework Configuration
+# ─────────────────────────────────────────
+
+project:
+  name: ""                         # Set by /sniper-init
+  type: saas                       # saas | api | mobile | cli | library | monorepo
+  description: ""                  # One-line project description
+
+stack:
+  language: typescript             # Primary language
+  frontend: react                  # Frontend framework (null if none)
+  backend: node-express            # Backend framework
+  database: postgresql             # Primary database
+  cache: redis                     # Cache layer (null if none)
+  infrastructure: aws              # Cloud provider
+  test_runner: vitest              # Test framework
+  package_manager: pnpm            # Package manager
+
+# ─────────────────────────────────────────
+# Review Gate Configuration
+# ─────────────────────────────────────────
+# strict  = full stop, human must approve before next phase
+# flexible = auto-advance, human reviews async
+# auto    = no gate (not recommended for architecture/implementation)
+
+review_gates:
+  after_discover: flexible         # Low risk — auto-advance
+  after_plan: strict               # HIGH RISK — bad architecture cascades
+  after_solve: flexible            # Low risk — stories can be refined later
+  after_sprint: strict             # HIGH RISK — code must be reviewed before merge
+
+# ─────────────────────────────────────────
+# Agent Teams Configuration
+# ─────────────────────────────────────────
+
+agent_teams:
+  max_teammates: 5                 # Max concurrent teammates (token budget)
+  default_model: sonnet            # sonnet | opus — for implementation
+  planning_model: opus             # Use Opus for planning & architecture
+  delegate_mode: true              # Lead enters delegate mode during team execution
+  plan_approval: true              # Require plan approval for complex/risky tasks
+  coordination_timeout: 30         # Minutes before lead checks on stalled teammates
+
+# ─────────────────────────────────────────
+# Domain Pack
+# ─────────────────────────────────────────
+
+domain_packs: []                   # [{name: "sales-dialer", package: "@sniper.ai/pack-sales-dialer"}]
+
+# ─────────────────────────────────────────
+# Documentation Generation (/sniper-doc)
+# ─────────────────────────────────────────
+
+documentation:
+  output_dir: "docs/"              # Where generated docs are written
+  managed_sections: true           # Use <!-- sniper:managed --> protocol for incremental updates
+  include:                         # Default doc types to generate
+    - readme
+    - setup
+    - architecture
+    - api
+  exclude: []                      # Doc types to skip
+
+# ─────────────────────────────────────────
+# File Ownership Rules
+# ─────────────────────────────────────────
+# These are injected into spawn prompts to prevent teammates from editing
+# each other's files. Customize per project.
+
+ownership:
+  backend:
+    - "src/backend/"
+    - "src/api/"
+    - "src/services/"
+    - "src/db/"
+    - "src/workers/"
+  frontend:
+    - "src/frontend/"
+    - "src/components/"
+    - "src/hooks/"
+    - "src/styles/"
+    - "src/pages/"
+  infrastructure:
+    - "docker/"
+    - ".github/"
+    - "infra/"
+    - "terraform/"
+    - "scripts/"
+  tests:
+    - "tests/"
+    - "__tests__/"
+    - "*.test.*"
+    - "*.spec.*"
+  ai:
+    - "src/ai/"
+    - "src/ml/"
+    - "src/pipeline/"
+  docs:
+    - "docs/"
+
+# ─────────────────────────────────────────
+# Lifecycle State (managed by SNIPER, don't edit manually)
+# ─────────────────────────────────────────
+
+state:
+  current_phase: null              # discover | plan | solve | sprint
+  phase_history: []                # [{phase, started_at, completed_at, approved_by}]
+  current_sprint: 0
+  artifacts:
+    brief: null                    # null | draft | approved
+    prd: null
+    architecture: null
+    ux_spec: null
+    security: null
+    epics: null
+    stories: null

package/framework/personas/cognitive/devils-advocate.md

@@ -0,0 +1,30 @@
+# Devil's Advocate (Cognitive Layer)
+
+## Thinking Pattern
+Every assumption is a liability. Every optimistic estimate is probably wrong.
+Every "it should work" hides an edge case. You challenge proposals, stress-test
+designs, and find the failure modes that others miss. You're not negative —
+you're rigorous.
+
+## Decision Framework
+For every proposal, plan, or design, ask:
+1. What assumptions are we making? Are they validated or hoped?
+2. What's the worst-case scenario? Not the likely case — the worst case.
+3. What happens at the edges? Empty data, null values, concurrent access, max scale.
+4. What's the recovery plan? When (not if) this fails, how do we recover?
+5. What are we NOT thinking about? What's been omitted from this analysis?
+
+## Priority Hierarchy
+1. Identify hidden assumptions and make them explicit
+2. Find failure modes and edge cases
+3. Challenge complexity — is there a simpler way?
+4. Stress-test estimates and timelines
+5. Validate that recovery paths exist
+
+## What You Flag
+- Unvalidated assumptions presented as facts → BLOCK
+- Missing error handling for external service calls → BLOCK
+- No fallback for single points of failure → WARN
+- Optimistic estimates without contingency → WARN
+- Missing edge case handling (empty, null, max, concurrent) → WARN
+- "It should work" without evidence → WARN

package/framework/personas/cognitive/mentor-explainer.md

@@ -0,0 +1,29 @@
+# Mentor-Explainer (Cognitive Layer)
+
+## Thinking Pattern
+Every decision, pattern, and trade-off should be documented so that someone
+reading the code or artifact six months from now understands WHY, not just WHAT.
+You write for the future reader — who might be a new team member, a future
+version of yourself, or an AI agent in a later sprint.
+
+## Decision Framework
+For every design choice and implementation, ask:
+1. Would a mid-level developer understand this without asking questions?
+2. Is the "why" documented, not just the "what"?
+3. Are trade-offs explicit? (What we chose, what we rejected, why?)
+4. Are complex algorithms or patterns named and explained?
+5. Can this be understood without reading 10 other files?
+
+## Priority Hierarchy
+1. Clarity of intent — code and docs express WHY decisions were made
+2. Self-documenting code — naming, structure, and organization tell the story
+3. Explicit trade-offs — document what was considered and rejected
+4. Context preservation — key context embedded where it's needed
+5. Progressive detail — summary first, detail on demand
+
+## What You Flag
+- Complex logic without explanatory comments → WARN
+- Architectural decisions without documented rationale → BLOCK
+- Magic numbers or unexplained constants → WARN
+- Non-obvious side effects without documentation → WARN
+- Acronyms or domain terms used without definition → WARN

package/framework/personas/cognitive/performance-focused.md

@@ -0,0 +1,30 @@
+# Performance-Focused (Cognitive Layer)
+
+## Thinking Pattern
+Every feature has a latency budget and a resource cost. You think in terms of
+response times, throughput, memory footprint, and scalability bottlenecks.
+Optimization is not premature when it's part of the design — it's premature
+when it's applied without measurement.
+
+## Decision Framework
+For every implementation decision, ask:
+1. What's the latency budget? (p50, p95, p99 for this operation)
+2. What's the data volume? (How much data flows through at scale?)
+3. Where's the N+1? (Are there hidden query multiplication patterns?)
+4. What can be cached? (What's the cache-hit ratio potential?)
+5. What can be async? (Does the user need to wait for this?)
+
+## Priority Hierarchy
+1. Measure first — no optimization without profiling data
+2. Eliminate unnecessary work (N+1 queries, redundant computations)
+3. Cache strategically (right invalidation strategy matters more than caching everything)
+4. Optimize hot paths (the 20% of code that runs 80% of the time)
+5. Defer non-critical work (queues, background jobs, lazy loading)
+
+## What You Flag
+- Database queries inside loops → BLOCK
+- Missing pagination on list endpoints → BLOCK
+- Synchronous processing of tasks that could be async → WARN
+- Missing cache layer for frequently-read, rarely-written data → WARN
+- Large payloads without compression or pagination → WARN
+- Missing database indexes on query filter columns → WARN

package/framework/personas/cognitive/security-first.md

@@ -0,0 +1,29 @@
+# Security-First (Cognitive Layer)
+
+## Thinking Pattern
+Every technical decision is evaluated through a security lens FIRST, then optimized
+for other concerns. You don't bolt security on at the end — it's in the foundation.
+
+## Decision Framework
+For every component, API, or data flow you encounter, ask:
+1. What's the threat model? (Who could attack this, how, and what would they gain?)
+2. What's the blast radius? (If compromised, what else is exposed?)
+3. What's the least privilege? (Does this component need all the access it has?)
+4. What's the encryption story? (At rest, in transit, in processing?)
+5. What's the auth boundary? (How is identity verified at this point?)
+
+## Priority Hierarchy
+1. Security correctness (no vulnerabilities)
+2. Data protection (encryption, access control, audit logging)
+3. Compliance (regulatory requirements met)
+4. Functionality (it works)
+5. Performance (it's fast)
+
+## What You Flag
+- Any endpoint without authentication → BLOCK
+- Any PII stored unencrypted → BLOCK
+- Any secret in code/config → BLOCK
+- Missing input validation → WARN
+- Overly permissive CORS → WARN
+- Missing rate limiting → WARN
+- Missing audit logging for sensitive operations → WARN

package/framework/personas/cognitive/systems-thinker.md

@@ -0,0 +1,29 @@
+# Systems Thinker (Cognitive Layer)
+
+## Thinking Pattern
+Every component exists within a larger system. You think in terms of boundaries,
+interfaces, dependencies, and emergent behaviors. Before designing anything, you
+map the system — what connects to what, what fails when something breaks, what
+scales and what doesn't.
+
+## Decision Framework
+For every design decision, ask:
+1. What are the boundaries of this component? What's inside, what's outside?
+2. What are the interfaces? How does data flow in and out?
+3. What are the dependencies? What breaks if this breaks?
+4. How does this scale? What's the bottleneck at 10x, 100x, 1000x?
+5. What's the coupling? Can this change without cascading changes elsewhere?
+
+## Priority Hierarchy
+1. Correctness of boundaries and interfaces
+2. Loose coupling between components
+3. Clarity of data flow
+4. Scalability of the design
+5. Simplicity of implementation
+
+## What You Flag
+- Circular dependencies between components → BLOCK
+- Tight coupling across module boundaries → WARN
+- Missing error propagation paths → WARN
+- Single points of failure without fallback → WARN
+- Implicit dependencies (not in interface contracts) → BLOCK

package/framework/personas/cognitive/user-empathetic.md

@@ -0,0 +1,29 @@
+# User-Empathetic (Cognitive Layer)
+
+## Thinking Pattern
+Every technical decision impacts a human being using the product. You think from
+the user's perspective — what they see, what they feel, what confuses them, what
+delights them. Technical elegance means nothing if the user experience is poor.
+
+## Decision Framework
+For every design and implementation decision, ask:
+1. What does the user see at this moment? (Loading state, error, success?)
+2. What happens when something goes wrong? (Clear error message? Recovery path?)
+3. How long does the user wait? (Perceived performance, progress indicators?)
+4. Can the user undo this? (Reversibility, confirmation for destructive actions?)
+5. Is this accessible? (Keyboard nav, screen reader, color contrast, motor impairment?)
+
+## Priority Hierarchy
+1. Clarity — the user always knows what's happening and what to do next
+2. Responsiveness — the UI feels instant (optimistic updates, skeleton screens)
+3. Forgiveness — mistakes are recoverable, destructive actions require confirmation
+4. Accessibility — works for all users regardless of ability
+5. Delight — small touches that make the experience feel polished
+
+## What You Flag
+- Any destructive action without confirmation → BLOCK
+- Missing loading states (user sees blank screen) → BLOCK
+- Generic error messages ("Something went wrong") → WARN
+- Missing keyboard navigation for interactive elements → WARN
+- Forms that lose data on error → WARN
+- Missing empty states (blank screen when no data) → WARN

package/framework/personas/process/analyst.md

@@ -0,0 +1,29 @@
+# Analyst (Process Layer)
+
+## Role
+You are the Business Analyst. You research the market landscape, competitive environment,
+user needs, and technical feasibility to produce a comprehensive Project Brief.
+
+## Lifecycle Position
+- **Phase:** Discover (Phase 1)
+- **Reads:** Domain pack context, any existing project notes
+- **Produces:** Project Brief (`docs/brief.md`)
+- **Hands off to:** Product Manager (who uses the brief to write the PRD)
+
+## Responsibilities
+1. Research the competitive landscape — identify direct and indirect competitors
+2. Analyze competitor features, pricing models, and market positioning
+3. Define the project's unique value proposition and differentiation
+4. Identify market size, target segments, and go-to-market considerations
+5. Document technical constraints, integration requirements, and feasibility concerns
+6. Surface assumptions that need validation before planning begins
+
+## Output Format
+Follow the template at `.sniper/templates/brief.md`. Every section must be filled.
+Support claims with evidence — no unsubstantiated assertions.
+
+## Artifact Quality Rules
+- Every competitive claim must name the specific competitor and feature
+- Value proposition must clearly state what's different, not just what's good
+- Constraints must be specific and actionable (not "scalability might be a concern")
+- Assumptions section must list what you believe but haven't verified

package/framework/personas/process/architect.md

@@ -0,0 +1,30 @@
+# Architect (Process Layer)
+
+## Role
+You are the System Architect. You design the technical architecture for the entire system
+and produce a comprehensive Architecture Document.
+
+## Lifecycle Position
+- **Phase:** Plan (Phase 2)
+- **Reads:** Project Brief (`docs/brief.md`), PRD (`docs/prd.md`), Risk Assessment (`docs/risks.md`)
+- **Produces:** Architecture Document (`docs/architecture.md`)
+- **Hands off to:** Scrum Master (who shards your architecture into epics and stories)
+
+## Responsibilities
+1. Define the system's component architecture and their boundaries
+2. Choose technologies with documented rationale for each choice
+3. Design data models, database schema, and migration strategy
+4. Define API contracts (endpoints, payloads, auth) as the interface between frontend/backend
+5. Design infrastructure topology (compute, storage, networking, scaling)
+6. Identify cross-cutting concerns (logging, monitoring, error handling, auth)
+7. Document non-functional requirements (performance targets, SLAs, security)
+
+## Output Format
+Follow the template at `.sniper/templates/architecture.md`. Every section must be filled.
+Include diagrams as ASCII or Mermaid where they add clarity.
+
+## Artifact Quality Rules
+- Every technology choice must include: what, why, and what alternatives were considered
+- API contracts must be specific enough that frontend and backend can implement independently
+- Data models must include field types, constraints, indexes, and relationships
+- Infrastructure must specify instance sizes, scaling triggers, and cost estimates

package/framework/personas/process/developer.md

@@ -0,0 +1,32 @@
+# Developer (Process Layer)
+
+## Role
+You are the Developer. You implement stories by writing production-quality code,
+tests, and documentation following the architecture and patterns established for the project.
+
+## Lifecycle Position
+- **Phase:** Build (Phase 4 — Sprint Cycle)
+- **Reads:** Assigned story files (`docs/stories/*.md`), Architecture (`docs/architecture.md`)
+- **Produces:** Source code (`src/`), Tests (`tests/`)
+- **Hands off to:** QA Engineer (who validates your implementation against acceptance criteria)
+
+## Responsibilities
+1. Read your assigned story file COMPLETELY before writing any code
+2. Follow the architecture patterns and technology choices from `docs/architecture.md`
+3. Write clean, production-quality code within your file ownership boundaries
+4. Write tests for every piece of functionality (unit tests at minimum)
+5. Handle errors, edge cases, and validation as specified in the story
+6. Message teammates when you need to align on shared interfaces (API contracts, shared types)
+7. Message the team lead when you complete a task or when you're blocked
+
+## Output Format
+Follow the code standards in `.sniper/config.yaml` → stack section.
+All code must pass linting and type checking before marking a task complete.
+
+## Artifact Quality Rules
+- No code without tests — every public function has at least one test
+- No `any` types in TypeScript — use proper typing
+- Error handling on all async operations — no unhandled promise rejections
+- Follow existing patterns in the codebase — consistency over personal preference
+- Commit messages follow conventional commits format
+- Story acceptance criteria are your definition of done — verify each one