@arvorco/relentless 0.1.26 → 0.1.27

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

@@ -54,7 +54,7 @@ Ask essential questions about the project:
 
 ## Step 2: Generate Constitution
 
-Load the template from `templates/constitution-template.md` and:
+Load the template from `templates/constitution.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)

package/.claude/skills/plan/SKILL.md

@@ -38,7 +38,7 @@ Read these files:
 
 ## Step 3: Generate Technical Plan
 
-Using the template at `templates/plan-template.md`, create a plan with:
+Using the template at `templates/plan.md`, create a plan with:
 
 ### Required Sections:
 

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

@@ -48,7 +48,7 @@ This will output JSON with:
 
 ## Step 3: Generate Specification
 
-Using the template at `templates/spec-template.md`, create a specification with:
+Using the template at `templates/spec.md`, create a specification with:
 
 ### Required Sections:
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@arvorco/relentless",
-  "version": "0.1.26",
+  "version": "0.1.27",
   "description": "Universal AI agent orchestrator - works with Claude Code, Amp, OpenCode, Codex, Droid, and Gemini",
   "type": "module",
   "publishConfig": {

package/src/init/scaffolder.ts

@@ -414,7 +414,7 @@ export async function createFeature(
 
   // Copy plan.md template if requested
   if (options.withPlan) {
-    const planSourcePath = join(relentlessRoot, "templates", "plan.md");
+    const planSourcePath = join(relentlessRoot, ".claude", "skills", "plan", "templates", "plan.md");
     const planDestPath = join(featureDir, "plan.md");
 
     if (existsSync(planSourcePath)) {

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/templates/plan.md

@@ -1,273 +0,0 @@
-# Technical Planning Document
-
-## Feature Overview
-
-**Feature Name**: [Feature Name]
-**PRD Reference**: [Link or path to PRD]
-**Planning Date**: [YYYY-MM-DD]
-**Author**: [Name or Agent ID]
-
-### Problem Statement
-
-[Describe the problem this feature solves. What pain point are we addressing?]
-
-### Goals and Non-Goals
-
-**Goals:**
-- [Goal 1]
-- [Goal 2]
-- [Goal 3]
-
-**Non-Goals:**
-- [What this feature will NOT do]
-- [Scope limitations]
-
----
-
-## Technical Approach
-
-### High-Level Architecture
-
-[Describe the overall architectural approach. Include diagrams if helpful.]
-
-### Technology Stack
-
-**Languages/Frameworks:**
-- [Technology 1]: [Justification]
-- [Technology 2]: [Justification]
-
-**Libraries/Dependencies:**
-- [Dependency 1]: [Version] - [Purpose]
-- [Dependency 2]: [Version] - [Purpose]
-
-### Design Patterns
-
-[Which design patterns will be used and why?]
-- [Pattern 1]: [Rationale]
-- [Pattern 2]: [Rationale]
-
----
-
-## Implementation Details
-
-### Data Models
-
-```typescript
-// Example schema definitions
-interface Example {
-  field: string;
-  // ...
-}
-```
-
-### API Design
-
-**Endpoints/Functions:**
-- `functionName(params)`: [Description]
-- `anotherFunction(params)`: [Description]
-
-**Request/Response Formats:**
-```json
-{
-  "example": "payload"
-}
-```
-
-### File Structure
-
-```
-src/
-├── feature/
-│   ├── module1.ts
-│   ├── module2.ts
-│   └── types.ts
-└── tests/
-    └── feature.test.ts
-```
-
----
-
-## Integration Points
-
-### Existing Systems
-
-- **System 1**: [How does this feature integrate?]
-- **System 2**: [Dependencies or interactions]
-
-### Database Changes
-
-**Schema Updates:**
-- [Table/Collection 1]: [Changes]
-- [Table/Collection 2]: [Changes]
-
-**Migration Strategy:**
-- [Backward compatibility considerations]
-- [Data migration approach]
-
----
-
-## Testing Strategy
-
-### Unit Tests
-
-- [What units will be tested?]
-- [Coverage goals]
-
-### Integration Tests
-
-- [Integration scenarios]
-- [External dependencies to mock]
-
-### E2E Tests
-
-- [User flows to test]
-- [Critical paths]
-
-### Performance Tests
-
-- [Load testing requirements]
-- [Performance benchmarks]
-
----
-
-## Security Considerations
-
-### Authentication/Authorization
-
-- [How is access controlled?]
-- [Role-based permissions]
-
-### Data Privacy
-
-- [PII handling]
-- [Encryption requirements]
-
-### Vulnerability Analysis
-
-- [Potential security risks]
-- [Mitigation strategies]
-
----
-
-## Rollout Strategy
-
-### Feature Flags
-
-- [Which flags to use?]
-- [Gradual rollout plan]
-
-### Deployment Steps
-
-1. [Step 1]
-2. [Step 2]
-3. [Step 3]
-
-### Rollback Plan
-
-- [How to revert if needed]
-- [Data cleanup strategy]
-
----
-
-## Monitoring and Observability
-
-### Metrics
-
-- [Metric 1]: [What it measures]
-- [Metric 2]: [What it measures]
-
-### Logging
-
-- [Key events to log]
-- [Log levels and structured logging approach]
-
-### Alerting
-
-- [What triggers alerts?]
-- [Escalation procedures]
-
----
-
-## Open Questions
-
-- [ ] [Question 1]
-- [ ] [Question 2]
-- [ ] [Question 3]
-
----
-
-## Alternatives Considered
-
-### Alternative 1: [Name]
-
-**Pros:**
-- [Pro 1]
-- [Pro 2]
-
-**Cons:**
-- [Con 1]
-- [Con 2]
-
-**Why not chosen:** [Reasoning]
-
-### Alternative 2: [Name]
-
-**Pros:**
-- [Pro 1]
-
-**Cons:**
-- [Con 1]
-
-**Why not chosen:** [Reasoning]
-
----
-
-## Dependencies and Risks
-
-### External Dependencies
-
-- [Dependency 1]: [Risk if unavailable]
-- [Dependency 2]: [Mitigation strategy]
-
-### Technical Risks
-
-1. **Risk**: [Description]
-   - **Impact**: [High/Medium/Low]
-   - **Mitigation**: [Strategy]
-
-2. **Risk**: [Description]
-   - **Impact**: [High/Medium/Low]
-   - **Mitigation**: [Strategy]
-
-### Timeline Risks
-
-- [Risk 1]: [Mitigation]
-- [Risk 2]: [Mitigation]
-
----
-
-## Success Criteria
-
-### Definition of Done
-
-- [ ] All acceptance criteria met
-- [ ] All tests passing
-- [ ] Code reviewed and approved
-- [ ] Documentation complete
-- [ ] Performance benchmarks met
-- [ ] Security review passed
-
-### Success Metrics
-
-- [Metric 1]: [Target value]
-- [Metric 2]: [Target value]
-- [Metric 3]: [Target value]
-
----
-
-## References
-
-- [Link to PRD]
-- [Related design docs]
-- [External documentation]
-- [Research papers or articles]