@arvorco/relentless 0.1.0 → 0.1.6

package/.claude/skills/clarify/SKILL.md

@@ -1,174 +0,0 @@
----
-name: clarify
-description: "Identify and resolve ambiguities in feature specifications. Use when spec has unclear requirements. Triggers on: clarify spec, resolve ambiguities, clarify requirements."
----
-
-# Specification Clarification Tool
-
-Systematically identify and resolve ambiguities in feature specifications.
-
----
-
-## The Job
-
-1. Read spec.md
-2. Scan for 9 types of ambiguities
-3. Present clarification questions to user
-4. Update spec with answers
-5. Save clarification log
-
----
-
-## Step 1: Load Specification
-
-Read `relentless/features/NNN-feature/spec.md`
-
----
-
-## Step 2: Scan for Ambiguities
-
-Check for these 9 types:
-
-**1. Behavioral Ambiguities**
-- What happens when [action]?
-- How should system respond to [event]?
-- Example: "What happens when user enters wrong password 5 times?"
-
-**2. Data Ambiguities**
-- What are required vs optional fields?
-- What validation rules apply?
-- Example: "What email format validation should we use?"
-
-**3. UI/UX Ambiguities**
-- Where should this be displayed?
-- How should user interact?
-- What visual style?
-- Example: "Should password field show/hide toggle?"
-
-**4. Integration Ambiguities**
-- Which external API/service?
-- What happens if service unavailable?
-- Example: "Which email provider: SendGrid, Mailgun, or AWS SES?"
-
-**5. Permission Ambiguities**
-- Who can perform this action?
-- What authorization rules?
-- Example: "Can unconfirmed users log in or should we block them?"
-
-**6. Performance Ambiguities**
-- What are acceptable response times?
-- Pagination requirements?
-- Example: "How many login attempts allowed per minute?"
-
-**7. Error Handling Ambiguities**
-- What errors can occur?
-- How should errors be displayed?
-- Example: "What message for duplicate email: '409 Conflict' or custom message?"
-
-**8. State Management Ambiguities**
-- How is data persisted?
-- What about caching?
-- Example: "Should we remember failed login attempts across sessions?"
-
-**9. Edge Case Ambiguities**
-- What about empty data?
-- Race conditions?
-- Example: "What if two users register with same email simultaneously?"
-
----
-
-## Step 3: Present Questions
-
-For each ambiguity found (max 5 most critical):
-
-```markdown
-## Question N: [Topic]
-
-**Context:** [Quote relevant spec section]
-
-**What we need to know:** [Specific question]
-
-**Options:**
-A. [Option 1] - [Implications]
-B. [Option 2] - [Implications]
-C. [Option 3] - [Implications]
-D. Custom - [Your answer]
-
-**Your choice:** _
-```
-
----
-
-## Step 4: Update Specification
-
-After receiving answers:
-1. Update spec.md with clarifications
-2. Remove `[NEEDS CLARIFICATION]` markers
-3. Add concrete details based on answers
-
----
-
-## Step 5: Save Clarification Log
-
-Create `relentless/features/NNN-feature/clarification-log.md`:
-
-```markdown
-# Clarification Log: Feature Name
-
-## Q1: [Topic] - RESOLVED
-**Date:** 2026-01-11
-**Question:** [Question]
-**Answer:** [User's choice]
-**Updated Sections:** [List spec sections updated]
-
-## Q2: [Topic] - DEFERRED
-**Date:** 2026-01-11
-**Question:** [Question]
-**Reason:** Can be decided during implementation
-```
-
----
-
-## Example
-
-```markdown
-## Question 1: Password Requirements
-
-**Context:** Spec says "password must be secure" but doesn't define requirements.
-
-**What we need to know:** What are the specific password requirements?
-
-**Options:**
-A. Basic (min 8 characters) - Simple, user-friendly
-B. Moderate (min 8 chars + number + symbol) - Balanced security
-C. Strict (min 12 chars + number + symbol + upper/lower) - High security
-D. Custom - Define your own rules
-
-**Your choice:** B
-
----
-
-## Question 2: Failed Login Handling
-
-**Context:** Spec doesn't mention what happens after failed login attempts.
-
-**What we need to know:** How should we handle repeated failed logins?
-
-**Options:**
-A. No limit - Allow unlimited attempts
-B. Rate limit - Max 5 attempts per minute per IP
-C. Account lockout - Lock account after 5 failed attempts for 30 minutes
-D. Custom - Define your own approach
-
-**Your choice:** C
-```
-
----
-
-## Notes
-
-- Prioritize by impact: security > scope > UX > technical
-- Maximum 5 questions per session
-- Some ambiguities can be deferred to implementation
-- Update spec immediately after clarification
-- Keep clarification log for future reference

