ralph-prompt-single-task

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Ralph Prompt Generator: Single Task

Ralph提示词生成器：单任务版

Overview

概述

Generates well-structured prompts optimized for the Ralph Wiggum technique for single, focused tasks. These prompts include clear completion criteria, automatic verification (tests), self-correction loops, and proper

<promise>

completion tags.

Best For:

Bug fixes with clear success criteria
Single feature implementations
Refactoring tasks
Adding tests for existing code
Documentation for specific modules
Performance optimizations with measurable targets

Ralph Philosophy: This generator embraces the principle that failures are deterministic and fixable. Each iteration learns from the previous one. Don't fear failures—they're expected and provide data for improvement through prompt tuning.

生成针对Ralph Wiggum技术优化的结构清晰的单任务聚焦型提示词。这些提示词包含明确的完成标准、自动验证（测试）、自我修正循环以及规范的

<promise>

完成标签。

最佳适用场景：

具备明确成功标准的Bug修复
单一功能实现
代码重构任务
为现有代码添加测试
特定模块的文档编写
具备可衡量目标的性能优化

Ralph核心理念：该生成器秉持「失败是可预测且可修复」的原则。每次迭代都会从之前的尝试中学习。无需惧怕失败——失败是预期之内的，能为通过提示词调优实现改进提供数据支持。

Quick Start

快速开始

Input Required:

Task description (what needs to be done)
Success criteria (how to verify completion)
Completion promise text (the phrase that signals done)

Generate prompt with:

Generate a Ralph prompt for: [task description]
Success criteria: [how to verify]
Promise: [completion phrase]

所需输入：

任务描述（需要完成的内容）
成功标准（如何验证任务完成）
完成承诺文本（标记任务完成的短语）

生成提示词的命令：

Generate a Ralph prompt for: [task description]
Success criteria: [how to verify]
Promise: [completion phrase]

Prompt Generation Workflow

提示词生成流程

Step 1: Analyze the Task

步骤1：分析任务

Identify these elements:

Action: What specific work needs to be done?
Scope: What files/modules are affected?
Verification: How can success be automatically verified?
Edge cases: What could go wrong?

识别以下要素：

动作：需要执行哪些具体工作？
范围：哪些文件/模块会受影响？
验证：如何自动验证任务成功？
边缘情况：可能出现哪些问题？

Step 2: Define Completion Criteria

步骤2：定义完成标准

Good completion criteria are:

Measurable (tests pass, no errors, specific output)
Verifiable automatically (not subjective)
Binary (clearly done or not done)

Examples:

Task Type	Good Criteria	Bad Criteria
Bug fix	"Tests pass, bug no longer reproducible"	"Bug is fixed"
Feature	"All CRUD endpoints return 200, tests pass"	"Feature works"
Refactor	"All tests pass, code uses new pattern"	"Code is cleaner"

优质的完成标准具备以下特点：

可衡量（测试通过、无错误、特定输出结果）
可自动验证（非主观判断）
二元性（明确的完成或未完成状态）

示例：

任务类型	优质标准	劣质标准
Bug修复	"测试通过，Bug无法复现"	"Bug已修复"
功能开发	"所有CRUD接口返回200状态码，测试通过"	"功能可用"
代码重构	"所有测试通过，代码采用新设计模式"	"代码更简洁"

Step 3: Structure the Prompt

步骤3：构建提示词结构

Use this template:

markdown

undefined

使用以下模板：

markdown

undefined

Task: [Clear Task Title]

Task: [清晰的任务标题]

Objective

[1-2 sentence clear description of what needs to be accomplished]

[1-2句话清晰描述需要达成的目标]

Context

[Brief background - what exists, why this is needed]

[简要背景 - 当前已有内容、任务的必要性]

Requirements

[Specific requirement 1]
[Specific requirement 2]
[Specific requirement 3]

[具体需求1]
[具体需求2]
[具体需求3]

Success Criteria

Verification Steps

[How to verify criterion 1]
[How to verify criterion 2]
[How to verify criterion 3]

[如何验证标准1]
[如何验证标准2]
[如何验证标准3]

TDD Approach

Write/identify failing tests for the requirement
Implement the solution
Run tests:
```
[test command]
```
If tests fail, analyze output and fix
Repeat until all tests pass

