specrails-core 3.8.0 → 4.0.0

package/.claude/skills/openspec-verify-change/SKILL.md

@@ -1,168 +0,0 @@
----
-name: openspec-verify-change
-description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.1.1"
----
-
-Verify that an implementation matches the change artifacts (specs, tasks, design).
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show changes that have implementation tasks (tasks artifact exists).
-   Include the schema used for each change if available.
-   Mark changes with incomplete tasks as "(In Progress)".
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - Which artifacts exist for this change
-
-3. **Get the change directory and load artifacts**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns the change directory and context files. Read all available artifacts from `contextFiles`.
-
-4. **Initialize verification report structure**
-
-   Create a report structure with three dimensions:
-   - **Completeness**: Track tasks and spec coverage
-   - **Correctness**: Track requirement implementation and scenario coverage
-   - **Coherence**: Track design adherence and pattern consistency
-
-   Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
-
-5. **Verify Completeness**
-
-   **Task Completion**:
-   - If tasks.md exists in contextFiles, read it
-   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
-   - Count complete vs total tasks
-   - If incomplete tasks exist:
-     - Add CRITICAL issue for each incomplete task
-     - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
-
-   **Spec Coverage**:
-   - If delta specs exist in `openspec/changes/<name>/specs/`:
-     - Extract all requirements (marked with "### Requirement:")
-     - For each requirement:
-       - Search codebase for keywords related to the requirement
-       - Assess if implementation likely exists
-     - If requirements appear unimplemented:
-       - Add CRITICAL issue: "Requirement not found: <requirement name>"
-       - Recommendation: "Implement requirement X: <description>"
-
-6. **Verify Correctness**
-
-   **Requirement Implementation Mapping**:
-   - For each requirement from delta specs:
-     - Search codebase for implementation evidence
-     - If found, note file paths and line ranges
-     - Assess if implementation matches requirement intent
-     - If divergence detected:
-       - Add WARNING: "Implementation may diverge from spec: <details>"
-       - Recommendation: "Review <file>:<lines> against requirement X"
-
-   **Scenario Coverage**:
-   - For each scenario in delta specs (marked with "#### Scenario:"):
-     - Check if conditions are handled in code
-     - Check if tests exist covering the scenario
-     - If scenario appears uncovered:
-       - Add WARNING: "Scenario not covered: <scenario name>"
-       - Recommendation: "Add test or implementation for scenario: <description>"
-
-7. **Verify Coherence**
-
-   **Design Adherence**:
-   - If design.md exists in contextFiles:
-     - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
-     - Verify implementation follows those decisions
-     - If contradiction detected:
-       - Add WARNING: "Design decision not followed: <decision>"
-       - Recommendation: "Update implementation or revise design.md to match reality"
-   - If no design.md: Skip design adherence check, note "No design.md to verify against"
-
-   **Code Pattern Consistency**:
-   - Review new code for consistency with project patterns
-   - Check file naming, directory structure, coding style
-   - If significant deviations found:
-     - Add SUGGESTION: "Code pattern deviation: <details>"
-     - Recommendation: "Consider following project pattern: <example>"
-
-8. **Generate Verification Report**
-
-   **Summary Scorecard**:
-   ```
-   ## Verification Report: <change-name>
-
-   ### Summary
-   | Dimension    | Status           |
-   |--------------|------------------|
-   | Completeness | X/Y tasks, N reqs|
-   | Correctness  | M/N reqs covered |
-   | Coherence    | Followed/Issues  |
-   ```
-
-   **Issues by Priority**:
-
-   1. **CRITICAL** (Must fix before archive):
-      - Incomplete tasks
-      - Missing requirement implementations
-      - Each with specific, actionable recommendation
-
-   2. **WARNING** (Should fix):
-      - Spec/design divergences
-      - Missing scenario coverage
-      - Each with specific recommendation
-
-   3. **SUGGESTION** (Nice to fix):
-      - Pattern inconsistencies
-      - Minor improvements
-      - Each with specific recommendation
-
-   **Final Assessment**:
-   - If CRITICAL issues: "X critical issue(s) found. Fix before archiving."
-   - If only warnings: "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."
-   - If all clear: "All checks passed. Ready for archive."
-
-**Verification Heuristics**
-
-- **Completeness**: Focus on objective checklist items (checkboxes, requirements list)
-- **Correctness**: Use keyword search, file path analysis, reasonable inference - don't require perfect certainty
-- **Coherence**: Look for glaring inconsistencies, don't nitpick style
-- **False Positives**: When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL
-- **Actionability**: Every issue must have a specific recommendation with file/line references where applicable
-
-**Graceful Degradation**
-
-- If only tasks.md exists: verify task completion only, skip spec/design checks
-- If tasks + specs exist: verify completeness and correctness, skip design
-- If full artifacts: verify all three dimensions
-- Always note which checks were skipped and why
-
-**Output Format**
-
-Use clear markdown with:
-- Table for summary scorecard
-- Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
-- Code references in format: `file.ts:123`
-- Specific, actionable recommendations
-- No vague suggestions like "consider reviewing"