package/.claude/skills/constitution/SKILL.md

@@ -1,150 +0,0 @@
----
-name: constitution
-description: "Create or update the project constitution - personalized governance and coding principles. Use when starting a project or updating project standards. Triggers on: create constitution, update principles, set project rules."
----
-
-# Project Constitution Generator
-
-Create a personalized project constitution that defines your team's coding principles, patterns, and governance.
-
----
-
-## The Job
-
-1. Ask the user about their project's coding philosophy and standards
-2. Generate a personalized constitution based on their answers
-3. Save to `relentless/constitution.md`
-4. Ensure consistency with project templates and documentation
-
-**Important:** The constitution is the foundation for all feature work - create this before generating features.
-
----
-
-## Step 1: Gather Project Information
-
-Ask essential questions about the project:
-
-**Project Identity:**
-- Project name?
-- Primary programming language(s)?
-- Tech stack (frameworks, libraries)?
-
-**Testing Philosophy:**
-- Testing approach? (TDD, test after, pragmatic)
-- Required test coverage?
-- Testing frameworks preferred?
-
-**Code Quality:**
-- Linting/formatting tools?
-- Required checks before commit? (typecheck, lint, test)
-- Code review requirements?
-
-**Architecture Principles:**
-- Preferred patterns? (MVC, clean architecture, etc.)
-- Modularity requirements?
-- Performance expectations?
-
-**Version Control:**
-- Branch naming conventions?
-- Commit message format?
-- CI/CD requirements?
-
----
-
-## Step 2: Generate Constitution
-
-Load the template from `templates/constitution-template.md` and:
-
-1. Replace all `[PLACEHOLDER]` tokens with concrete values from user answers
-2. Add/remove principles based on project needs (template is a starting point)
-3. Ensure each principle has:
-   - **MUST** rules (enforced, blocking)
-   - **SHOULD** rules (best practices, warnings)
-   - Clear rationale
-4. Set version to `1.0.0` for new constitutions
-5. Set ratification date to today
-6. Add governance section with amendment procedures
-
----
-
-## Step 3: Validate & Save
-
-Before saving:
-- No `[PLACEHOLDER]` tokens remain (unless explicitly marked as TODO)
-- All dates in ISO format (YYYY-MM-DD)
-- Principles are declarative and testable
-- Version format is semantic (X.Y.Z)
-
-Save to: `relentless/constitution.md`
-
----
-
-## Step 4: Report
-
-Output summary:
-- Constitution version created
-- Number of principles defined
-- Key MUST/SHOULD rules
-- Next steps: "Now create your first feature with `/relentless.specify`"
-
----
-
-## Updating Existing Constitution
-
-If `relentless/constitution.md` exists:
-1. Load current version
-2. Ask what needs to change
-3. Increment version appropriately:
-   - **MAJOR**: Breaking changes to principles
-   - **MINOR**: New principles added
-   - **PATCH**: Clarifications, typo fixes
-4. Update `LAST_AMENDED_DATE` to today
-5. Add amendment notes at top
-
----
-
-## Example Constitution Structure
-
-```markdown
-# Project Constitution
-
-**Version:** 1.0.0  
-**Ratified:** 2026-01-11  
-**Last Amended:** 2026-01-11
-
-## Principles
-
-### Principle 1: Type Safety
-**MUST:**
-- All code must pass TypeScript strict mode
-- No `any` types except in documented cases
-
-**SHOULD:**
-- Use Zod for runtime validation
-- Prefer inference over explicit types
-
-**Rationale:** Type safety prevents runtime errors and improves maintainability.
-
-### Principle 2: Testing
-**MUST:**
-- All features must have unit tests
-- CI must pass before merging
-
-**SHOULD:**
-- Aim for 80% coverage
-- Write tests before implementation (TDD)
-
-**Rationale:** Tests document behavior and prevent regressions.
-
-## Governance
-
-**Amendment Process:**
-1. Propose changes via PR
-2. Discuss with team
-3. Update version semantically
-4. Document rationale
-
-**Compliance:**
-- Constitution checked before each feature implementation
-- Violations block PR merge
-```

package/.claude/skills/constitution/templates/constitution-template.md