为需求编写/识别失败的测试用例
实现解决方案
运行测试：
```
[测试命令]
```
如果测试失败，分析输出结果并修复问题
重复操作直至所有测试通过

Completion

When ALL of the following are true:

All success criteria met (checklist above)
All tests passing
No regressions introduced

Output: <promise>[COMPLETION_PHRASE]</promise>

当以下所有条件均满足时：

所有成功标准已达成（上述勾选列表全部完成）
所有测试通过
未引入任何回归问题

输出：<promise>[COMPLETION_PHRASE]</promise>

If Stuck

After multiple iterations without progress:

Document what's blocking progress
List approaches attempted
Identify specific error or issue
Do NOT output false promise - continue iterating or wait for max-iterations

undefined

经过多次迭代仍无进展时：

记录当前阻碍进度的问题
列出已尝试的解决方法
明确具体的错误或问题
请勿输出虚假的promise标签 - 继续迭代或等待达到最大迭代次数

undefined

Step 4: Add Verification Commands

步骤4：添加验证命令

Include specific commands to verify success:

markdown

undefined

包含用于验证成功的具体命令：

markdown

undefined

Verification Commands

bash

undefined

bash

undefined

Run tests

运行测试

npm test

or

或

pytest tests/

Check for errors

检查错误

npm run lint

or

或

ruff check .

Verify specific functionality

验证特定功能

curl -X GET http://localhost:3000/api/endpoint

undefined

curl -X GET http://localhost:3000/api/endpoint

undefined

Example Prompts

提示词示例

Example 1: Bug Fix

示例1：Bug修复

Input:

Task: Fix authentication token refresh race condition
Verification: Auth tests pass, no 401 errors in logs
Promise: AUTH_FIX_COMPLETE

Generated Prompt:

markdown

undefined

输入：

任务：修复认证令牌刷新的竞态条件
验证：认证测试通过，日志中无401错误
承诺：AUTH_FIX_COMPLETE

生成的提示词：

markdown

undefined

Task: Fix Authentication Token Refresh Race Condition

Objective

Fix the race condition in token refresh that causes intermittent 401 errors when multiple requests trigger refresh simultaneously.

Context

The auth module in

src/auth/

handles JWT token refresh. When a token expires, multiple concurrent requests may all attempt to refresh, causing a race condition where some requests fail with 401.

The auth module in

src/auth/

handles JWT token refresh. When a token expires, multiple concurrent requests may all attempt to refresh, causing a race condition where some requests fail with 401.

Requirements

Implement token refresh locking/queuing mechanism
Ensure concurrent requests wait for single refresh
Maintain backward compatibility with existing auth flow
Add tests covering concurrent refresh scenario

Implement token refresh locking/queuing mechanism
Ensure concurrent requests wait for single refresh
Maintain backward compatibility with existing auth flow
Add tests covering concurrent refresh scenario

Success Criteria

All existing auth tests pass
New concurrent refresh test passes
No 401 errors in integration test logs
Token refresh happens only once per expiration

All existing auth tests pass
New concurrent refresh test passes
No 401 errors in integration test logs
Token refresh happens only once per expiration

Verification Steps

Run auth tests:
```
npm test -- --grep "auth"
```
Run concurrent refresh test:
```
npm test -- --grep "concurrent"
```
Check logs for 401 after integration test
Verify single refresh in logs during concurrent requests

Run auth tests:
```
npm test -- --grep "auth"
```
Run concurrent refresh test:
```
npm test -- --grep "concurrent"
```
Check logs for 401 after integration test
Verify single refresh in logs during concurrent requests

TDD Approach

Write test for concurrent token refresh scenario
Verify test fails with current implementation
Implement locking mechanism
Run tests:
```
npm test
```
If tests fail, analyze and fix
Repeat until all pass

Write test for concurrent token refresh scenario
Verify test fails with current implementation
Implement locking mechanism
Run tests:
```
npm test
```
If tests fail, analyze and fix
Repeat until all pass

Completion

When ALL of the following are true:

All auth tests passing (including new concurrent test)
Integration tests show no 401 errors
Single refresh verified in logs

Output: <promise>AUTH_FIX_COMPLETE</promise>

When ALL of the following are true:

All auth tests passing (including new concurrent test)
Integration tests show no 401 errors
Single refresh verified in logs during concurrent requests

