@arvorco/relentless 0.1.0 → 0.1.6

package/.claude/skills/relentless/SKILL.md

@@ -1,265 +0,0 @@
----
-name: relentless
-description: "Convert PRDs to prd.json format for the Relentless autonomous agent system. Use when you have an existing PRD and need to convert it to Relentless JSON format. Triggers on: convert this prd, turn this into relentless format, create prd.json from this, relentless json."
----
-
-# Relentless PRD Converter
-
-Converts existing PRDs to the prd.json format that Relentless uses for autonomous execution with any AI coding agent.
-
----
-
-## The Job
-
-Take a PRD (markdown file or text) and convert it to `relentless/prd.json` in your project directory.
-
-**Important:** All relentless files are stored in the `relentless/` subdirectory.
-
----
-
-## Output Format
-
-```json
-{
-  "project": "[Project Name]",
-  "branchName": "relentless/[feature-name-kebab-case]",
-  "description": "[Feature description from PRD title/intro]",
-  "userStories": [
-    {
-      "id": "US-001",
-      "title": "[Story title]",
-      "description": "As a [user], I want [feature] so that [benefit]",
-      "acceptanceCriteria": [
-        "Criterion 1",
-        "Criterion 2",
-        "Typecheck passes"
-      ],
-      "priority": 1,
-      "passes": false,
-      "notes": ""
-    }
-  ]
-}
-```
-
----
-
-## Story Size: The Number One Rule
-
-**Each story must be completable in ONE Relentless iteration (one context window).**
-
-Relentless spawns a fresh AI agent instance per iteration with no memory of previous work. If a story is too big, the LLM runs out of context before finishing and produces broken code.
-
-### Right-sized stories:
-- Add a database column and migration
-- Add a UI component to an existing page
-- Update a server action with new logic
-- Add a filter dropdown to a list
-
-### Too big (split these):
-- "Build the entire dashboard" - Split into: schema, queries, UI components, filters
-- "Add authentication" - Split into: schema, middleware, login UI, session handling
-- "Refactor the API" - Split into one story per endpoint or pattern
-
-**Rule of thumb:** If you cannot describe the change in 2-3 sentences, it is too big.
-
----
-
-## Story Ordering: Dependencies First
-
-Stories execute in priority order. Earlier stories must not depend on later ones.
-
-**Correct order:**
-1. Schema/database changes (migrations)
-2. Server actions / backend logic
-3. UI components that use the backend
-4. Dashboard/summary views that aggregate data
-
-**Wrong order:**
-1. UI component (depends on schema that does not exist yet)
-2. Schema change
-
----
-
-## Acceptance Criteria: Must Be Verifiable
-
-Each criterion must be something the agent can CHECK, not something vague.
-
-### Good criteria (verifiable):
-- "Add `status` column to tasks table with default 'pending'"
-- "Filter dropdown has options: All, Active, Completed"
-- "Clicking delete shows confirmation dialog"
-- "Typecheck passes"
-- "Tests pass"
-
-### Bad criteria (vague):
-- "Works correctly"
-- "User can do X easily"
-- "Good UX"
-- "Handles edge cases"
-
-### Always include as final criterion:
-```
-"Typecheck passes"
-```
-
-For stories with testable logic, also include:
-```
-"Tests pass"
-```
-
-### For stories that change UI, also include:
-```
-"Verify in browser"
-```
-
-Frontend stories are NOT complete until visually verified.
-
----
-
-## Conversion Rules
-
-1. **Each user story becomes one JSON entry**
-2. **IDs**: Sequential (US-001, US-002, etc.)
-3. **Priority**: Based on dependency order, then document order
-4. **All stories**: `passes: false` and empty `notes`
-5. **branchName**: Derive from feature name, kebab-case, prefixed with `relentless/`
-6. **Always add**: "Typecheck passes" to every story's acceptance criteria
-
----
-
-## Splitting Large PRDs
-
-If a PRD has big features, split them:
-
-**Original:**
-> "Add user notification system"
-
-**Split into:**
-1. US-001: Add notifications table to database
-2. US-002: Create notification service for sending notifications
-3. US-003: Add notification bell icon to header
-4. US-004: Create notification dropdown panel
-5. US-005: Add mark-as-read functionality
-6. US-006: Add notification preferences page
-
-Each is one focused change that can be completed and verified independently.
-
----
-
-## Example
-
-**Input PRD:**
-```markdown
-# Task Status Feature
-
-Add ability to mark tasks with different statuses.
-
-## Requirements
-- Toggle between pending/in-progress/done on task list
-- Filter list by status
-- Show status badge on each task
-- Persist status in database
-```
-
-**Output prd.json:**
-```json
-{
-  "project": "TaskApp",
-  "branchName": "relentless/task-status",
-  "description": "Task Status Feature - Track task progress with status indicators",
-  "userStories": [
-    {
-      "id": "US-001",
-      "title": "Add status field to tasks table",
-      "description": "As a developer, I need to store task status in the database.",
-      "acceptanceCriteria": [
-        "Add status column: 'pending' | 'in_progress' | 'done' (default 'pending')",
-        "Generate and run migration successfully",
-        "Typecheck passes"
-      ],
-      "priority": 1,
-      "passes": false,
-      "notes": ""
-    },
-    {
-      "id": "US-002",
-      "title": "Display status badge on task cards",
-      "description": "As a user, I want to see task status at a glance.",
-      "acceptanceCriteria": [
-        "Each task card shows colored status badge",
-        "Badge colors: gray=pending, blue=in_progress, green=done",
-        "Typecheck passes",
-        "Verify in browser"
-      ],
-      "priority": 2,
-      "passes": false,
-      "notes": ""
-    },
-    {
-      "id": "US-003",
-      "title": "Add status toggle to task list rows",
-      "description": "As a user, I want to change task status directly from the list.",
-      "acceptanceCriteria": [
-        "Each row has status dropdown or toggle",
-        "Changing status saves immediately",
-        "UI updates without page refresh",
-        "Typecheck passes",
-        "Verify in browser"
-      ],
-      "priority": 3,
-      "passes": false,
-      "notes": ""
-    },
-    {
-      "id": "US-004",
-      "title": "Filter tasks by status",
-      "description": "As a user, I want to filter the list to see only certain statuses.",
-      "acceptanceCriteria": [
-        "Filter dropdown: All | Pending | In Progress | Done",
-        "Filter persists in URL params",
-        "Typecheck passes",
-        "Verify in browser"
-      ],
-      "priority": 4,
-      "passes": false,
-      "notes": ""
-    }
-  ]
-}
-```
-
----
-
-## Running Relentless
-
-After creating relentless/prd.json, run the orchestrator:
-
-```bash
-# With Claude Code (default)
-./relentless/bin/relentless.sh
-
-# With a specific agent
-./relentless/bin/relentless.sh --agent amp
-./relentless/bin/relentless.sh --agent codex
-./relentless/bin/relentless.sh --agent gemini
-
-# Smart routing (auto-select best agent per story)
-./relentless/bin/relentless.sh --agent auto
-
-# Custom max iterations
-./relentless/bin/relentless.sh --max-iterations 30
-```
-
----
-
-## Checklist Before Saving
-
-Before writing prd.json, verify:
-
-- [ ] Each story is completable in one iteration (small enough)
-- [ ] Stories are ordered by dependency (schema to backend to UI)
-- [ ] Every story has "Typecheck passes" as criterion
-- [ ] UI stories have "Verify in browser" as criterion
-- [ ] Acceptance criteria are verifiable (not vague)
-- [ ] No story depends on a later story