package/prompts/analyze-codebase.md

@@ -1,87 +0,0 @@
-# Codebase Analysis Prompt
-
-Analyze this repository to understand its architecture, stack, and conventions.
-
-## What to detect
-
-### 1. Languages & Frameworks
-- Scan for language-specific files: `*.py`, `*.ts`, `*.tsx`, `*.js`, `*.go`, `*.rs`, `*.java`, `*.kt`, `*.rb`, `*.cs`, `*.swift`
-- Check dependency files: `requirements.txt`, `pyproject.toml`, `package.json`, `go.mod`, `Cargo.toml`, `pom.xml`, `Gemfile`, `*.csproj`
-- Identify frameworks from imports: FastAPI, Django, Flask, Express, Next.js, React, Vue, Angular, Spring, Gin, Actix, Rails, etc.
-
-### 2. Architecture Layers
-For each detected layer, identify:
-- **Name**: e.g., "Backend", "Frontend", "Core", "API", "Mobile", "CLI"
-- **Path**: e.g., `backend/`, `src/`, `frontend/`, `app/`, `lib/`
-- **Tech**: e.g., "FastAPI (Python)", "React + TypeScript", "Go package"
-- **Tag**: e.g., `[backend]`, `[frontend]`, `[core]`, `[mobile]`, `[test]`
-
-### 3. CI/CD Commands
-Parse `.github/workflows/*.yml`, `.gitlab-ci.yml`, `Jenkinsfile`, `Makefile`, `package.json` scripts to find:
-- **Lint** commands (ruff, eslint, golangci-lint, clippy, rubocop)
-- **Format** commands (ruff format, prettier, gofmt, rustfmt)
-- **Test** commands (pytest, vitest, jest, go test, cargo test)
-- **Build** commands (tsc, vite build, go build, cargo build)
-- **Type check** commands (tsc --noEmit, mypy, pyright)
-
-### 4. Conventions
-Read 3-5 representative source files from each layer to detect:
-- Naming style (snake_case, camelCase, PascalCase)
-- Import organization patterns
-- Error handling approach
-- Testing patterns (framework, mocking, fixtures)
-- API style (REST, GraphQL, tRPC, gRPC)
-- State management (if frontend)
-- Database access pattern (ORM, raw SQL, repository pattern)
-
-### 5. Project Warnings
-Look for:
-- Concurrency constraints
-- Authentication patterns
-- State management gotchas
-- Known test isolation issues
-- Environment-specific behavior
-
-## Output Format
-
-Return a structured analysis:
-
-```yaml
-project:
-  name: "project-name"
-  description: "One-line description"
-
-stack:
-  - layer: "Backend"
-    tech: "FastAPI (Python 3.11)"
-    path: "backend/"
-    tag: "[backend]"
-  - layer: "Frontend"
-    tech: "React 19 + TypeScript + Vite"
-    path: "frontend/"
-    tag: "[frontend]"
-
-ci:
-  backend:
-    lint: "ruff check ."
-    format: "ruff format --check ."
-    test: "pytest tests/ -q"
-  frontend:
-    lint: "npm run lint"
-    typecheck: "npx tsc --noEmit"
-    test: "npx vitest run"
-
-conventions:
-  backend:
-    - "Routes are thin: validate → call service → return model"
-    - "Services own business logic"
-    - "Repository pattern for data access"
-  frontend:
-    - "Functional components with hooks"
-    - "TanStack Query for server state"
-    - "Tailwind for styling"
-
-warnings:
-  - "Auth: All endpoints require authentication"
-  - "Tests: Fixtures must use scope='function'"
-```

package/prompts/generate-personas.md