@@ -1,228 +0,0 @@
-# Project Constitution
-
-## Overview
-
-This document defines the governing principles, patterns, and constraints for this project. All agents and developers MUST follow these guidelines when working on the codebase.
-
-## Core Principles
-
-### Architecture
-
-**MUST** follow these architectural patterns:
-- Follow existing code structure and organization patterns
-- Keep modules focused and single-purpose
-- Use dependency injection where appropriate
-
-**SHOULD** consider these best practices:
-- Prefer composition over inheritance
-- Keep functions small and focused
-- Write self-documenting code
-
-### Code Quality
-
-**MUST** maintain these quality standards:
-- All commits MUST pass typecheck with 0 errors
-- All commits MUST pass lint with 0 warnings
-- All new features MUST include appropriate tests
-- All code MUST be formatted consistently
-
-**SHOULD** strive for:
-- High test coverage (aim for >80%)
-- Clear, descriptive variable and function names
-- Comprehensive error handling
-
-### Version Control
-
-**MUST** follow these Git practices:
-- Write clear, descriptive commit messages
-- Reference user story IDs in commits: `feat: [US-XXX] - Description`
-- Keep commits focused and atomic
-- Do not commit broken code
-
-**SHOULD** maintain:
-- Clean commit history
-- Meaningful branch names
-- Updated documentation with code changes
-
-## Technology Stack
-
-### Language & Runtime
-
-- **TypeScript** - Primary language
-- **Bun** - Runtime environment (not Node.js)
-- **Zod** - Schema validation
-
-### Key Libraries
-
-- Commander - CLI parsing
-- Chalk - Terminal formatting
-- Execa - Process execution
-
-## File Organization
-
-```
-project/
-├── bin/              # CLI entry points
-├── src/              # Source code
-│   ├── agents/       # Agent adapters
-│   ├── config/       # Configuration
-│   ├── execution/    # Orchestration
-│   ├── init/         # Project scaffolding
-│   └── prd/          # PRD handling
-├── templates/        # Template files
-├── skills/           # Agent skills
-└── relentless/       # Relentless workspace
-    ├── config.json
-    ├── prompt.md
-    └── features/
-```
-
-## Coding Standards
-
-### TypeScript
-
-**MUST** follow:
-- Use strict TypeScript mode
-- Avoid `any` type - use `unknown` or proper types
-- Export types alongside implementations
-- Use Zod schemas for runtime validation
-
-**SHOULD** prefer:
-- Interface for public APIs
-- Type for unions and intersections
-- Explicit return types on public functions
-
-### Error Handling
-
-**MUST** implement:
-- Descriptive error messages
-- Proper error types
-- Validation at system boundaries
-- Graceful degradation where appropriate
-
-**SHOULD** include:
-- Context in error messages
-- Recovery suggestions
-- Logging for debugging
-
-### Testing
-
-**MUST** test:
-- Core business logic
-- Edge cases and error conditions
-- Integration points
-- CLI commands
-
-**SHOULD** test:
-- Helper functions
-- Utilities
-- Type guards
-
-## Documentation
-
-**MUST** document:
-- Public APIs and interfaces
-- Complex algorithms or logic
-- Breaking changes in commits
-- Setup and installation steps
-
-**SHOULD** document:
-- Configuration options
-- Architecture decisions
-- Common workflows
-- Troubleshooting steps
-
-## Security
-
-**MUST** ensure:
-- No secrets committed to git
-- Proper input validation
-- Safe file system operations
-- Minimal permissions required
-
-**SHOULD** consider:
-- Rate limiting where appropriate
-- Audit logs for sensitive operations
-- Security updates for dependencies
-
-## Performance
-
-**MUST** maintain:
-- Fast startup time (<1s)
-- Responsive CLI commands
-- Efficient file operations
-- Minimal memory footprint
-
-**SHOULD** optimize:
-- Parallel operations where safe
-- Caching for repeated operations
-- Lazy loading of heavy modules
-
-## Constraints
-
-### Dependencies
-
-**MUST NOT**:
-- Add dependencies without justification
-- Include deprecated packages
-- Use packages with known security issues
-
-**SHOULD**:
-- Prefer built-in solutions over dependencies
-- Keep dependencies minimal and focused
-- Regularly update dependencies
-
-### Backwards Compatibility
-
-**MUST**:
-- Maintain compatibility with existing PRDs
-- Provide migration paths for breaking changes
-- Version configuration formats
-
-**SHOULD**:
-- Deprecate features before removal
-- Provide clear upgrade documentation
-- Support at least 2 major versions
-
-## Agent-Specific Guidelines
-
-### For All Agents
-
-**MUST**:
-- Read progress.txt before starting work
-- Work on ONE story per iteration
-- Update PRD after completing a story
-- Append learnings to progress.txt
-- Run all quality checks before committing
-
-**SHOULD**:
-- Review existing code before modifying
-- Follow established patterns
-- Ask questions when unclear
-- Document non-obvious decisions
-
-### Iteration Workflow
-
-1. Read PRD to find next incomplete story
-2. Read progress.txt for context and patterns
-3. Review relevant existing code
-4. Implement the single story
-5. Run typecheck and lint
-6. Run tests if applicable
-7. Commit with proper message format
-8. Update PRD passes: true
-9. Append to progress.txt
-10. Check if all stories complete
-
-## Review and Updates
-
-This constitution should be:
-- **Reviewed** at project milestones
-- **Updated** when patterns emerge
-- **Referenced** in code reviews
-- **Enforced** in CI/CD pipelines
-
----
-
-Last Updated: YYYY-MM-DD
-Version: 1.0.0

