@arvorco/relentless 0.1.20 → 0.1.22
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/commands/relentless.implement.md +34 -7
- package/.claude/skills/implement/SKILL.md +192 -91
- package/CHANGELOG.md +269 -0
- package/package.json +1 -1
- package/relentless/constitution.md +393 -0
- package/relentless/prompt.md +192 -21
- package/src/execution/runner.ts +33 -4
- package/src/execution/story-prompt.ts +170 -0
- package/src/prd/parser.ts +1 -1
|
@@ -0,0 +1,393 @@
|
|
|
1
|
+
# Relentless Project Constitution
|
|
2
|
+
|
|
3
|
+
**Version:** 2.0.0
|
|
4
|
+
**Ratified:** 2026-01-13
|
|
5
|
+
**Last Amended:** 2026-01-13
|
|
6
|
+
|
|
7
|
+
---
|
|
8
|
+
|
|
9
|
+
## Preamble
|
|
10
|
+
|
|
11
|
+
Relentless is a universal AI agent orchestrator that empowers developers to run any AI coding agent autonomously until all tasks are complete. This constitution establishes the governing principles, patterns, and constraints that guide development and ensure Relentless remains performant, reliable, and cost-effective.
|
|
12
|
+
|
|
13
|
+
Our mission is to build one of the best AI orchestration tools in the world - simple, genius, and efficient.
|
|
14
|
+
|
|
15
|
+
---
|
|
16
|
+
|
|
17
|
+
## Core Identity
|
|
18
|
+
|
|
19
|
+
**Project:** Relentless
|
|
20
|
+
**Organization:** Arvor
|
|
21
|
+
**Purpose:** Universal AI Agent Orchestrator
|
|
22
|
+
**Languages:** TypeScript (strict mode)
|
|
23
|
+
**Runtime:** Bun (not Node.js)
|
|
24
|
+
**License:** MIT
|
|
25
|
+
|
|
26
|
+
---
|
|
27
|
+
|
|
28
|
+
## Part I: Foundational Principles
|
|
29
|
+
|
|
30
|
+
### Principle 1: Test-Driven Development (TDD)
|
|
31
|
+
|
|
32
|
+
**MUST:**
|
|
33
|
+
- All new features MUST have tests written BEFORE implementation begins
|
|
34
|
+
- Tests MUST define expected behavior with clear assertions
|
|
35
|
+
- Implementation MUST NOT proceed until failing tests exist
|
|
36
|
+
- All tests MUST pass before any story is marked complete
|
|
37
|
+
- E2E tests MUST exist for critical user workflows
|
|
38
|
+
|
|
39
|
+
**SHOULD:**
|
|
40
|
+
- Aim for >80% code coverage on new features
|
|
41
|
+
- Write tests that serve as living documentation
|
|
42
|
+
- Use property-based testing for complex logic
|
|
43
|
+
- Include edge case tests for all boundary conditions
|
|
44
|
+
|
|
45
|
+
**Rationale:** TDD prevents regressions in long autonomous runs where agents may introduce subtle bugs. Tests serve as contracts that agents must satisfy, providing fast feedback loops essential for AI-driven development. Reference: [Test-Driven Development with AI](https://www.builder.io/blog/test-driven-development-ai)
|
|
46
|
+
|
|
47
|
+
---
|
|
48
|
+
|
|
49
|
+
### Principle 2: Smart Model Routing
|
|
50
|
+
|
|
51
|
+
**MUST:**
|
|
52
|
+
- Planning phase MUST evaluate task complexity before assigning models
|
|
53
|
+
- Each specification MUST ask user whether smart routing is desired
|
|
54
|
+
- Routing decisions MUST be made at planning time, not runtime
|
|
55
|
+
- Model/harness performance history MUST be tracked for future planning
|
|
56
|
+
- Simple tasks MUST be routable to cheaper/free models when user opts in
|
|
57
|
+
- Complex tasks and final reviews MUST use SOTA models (Opus 4.5, GPT-5-2, etc.)
|
|
58
|
+
|
|
59
|
+
**SHOULD:**
|
|
60
|
+
- Maintain a knowledge base of model/harness capabilities and strengths
|
|
61
|
+
- Update routing heuristics based on observed task outcomes
|
|
62
|
+
- Consider task dependencies when routing parallel work
|
|
63
|
+
- Balance cost optimization with quality requirements
|
|
64
|
+
|
|
65
|
+
**Rationale:** Different models excel at different tasks. Strategic routing saves costs (up to 75% reduction) while maintaining quality. SOTA models handle complex reasoning; lighter models handle boilerplate. Reference: [MasRouter](https://aclanthology.org/2025.acl-long.757.pdf), [Dynamic LLM Routing](https://arxiv.org/abs/2502.16696)
|
|
66
|
+
|
|
67
|
+
---
|
|
68
|
+
|
|
69
|
+
### Principle 3: Parallel Execution with Git Worktrees
|
|
70
|
+
|
|
71
|
+
**MUST:**
|
|
72
|
+
- Parallel tasks MUST use git worktrees for clean isolation
|
|
73
|
+
- Each worktree MUST be on an independent branch
|
|
74
|
+
- Merge strategy MUST be defined before parallel execution begins
|
|
75
|
+
- Post-merge testing MUST validate combined implementations
|
|
76
|
+
- Worktrees MUST be cleaned up after successful merge
|
|
77
|
+
- Circular dependencies MUST be detected and prevented before parallelization
|
|
78
|
+
|
|
79
|
+
**SHOULD:**
|
|
80
|
+
- Limit parallel worktrees to prevent resource exhaustion
|
|
81
|
+
- Prefer parallel execution for independent tasks only
|
|
82
|
+
- Run integration tests after merging worktrees
|
|
83
|
+
- Log all worktree operations for debugging
|
|
84
|
+
|
|
85
|
+
**Rationale:** Git worktrees enable up to 50 agents working in parallel with clean isolation and easy merging. Cleanup prevents workspace pollution. Reference: [Parallelizing AI Coding Agents](https://ainativedev.io/news/how-to-parallelize-ai-coding-agents)
|
|
86
|
+
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
### Principle 4: Queued Prompts (Mid-Run Input)
|
|
90
|
+
|
|
91
|
+
**MUST:**
|
|
92
|
+
- Implement file-based queue (.queue.txt) for mid-run user input
|
|
93
|
+
- Agents MUST check queue between iterations
|
|
94
|
+
- Queued prompts MUST persist in memory for subsequent iterations
|
|
95
|
+
- Queue MUST be processed in FIFO order
|
|
96
|
+
- Acknowledge queued prompts in progress.txt
|
|
97
|
+
|
|
98
|
+
**SHOULD:**
|
|
99
|
+
- Support priority flags in queued messages
|
|
100
|
+
- Allow queue inspection without modifying it
|
|
101
|
+
- Clear processed items from queue after acknowledgment
|
|
102
|
+
- Support structured commands (pause, skip, abort) in queue
|
|
103
|
+
|
|
104
|
+
**Rationale:** Long autonomous runs need human intervention capability without interrupting the flow. File-based queues are simple, debuggable, and work across all agents. Reference: [Human-in-the-Loop Best Practices](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns)
|
|
105
|
+
|
|
106
|
+
---
|
|
107
|
+
|
|
108
|
+
### Principle 5: Adaptive Final Review
|
|
109
|
+
|
|
110
|
+
**MUST:**
|
|
111
|
+
- Every feature MUST have a final review phase before completion
|
|
112
|
+
- Review MUST be performed by SOTA model (Opus 4.5, GPT-5-2, or equivalent)
|
|
113
|
+
- Review scope MUST adapt to feature size:
|
|
114
|
+
- Small features: Full codebase review in single context
|
|
115
|
+
- Large features: Multi-context review with summary aggregation
|
|
116
|
+
- Review MUST check for: bugs, code quality, unnecessary artifacts, duplicate code, slop removal
|
|
117
|
+
- Review findings MUST be documented and acted upon
|
|
118
|
+
|
|
119
|
+
**SHOULD:**
|
|
120
|
+
- Use automated pre-checks before SOTA review to optimize costs
|
|
121
|
+
- Flag high-risk areas for deeper analysis
|
|
122
|
+
- Generate review report with actionable items
|
|
123
|
+
- Track review quality metrics over time
|
|
124
|
+
|
|
125
|
+
**Rationale:** AI agents can produce "slop" - unnecessary code, duplications, or artifacts. A final expert review catches issues that accumulated over many iterations. Adaptive scoping ensures thoroughness without waste.
|
|
126
|
+
|
|
127
|
+
---
|
|
128
|
+
|
|
129
|
+
### Principle 6: Agent-Aware Best Practices
|
|
130
|
+
|
|
131
|
+
**MUST:**
|
|
132
|
+
- Maintain up-to-date knowledge of each agent's capabilities
|
|
133
|
+
- Document agent-specific best practices and limitations
|
|
134
|
+
- Respect agent rate limits with intelligent fallback
|
|
135
|
+
- Use agent-appropriate prompting styles
|
|
136
|
+
- Track agent performance for routing optimization
|
|
137
|
+
|
|
138
|
+
**SHOULD:**
|
|
139
|
+
- Auto-detect agent availability and health
|
|
140
|
+
- Implement graceful degradation between agent tiers
|
|
141
|
+
- Share learned patterns across agent runs via progress.txt
|
|
142
|
+
- Monitor harness/model ecosystem for new capabilities
|
|
143
|
+
|
|
144
|
+
**Rationale:** Each agent (Claude, Amp, OpenCode, Codex, Droid, Gemini) has unique strengths. Leveraging these differences maximizes effectiveness and minimizes costs. Reference: [AI Agent Orchestration Frameworks](https://blog.n8n.io/ai-agent-orchestration-frameworks/)
|
|
145
|
+
|
|
146
|
+
---
|
|
147
|
+
|
|
148
|
+
## Part II: Code Quality Standards
|
|
149
|
+
|
|
150
|
+
### Principle 7: Zero-Lint Policy
|
|
151
|
+
|
|
152
|
+
**MUST:**
|
|
153
|
+
- All code MUST pass lint with zero warnings (not just errors)
|
|
154
|
+
- All code MUST pass typecheck with zero errors
|
|
155
|
+
- No subterfuges or workarounds to suppress legitimate lint issues
|
|
156
|
+
- Fix lints properly as an expert developer (IQ 300 approach)
|
|
157
|
+
- Run lint and typecheck before every commit
|
|
158
|
+
|
|
159
|
+
**SHOULD:**
|
|
160
|
+
- Configure strictest reasonable lint rules
|
|
161
|
+
- Use automated formatting (Prettier, etc.)
|
|
162
|
+
- Address lint issues immediately, not as technical debt
|
|
163
|
+
|
|
164
|
+
**Rationale:** Clean code performs better and maintains clarity. Lint warnings often signal real issues that compound over time.
|
|
165
|
+
|
|
166
|
+
---
|
|
167
|
+
|
|
168
|
+
### Principle 8: TypeScript Strictness
|
|
169
|
+
|
|
170
|
+
**MUST:**
|
|
171
|
+
- Use TypeScript strict mode throughout
|
|
172
|
+
- Avoid `any` type - use `unknown` or proper types
|
|
173
|
+
- Export types alongside implementations
|
|
174
|
+
- Use Zod schemas for runtime validation
|
|
175
|
+
- Document complex type constraints
|
|
176
|
+
|
|
177
|
+
**SHOULD:**
|
|
178
|
+
- Prefer type inference where clear
|
|
179
|
+
- Use interfaces for public APIs
|
|
180
|
+
- Use types for unions/intersections
|
|
181
|
+
- Add explicit return types on exported functions
|
|
182
|
+
|
|
183
|
+
**Rationale:** Type safety prevents runtime errors and enables better tooling. Strict mode catches issues at compile time rather than production.
|
|
184
|
+
|
|
185
|
+
---
|
|
186
|
+
|
|
187
|
+
### Principle 9: Minimal Dependencies
|
|
188
|
+
|
|
189
|
+
**MUST NOT:**
|
|
190
|
+
- Add dependencies without clear justification
|
|
191
|
+
- Include deprecated packages
|
|
192
|
+
- Use packages with known security vulnerabilities
|
|
193
|
+
|
|
194
|
+
**MUST:**
|
|
195
|
+
- Prefer built-in solutions over external dependencies
|
|
196
|
+
- Audit dependencies regularly
|
|
197
|
+
- Pin versions for reproducibility
|
|
198
|
+
|
|
199
|
+
**SHOULD:**
|
|
200
|
+
- Consider bundle size impact
|
|
201
|
+
- Evaluate maintenance status of dependencies
|
|
202
|
+
- Prefer well-maintained, popular packages
|
|
203
|
+
|
|
204
|
+
**Rationale:** Every dependency is a potential security risk, maintenance burden, and performance cost. Minimalism keeps the codebase lean and secure.
|
|
205
|
+
|
|
206
|
+
---
|
|
207
|
+
|
|
208
|
+
## Part III: Architecture Principles
|
|
209
|
+
|
|
210
|
+
### Principle 10: Clean Architecture
|
|
211
|
+
|
|
212
|
+
**MUST:**
|
|
213
|
+
- Maintain clear separation of concerns
|
|
214
|
+
- Keep modules focused and single-purpose
|
|
215
|
+
- Use dependency injection for testability
|
|
216
|
+
- Follow existing code structure patterns
|
|
217
|
+
|
|
218
|
+
**SHOULD:**
|
|
219
|
+
- Prefer composition over inheritance
|
|
220
|
+
- Keep functions small and focused (<30 lines)
|
|
221
|
+
- Write self-documenting code
|
|
222
|
+
- Use meaningful names that reveal intent
|
|
223
|
+
|
|
224
|
+
**Rationale:** Clean architecture enables parallel development, easier testing, and maintainable codebases. AI agents work better with well-organized code.
|
|
225
|
+
|
|
226
|
+
---
|
|
227
|
+
|
|
228
|
+
### Principle 11: Performance First
|
|
229
|
+
|
|
230
|
+
**MUST:**
|
|
231
|
+
- Maintain fast startup time (<1s)
|
|
232
|
+
- Ensure responsive CLI commands
|
|
233
|
+
- Optimize file operations for large codebases
|
|
234
|
+
- Keep memory footprint minimal
|
|
235
|
+
|
|
236
|
+
**SHOULD:**
|
|
237
|
+
- Use lazy loading for heavy modules
|
|
238
|
+
- Cache repeated operations
|
|
239
|
+
- Profile performance regularly
|
|
240
|
+
- Parallelize where safe
|
|
241
|
+
|
|
242
|
+
**Rationale:** Performance directly impacts developer experience and agent efficiency. Slow tools waste time and money.
|
|
243
|
+
|
|
244
|
+
---
|
|
245
|
+
|
|
246
|
+
### Principle 12: Error Handling Excellence
|
|
247
|
+
|
|
248
|
+
**MUST:**
|
|
249
|
+
- Surface errors clearly - never hide failures
|
|
250
|
+
- Provide descriptive error messages with context
|
|
251
|
+
- Validate inputs at system boundaries
|
|
252
|
+
- Implement graceful degradation
|
|
253
|
+
|
|
254
|
+
**SHOULD:**
|
|
255
|
+
- Include recovery suggestions in errors
|
|
256
|
+
- Log errors with sufficient context for debugging
|
|
257
|
+
- Use circuit breaker patterns for external dependencies
|
|
258
|
+
- Consider error handling in design
|
|
259
|
+
|
|
260
|
+
**Rationale:** Autonomous agents need clear error signals to self-correct. Hidden errors cause cascading failures in long runs. Reference: [AI Agent Error Handling](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns)
|
|
261
|
+
|
|
262
|
+
---
|
|
263
|
+
|
|
264
|
+
## Part IV: Version Control & Documentation
|
|
265
|
+
|
|
266
|
+
### Principle 13: Git Discipline
|
|
267
|
+
|
|
268
|
+
**MUST:**
|
|
269
|
+
- Write clear, descriptive commit messages
|
|
270
|
+
- Reference story IDs: `feat: [US-XXX] - Description`
|
|
271
|
+
- Keep commits focused and atomic
|
|
272
|
+
- Never commit broken code
|
|
273
|
+
- Never commit secrets
|
|
274
|
+
|
|
275
|
+
**SHOULD:**
|
|
276
|
+
- Maintain clean commit history
|
|
277
|
+
- Use meaningful branch names
|
|
278
|
+
- Squash WIP commits before merge
|
|
279
|
+
- Update docs with code changes
|
|
280
|
+
|
|
281
|
+
**Rationale:** Git history is memory for AI agents across iterations. Clean history enables better context and debugging.
|
|
282
|
+
|
|
283
|
+
---
|
|
284
|
+
|
|
285
|
+
### Principle 14: Documentation Standards
|
|
286
|
+
|
|
287
|
+
**MUST:**
|
|
288
|
+
- Document public APIs and interfaces
|
|
289
|
+
- Document complex algorithms
|
|
290
|
+
- Keep README up to date
|
|
291
|
+
- Document breaking changes
|
|
292
|
+
|
|
293
|
+
**SHOULD:**
|
|
294
|
+
- Write self-documenting code first
|
|
295
|
+
- Document "why" not just "what"
|
|
296
|
+
- Keep docs in sync with code
|
|
297
|
+
- Include troubleshooting guides
|
|
298
|
+
|
|
299
|
+
**Rationale:** Documentation helps both humans and AI agents understand the codebase. Good docs reduce errors and speed up development.
|
|
300
|
+
|
|
301
|
+
---
|
|
302
|
+
|
|
303
|
+
## Part V: Security & Compliance
|
|
304
|
+
|
|
305
|
+
### Principle 15: Security First
|
|
306
|
+
|
|
307
|
+
**MUST:**
|
|
308
|
+
- Never commit secrets to git
|
|
309
|
+
- Validate all external inputs
|
|
310
|
+
- Use safe file system operations
|
|
311
|
+
- Follow principle of least privilege
|
|
312
|
+
- Log sensitive operations
|
|
313
|
+
|
|
314
|
+
**SHOULD:**
|
|
315
|
+
- Regular dependency audits
|
|
316
|
+
- Rate limiting where appropriate
|
|
317
|
+
- Security-focused code review
|
|
318
|
+
- Keep security patches current
|
|
319
|
+
|
|
320
|
+
**Rationale:** Security vulnerabilities in orchestration tools can have wide-reaching impact. Proactive security prevents costly incidents.
|
|
321
|
+
|
|
322
|
+
---
|
|
323
|
+
|
|
324
|
+
## Part VI: Future Roadmap Principles
|
|
325
|
+
|
|
326
|
+
The following are strategic directions that guide future development:
|
|
327
|
+
|
|
328
|
+
### Cost & Metrics Dashboard
|
|
329
|
+
- Investigate harness-specific methods for cost/usage tracking
|
|
330
|
+
- Consider integration with existing tools like Claude Code's /status
|
|
331
|
+
- Build unified dashboard when implementation path is clear
|
|
332
|
+
|
|
333
|
+
### Enhanced Model Routing Intelligence
|
|
334
|
+
- Build and maintain model capability knowledge base
|
|
335
|
+
- Track task outcomes for routing optimization
|
|
336
|
+
- Develop routing heuristics from empirical data
|
|
337
|
+
|
|
338
|
+
### Extended Parallel Execution
|
|
339
|
+
- Support for containerized agent isolation (future option)
|
|
340
|
+
- Cross-worktree dependency management
|
|
341
|
+
- Distributed execution across machines
|
|
342
|
+
|
|
343
|
+
### Integration Ecosystem
|
|
344
|
+
- GitHub Actions integration
|
|
345
|
+
- CI/CD pipeline templates
|
|
346
|
+
- IDE extensions for orchestration control
|
|
347
|
+
|
|
348
|
+
---
|
|
349
|
+
|
|
350
|
+
## Governance
|
|
351
|
+
|
|
352
|
+
### Amendment Process
|
|
353
|
+
|
|
354
|
+
1. **Propose:** Create PR with proposed changes
|
|
355
|
+
2. **Discuss:** Gather feedback from team and community
|
|
356
|
+
3. **Update:** Increment version semantically:
|
|
357
|
+
- **MAJOR:** Breaking changes to principles
|
|
358
|
+
- **MINOR:** New principles added
|
|
359
|
+
- **PATCH:** Clarifications, typo fixes
|
|
360
|
+
4. **Document:** Record rationale for changes
|
|
361
|
+
5. **Ratify:** Merge after approval
|
|
362
|
+
|
|
363
|
+
### Compliance
|
|
364
|
+
|
|
365
|
+
- Constitution checked before each feature implementation
|
|
366
|
+
- Violations block story completion
|
|
367
|
+
- Agents must reference constitution in progress.txt
|
|
368
|
+
- Regular review at project milestones
|
|
369
|
+
|
|
370
|
+
### Version History
|
|
371
|
+
|
|
372
|
+
| Version | Date | Changes |
|
|
373
|
+
|---------|------|---------|
|
|
374
|
+
| 2.0.0 | 2026-01-13 | Major revision: Added smart routing, parallel execution, queued prompts, adaptive review, TDD requirements, agent-aware practices |
|
|
375
|
+
| 1.0.0 | Previous | Initial constitution |
|
|
376
|
+
|
|
377
|
+
---
|
|
378
|
+
|
|
379
|
+
## References
|
|
380
|
+
|
|
381
|
+
- [AI Agent Orchestration Frameworks](https://blog.n8n.io/ai-agent-orchestration-frameworks/)
|
|
382
|
+
- [MasRouter: Learning to Route LLMs](https://aclanthology.org/2025.acl-long.757.pdf)
|
|
383
|
+
- [Dynamic LLM Routing](https://arxiv.org/abs/2502.16696)
|
|
384
|
+
- [Difficulty-Aware Agent Orchestration](https://arxiv.org/html/2509.11079v1)
|
|
385
|
+
- [Parallelizing AI Coding Agents](https://ainativedev.io/news/how-to-parallelize-ai-coding-agents)
|
|
386
|
+
- [Test-Driven Development with AI](https://www.builder.io/blog/test-driven-development-ai)
|
|
387
|
+
- [TDD, AI agents and coding with Kent Beck](https://newsletter.pragmaticengineer.com/p/tdd-ai-agents-and-coding-with-kent)
|
|
388
|
+
- [Azure AI Agent Design Patterns](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/ai-agent-design-patterns)
|
|
389
|
+
- [LLM Cost Optimization Guide](https://futureagi.com/blogs/llm-cost-optimization-2025)
|
|
390
|
+
|
|
391
|
+
---
|
|
392
|
+
|
|
393
|
+
*This constitution is the foundation for all Relentless development. Reference it during specification, planning, and implementation.*
|
package/relentless/prompt.md
CHANGED
|
@@ -1,22 +1,76 @@
|
|
|
1
1
|
# Relentless Agent Instructions
|
|
2
2
|
|
|
3
|
-
You are an autonomous coding agent working on a
|
|
3
|
+
You are an autonomous coding agent working on the Relentless project - a universal AI agent orchestrator.
|
|
4
|
+
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
## CRITICAL: Quality Gates (Non-Negotiable)
|
|
8
|
+
|
|
9
|
+
Before marking ANY story as complete, ALL checks must pass:
|
|
10
|
+
|
|
11
|
+
```bash
|
|
12
|
+
# TypeScript strict mode check
|
|
13
|
+
bun run typecheck
|
|
14
|
+
|
|
15
|
+
# ESLint with zero warnings policy
|
|
16
|
+
bun run lint
|
|
17
|
+
|
|
18
|
+
# All tests must pass
|
|
19
|
+
bun test
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
**If ANY check fails, DO NOT mark the story as complete. Fix the issues first.**
|
|
23
|
+
|
|
24
|
+
---
|
|
4
25
|
|
|
5
26
|
## Before You Start
|
|
6
27
|
|
|
7
|
-
1. **
|
|
8
|
-
2. **
|
|
9
|
-
3. **Read
|
|
28
|
+
1. **Read the Constitution** - Review `relentless/constitution.md` for project principles
|
|
29
|
+
2. **Review the Codebase** - Understand current state, architecture, and patterns
|
|
30
|
+
3. **Read progress.txt** - Check the Codebase Patterns section for learnings from previous iterations
|
|
31
|
+
4. **Read the PRD** - Understand what needs to be done
|
|
32
|
+
5. **Check the Queue** - Look for `.queue.txt` for any mid-run user input
|
|
33
|
+
|
|
34
|
+
---
|
|
10
35
|
|
|
11
36
|
## Your Task
|
|
12
37
|
|
|
13
38
|
1. Read the PRD at `relentless/features/<feature>/prd.json`
|
|
14
39
|
2. Read the progress log at `relentless/features/<feature>/progress.txt`
|
|
15
40
|
3. Check you're on the correct branch from PRD `branchName`. If not, check it out or create from main.
|
|
16
|
-
4. Pick the **highest priority** user story where `passes: false`
|
|
41
|
+
4. Pick the **highest priority** user story where `passes: false` and all dependencies are met
|
|
17
42
|
5. **Review relevant code** before implementing - understand existing patterns
|
|
18
43
|
|
|
19
|
-
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## TDD Workflow (MANDATORY)
|
|
47
|
+
|
|
48
|
+
Relentless follows strict Test-Driven Development. For EVERY story:
|
|
49
|
+
|
|
50
|
+
### Step 1: Write Failing Tests First
|
|
51
|
+
```bash
|
|
52
|
+
# Create test file if needed
|
|
53
|
+
# Write tests that define expected behavior
|
|
54
|
+
bun test # Tests MUST fail (red phase)
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
### Step 2: Implement Minimum Code
|
|
58
|
+
```bash
|
|
59
|
+
# Write only enough code to pass tests
|
|
60
|
+
bun test # Tests MUST pass (green phase)
|
|
61
|
+
```
|
|
62
|
+
|
|
63
|
+
### Step 3: Refactor
|
|
64
|
+
```bash
|
|
65
|
+
# Clean up while keeping tests green
|
|
66
|
+
bun test # Tests MUST still pass
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
**Do NOT skip TDD. Tests are contracts that validate your implementation.**
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## Research Phase (if story has `research: true`)
|
|
20
74
|
|
|
21
75
|
If the current story has `research: true` and no research file exists yet:
|
|
22
76
|
|
|
@@ -30,50 +84,167 @@ If the current story has `research: true` and no research file exists yet:
|
|
|
30
84
|
3. **Do NOT implement** - only research and document
|
|
31
85
|
4. Save your findings to the research file and end your turn
|
|
32
86
|
|
|
33
|
-
|
|
87
|
+
---
|
|
88
|
+
|
|
89
|
+
## Implementation Phase
|
|
34
90
|
|
|
35
91
|
If research findings exist (or research is not required):
|
|
36
92
|
|
|
37
|
-
|
|
38
|
-
|
|
39
|
-
|
|
40
|
-
|
|
41
|
-
|
|
93
|
+
1. **Write tests first** (TDD - mandatory)
|
|
94
|
+
2. Implement that single user story (using research findings if available)
|
|
95
|
+
3. Run quality checks (typecheck, lint, test)
|
|
96
|
+
4. If checks pass, commit ALL changes with message: `feat: [Story ID] - [Story Title]`
|
|
97
|
+
5. Update the PRD to set `passes: true` for the completed story
|
|
98
|
+
6. Append your progress to `relentless/features/<feature>/progress.txt`
|
|
99
|
+
|
|
100
|
+
---
|
|
101
|
+
|
|
102
|
+
## Check for Queued Prompts
|
|
103
|
+
|
|
104
|
+
Between iterations, check `.queue.txt` for user input:
|
|
105
|
+
|
|
106
|
+
```bash
|
|
107
|
+
# If .queue.txt exists, read and process it
|
|
108
|
+
# Acknowledge in progress.txt
|
|
109
|
+
# Process in FIFO order
|
|
110
|
+
```
|
|
111
|
+
|
|
112
|
+
---
|
|
42
113
|
|
|
43
114
|
## Progress Report Format
|
|
44
115
|
|
|
45
116
|
APPEND to progress.txt (never replace, always append):
|
|
117
|
+
|
|
46
118
|
```
|
|
47
119
|
## [Date/Time] - [Story ID]
|
|
48
120
|
- What was implemented
|
|
49
121
|
- Files changed
|
|
122
|
+
- Tests added/modified
|
|
50
123
|
- **Learnings for future iterations:**
|
|
51
124
|
- Patterns discovered
|
|
52
125
|
- Gotchas encountered
|
|
53
126
|
- Useful context
|
|
127
|
+
- **Constitution compliance:** [list principles followed]
|
|
54
128
|
---
|
|
55
129
|
```
|
|
56
130
|
|
|
131
|
+
---
|
|
132
|
+
|
|
57
133
|
## Quality Requirements
|
|
58
134
|
|
|
59
|
-
|
|
60
|
-
-
|
|
61
|
-
-
|
|
62
|
-
-
|
|
63
|
-
-
|
|
135
|
+
### Code Quality (Zero-Lint Policy)
|
|
136
|
+
- All commits MUST pass typecheck with 0 errors
|
|
137
|
+
- All commits MUST pass lint with 0 warnings (not just errors)
|
|
138
|
+
- No subterfuges to escape linting - fix issues properly
|
|
139
|
+
- All new features MUST include appropriate tests
|
|
140
|
+
|
|
141
|
+
### Testing Requirements
|
|
142
|
+
- Unit tests for all business logic
|
|
143
|
+
- Integration tests for API endpoints
|
|
144
|
+
- E2E tests for critical user workflows
|
|
145
|
+
- Tests MUST be written BEFORE implementation (TDD)
|
|
146
|
+
|
|
147
|
+
### TypeScript Strictness
|
|
148
|
+
- Use strict mode throughout
|
|
149
|
+
- Avoid `any` type - use `unknown` or proper types
|
|
150
|
+
- Use Zod for runtime validation
|
|
151
|
+
|
|
152
|
+
---
|
|
153
|
+
|
|
154
|
+
## Project-Specific Patterns
|
|
155
|
+
|
|
156
|
+
### Directory Structure
|
|
157
|
+
```
|
|
158
|
+
relentless/
|
|
159
|
+
├── bin/ # CLI entry point (relentless.ts)
|
|
160
|
+
├── src/ # Core TypeScript implementation
|
|
161
|
+
│ ├── agents/ # Agent adapters (claude, amp, opencode, codex, droid, gemini)
|
|
162
|
+
│ ├── config/ # Configuration schema and loading
|
|
163
|
+
│ ├── prd/ # PRD parsing and validation
|
|
164
|
+
│ ├── execution/ # Orchestration loop and routing
|
|
165
|
+
│ └── init/ # Project initialization scaffolder
|
|
166
|
+
├── templates/ # Templates copied to projects on init
|
|
167
|
+
├── .claude/ # Skills and commands
|
|
168
|
+
│ ├── skills/ # Skill implementations
|
|
169
|
+
│ └── commands/ # Command wrappers
|
|
170
|
+
└── relentless/ # Relentless workspace
|
|
171
|
+
├── config.json
|
|
172
|
+
├── constitution.md
|
|
173
|
+
├── prompt.md
|
|
174
|
+
└── features/
|
|
175
|
+
```
|
|
176
|
+
|
|
177
|
+
### Key Technologies
|
|
178
|
+
- **Runtime:** Bun (NOT Node.js)
|
|
179
|
+
- **Language:** TypeScript (strict mode)
|
|
180
|
+
- **Validation:** Zod schemas
|
|
181
|
+
- **CLI:** Commander
|
|
182
|
+
- **Formatting:** Chalk
|
|
183
|
+
- **UI:** Ink (React for CLI)
|
|
184
|
+
|
|
185
|
+
### Test File Patterns
|
|
186
|
+
- Unit tests: `*.test.ts` alongside source files
|
|
187
|
+
- Integration tests: `tests/integration/`
|
|
188
|
+
- E2E tests: `tests/e2e/`
|
|
189
|
+
|
|
190
|
+
---
|
|
191
|
+
|
|
192
|
+
## Agent-Specific Guidelines
|
|
193
|
+
|
|
194
|
+
### Rate Limit Awareness
|
|
195
|
+
- If you hit rate limits, note in progress.txt for future planning
|
|
196
|
+
- Relentless will auto-fallback to other agents when limits hit
|
|
197
|
+
|
|
198
|
+
### Model Routing Notes
|
|
199
|
+
- Simple tasks: Cheaper models acceptable
|
|
200
|
+
- Complex logic: Use capable models
|
|
201
|
+
- Final reviews: Always use SOTA models (Opus 4.5, GPT-5-2)
|
|
202
|
+
|
|
203
|
+
### Parallel Execution
|
|
204
|
+
- Tasks marked `[P]` in tasks.md can run in parallel
|
|
205
|
+
- Use git worktrees for parallel work
|
|
206
|
+
- Clean up worktrees after merge
|
|
207
|
+
- Run integration tests after merging parallel work
|
|
208
|
+
|
|
209
|
+
---
|
|
210
|
+
|
|
211
|
+
## Common Pitfalls to Avoid
|
|
212
|
+
|
|
213
|
+
1. **Skipping TDD** - Never implement without tests first
|
|
214
|
+
2. **Suppressing lints** - Fix issues properly, don't disable rules
|
|
215
|
+
3. **Large commits** - Keep commits focused and atomic
|
|
216
|
+
4. **Missing typecheck** - Always run `bun run typecheck` before commit
|
|
217
|
+
5. **Ignoring progress.txt** - Read learnings from previous iterations
|
|
218
|
+
6. **Not checking queue** - Always check `.queue.txt` for user input
|
|
219
|
+
7. **Using Node.js APIs** - Use Bun APIs instead
|
|
220
|
+
8. **Adding unnecessary dependencies** - Prefer built-in solutions
|
|
221
|
+
|
|
222
|
+
---
|
|
64
223
|
|
|
65
224
|
## Stop Condition
|
|
66
225
|
|
|
67
226
|
After completing a user story, check if ALL stories have `passes: true`.
|
|
68
227
|
|
|
69
228
|
If ALL stories are complete and passing, reply with:
|
|
70
|
-
|
|
229
|
+
`<promise>COMPLETE</promise>`
|
|
71
230
|
|
|
72
231
|
If there are still stories with `passes: false`, end your response normally (another iteration will pick up the next story).
|
|
73
232
|
|
|
74
|
-
|
|
233
|
+
---
|
|
234
|
+
|
|
235
|
+
## Important Reminders
|
|
75
236
|
|
|
76
237
|
- Work on ONE story per iteration
|
|
238
|
+
- Write tests BEFORE implementation (TDD)
|
|
77
239
|
- Review existing code before implementing
|
|
78
|
-
- Commit frequently
|
|
79
|
-
- Keep
|
|
240
|
+
- Commit frequently with proper message format
|
|
241
|
+
- Keep all quality checks passing
|
|
242
|
+
- Check `.queue.txt` for mid-run input
|
|
243
|
+
- Reference constitution principles in progress.txt
|
|
244
|
+
- Clean up any worktrees after merging
|
|
245
|
+
|
|
246
|
+
---
|
|
247
|
+
|
|
248
|
+
**Personalized for Relentless**
|
|
249
|
+
**Generated:** 2026-01-13
|
|
250
|
+
**Re-generate:** /relentless.constitution
|