@@ -1,61 +0,0 @@
-# Persona Generation Prompt
-
-Generate Value Proposition Canvas personas for the target users of this project.
-
-## Input
-
-The user has described their target users in natural language. Use this description to:
-
-1. **Research the competitive landscape** using WebSearch:
-   - Search for existing tools these users currently use
-   - Find common pain points and frustrations in forums (Reddit, HN, product reviews)
-   - Identify feature gaps in competitor products
-   - Understand workflow patterns and daily routines
-
-2. **Generate a detailed VPC persona** for each user type that includes:
-
-### Profile
-- **Nickname + Role**: A memorable name and short role description
-- **Age range**: Typical demographic
-- **Key behaviors**: 4-5 bullet points describing how they work/interact with tools
-- **Tools currently used**: List of specific competitor products/tools
-- **Spending pattern**: If relevant (monthly spend, budget constraints)
-- **Mindset**: How they think about the problem space
-
-### Value Proposition Canvas
-
-#### Customer Jobs (6-8 entries)
-| Type | Job |
-|------|-----|
-| **Functional** | Concrete tasks they need to accomplish |
-| **Social** | How they want to be perceived by others |
-| **Emotional** | How they want to feel |
-
-#### Pains (6-8 entries, graded by severity)
-| Severity | Pain |
-|----------|------|
-| **Critical** | Major blockers — things that cause real frustration or wasted time |
-| **High** | Significant issues that affect daily workflow |
-| **Medium** | Annoyances that are tolerable but reduce satisfaction |
-| **Low** | Minor inconveniences |
-
-#### Gains (6-8 entries, graded by impact)
-| Impact | Gain |
-|--------|------|
-| **High** | Game-changing improvements that would make them switch tools |
-| **Medium** | Meaningful improvements to their workflow |
-| **Low** | Nice-to-haves |
-
-### Key Insight
-> The single most important unmet need that this project can uniquely address. This should be the intersection of a critical pain + a high-impact gain that no competitor handles well.
-
-### Sources
-List the actual URLs used during research (competitive analysis, forums, reviews, documentation).
-
-## Quality Criteria
-
-- **Grounded in research**: Every pain and gain should be traceable to real user feedback, not assumptions
-- **Specific, not generic**: "Spending 30 minutes swapping cards between decks" > "Managing multiple decks is hard"
-- **Actionable**: Each pain/gain should suggest a potential feature
-- **Differentiated**: Personas should have meaningfully different needs — if they're too similar, merge them
-- **Realistic**: Don't invent fantasy users — base on actual market segments

package/prompts/infer-conventions.md

@@ -1,72 +0,0 @@
-# Convention Inference Prompt
-
-Analyze source files to infer coding conventions and patterns used in this project.
-
-## How to Analyze
-
-For each detected layer (backend, frontend, core, etc.):
-
-1. **Read 3-5 representative files** from that layer
-   - Pick files that are central to the layer (routes, components, services, models)
-   - Prefer files with 50-200 lines (enough to show patterns without being overwhelming)
-   - Avoid auto-generated files, config files, or test files for primary analysis
-
-2. **Identify these patterns:**
-
-### Naming
-- Variable naming: snake_case, camelCase, PascalCase
-- Function naming: snake_case, camelCase
-- Class/Type naming: PascalCase, SCREAMING_SNAKE
-- File naming: kebab-case, snake_case, PascalCase
-- Test naming: `test_behavior`, `describe/it`, `Test_Behavior`
-
-### Code Organization
-- Import ordering (stdlib → third-party → local)
-- Module structure (one class per file, multiple, etc.)
-- Export patterns (named exports, default exports, barrel files)
-- Separation of concerns (where does business logic live?)
-
-### Error Handling
-- Exception types (custom exceptions, error codes, Result types)
-- Error propagation (throw, return errors, Result/Option)
-- API error format (structured error responses, HTTP status codes)
-- Validation approach (Pydantic, Zod, custom validators)
-
-### Testing
-- Test framework (pytest, vitest, jest, go test)
-- Test organization (mirrored structure, flat, grouped by type)
-- Mocking approach (unittest.mock, jest.mock, testify)
-- Fixture patterns (pytest fixtures, setup/teardown, factory functions)
-- Test isolation concerns (scope, cleanup, temp directories)
-
-### API Patterns
-- Style (REST, GraphQL, tRPC, gRPC)
-- Route organization (resource-based, feature-based)
-- Middleware usage (auth, logging, rate limiting)
-- Request/response types (Pydantic, TypeScript interfaces, protobuf)
-
-### State Management (frontend)
-- Server state (TanStack Query, SWR, Redux Query)
-- Client state (Context, Zustand, Redux, Jotai)
-- Form handling (React Hook Form, Formik, native)
-
-### Database/Storage
-- Access pattern (Repository, DAO, Active Record, raw queries)
-- ORM (SQLAlchemy, Prisma, GORM, Diesel)
-- Migration tool (Alembic, Prisma Migrate, golang-migrate)
-- Connection management (pool, per-request, singleton)
-
-## Output Format
-
-For each layer, produce a concise list of conventions suitable for a `.claude/rules/{layer}.md` file:
-
-```markdown
-# {Layer Name} Conventions
-
-- Convention 1: description
-- Convention 2: description
-- Convention 3: description
-...
-```
-
-Keep each convention to one line. Focus on patterns that a developer needs to follow when writing new code in this layer.