package/.claude/skills/implement/SKILL.md

@@ -1,141 +0,0 @@
----
-name: implement
-description: "Execute implementation workflow phase by phase. Use after analysis passes. Triggers on: start implementation, implement feature, begin coding."
----
-
-# Implementation Workflow Executor
-
-Guide systematic implementation of features using the task breakdown.
-
----
-
-## The Job
-
-Guide user through implementing tasks in correct order following dependencies.
-
----
-
-## Prerequisites
-
-Before starting:
-- `/relentless.analyze` must pass (no CRITICAL issues)
-- All artifacts exist (spec, plan, tasks, checklist)
-- Constitution reviewed
-
----
-
-## Implementation Flow
-
-### Phase 0: Setup
-1. Review `tasks.md` for setup tasks
-2. Install dependencies
-3. Create directory structure
-4. Initialize configuration
-
-### Phase 1: Foundation
-1. Implement data models
-2. Create base utilities
-3. Set up infrastructure
-4. Tests for foundation
-
-### Phase 2: User Stories
-For each story in dependency order:
-1. Read story acceptance criteria
-2. Implement functionality
-3. Write tests
-4. Run quality checks (typecheck, lint)
-5. Verify against checklist
-6. Commit changes
-7. Mark story complete in prd.json
-
-### Phase 3: Polish
-1. Performance optimization
-2. Error handling improvements
-3. Documentation
-4. Final quality checks
-
----
-
-## Per-Story Workflow
-
-```markdown
-**Current:** US-001: Create User Registration Endpoint
-
-**Acceptance Criteria:**
-- [ ] POST /api/auth/register endpoint exists
-- [ ] Email validation works
-- [ ] Password requirements enforced
-- [ ] Password hashed before storage
-- [ ] Confirmation email sent
-- [ ] Returns 201 with user ID
-- [ ] Returns 400 for invalid input
-- [ ] Typecheck passes
-- [ ] Tests pass
-
-**Checklist Items:**
-- CHK-001: User table created
-- CHK-006: Password hashing uses bcrypt
-- CHK-011: Returns correct status codes
-
-**Steps:**
-1. Create endpoint handler
-2. Implement validation
-3. Add password hashing
-4. Integrate email service
-5. Write unit tests
-6. Write integration tests
-7. Run typecheck
-8. Run tests
-9. Verify checklist items
-10. Commit with message: "feat: US-001 - Create User Registration Endpoint"
-```
-
----
-
-## Quality Gates
-
-Before marking story complete:
-- [ ] All acceptance criteria checked
-- [ ] Typecheck passes
-- [ ] Linter passes
-- [ ] Tests pass
-- [ ] Relevant checklist items verified
-- [ ] Code committed
-
----
-
-## Progress Tracking
-
-Update `progress.txt` after each story:
-
-```markdown
-## 2026-01-11 - US-001
-- Implemented user registration endpoint
-- Added email validation and password hashing
-- Email service integration working
-- All tests passing
-
-**Learnings:**
-- Bcrypt cost factor 12 provides good balance
-- Email validation regex from validator.js works well
-- Nodemailer setup straightforward
-
-**Files Changed:**
-- src/api/auth/register.ts (new)
-- src/services/user.service.ts (new)
-- src/utils/password.ts (new)
-- tests/auth/register.test.ts (new)
-
----
-```
-
----
-
-## Notes
-
-- Work on ONE story at a time
-- Follow dependency order
-- Don't skip quality checks
-- Commit frequently
-- Update progress after each story
-- This is a guided workflow, not automated