Output: <promise>AUTH_FIX_COMPLETE</promise>

If Stuck

After multiple iterations:

Document the specific race condition behavior
List locking approaches tried
Identify where locks are failing
Do NOT output false promise

undefined

After multiple iterations:

Document the specific race condition behavior
List locking approaches tried
Identify where locks are failing
Do NOT output false promise

undefined

Example 2: Feature Implementation

示例2：功能实现

Input:

Task: Add pagination to /api/users endpoint
Verification: Pagination params work, tests pass
Promise: PAGINATION_DONE

Generated Prompt:

markdown

undefined

输入：

任务：为/api/users接口添加分页功能
验证：分页参数生效，测试通过
承诺：PAGINATION_DONE

生成的提示词：

markdown

undefined

Task: Add Pagination to Users Endpoint

Objective

Implement offset-based pagination for GET /api/users endpoint with page, limit, and total count.

Context

The users endpoint in

src/routes/users.ts

currently returns all users. As the user base grows, this needs pagination for performance.

The users endpoint in

src/routes/users.ts

currently returns all users. As the user base grows, this needs pagination for performance.

Requirements

Accept
```
page
```
(default 1) and
```
limit
```
(default 20, max 100) query params
Return paginated response with metadata: { data: [], page, limit, total, totalPages }
Handle edge cases: invalid params, page beyond data, empty results
Add comprehensive tests for pagination

Accept
```
page
```
(default 1) and
```
limit
```
(default 20, max 100) query params
Return paginated response with metadata: { data: [], page, limit, total, totalPages }
Handle edge cases: invalid params, page beyond data, empty results
Add comprehensive tests for pagination

Success Criteria

GET /api/users returns paginated response
```
page
```
and
```
limit
```
query params work correctly
Response includes correct metadata (total, totalPages)
Edge cases handled gracefully
All new pagination tests pass
Existing user tests still pass

GET /api/users returns paginated response
```
page
```
and
```
limit
```
query params work correctly
Response includes correct metadata (total, totalPages)
Edge cases handled gracefully
All new pagination tests pass
Existing user tests still pass

Verification Steps

Run tests:
```
npm test -- --grep "users"
```

Manual verification:

curl localhost:3000/api/users?page=1&limit=10

curl localhost:3000/api/users?page=999&limit=10

```
curl localhost:3000/api/users?limit=200
```

Run tests:
```
npm test -- --grep "users"
```

Manual verification:

curl localhost:3000/api/users?page=1&limit=10

curl localhost:3000/api/users?page=999&limit=10

```
curl localhost:3000/api/users?limit=200
```

TDD Approach

Write tests for pagination behavior
Verify tests fail
Implement pagination logic
Run tests:
```
npm test
```
If failures, fix and retry
Test edge cases manually

Write tests for pagination behavior
Verify tests fail
Implement pagination logic
Run tests:
```
npm test
```
If failures, fix and retry
Test edge cases manually

Completion

When ALL of the following are true:

All pagination tests pass
All existing user tests pass
Manual verification shows correct behavior
Edge cases handled (returns empty for page beyond data)

Output: <promise>PAGINATION_DONE</promise>

When ALL of the following are true:

All pagination tests pass
All existing user tests pass
Manual verification shows correct behavior
Edge cases handled (returns empty for page beyond data)

Output: <promise>PAGINATION_DONE</promise>

If Stuck

Document:

Which tests are failing and why
What pagination approach was tried
Specific error messages
Do NOT output false promise

undefined

Document:

Which tests are failing and why
What pagination approach was tried
Specific error messages
Do NOT output false promise

undefined

Example 3: Refactoring Task

示例3：重构任务

Input:

Task: Convert callbacks to async/await in database module
Verification: All DB tests pass, no callback patterns remain
Promise: ASYNC_REFACTOR_COMPLETE

Generated Prompt:

markdown

undefined

输入：

任务：将数据库模块中的回调函数转换为async/await模式
验证：所有数据库测试通过，无回调模式残留
承诺：ASYNC_REFACTOR_COMPLETE

生成的提示词：

markdown

undefined

Task: Convert Database Module to Async/Await

Objective

Refactor all callback-based database operations in

src/db/

to use async/await pattern for improved readability and error handling.

Refactor all callback-based database operations in

src/db/

to use async/await pattern for improved readability and error handling.

