@arvorco/relentless 0.1.0

package/.claude/skills/analyze/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: analyze
+description: "Analyze consistency across spec, plan, tasks, and checklist. Use before implementation. Triggers on: analyze consistency, check artifacts, validate feature."
+---
+
+# Cross-Artifact Consistency Analyzer
+
+Validate consistency across feature artifacts before implementation.
+
+---
+
+## The Job
+
+1. Read all feature artifacts
+2. Check for consistency issues
+3. Validate against constitution
+4. Report findings
+
+---
+
+## Files to Analyze
+
+Required:
+- `relentless/constitution.md`
+- `relentless/features/NNN-feature/spec.md`
+- `relentless/features/NNN-feature/plan.md`
+- `relentless/features/NNN-feature/tasks.md`
+- `relentless/features/NNN-feature/checklist.md`
+
+Optional:
+- `relentless/features/NNN-feature/prd.json`
+- `relentless/features/NNN-feature/progress.txt`
+
+---
+
+## Validation Checks
+
+### 1. Completeness
+- [ ] All functional requirements from spec have tasks
+- [ ] All tasks reference spec requirements
+- [ ] Plan addresses all spec requirements
+- [ ] Checklist covers all tasks
+
+### 2. Constitution Compliance
+- [ ] Plan follows MUST rules
+- [ ] Tasks include required quality checks
+- [ ] Testing requirements met
+- [ ] Security requirements addressed
+
+### 3. Dependency Consistency
+- [ ] Task dependencies are valid (no circular refs)
+- [ ] Referenced dependencies exist
+- [ ] Dependency order makes sense
+
+### 4. Scope Consistency
+- [ ] Plan doesn't include out-of-scope items
+- [ ] Tasks match plan scope
+- [ ] No scope creep in checklist
+
+### 5. Data Model Consistency
+- [ ] Entities mentioned in spec are in plan
+- [ ] Plan data models match spec requirements
+- [ ] Tasks create required entities
+
+### 6. API Consistency
+- [ ] Endpoints in plan match spec scenarios
+- [ ] Tasks implement all planned endpoints
+- [ ] Checklist validates all endpoints
+
+### 7. Testing Coverage
+- [ ] Each task has test acceptance criteria
+- [ ] Checklist includes test validation
+- [ ] Test types match constitution requirements
+
+---
+
+## Issue Severity
+
+**CRITICAL:** Blocks implementation
+- Constitution MUST rule violations
+- Circular dependencies
+- Missing required artifacts
+
+**WARNING:** Should fix before implementation
+- Incomplete coverage of requirements
+- Ambiguous acceptance criteria
+- Missing test criteria
+
+**INFO:** Nice to have
+- Style inconsistencies
+- Minor gaps in checklist
+- Optimization opportunities
+
+---
+
+## Report Format
+
+```markdown
+# Consistency Analysis: Feature Name
+
+**Date:** 2026-01-11
+**Status:** PASS / ISSUES FOUND
+
+## Summary
+- Stories: N/M completed
+- Issues: X total (Y critical, Z warnings, W info)
+
+## Critical Issues
+
+### CRIT-001: Circular Dependency
+**Location:** tasks.md
+**Details:** US-002 depends on US-003, US-003 depends on US-002
+**Fix:** Remove circular dependency, reorder tasks
+
+## Warnings
+
+### WARN-001: Missing Test Coverage
+**Location:** tasks.md, US-004
+**Details:** No integration test in acceptance criteria
+**Fix:** Add integration test requirement
+
+## Info
+
+### INFO-001: Checklist Gap
+**Location:** checklist.md
+**Details:** No performance validation for US-005
+**Suggestion:** Add performance checklist item
+
+## Recommendations
+
+1. Fix all CRITICAL issues before proceeding
+2. Address WARNINGS for better quality
+3. Consider INFO items for completeness
+
+**Next Steps:**
+- If CRITICAL issues: Fix and re-run analysis
+- If only WARNINGS: Proceed with caution
+- If PASS: Ready for `/relentless.implement`
+```
+
+---
+
+## Notes
+
+- Run before starting implementation
+- Constitution compliance is non-negotiable
+- Fix critical issues immediately
+- Warnings can sometimes be deferred
+- Re-run after making fixes

