Skip to content

Commit e141e85

Browse files
authored
Merge pull request #11 from kingstinct/refactor/dedupe-eternity-loop
Refactor eternity-loop: dedupe helpers, add PR review handling & CI failure auto-fix
2 parents 7d98bf5 + 7fc83fe commit e141e85

8 files changed

Lines changed: 772 additions & 248 deletions

File tree

general/skills/ralph/SKILL.md

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11
---
22
name: ralph
33
description: "Convert PRDs to prd.json format for the Ralph autonomous agent system. Use when you have an existing PRD and need to convert it to Ralph's JSON format. Triggers on: convert this prd, turn this into ralph format, create prd.json from this, ralph json."
4-
user-invocable: true
4+
user-invokable: true
55
---
66

77
# Ralph PRD Converter
@@ -21,6 +21,7 @@ Take a PRD (markdown file or text) and convert it to `prd.json` in your ralph di
2121
```json
2222
{
2323
"project": "[Project Name]",
24+
"branchName": "[branch-name-from-context]",
2425
"description": "[Feature description from PRD title/intro]",
2526
"userStories": [
2627
{
@@ -111,7 +112,7 @@ For stories with testable logic, also include:
111112
"Verify in browser using dev-browser skill"
112113
```
113114

114-
Frontend stories are NOT complete until visually verified. Ralph will use the dev-browser skill to navigate to the page, interact with the UI, and confirm changes work.
115+
Frontend stories are NOT complete until visually verified. Ralph will use the dev-browser skill to navigate to the page, interact with the UI, and confirm changes work. If it's a mobile project with Expo also use the simulator tools to verify, similar as you would with dev-browser.
115116

116117
---
117118

@@ -121,7 +122,8 @@ Frontend stories are NOT complete until visually verified. Ralph will use the de
121122
2. **IDs**: Sequential (US-001, US-002, etc.)
122123
3. **Priority**: Based on dependency order, then document order
123124
4. **All stories**: `passes: false` and empty `notes`
124-
5. **Always add**: "Typecheck passes" to every story's acceptance criteria
125+
5. **branchName**: Use the branch name provided in the context (e.g., from Linear or the PR). If none is provided, derive from feature name in kebab-case prefixed with `ralph/`
126+
6. **Always add**: "Typecheck passes" to every story's acceptance criteria
125127

126128
---
127129

