Use when you have a written implementation plan to execute in a separate session with review checkpoints
npx skills add SafaElmali/10x-claude --skill "ralph-linear"
Install specific skill from multi-skill repository
# Description
|
# SKILL.md
name: ralph-linear
description: |
Comprehensive Ralph Loop workflow for Linear tickets. Combines PRD creation, agent selection (frontend/backend/fullstack/rails), iterative development with progress tracking, and automated PR creation.
Use when working on Linear tickets that need structured development with quality gates.
user: "/ralph-linear WEB-1234"
assistant: "Starting Ralph Linear workflow for WEB-1234..."
user: "work on ticket WEB-5503 with ralph"
assistant: "I'll use ralph-linear to process this ticket with structured development."
Ralph Linear Workflow
You are executing a structured Ralph Loop development workflow. Follow this process precisely.
Arguments
Parse the input for:
- TICKET_ID - Linear ticket ID (e.g., WEB-1234) - REQUIRED
- --max-iterations <n> - Max iterations (default: 10 for small, 30 for large)
- --skip-prd - Skip PRD generation phase
- --auto - Skip the plan approval gate and proceed automatically
- --no-worktree - Stay in main repo instead of creating a worktree (default: creates worktree)
Output Format
IMPORTANT: Keep output minimal and focused. Each iteration outputs ONLY:
## {TICKET_ID} - Iteration {N}/{max}
- [x] Task 1 description
- [x] Task 2 description
- [ ] **โ Task 3 description** (current)
- [ ] Task 4 description
Status: โ Lint | โ Tests | โ Committed
No verbose explanations. Just the task list with progress markers.
Workflow Phases
Phase 0: Setup & Context Gathering
-
Fetch ticket details:
Use mcp__plugin_linear_linear__get_issue to fetch ticket details -
Worktree Setup (default):
Skip if: --no-worktree flag OR already in worktree for this ticket.
a. Check if already in worktree:
bash
pwd | grep -q "swarm-{TICKET_ID}" && echo "Already in worktree"
b. Create worktree with branch:
bash
git worktree add ../swarm-{TICKET_ID} -b safa/{TICKET_ID}/{short-desc} main
cd ../swarm-{TICKET_ID}
c. Inform user:
Created worktree at: ../swarm-{TICKET_ID}
Working in isolated directory.
With --no-worktree: Create branch in-place:
bash
git checkout -b safa/{TICKET_ID}/{short-desc}
-
Analyze ticket and create task list:
Break down the ticket into specific implementation tasks. These are the ACTUAL tasks you will complete, not phases. -
Create progress.txt with goal task list:
```
# {TICKET_ID}: {Ticket Title}
## Goal Tasks
- [ ] Task 1: {specific implementation task}
- [ ] Task 2: {specific implementation task}
- [ ] Task 3: {specific implementation task}
- [ ] Visual validation with Playwright
- [ ] Create PR
## Current: Task 1
Started: {timestamp}
```
-
Output the task list immediately:
```
## {TICKET_ID} - Starting -
[ ] Task 1: {description}
- [ ] Task 2: {description}
- [ ] Task 3: {description}
- [ ] Visual validation
- [ ] Create PR
```
Phase 1: PRD Creation (Brief)
Create a brief PRD in progress.txt:
## PRD
**Problem:** {one sentence}
**Solution:** {one sentence}
**Acceptance Criteria:**
- {criterion 1}
- {criterion 2}
Phase 1.5: Clarification & Plan Approval
If --auto flag is present: Skip this phase entirely. Display the plan briefly and proceed directly to Phase 2 (Implementation) without waiting for approval.
Otherwise: Before starting implementation, ensure requirements are clear and get user approval.
Step 1: Identify Unclear Requirements
Review the ticket and PRD. If ANYTHING is unclear, ask questions BEFORE proposing tasks:
## {TICKET_ID} - Clarification Needed
I have some questions before creating the implementation plan:
1. {Question about unclear requirement}
2. {Question about edge case}
3. {Question about design/behavior}
Keep asking questions until you have clarity on:
- Expected behavior and edge cases
- Design specifications (if UI work)
- API contracts (if backend work)
- Scope boundaries (what's NOT included)
Do NOT proceed to the plan until all ambiguities are resolved.
Step 2: Present Plan for Approval
Once requirements are clear, present the plan and STOP to wait for user confirmation:
## {TICKET_ID} - Plan Review
**Problem:** {one sentence from PRD}
**Solution:** {one sentence from PRD}
### Proposed Tasks
1. {Task 1 description}
2. {Task 2 description}
3. {Task 3 description}
4. Visual validation
5. Create PR
### Agent: {frontend-developer | backend-developer | senior-rails-backend-dev | fullstack-developer}
**Reasoning:** {why this agent was selected}
### Files likely to change:
- {file path 1}
- {file path 2}
---
**Approve this plan? (y/n/adjust)**
Wait for user response before proceeding:
| Response | Action |
|---|---|
y / yes / approve |
Continue to Phase 2 implementation |
n / no |
Ask what's wrong, revise the plan |
adjust / custom feedback |
Incorporate user's modifications, re-present plan |
Do NOT proceed to implementation until user explicitly approves.
Phase 2: Agent Selection
Select agent based on task type:
| Task Type | Agent |
|---|---|
| UI/CSS only | frontend-developer |
| API/DB only (Node/TS) | backend-developer |
| Rails/Ruby backend | senior-rails-backend-dev |
| Both UI + API | fullstack-developer |
Phase 3: Implementation Loop
For each task:
- Mark task as current in output
- Implement the change
- Run feedback loops (lint, tests)
- Commit with descriptive message
- Mark task complete, move to next
- Update progress.txt
Output per iteration:
## {TICKET_ID} - Iteration {N}/{max}
- [x] Find the CSS causing white block
- [ ] **โ Fix container height** (current)
- [ ] Test fix locally
- [ ] Visual validation with Playwright
- [ ] Create PR
Status: โ Lint | โ Tests | โ Pending commit
Phase 4: Visual Validation
IMPORTANT: For any UI changes, validate visually before creating PR.
Step 1: Detect Context from Modified Files
Check which files were modified to determine context:
| Modified Files | Context | URL | Auth |
|---|---|---|---|
client/src/routes/website/ |
Website Builder | localhost:3001 | Publisher |
apps/orchid-v1/ or apps/orchid-v2/ |
Orchid | localhost:3002 | Subscriber (optional) |
| Other client files | Default | localhost:3001 | Publisher |
Step 2: Load Config Files
Read ~/.claude/beehiiv/credentials.json โ get auth credentials
Read ~/.claude/beehiiv/website-builder.md or ~/.claude/beehiiv/orchid.md โ get context instructions
Step 3: Authenticate (if required)
Automated login (try first):
1. Navigate to login page
2. Snapshot to find form fields
3. Fill email/password from credentials.json
4. Click submit
5. Wait for redirect
Manual login fallback:
If automated login fails (2FA, captcha, magic link):
1. Take screenshot
2. Tell user: "Please log in manually in the browser window, then tell me when ready"
3. Wait for user confirmation
4. Continue with testing
Step 4: Visual Testing
Use agent-browser CLI (simple checks):
# Open local dev server (use correct URL from context)
agent-browser open http://localhost:3001
# Get accessibility tree to find elements
agent-browser snapshot
# Navigate to the page with changes
agent-browser click @nav-link # or CSS selector
# Take screenshot for PR
agent-browser screenshot {TICKET_ID}-after.png
# Test mobile viewport
agent-browser close
agent-browser open http://localhost:3001 --viewport 375x812
agent-browser screenshot {TICKET_ID}-mobile.png
# Clean up
agent-browser close
Use Playwright MCP (complex flows, auth required):
1. browser_navigate โ appropriate URL (3001 or 3002)
2. browser_snapshot โ get element refs
3. browser_type โ fill login form with credentials
4. browser_click โ submit login
5. browser_wait_for โ dashboard/redirect
6. browser_navigate โ page with changes
7. browser_snapshot โ verify structure
8. browser_take_screenshot โ capture for PR
9. browser_close โ cleanup
When to use which:
| Scenario | Tool |
|---|---|
| Simple page screenshot | agent-browser |
| CSS/layout validation | agent-browser |
| Responsive testing | agent-browser |
| Auth required | Playwright MCP |
| Multi-step user flow | Playwright MCP |
| Forms with modals/iframes | Playwright MCP |
| Signup/checkout flows | Playwright MCP |
Phase 4.5: Quality Checks (automatic for frontend)
If agent is frontend-developer or fullstack-developer, run these checks before PR:
React Best Practices
For any React/Next.js code changed:
- Check for performance issues (waterfalls, bundle size, re-renders)
- Apply rules from /react-best-practices skill
- Fix any CRITICAL or HIGH severity issues
Web Design Guidelines
For any UI components changed:
- Fetch guidelines from: https://raw.githubusercontent.com/vercel-labs/web-interface-guidelines/main/command.md
- Check accessibility (a11y) and UX patterns
- Fix any violations found
Output:
## {TICKET_ID} - Quality Checks
โ React Best Practices: {N issues found, N fixed}
โ Web Design Guidelines: {N issues found, N fixed}
Skip for backend-developer and senior-rails-backend-dev agents.
Phase 5: PR Creation
When all tasks complete:
- Final commit if needed
- Push branch:
git push -u origin <branch-name> - Create PR with this exact format:
gh pr create --title "[{TICKET_ID}](linear-url): {task-title}" --body "$(cat <<'EOF'
## Summary
{Start with a concise paragraph explaining:
- What was wrong / missing (the issue)
- What changed to solve it}
{Follow with bullets summarizing the key changes:}
- {Key change 1}
- {Key change 2}
- {Key change 3}
## Test plan
- [ ] {Manual test step 1}
- [ ] {Manual test step 2}
- [ ] {Verify specific behavior}
Ticket: {TICKET_ID}
EOF
)"
- Output:
```
PR: {url}
Worktree cleanup (after PR merged):
git worktree remove ../swarm-{TICKET_ID}
```
<promise>COMPLETE</promise>
Commit Guidelines
After EACH task (not at the end):
git add -A
git commit -m "$(cat <<'EOF'
{type}: {short description}
- {What changed}
Ticket: {TICKET_ID}
EOF
)"
Progress File Format
Keep progress.txt updated:
# {TICKET_ID}: {Title}
## Goal Tasks
- [x] Task 1: Find CSS issue
- [x] Task 2: Fix container height
- [ ] Task 3: Visual validation
- [ ] Task 4: Create PR
## Current: Task 3
Status: Implementation complete, validating...
## Log
- Found issue in SurveyForm.tsx line 45
- Fixed by removing min-height: 100vh
- Committed: fix: remove extra whitespace in survey form
Error Recovery
If stuck:
1. Check progress.txt for context
2. Check git log
3. Ask user for guidance
Completion
Output <promise>COMPLETE</promise> ONLY when:
- All goal tasks marked [x]
- PR created successfully
Example Full Output
## WEB-6135 - Starting
- [ ] Investigate CSS causing white block
- [ ] Fix the container/layout issue
- [ ] Visual validation with Playwright
- [ ] Create PR
---
## WEB-6135 - Iteration 1/10
- [x] Investigate CSS causing white block
- [ ] **โ Fix the container/layout issue** (current)
- [ ] Visual validation with Playwright
- [ ] Create PR
Status: โ Lint | โ Tests | โ Pending
---
## WEB-6135 - Iteration 2/10
- [x] Investigate CSS causing white block
- [x] Fix the container/layout issue
- [ ] **โ Visual validation with Playwright** (current)
- [ ] Create PR
Status: โ Lint | โ Tests | โ Committed
---
## WEB-6135 - Iteration 3/10
- [x] Investigate CSS causing white block
- [x] Fix the container/layout issue
- [x] Visual validation with Playwright
- [ ] **โ Create PR** (current)
Status: โ Lint | โ Tests | โ Committed
---
## WEB-6135 - Complete
- [x] Investigate CSS causing white block
- [x] Fix the container/layout issue
- [x] Visual validation with Playwright
- [x] Create PR
PR: https://github.com/your-org/your-repo/pull/XXXX
<promise>COMPLETE</promise>
# Supported AI Coding Agents
This skill is compatible with the SKILL.md standard and works with all major AI coding agents:
Learn more about the SKILL.md standard and how to use these skills with your preferred AI coding agent.