package/.claude/skills/checklist/SKILL.md

@@ -0,0 +1,173 @@
+---
+name: checklist
+description: "Generate quality validation checklist from spec, plan, and tasks. Use after creating tasks. Triggers on: create checklist, quality checklist, validation checklist."
+---
+
+# Quality Validation Checklist Generator
+
+Generate domain-specific quality checklists to validate implementation completeness.
+
+---
+
+## The Job
+
+1. Read spec.md, plan.md, and tasks.md
+2. Extract quality requirements from constitution
+3. Generate comprehensive checklist
+4. Save to `checklist.md`
+
+**Important:** Checklist items get merged into prd.json acceptance criteria!
+
+---
+
+## Step 1: Locate Feature Files
+
+Verify these files exist:
+- `relentless/features/NNN-feature/spec.md`
+- `relentless/features/NNN-feature/plan.md`
+- `relentless/features/NNN-feature/tasks.md`
+
+---
+
+## Step 2: Load Context
+
+Read:
+1. `relentless/constitution.md` - Quality standards and requirements
+2. Feature files (spec, plan, tasks)
+3. Identify the feature domain (auth, payments, dashboard, etc.)
+
+---
+
+## Step 3: Generate Checklist Categories
+
+Create 5-7 categories based on feature domain:
+
+**Common Categories:**
+- Schema & Database
+- Backend Logic
+- Frontend Components (if applicable)
+- API Integration
+- Testing & Validation
+- Security & Permissions
+- Performance & UX
+- Documentation
+
+---
+
+## Step 4: Generate Checklist Items
+
+For each category, create 5-10 specific validation items:
+
+**Format:**
+```markdown
+- [ ] CHK-001 [US-001] Specific, testable requirement
+- [ ] CHK-002 [Gap] Missing specification identified
+- [ ] CHK-003 [Ambiguity] Unclear requirement needs clarification
+- [ ] CHK-004 [Edge Case] Potential edge case to handle
+```
+
+**Guidelines:**
+- 80% of items should reference specific user stories `[US-XXX]`
+- 20% should identify gaps, ambiguities, or edge cases
+- Each item must be specific and testable
+- Total: 20-40 items across all categories
+
+---
+
+## Step 5: Reference Constitution
+
+Ensure checklist includes items for constitution MUST rules:
+- Type safety requirements
+- Testing coverage
+- Security standards
+- Performance expectations
+- Code quality standards
+
+---
+
+## Step 6: Save & Report
+
+1. Save to `relentless/features/NNN-feature/checklist.md`
+2. Report:
+   - Total checklist items: N
+   - Items per category
+   - Constitution compliance items: N
+   - Gaps identified: N
+   - Next step: `relentless convert tasks.md`
+
+---
+
+## Example Checklist
+
+```markdown
+# Quality Checklist: User Authentication
+
+**Purpose:** Validate completeness of user authentication implementation
+**Created:** 2026-01-11
+**Feature:** [spec.md](./spec.md)
+
+## Schema & Database
+
+- [ ] CHK-001 [US-001] User table has all required fields (id, email, password_hash, confirmed, timestamps)
+- [ ] CHK-002 [US-001] Email field has UNIQUE constraint
+- [ ] CHK-003 [US-001] Indexes created on frequently queried fields (email)
+- [ ] CHK-004 [Gap] Consider adding last_login_at timestamp for analytics
+- [ ] CHK-005 [US-001] Migration script tested on clean database
+
+## Backend Logic
+
+- [ ] CHK-006 [US-001] Password hashing uses bcrypt with appropriate cost factor
+- [ ] CHK-007 [US-001] Email validation prevents common typos and invalid formats
+- [ ] CHK-008 [US-002] JWT tokens include user ID and expiration
+- [ ] CHK-009 [US-002] Token verification handles expired tokens gracefully
+- [ ] CHK-010 [Ambiguity] Password reset flow not specified - out of scope?
+
+## API Integration
+
+- [ ] CHK-011 [US-001] POST /api/auth/register returns 201 on success
+- [ ] CHK-012 [US-001] Register endpoint returns 400 for invalid email
+- [ ] CHK-013 [US-001] Register endpoint returns 409 for duplicate email
+- [ ] CHK-014 [US-002] POST /api/auth/login returns 401 for wrong password
+- [ ] CHK-015 [US-002] Login endpoint returns 403 for unconfirmed account
+- [ ] CHK-016 [Edge Case] Rate limiting on auth endpoints to prevent brute force
+
+## Testing & Validation
+
+- [ ] CHK-017 [US-001] Unit tests for password hashing utility
+- [ ] CHK-018 [US-001] Unit tests for email validation
+- [ ] CHK-019 [US-002] Integration test for full registration flow
+- [ ] CHK-020 [US-002] Integration test for login flow
+- [ ] CHK-021 [US-003] E2E test for email confirmation
+- [ ] CHK-022 [Constitution] Test coverage meets minimum 80% requirement
+
+## Security & Permissions
+
+- [ ] CHK-023 [US-001] Passwords never logged or exposed in errors
+- [ ] CHK-024 [US-001] Password requirements enforced (min length, complexity)
+- [ ] CHK-025 [US-002] JWT secret stored in environment variable, not code
+- [ ] CHK-026 [US-002] Token expiration validated on every request
+- [ ] CHK-027 [Gap] Consider adding account lockout after N failed attempts
+
+## Performance & UX
+
+- [ ] CHK-028 [US-001] Registration completes within 2 seconds
+- [ ] CHK-029 [US-002] Login completes within 1 second
+- [ ] CHK-030 [US-003] Confirmation email sent within 30 seconds
+- [ ] CHK-031 [Edge Case] Graceful handling when email service is down
+
+## Documentation
+
+- [ ] CHK-032 API endpoints documented with examples
+- [ ] CHK-033 Environment variables documented in README
+- [ ] CHK-034 Database schema documented
+```
+
+---
+
+## Notes
+
+- Checklist items will be merged into acceptance criteria during convert
+- Reference user stories with `[US-XXX]` tags
+- Identify gaps and ambiguities with `[Gap]` and `[Ambiguity]` tags
+- Each item must be independently verifiable
+- Balance between comprehensiveness and practicality

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

