agentic-loop 3.9.1 → 3.10.0
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/skills/explain/SKILL.md +114 -0
- package/.claude/skills/idea/SKILL.md +216 -0
- package/.claude/skills/my-dna/SKILL.md +122 -0
- package/.claude/skills/prd/SKILL.md +770 -0
- package/.claude/skills/review/SKILL.md +167 -0
- package/.claude/skills/sign/SKILL.md +32 -0
- package/.claude/skills/styleguide/SKILL.md +450 -0
- package/.claude/skills/tour/SKILL.md +353 -0
- package/.claude/skills/vibe-check/SKILL.md +116 -0
- package/.claude/skills/vibe-help/SKILL.md +47 -0
- package/.claude/skills/vibe-list/SKILL.md +203 -0
- package/package.json +1 -1
- package/ralph/setup.sh +10 -3
|
@@ -0,0 +1,114 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Explain what code does line by line so you can understand and learn from it.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# Explain Code
|
|
6
|
+
|
|
7
|
+
Explain what code does, line by line, so you can understand and learn from it.
|
|
8
|
+
|
|
9
|
+
## Instructions
|
|
10
|
+
|
|
11
|
+
When the user asks you to explain code:
|
|
12
|
+
|
|
13
|
+
### Step 1: Identify the Code
|
|
14
|
+
|
|
15
|
+
If the user provides a file path, read that file. If they paste code directly, use that.
|
|
16
|
+
|
|
17
|
+
If no code is specified, ask:
|
|
18
|
+
> "What code would you like me to explain? Please provide a file path or paste the code."
|
|
19
|
+
|
|
20
|
+
### Step 2: Provide Overview
|
|
21
|
+
|
|
22
|
+
Start with a high-level summary:
|
|
23
|
+
- What is the purpose of this code?
|
|
24
|
+
- What problem does it solve?
|
|
25
|
+
- How does it fit into the larger application?
|
|
26
|
+
|
|
27
|
+
### Step 3: Walk Through Line by Line
|
|
28
|
+
|
|
29
|
+
For each significant section, explain:
|
|
30
|
+
- **What** it does (literally)
|
|
31
|
+
- **Why** it's needed (purpose)
|
|
32
|
+
- **How** it works (mechanism)
|
|
33
|
+
|
|
34
|
+
Use this format:
|
|
35
|
+
|
|
36
|
+
```
|
|
37
|
+
Lines X-Y: [Brief description]
|
|
38
|
+
- This code [what it does]
|
|
39
|
+
- It's needed because [why]
|
|
40
|
+
- It works by [how]
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
### Step 4: Highlight Key Concepts
|
|
44
|
+
|
|
45
|
+
Point out important patterns and concepts:
|
|
46
|
+
- Design patterns used
|
|
47
|
+
- Language features that might be unfamiliar
|
|
48
|
+
- Best practices demonstrated
|
|
49
|
+
- Potential gotchas or edge cases
|
|
50
|
+
|
|
51
|
+
### Step 5: Summarize
|
|
52
|
+
|
|
53
|
+
End with:
|
|
54
|
+
- Key takeaways
|
|
55
|
+
- What the user should understand now
|
|
56
|
+
- Suggestions for further learning if applicable
|
|
57
|
+
|
|
58
|
+
## Example Output
|
|
59
|
+
|
|
60
|
+
```
|
|
61
|
+
## Overview
|
|
62
|
+
|
|
63
|
+
This is a React custom hook that manages authentication state. It handles
|
|
64
|
+
login, logout, and automatic token refresh.
|
|
65
|
+
|
|
66
|
+
## Line-by-Line Explanation
|
|
67
|
+
|
|
68
|
+
### Lines 1-5: Imports
|
|
69
|
+
```typescript
|
|
70
|
+
import { useState, useEffect, useCallback } from 'react';
|
|
71
|
+
import { authApi } from '@/services/api';
|
|
72
|
+
import { User } from '@/types';
|
|
73
|
+
```
|
|
74
|
+
- Imports React hooks for state management and side effects
|
|
75
|
+
- Imports the auth API service for making authentication requests
|
|
76
|
+
- Imports the User type for type safety
|
|
77
|
+
|
|
78
|
+
### Lines 7-15: Hook Definition and State
|
|
79
|
+
```typescript
|
|
80
|
+
export function useAuth() {
|
|
81
|
+
const [user, setUser] = useState<User | null>(null);
|
|
82
|
+
const [loading, setLoading] = useState(true);
|
|
83
|
+
```
|
|
84
|
+
- Creates a custom hook that can be used in any component
|
|
85
|
+
- `user` state holds the current user (or null if logged out)
|
|
86
|
+
- `loading` state tracks whether we're still checking auth status
|
|
87
|
+
- Starting with `loading: true` prevents flash of unauthenticated content
|
|
88
|
+
|
|
89
|
+
### Lines 17-30: Auto-refresh Effect
|
|
90
|
+
[... continue explanation ...]
|
|
91
|
+
|
|
92
|
+
## Key Concepts
|
|
93
|
+
|
|
94
|
+
1. **Custom Hooks**: Reusable logic extracted from components
|
|
95
|
+
2. **Optimistic Updates**: UI updates before server confirms
|
|
96
|
+
3. **Token Refresh**: Automatic re-authentication before expiry
|
|
97
|
+
|
|
98
|
+
## Takeaways
|
|
99
|
+
|
|
100
|
+
- This hook centralizes all auth logic in one place
|
|
101
|
+
- Components just need to call `useAuth()` to access auth state
|
|
102
|
+
- The refresh logic runs automatically in the background
|
|
103
|
+
```
|
|
104
|
+
|
|
105
|
+
## Tips for Users
|
|
106
|
+
|
|
107
|
+
Ask me to explain:
|
|
108
|
+
- "Explain this function" (paste code)
|
|
109
|
+
- "Explain src/hooks/useAuth.ts"
|
|
110
|
+
- "Explain lines 50-100 of api.ts"
|
|
111
|
+
- "What does this regex do?"
|
|
112
|
+
- "Why is this pattern used here?"
|
|
113
|
+
|
|
114
|
+
I'll adjust the depth based on what you ask. For simple code, I'll be brief. For complex code, I'll be thorough.
|
|
@@ -0,0 +1,216 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Brainstorm a feature idea, then generate PRDs for Ralph autonomous execution.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# /idea - From Brainstorm to PRD
|
|
6
|
+
|
|
7
|
+
You are helping the user go from a rough idea to executable PRDs for Ralph.
|
|
8
|
+
|
|
9
|
+
**CRITICAL: This command does NOT write code. It produces documentation files only.**
|
|
10
|
+
|
|
11
|
+
## When to Use
|
|
12
|
+
|
|
13
|
+
| Workflow | Best For |
|
|
14
|
+
|----------|----------|
|
|
15
|
+
| **`/idea`** | Structured brainstorming with guided questions - Claude leads |
|
|
16
|
+
| **Plan mode → save to `docs/ideas/`** | Free-form exploration - you lead the thinking |
|
|
17
|
+
| **`/prd "description"`** | Quick PRD, no docs artifact needed |
|
|
18
|
+
|
|
19
|
+
**Both `/idea` and plan mode can produce `docs/ideas/*.md` files.** The difference is who drives the conversation:
|
|
20
|
+
- `/idea` asks you structured questions (scope, UX, edge cases, etc.)
|
|
21
|
+
- Plan mode lets you explore freely with Claude's help
|
|
22
|
+
|
|
23
|
+
Use `/idea` when you want the structured checklist. Use plan mode when you prefer to think through it your way.
|
|
24
|
+
|
|
25
|
+
## User Input
|
|
26
|
+
|
|
27
|
+
```text
|
|
28
|
+
$ARGUMENTS
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
## Workflow
|
|
32
|
+
|
|
33
|
+
### Step 1: Start Brainstorming
|
|
34
|
+
|
|
35
|
+
If `$ARGUMENTS` is empty, ask: "What feature or idea would you like to brainstorm?"
|
|
36
|
+
|
|
37
|
+
If `$ARGUMENTS` has content, acknowledge it and proceed.
|
|
38
|
+
|
|
39
|
+
Say: "Let's brainstorm this idea. I'll help you think it through, then we'll create documentation for Ralph to execute."
|
|
40
|
+
|
|
41
|
+
### Step 2: Explore and Ask Questions
|
|
42
|
+
|
|
43
|
+
Help the user flesh out the idea through conversation:
|
|
44
|
+
|
|
45
|
+
1. **Understand the goal** - What problem does this solve? Who benefits?
|
|
46
|
+
2. **Explore the codebase** - Use Glob/Grep/Read to understand what exists and what patterns to follow
|
|
47
|
+
3. **Ask clarifying questions** about:
|
|
48
|
+
|
|
49
|
+
**Scope & UX:**
|
|
50
|
+
- What's in scope vs out of scope?
|
|
51
|
+
- What does the user see/do? (ask for mockup if UI)
|
|
52
|
+
- What are the edge cases?
|
|
53
|
+
|
|
54
|
+
**Security (IMPORTANT - ask if feature involves):**
|
|
55
|
+
- Authentication: Who can access this? Login required?
|
|
56
|
+
- Passwords: How stored? (must be hashed, never plain text)
|
|
57
|
+
- User input: What validation needed? (SQL injection, XSS, command injection)
|
|
58
|
+
- Sensitive data: What should NEVER be in API responses?
|
|
59
|
+
- Rate limiting: Should this be rate limited? (login attempts, API calls)
|
|
60
|
+
|
|
61
|
+
**Scale (IMPORTANT - ask if feature involves lists/data):**
|
|
62
|
+
- How many items expected? (10s, 1000s, millions?)
|
|
63
|
+
- Pagination needed? What's the max per page?
|
|
64
|
+
- Caching needed? How fresh must data be?
|
|
65
|
+
- Database indexes: What will be queried/sorted frequently?
|
|
66
|
+
|
|
67
|
+
### Step 3: Summarize Before Writing
|
|
68
|
+
|
|
69
|
+
When you have enough information, summarize what you've learned:
|
|
70
|
+
|
|
71
|
+
Say: "Here's what I understand about the feature:
|
|
72
|
+
|
|
73
|
+
**Problem:** [summary]
|
|
74
|
+
**Solution:** [summary]
|
|
75
|
+
**Key decisions:** [list]
|
|
76
|
+
|
|
77
|
+
Ready to write this to `docs/ideas/{feature-name}.md`? Say **'yes'** or tell me what to adjust."
|
|
78
|
+
|
|
79
|
+
**STOP and wait for user confirmation before writing any files.**
|
|
80
|
+
|
|
81
|
+
### Step 4: Write the Idea File
|
|
82
|
+
|
|
83
|
+
Once the user confirms, write the idea file:
|
|
84
|
+
|
|
85
|
+
1. Create the directory if needed:
|
|
86
|
+
```bash
|
|
87
|
+
mkdir -p docs/ideas
|
|
88
|
+
```
|
|
89
|
+
|
|
90
|
+
2. Write to `docs/ideas/{feature-name}.md` with this structure:
|
|
91
|
+
```markdown
|
|
92
|
+
# {Feature Name}
|
|
93
|
+
|
|
94
|
+
## Problem
|
|
95
|
+
What problem does this solve?
|
|
96
|
+
|
|
97
|
+
## Solution
|
|
98
|
+
High-level description of the solution.
|
|
99
|
+
|
|
100
|
+
## User Stories
|
|
101
|
+
- As a [user], I want to [action] so that [benefit]
|
|
102
|
+
- ...
|
|
103
|
+
|
|
104
|
+
## Scope
|
|
105
|
+
### In Scope
|
|
106
|
+
- ...
|
|
107
|
+
|
|
108
|
+
### Out of Scope
|
|
109
|
+
- ...
|
|
110
|
+
|
|
111
|
+
## Architecture
|
|
112
|
+
### Directory Structure
|
|
113
|
+
- Where new files should go (be specific: `src/components/forms/`, not just `src/`)
|
|
114
|
+
|
|
115
|
+
### Patterns to Follow
|
|
116
|
+
- Existing components/utilities to reuse
|
|
117
|
+
- Naming conventions
|
|
118
|
+
|
|
119
|
+
### Do NOT Create
|
|
120
|
+
- List things that already exist (avoid duplication)
|
|
121
|
+
|
|
122
|
+
## Security Requirements
|
|
123
|
+
- **Authentication**: Who can access? Login required?
|
|
124
|
+
- **Password handling**: Must be hashed with bcrypt (cost 10+), never in responses
|
|
125
|
+
- **Input validation**: What must be validated/sanitized?
|
|
126
|
+
- **Rate limiting**: What should be rate limited?
|
|
127
|
+
- **Sensitive data**: What must NEVER appear in logs/responses?
|
|
128
|
+
|
|
129
|
+
## Scale Requirements
|
|
130
|
+
- **Expected volume**: How many users/items/requests?
|
|
131
|
+
- **Pagination**: Max items per page (recommend 100)
|
|
132
|
+
- **Caching**: What can be cached? For how long?
|
|
133
|
+
- **Database**: What indexes are needed?
|
|
134
|
+
|
|
135
|
+
## UI Mockup (if applicable)
|
|
136
|
+
```
|
|
137
|
+
┌─────────────────────────────────┐
|
|
138
|
+
│ [ASCII mockup of the UI] │
|
|
139
|
+
└─────────────────────────────────┘
|
|
140
|
+
```
|
|
141
|
+
|
|
142
|
+
## Open Questions
|
|
143
|
+
- Any unresolved decisions
|
|
144
|
+
```
|
|
145
|
+
|
|
146
|
+
3. Say: "I've written the idea to `docs/ideas/{feature-name}.md`.
|
|
147
|
+
|
|
148
|
+
Review it and let me know:
|
|
149
|
+
- **'approved'** - Ready to generate PRD
|
|
150
|
+
- **'edit [changes]'** - Tell me what to change"
|
|
151
|
+
|
|
152
|
+
**STOP and wait for user response. Do not proceed until they say 'approved' or 'done'.**
|
|
153
|
+
|
|
154
|
+
### Step 5: Generate PRD
|
|
155
|
+
|
|
156
|
+
**Only proceed here after user explicitly approves the idea file.**
|
|
157
|
+
|
|
158
|
+
Say: "Now I'll generate the PRD from your idea file."
|
|
159
|
+
|
|
160
|
+
**Use the Skill tool** to invoke `/prd` with the idea file path:
|
|
161
|
+
```
|
|
162
|
+
Skill: prd
|
|
163
|
+
Args: docs/ideas/{feature-name}.md
|
|
164
|
+
```
|
|
165
|
+
|
|
166
|
+
This hands off to `/prd` which handles:
|
|
167
|
+
- Reading the idea file
|
|
168
|
+
- Splitting into stories
|
|
169
|
+
- Writing `.ralph/prd.json`
|
|
170
|
+
- All PRD schema details (testing, testSteps, MCP tools, etc.)
|
|
171
|
+
|
|
172
|
+
**DO NOT duplicate the PRD schema or guidelines here - /prd is the single source of truth.**
|
|
173
|
+
|
|
174
|
+
---
|
|
175
|
+
|
|
176
|
+
## Error Handling
|
|
177
|
+
|
|
178
|
+
- If user provides no arguments, ask what they want to brainstorm
|
|
179
|
+
- If user abandons mid-flow, the idea file is still saved for later
|
|
180
|
+
- If /prd fails, check the idea file has enough detail
|
|
181
|
+
|
|
182
|
+
---
|
|
183
|
+
|
|
184
|
+
## Guidelines
|
|
185
|
+
|
|
186
|
+
### Idea File Quality
|
|
187
|
+
|
|
188
|
+
A good idea file has:
|
|
189
|
+
- **Clear problem statement** - What's broken or missing?
|
|
190
|
+
- **Specific solution** - Not vague ("improve UX") but concrete ("add inline validation")
|
|
191
|
+
- **Scope boundaries** - What's explicitly out of scope?
|
|
192
|
+
- **Architecture hints** - Where do files go? What patterns to follow?
|
|
193
|
+
|
|
194
|
+
### ASCII Art for UI
|
|
195
|
+
|
|
196
|
+
If the feature involves UI, include ASCII mockups in the idea file:
|
|
197
|
+
|
|
198
|
+
```
|
|
199
|
+
┌─────────────────────────────────────┐
|
|
200
|
+
│ Dashboard [⚙️] │
|
|
201
|
+
├─────────────────────────────────────┤
|
|
202
|
+
│ │
|
|
203
|
+
│ ┌─────────┐ ┌─────────┐ │
|
|
204
|
+
│ │ Card 1 │ │ Card 2 │ │
|
|
205
|
+
│ │ $1,234 │ │ 89% │ │
|
|
206
|
+
│ └─────────┘ └─────────┘ │
|
|
207
|
+
│ │
|
|
208
|
+
│ ┌─────────────────────────────┐ │
|
|
209
|
+
│ │ Recent Activity │ │
|
|
210
|
+
│ │ • Item 1 │ │
|
|
211
|
+
│ │ • Item 2 │ │
|
|
212
|
+
│ └─────────────────────────────┘ │
|
|
213
|
+
└─────────────────────────────────────┘
|
|
214
|
+
```
|
|
215
|
+
|
|
216
|
+
Ralph will read these from the idea file via `story.contextFiles`.
|
|
@@ -0,0 +1,122 @@
|
|
|
1
|
+
---
|
|
2
|
+
description: Set up your personal DNA - how you like to work and communicate with Claude.
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# My DNA - Personal Style Setup
|
|
6
|
+
|
|
7
|
+
You are helping the user define their DNA - their personal voice and project values. This makes Claude's output match their style.
|
|
8
|
+
|
|
9
|
+
This updates `CLAUDE.md` in the project root with their values and style.
|
|
10
|
+
|
|
11
|
+
## Step 1: Introduction
|
|
12
|
+
|
|
13
|
+
Say: "Let's set up your DNA so I can match your style and values in this project.
|
|
14
|
+
|
|
15
|
+
Your values shape everything - how we communicate, what we prioritize, and what the product feels like. A few quick questions."
|
|
16
|
+
|
|
17
|
+
## Step 2: Ask About Core Values
|
|
18
|
+
|
|
19
|
+
Use AskUserQuestion:
|
|
20
|
+
|
|
21
|
+
**Question:** "What values should guide this project? Pick any that resonate."
|
|
22
|
+
**Header:** "Core values"
|
|
23
|
+
**multiSelect:** true
|
|
24
|
+
**Options:**
|
|
25
|
+
- **Respect / Kindness** - "Treat people well, in code and communication"
|
|
26
|
+
- **Simplicity / Clarity** - "Avoid jargon, make things understandable"
|
|
27
|
+
- **Sustainability** - "Build things that last, think long-term"
|
|
28
|
+
|
|
29
|
+
## Step 3: Ask About Their Voice
|
|
30
|
+
|
|
31
|
+
Use AskUserQuestion:
|
|
32
|
+
|
|
33
|
+
**Question:** "How would you describe your writing style?"
|
|
34
|
+
**Header:** "Your voice"
|
|
35
|
+
**Options:**
|
|
36
|
+
- **Casual & direct** - "I write like I talk, no fluff"
|
|
37
|
+
- **Friendly & warm** - "Approachable, conversational"
|
|
38
|
+
- **Professional & clear** - "Polished but not stiff"
|
|
39
|
+
- **Minimal & precise** - "Say less, mean more"
|
|
40
|
+
|
|
41
|
+
## Step 4: Ask About Project Priority
|
|
42
|
+
|
|
43
|
+
Use AskUserQuestion:
|
|
44
|
+
|
|
45
|
+
**Question:** "What matters most for this project right now?"
|
|
46
|
+
**Header:** "Priority"
|
|
47
|
+
**Options:**
|
|
48
|
+
- **Ship it** - "Get it working and out the door"
|
|
49
|
+
- **Make it solid** - "Quality and reliability first"
|
|
50
|
+
- **Make it beautiful** - "Design and UX matter most"
|
|
51
|
+
- **Make it scale** - "Building for growth"
|
|
52
|
+
|
|
53
|
+
## Step 5: Ask About Audience
|
|
54
|
+
|
|
55
|
+
Use AskUserQuestion:
|
|
56
|
+
|
|
57
|
+
**Question:** "Who's this for?"
|
|
58
|
+
**Header:** "Audience"
|
|
59
|
+
**Options:**
|
|
60
|
+
- **Developers** - "Technical users who get it"
|
|
61
|
+
- **Everyone** - "Non-technical users, needs to be simple"
|
|
62
|
+
- **Business users** - "Professional, but not coders"
|
|
63
|
+
- **Just me** - "Personal project, I'm the user"
|
|
64
|
+
|
|
65
|
+
## Step 6: Ask About Product Tone
|
|
66
|
+
|
|
67
|
+
Use AskUserQuestion:
|
|
68
|
+
|
|
69
|
+
**Question:** "What vibe should the product have?"
|
|
70
|
+
**Header:** "Product tone"
|
|
71
|
+
**Options:**
|
|
72
|
+
- **Friendly** - "Warm, approachable, maybe playful"
|
|
73
|
+
- **Professional** - "Clean, trustworthy, serious"
|
|
74
|
+
- **Minimal** - "Say less, let the product speak"
|
|
75
|
+
- **Bold** - "Confident, opinionated, distinctive"
|
|
76
|
+
|
|
77
|
+
## Step 7: Optional Writing Sample
|
|
78
|
+
|
|
79
|
+
Ask:
|
|
80
|
+
|
|
81
|
+
"Optional: Paste a writing sample so I can match your voice. Could be anything - an email, a doc, a tweet. Or just say 'skip'."
|
|
82
|
+
|
|
83
|
+
If they provide a sample, note the patterns and include it. If they skip, move on.
|
|
84
|
+
|
|
85
|
+
## Step 8: Update CLAUDE.md
|
|
86
|
+
|
|
87
|
+
Add a DNA section to `CLAUDE.md` in the project root. If CLAUDE.md exists, append. If not, create it.
|
|
88
|
+
|
|
89
|
+
Use a marker `<!-- my-dna -->` to identify the section. If marker exists, replace that section.
|
|
90
|
+
|
|
91
|
+
```markdown
|
|
92
|
+
<!-- my-dna -->
|
|
93
|
+
## DNA
|
|
94
|
+
|
|
95
|
+
### Core Values
|
|
96
|
+
- [List their selected values]
|
|
97
|
+
|
|
98
|
+
### Voice
|
|
99
|
+
[Their style + any notes from writing sample]
|
|
100
|
+
|
|
101
|
+
### Project
|
|
102
|
+
- **Priority:** [ship it / solid / beautiful / scale]
|
|
103
|
+
- **Audience:** [developers / everyone / business / just me]
|
|
104
|
+
- **Tone:** [friendly / professional / minimal / bold]
|
|
105
|
+
```
|
|
106
|
+
|
|
107
|
+
## Step 9: Confirm
|
|
108
|
+
|
|
109
|
+
Say:
|
|
110
|
+
|
|
111
|
+
"Done! Added DNA to `CLAUDE.md`.
|
|
112
|
+
|
|
113
|
+
**Your style:** [One sentence summary, e.g., "Casual and direct, shipping fast for developers with a friendly vibe."]
|
|
114
|
+
|
|
115
|
+
I'll match this in code, docs, and commits. Run `/my-dna` again anytime to update."
|
|
116
|
+
|
|
117
|
+
## Notes
|
|
118
|
+
|
|
119
|
+
- Keep it short - 5 questions max
|
|
120
|
+
- No scanning, just ask
|
|
121
|
+
- If DNA section exists in CLAUDE.md (marker: `<!-- my-dna -->`), replace it
|
|
122
|
+
- The goal is to make Claude's output match their style and values
|