package/.claude/skills/specify/SKILL.md

@@ -1,220 +0,0 @@
----
-name: specify
-description: "Create feature specification from natural language description. Use when starting a new feature or creating a spec. Triggers on: create spec, specify feature, new feature spec."
----
-
-# Feature Specification Generator
-
-Create structured feature specifications from natural language descriptions.
-
----
-
-## The Job
-
-1. Receive feature description from user
-2. Generate short name and feature number
-3. Create branch and feature directory in `relentless/features/NNN-feature-name/`
-4. Generate specification using template
-5. Validate specification quality
-6. Save to `spec.md`
-
----
-
-## Step 1: Create Feature Structure
-
-Run the create-new-feature script to set up the branch and directory:
-
-```bash
-.claude/skills/specify/scripts/bash/create-new-feature.sh --json "FEATURE_DESCRIPTION"
-```
-
-This will output JSON with:
-- `BRANCH_NAME`: e.g., "003-user-auth"
-- `SPEC_FILE`: Full path to spec.md
-- `FEATURE_DIR`: Full path to feature directory
-- `FEATURE_NUM`: e.g., "003"
-
-**Important:** Parse this JSON and use these paths for all subsequent operations.
-
----
-
-## Step 2: Load Constitution & Context
-
-1. Read `relentless/constitution.md` for project governance
-2. Note any MUST/SHOULD rules that apply to specifications
-3. Keep these principles in mind while generating the spec
-
----
-
-## Step 3: Generate Specification
-
-Using the template at `templates/spec-template.md`, create a specification with:
-
-### Required Sections:
-
-**1. Feature Overview**
-- One-paragraph summary
-- User value proposition
-- Problem being solved
-
-**2. User Scenarios & Testing**
-- Concrete user stories
-- Step-by-step flows
-- Expected outcomes
-
-**3. Functional Requirements**
-- What the system must do
-- Testable requirements (no implementation details)
-- Clear success criteria
-
-**4. Success Criteria**
-- Measurable, technology-agnostic outcomes
-- Quantitative metrics (time, performance, volume)
-- Qualitative measures (user satisfaction, task completion)
-
-**5. Key Entities (if applicable)**
-- Data models and relationships
-- Fields and types (logical, not implementation)
-
-**6. Dependencies & Assumptions**
-- External systems required
-- Prerequisites
-- Assumptions made
-
-**7. Out of Scope**
-- What this feature explicitly does NOT include
-- Future considerations
-
----
-
-## Step 4: Handle Ambiguities
-
-If aspects are unclear:
-- Make informed guesses based on context
-- Only mark `[NEEDS CLARIFICATION: specific question]` if:
-  - Choice significantly impacts scope or UX
-  - Multiple reasonable interpretations exist
-  - No reasonable default exists
-- **LIMIT: Maximum 3 clarifications**
-
-If clarifications needed, present to user:
-
-```markdown
-## Clarification Needed
-
-**Q1: [Topic]**
-Context: [Quote spec section]
-Question: [Specific question]
-
-Options:
-A. [Option 1] - [Implications]
-B. [Option 2] - [Implications]
-C. Custom - [Your answer]
-
-Your choice: _
-```
-
----
-
-## Step 5: Validate Quality
-
-Check the specification against:
-
-- [ ] No implementation details (languages, frameworks, APIs)
-- [ ] Focused on user value and business needs
-- [ ] All requirements are testable
-- [ ] Success criteria are measurable
-- [ ] User scenarios cover primary flows
-- [ ] Dependencies identified
-- [ ] Scope clearly bounded
-- [ ] No more than 3 `[NEEDS CLARIFICATION]` markers
-
-If validation fails, revise and re-check (max 3 iterations).
-
----
-
-## Step 6: Save & Report
-
-1. Write complete specification to `SPEC_FILE` from JSON output
-2. Create progress.txt if it doesn't exist:
-   ```markdown
-   ---
-   feature: FEATURE_NAME
-   started: DATE
-   last_updated: DATE
-   stories_completed: 0
-   ---
-   
-   # Progress Log: FEATURE_NAME
-   ```
-
-3. Report to user:
-   - Branch created: `BRANCH_NAME`
-   - Spec saved: `SPEC_FILE`
-   - Quality validation: PASSED/FAILED
-   - Next step: `/relentless.plan` or `/relentless.clarify`
-
----
-
-## Example Output
-
-```markdown
-# Feature: User Authentication
-
-## Overview
-Enable users to create accounts and log in securely using email/password.
-
-## User Scenarios
-
-### Scenario 1: New User Registration
-1. User visits signup page
-2. Enters email and password
-3. Submits form
-4. Receives confirmation email
-5. Clicks confirmation link
-6. Account is activated
-
-**Expected Outcome:** User has active account and can log in.
-
-## Functional Requirements
-
-**REQ-1:** System must validate email format
-**REQ-2:** System must require passwords ≥ 8 characters
-**REQ-3:** System must send confirmation email within 1 minute
-**REQ-4:** System must hash passwords before storage
-
-## Success Criteria
-
-1. 95% of signups complete within 60 seconds
-2. Zero plaintext passwords in database
-3. Email confirmation rate > 80%
-
-## Key Entities
-
-**User**
-- email: string (unique)
-- password_hash: string
-- confirmed: boolean
-- created_at: timestamp
-
-## Dependencies
-
-- Email service provider (e.g., SendGrid, Mailgun)
-- Session management system
-
-## Out of Scope
-
-- Social login (OAuth)
-- Two-factor authentication
-- Password reset (separate feature)
-```
-
----
-
-## Notes
-
-- Always run the script first to get proper paths
-- Use absolute paths from JSON output
-- Validate before marking complete
-- Keep specification technology-agnostic
-- Focus on WHAT, not HOW