Context

The database module uses callback patterns from legacy code. Modern async/await improves code clarity and makes error handling more consistent.

Requirements

Convert all callback-based functions to async/await
Replace callback error handling with try/catch
Update all callers to use await
Maintain identical external API behavior
No callback patterns remaining in db module

Convert all callback-based functions to async/await
Replace callback error handling with try/catch
Update all callers to use await
Maintain identical external API behavior
No callback patterns remaining in db module

Success Criteria

Verification Steps

Run tests:
```
npm test -- --grep "database"
```
Search for callbacks:
```
grep -r "callback\|cb)" src/db/
```
TypeScript check:
```
npm run typecheck
```
Integration tests:
```
npm run test:integration
```

Run tests:
```
npm test -- --grep "database"
```
Search for callbacks:
```
grep -r "callback\|cb)" src/db/
```
TypeScript check:
```
npm run typecheck
```
Integration tests:
```
npm run test:integration
```

TDD Approach

Run all tests - ensure baseline passes
Convert one function at a time
Run tests after each conversion
If failures, fix before continuing
After all conversions, verify no callbacks remain

Run all tests - ensure baseline passes
Convert one function at a time
Run tests after each conversion
If failures, fix before continuing
After all conversions, verify no callbacks remain

Completion

When ALL of the following are true:

All database tests passing
grep for callbacks returns empty
TypeScript compilation succeeds
Integration tests pass

Output: <promise>ASYNC_REFACTOR_COMPLETE</promise>

When ALL of the following are true:

All database tests passing
grep for callbacks returns empty
TypeScript compilation succeeds
Integration tests pass

Output: <promise>ASYNC_REFACTOR_COMPLETE</promise>

If Stuck

Document:

Which function is causing issues
The specific error or test failure
What conversion approach was tried
Do NOT output false promise

undefined

Document:

Which function is causing issues
The specific error or test failure
What conversion approach was tried
Do NOT output false promise

undefined

Best Practices

最佳实践

DO:

建议：

Use specific, measurable success criteria
Include actual test commands
Add verification steps for each criterion
Include TDD approach for self-correction
Set clear completion conditions
Provide "If Stuck" guidance

使用具体、可衡量的成功标准
包含实际可运行的测试命令
为每个标准添加对应的验证步骤
纳入TDD开发模式以实现自我修正
设置清晰的完成条件
提供「遇到阻碍时」的指导内容

DON'T:

避免：

Use vague criteria ("make it work")
Skip verification commands
Forget edge cases
Make subjective success criteria
Allow escape without genuine completion

使用模糊的标准（如「功能可用」）
省略验证命令
忽略边缘情况
设置主观的成功标准
在未真正完成时输出完成承诺

Integration with Ralph Loop

与Ralph Loop集成

Run your generated prompt:

bash

/ralph-wiggum:ralph-loop "[paste generated prompt]" --completion-promise "YOUR_PROMISE" --max-iterations 30

Recommended settings:

Bug fixes:
```
--max-iterations 15-20
```
Features:
```
--max-iterations 25-35
```
Refactoring:
```
--max-iterations 20-30
```

运行生成的提示词：

bash

/ralph-wiggum:ralph-loop "[paste generated prompt]" --completion-promise "YOUR_PROMISE" --max-iterations 30

推荐配置：

Bug修复：
```
--max-iterations 15-20
```
功能开发：
```
--max-iterations 25-35
```
代码重构：
```
--max-iterations 20-30
```

Validation Checklist

验证清单

Before using a generated prompt, verify:

Task has single, focused objective
Success criteria are measurable
Verification commands are specific and runnable
TDD approach is defined
Completion promise is clear and specific
"If Stuck" section provides guidance

For multi-task prompts, see

ralph-prompt-multi-task

. For project-level prompts, see

ralph-prompt-project

. For research/analysis prompts, see

ralph-prompt-research

在使用生成的提示词前，请确认：

任务具备单一、聚焦的目标
成功标准可衡量
验证命令具体且可运行
已定义TDD开发流程
完成承诺清晰明确
「遇到阻碍时」部分提供了指导内容

如需生成多任务提示词，请查看

ralph-prompt-multi-task

。如需生成项目级提示词，请查看

ralph-prompt-project

。如需生成研究/分析类提示词，请查看

ralph-prompt-research

。