@@ -0,0 +1,40 @@
+# [CHECKLIST TYPE] Checklist: [FEATURE NAME]
+
+**Purpose**: [Brief description of what this checklist covers]
+**Created**: [DATE]
+**Feature**: [Link to spec.md or relevant documentation]
+
+**Note**: This checklist is generated by the `/relentless.checklist` command based on feature context and requirements.
+
+<!-- 
+  ============================================================================
+  IMPORTANT: The checklist items below are SAMPLE ITEMS for illustration only.
+  
+  The /relentless.checklist command MUST replace these with actual items based on:
+  - User's specific checklist request
+  - Feature requirements from spec.md
+  - Technical context from plan.md
+  - Implementation details from tasks.md
+  
+  DO NOT keep these sample items in the generated checklist file.
+  ============================================================================
+-->
+
+## [Category 1]
+
+- [ ] CHK001 First checklist item with clear action
+- [ ] CHK002 Second checklist item
+- [ ] CHK003 Third checklist item
+
+## [Category 2]
+
+- [ ] CHK004 Another category item
+- [ ] CHK005 Item with specific criteria
+- [ ] CHK006 Final item in this category
+
+## Notes
+
+- Check items off as completed: `[x]`
+- Add comments or findings inline
+- Link to relevant resources or documentation
+- Items are numbered sequentially for easy reference

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

@@ -0,0 +1,174 @@
+---
+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

@@ -0,0 +1,150 @@
+---
+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
+```