package/.claude/skills/specify/scripts/bash/check-prerequisites.sh

@@ -1,166 +0,0 @@
-#!/usr/bin/env bash
-
-# Consolidated prerequisite checking script
-#
-# This script provides unified prerequisite checking for Spec-Driven Development workflow.
-# It replaces the functionality previously spread across multiple scripts.
-#
-# Usage: ./check-prerequisites.sh [OPTIONS]
-#
-# OPTIONS:
-#   --json              Output in JSON format
-#   --require-tasks     Require tasks.md to exist (for implementation phase)
-#   --include-tasks     Include tasks.md in AVAILABLE_DOCS list
-#   --paths-only        Only output path variables (no validation)
-#   --help, -h          Show help message
-#
-# OUTPUTS:
-#   JSON mode: {"FEATURE_DIR":"...", "AVAILABLE_DOCS":["..."]}
-#   Text mode: FEATURE_DIR:... \n AVAILABLE_DOCS: \n ✓/✗ file.md
-#   Paths only: REPO_ROOT: ... \n BRANCH: ... \n FEATURE_DIR: ... etc.
-
-set -e
-
-# Parse command line arguments
-JSON_MODE=false
-REQUIRE_TASKS=false
-INCLUDE_TASKS=false
-PATHS_ONLY=false
-
-for arg in "$@"; do
-    case "$arg" in
-        --json)
-            JSON_MODE=true
-            ;;
-        --require-tasks)
-            REQUIRE_TASKS=true
-            ;;
-        --include-tasks)
-            INCLUDE_TASKS=true
-            ;;
-        --paths-only)
-            PATHS_ONLY=true
-            ;;
-        --help|-h)
-            cat << 'EOF'
-Usage: check-prerequisites.sh [OPTIONS]
-
-Consolidated prerequisite checking for Spec-Driven Development workflow.
-
-OPTIONS:
-  --json              Output in JSON format
-  --require-tasks     Require tasks.md to exist (for implementation phase)
-  --include-tasks     Include tasks.md in AVAILABLE_DOCS list
-  --paths-only        Only output path variables (no prerequisite validation)
-  --help, -h          Show this help message
-
-EXAMPLES:
-  # Check task prerequisites (plan.md required)
-  ./check-prerequisites.sh --json
-  
-  # Check implementation prerequisites (plan.md + tasks.md required)
-  ./check-prerequisites.sh --json --require-tasks --include-tasks
-  
-  # Get feature paths only (no validation)
-  ./check-prerequisites.sh --paths-only
-  
-EOF
-            exit 0
-            ;;
-        *)
-            echo "ERROR: Unknown option '$arg'. Use --help for usage information." >&2
-            exit 1
-            ;;
-    esac
-done
-
-# Source common functions
-SCRIPT_DIR="$(CDPATH="" cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
-source "$SCRIPT_DIR/common.sh"
-
-# Get feature paths and validate branch
-eval $(get_feature_paths)
-check_feature_branch "$CURRENT_BRANCH" "$HAS_GIT" || exit 1
-
-# If paths-only mode, output paths and exit (support JSON + paths-only combined)
-if $PATHS_ONLY; then
-    if $JSON_MODE; then
-        # Minimal JSON paths payload (no validation performed)
-        printf '{"REPO_ROOT":"%s","BRANCH":"%s","FEATURE_DIR":"%s","FEATURE_SPEC":"%s","IMPL_PLAN":"%s","TASKS":"%s"}\n' \
-            "$REPO_ROOT" "$CURRENT_BRANCH" "$FEATURE_DIR" "$FEATURE_SPEC" "$IMPL_PLAN" "$TASKS"
-    else
-        echo "REPO_ROOT: $REPO_ROOT"
-        echo "BRANCH: $CURRENT_BRANCH"
-        echo "FEATURE_DIR: $FEATURE_DIR"
-        echo "FEATURE_SPEC: $FEATURE_SPEC"
-        echo "IMPL_PLAN: $IMPL_PLAN"
-        echo "TASKS: $TASKS"
-    fi
-    exit 0
-fi
-
-# Validate required directories and files
-if [[ ! -d "$FEATURE_DIR" ]]; then
-    echo "ERROR: Feature directory not found: $FEATURE_DIR" >&2
-    echo "Run /relentless.specify first to create the feature structure." >&2
-    exit 1
-fi
-
-if [[ ! -f "$IMPL_PLAN" ]]; then
-    echo "ERROR: plan.md not found in $FEATURE_DIR" >&2
-    echo "Run /relentless.plan first to create the implementation plan." >&2
-    exit 1
-fi
-
-# Check for tasks.md if required
-if $REQUIRE_TASKS && [[ ! -f "$TASKS" ]]; then
-    echo "ERROR: tasks.md not found in $FEATURE_DIR" >&2
-    echo "Run /relentless.tasks first to create the task list." >&2
-    exit 1
-fi
-
-# Build list of available documents
-docs=()
-
-# Always check these optional docs
-[[ -f "$RESEARCH" ]] && docs+=("research.md")
-[[ -f "$DATA_MODEL" ]] && docs+=("data-model.md")
-
-# Check contracts directory (only if it exists and has files)
-if [[ -d "$CONTRACTS_DIR" ]] && [[ -n "$(ls -A "$CONTRACTS_DIR" 2>/dev/null)" ]]; then
-    docs+=("contracts/")
-fi
-
-[[ -f "$QUICKSTART" ]] && docs+=("quickstart.md")
-
-# Include tasks.md if requested and it exists
-if $INCLUDE_TASKS && [[ -f "$TASKS" ]]; then
-    docs+=("tasks.md")
-fi
-
-# Output results
-if $JSON_MODE; then
-    # Build JSON array of documents
-    if [[ ${#docs[@]} -eq 0 ]]; then
-        json_docs="[]"
-    else
-        json_docs=$(printf '"%s",' "${docs[@]}")
-        json_docs="[${json_docs%,}]"
-    fi
-    
-    printf '{"FEATURE_DIR":"%s","AVAILABLE_DOCS":%s}\n' "$FEATURE_DIR" "$json_docs"
-else
-    # Text output
-    echo "FEATURE_DIR:$FEATURE_DIR"
-    echo "AVAILABLE_DOCS:"
-    
-    # Show status of each potential document
-    check_file "$RESEARCH" "research.md"
-    check_file "$DATA_MODEL" "data-model.md"
-    check_dir "$CONTRACTS_DIR" "contracts/"
-    check_file "$QUICKSTART" "quickstart.md"
-    
-    if $INCLUDE_TASKS; then
-        check_file "$TASKS" "tasks.md"
-    fi
-fi