@@ -163,6 +165,7 @@ Add ability to mark tasks with different statuses.
163165
```json
164166
{
165167
"project": "TaskApp",
168+
"branchName": "ralph/task-status",
166169
"description": "Task Status Feature - Track task progress with status indicators",
167170
"userStories": [
168171
{
@@ -232,7 +235,7 @@ Add ability to mark tasks with different statuses.
232235
**Before writing a new prd.json, check if there is an existing one from a different feature:**
233236

234237
1. Read the current `prd.json` if it exists
235-
2. Check if the project/description differs from the new feature
238+
2. Check if `branchName` differs from the new feature's branch name
236239
3. If different AND `progress.txt` has content beyond the header:
237240
- Create archive folder: `archive/YYYY-MM-DD-feature-name/`
238241
- Copy current `prd.json` and `progress.txt` to archive
@@ -246,7 +249,7 @@ Add ability to mark tasks with different statuses.
246249

247250
Before writing prd.json, verify:
248251

249-
- [ ] **Previous run archived** (if prd.json exists with different project, archive it first)
252+
- [ ] **Previous run archived** (if prd.json exists with different branchName, archive it first)
250253
- [ ] Each story is completable in one iteration (small enough)
251254
- [ ] Stories are ordered by dependency (schema to backend to UI)
252255
- [ ] Every story has "Typecheck passes" as criterion
Lines changed: 15 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,15 @@
1+
# Create PRD from CI Failure Logs
2+
3+
Create a prd.json at the specified path to fix CI failures on an existing PR.
4+
5+
Use the provided branch name for the `branchName` field and project name for the `project` field.
6+
7+
Focus on the CI failure logs, not the original Linear issue (provided for context only).
8+
9+
## CI-fix-specific rules
10+
- Each distinct CI failure becomes a user story
11+
- Group failures that share the same root cause into a single user story
12+
- Keep fixes minimal — do NOT refactor unrelated code or make improvements beyond what's needed to fix the failures
13+
- Every user story MUST include "CI checks pass" as an acceptance criterion
14+
- Commit messages should use `fix(ci):` prefix
15+
- If the failure logs are unclear, include a user story for investigating and diagnosing the failure
Lines changed: 10 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,10 @@
1+
# Create GitHub PR
2+
3+
Create a GitHub PR for the current branch using the gh CLI.
4+
5+
In the PR body include:
6+
- Resolves the Linear issue identifier
7+
- Link to the Linear issue URL
8+
- A summary of what was implemented based on the commits on this branch (use git log main..HEAD)
9+
10+
Use a HEREDOC for the body to ensure correct formatting.
Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
# Create PRD from Linear Issue
2+
3+
Create a prd.json at the specified path for the Linear issue below.
4+
5+
Use the provided branch name for the `branchName` field in prd.json.
Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
# Create PRD from PR Review Feedback
2+
3+
Create a prd.json at the specified path to address PR review feedback.
4+
5+
Use the provided branch name for the `branchName` field and project name for the `project` field.
6+
7+
Focus on the PR review comments, not the original Linear issue (provided for context only).
8+
9+
## Review-specific rules
10+
- Each piece of review feedback that needs code changes becomes a user story
11+
- Comments that are just questions or requests for explanation should NOT become user stories - they will be answered separately
12+
- If ALL comments are questions/explanations with no code changes needed, create a prd.json with an empty userStories array
13+
- Include the original comment text in each user story description for context
Lines changed: 82 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,82 @@
1+
# Ralph Agent Instructions
2+
3+
You are an autonomous coding agent working on a software project.
4+
5+
## Your Task
6+
7+
1. Read the PRD at `prd.json` (in the same directory as this file)
8+
2. Read the progress log at `progress.txt` (check Codebase Patterns section first)
9+
3. Stay on the current branch. Do NOT create, switch, or check out any branches.
10+
4. Pick the **highest priority** user story where `passes: false`
11+
5. Implement that single user story
12+
6. Run quality checks (e.g., typecheck, lint, test - use whatever your project requires)
13+
7. Update CLAUDE.md files if you discover reusable patterns (see below)
14+
8. If checks pass, commit ALL changes with message: `feat: [Story ID] - [Story Title]`
15+
9. Update the PRD to set `passes: true` for the completed story
16+
10. Append your progress to `progress.txt`
17+
18+
## Progress Report Format
19+
20+
APPEND to progress.txt (never replace, always append):
21+
```
22+
## [Date/Time] - [Story ID]
23+
- What was implemented
24+
- Files changed
25+
- **Learnings for future iterations:**
26+
- Patterns discovered (e.g., "this codebase uses X for Y")
27+
- Gotchas encountered (e.g., "don't forget to update Z when changing W")
28+
- Useful context (e.g., "the evaluation panel is in component X")
29+
---
30+
```
31+
32+
The learnings section is critical - it helps future iterations avoid repeating mistakes and understand the codebase better.
33+
34+
## Consolidate Patterns
35+
36+
If you discover a **reusable pattern** that future iterations should know, add it to the `## Codebase Patterns` section at the TOP of progress.txt (create it if it doesn't exist). This section should consolidate the most important learnings:
37+
38+
```
39+
## Codebase Patterns
40+
- Example: Use `sql<number>` template for aggregations
41+
- Example: Always use `IF NOT EXISTS` for migrations
42+
- Example: Export types from actions.ts for UI components
43+
```
44+
45+
Only add patterns that are **general and reusable**, not story-specific details.
46+
47+
## Update CLAUDE.md Files
48+
49+
Before committing, check if any edited files have learnings worth preserving in nearby CLAUDE.md files:
50+
51+
1. **Identify directories with edited files** - Look at which directories you modified
52+
2. **Check for existing CLAUDE.md** - Look for CLAUDE.md in those directories or parent directories
53+
3. **Add valuable learnings** - If you discovered something future developers/agents should know
54+
55+
**Do NOT add:**
56+
- Story-specific implementation details
57+
- Temporary debugging notes
58+
- Information already in progress.txt
59+
60+
## Quality Requirements
61+
62+
- ALL commits must pass your project's quality checks (typecheck, lint, test)
63+
- Do NOT commit broken code
64+
- Keep changes focused and minimal
65+
- Follow existing code patterns
66+
67+
## Stop Condition
68+
69+
After completing a user story, check if ALL stories have `passes: true`.
70+
71+
If ALL stories are complete and passing, reply with:
72+
<promise>COMPLETE</promise>
73+
74+
If there are still stories with `passes: false`, end your response normally (another iteration will pick up the next story).
75+
76+
## Important
77+
78+
- Work on ONE story per iteration
79+
- Commit frequently
80+
- Keep CI green
81+
- Do NOT switch branches - stay on the current branch at all times
82+
- Read the Codebase Patterns section in progress.txt before starting
Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,13 @@
1+
# Reply to PR Review Comments
2+
3+
For each review comment, post a reply on the PR using the gh CLI explaining how it was addressed.
4+
5+
- For comments that requested code changes: explain what you changed and where, referencing the relevant commit(s)
6+
- For comments that asked questions: answer the question thoughtfully based on the codebase, WITHOUT making any code changes
7+
- For comments that are pure praise/approval: no reply needed
8+
- Use `gh api` to reply to inline review comments and issue comments:
9+
- For inline review comments: `gh api repos/{owner}/{repo}/pulls/PR_NUMBER/comments -f body='...' -f in_reply_to=COMMENT_ID`
10+
- For top-level issue comments: `gh api repos/{owner}/{repo}/issues/PR_NUMBER/comments -f body='...'`
11+
- Keep replies concise and helpful
12+
- Start every reply with "🤖 **eternity-loop bot:**" so it's clear this is an automated response
13+
- Do NOT make any code changes, only post comment replies

0 commit comments

Comments
 (0)