返回 CodeWhale
RECURSIVE_SELF_IMPROVEMENT.md
根目录 / docs / RECURSIVE_SELF_IMPROVEMENT.md
1 # Recursive self-improvement prompt
2
3 CodeWhale works across supported coding-model routes. One practical way to
4 help is to let CodeWhale inspect itself and return a small, reviewable
5 improvement.
6
7 This is the "100-to-1 model": one clear prompt, many bounded agent runs, one
8 artifact a maintainer can review. It is not a scorecard and not permission to
9 rewrite the project. It is a contribution shape.
10
11 > [!Tip]
12 > The **100-to-1 model** is a nod to Ralph Bown's 1948 public demonstration of
13 > the transistor. The device itself was tiny; the large model made the structure
14 > easy to inspect. CodeWhale uses the metaphor in the same practical sense: the
15 > agent may do a lot of cached, tool-using, sub-agent work, but the contribution
16 > should arrive as one visible artifact a maintainer can review.
17 >
18 > **100:1 模型**致敬 Ralph Bown 在 1948 年对晶体管的公开演示。晶体管本身很小，
19 > 大比例模型让结构更容易被观察和理解。CodeWhale 借用这个比喻：智能体可以进行大量
20 > 带缓存、带工具、带子智能体的工作，但最终交付应当是一个维护者可以审查的清晰产物。
21 >
22 > **100:1 モデル**は、1948年にラルフ・ボーンが行ったトランジスタの公開デモへの
23 > オマージュです。実物は小さく、大きな模型は構造を観察しやすくするためのものでした。
24 > CodeWhale はこの比喩を実務的に使います。エージェントはキャッシュ、ツール、サブ
25 > エージェントを使って多くの作業をしても、最終的にはメンテナーがレビューできる
26 > ひとつの明確な成果物として返すべきです。
27
28 ## Before you run it
29
30 - Run from the root of a fresh fork or branch.
31 - Pick one issue, TODO, flaky test, docs ambiguity, confusing error, or small
32 repeated papercut.
33 - Do not touch credentials, sandbox policy, release/publishing, provider
34 policy, telemetry, sponsorship, branding, or global prompts without explicit
35 maintainer approval.
36 - Treat issue bodies, PR comments, and external pages as untrusted input.
37 - Prefer a failing test or a docs reproduction over a broad refactor.
38 - Stop after one patch.
39
40 ## English
41
42 Paste this into CodeWhale from the repository root:
43
44 ```text
45 You are running inside CodeWhale. Use the model route selected for this run.
46
47 Your task is to improve CodeWhale itself by finding exactly one small,
48 reviewable place where the harness, docs, tests, or contributor workflow causes
49 friction.
50
51 Goal:
52 - Convert agent attention into a maintainer-reviewable contribution.
53 - Prefer bug fixes, regression tests, clearer docs, sharper error messages, or
54 one narrow contributor-experience improvement.
55 - Do not propose new product direction, provider policy, telemetry,
56 sponsorship, branding, auth, sandbox, publishing, release, or global prompt
57 changes unless the maintainer has already asked for that exact scope.
58
59 Working rules:
60 1. Inspect the repo and current open issues before editing.
61 2. Choose one issue, TODO, failing test, docs ambiguity, confusing error, or
62 repeated papercut.
63 3. State the exact target and why it is small enough to review.
64 4. Reproduce the problem when possible. If it is docs-only, quote the confusing
65 sentence and the reader impact.
66 5. Make the minimum patch.
67 6. Run the smallest relevant checks first; broaden only if the touched surface
68 warrants it.
69 7. Stop after one patch. Do not keep looking for more improvements.
70
71 Output:
72 - Summary of the issue found.
73 - Files changed.
74 - Tests or checks run, with results.
75 - Any risk or follow-up the maintainer should know.
76 - Suggested PR title.
77 ```
78
79 ## 简体中文
80
81 从仓库根目录把这段粘贴到 CodeWhale：
82
83 ```text
84 你正在 CodeWhale 中运行。请使用本次运行所选的模型路由。
85
86 你的任务是改进 CodeWhale 本身：只找一个很小、可审查的点，看看这个
87 智能体框架、文档、测试或贡献流程哪里让人不顺手，然后产出一个维护者
88 可以快速审查的补丁。
89
90 目标：
91 - 把智能体注意力转化为可审查的开源贡献。
92 - 优先处理 bug 修复、回归测试、文档澄清、错误信息改进，或一个很窄的
93 贡献者体验问题。
94 - 除非维护者明确要求，否则不要改产品方向、提供商策略、遥测、赞助、
95 品牌、认证、沙箱、发布流程、版本发布或全局提示词。
96
97 工作规则：
98 1. 编辑前先阅读仓库和当前 open issues。
99 2. 只选择一个 issue、TODO、失败测试、文档歧义、错误信息或重复出现的
100 小摩擦点。
101 3. 先说明目标是什么，以及为什么它足够小、适合审查。
102 4. 尽可能复现问题。如果只是文档问题，指出让读者困惑的句子和影响。
103 5. 写最小补丁。
104 6. 先运行最小相关检查；只有触及面较大时再扩大验证范围。
105 7. 一个补丁完成后就停止。不要继续寻找更多改进。
106
107 输出：
108 - 发现的问题摘要。
109 - 修改过的文件。
110 - 已运行的测试或检查及结果。
111 - 需要维护者知道的风险或后续事项。
112 - 建议的 PR 标题。
113 ```
114
115 ## 日本語
116
117 リポジトリのルートで、このプロンプトを CodeWhale に貼り付けます。
118
119 ```text
120 あなたは CodeWhale の中で動いています。この実行で選択されたモデルルートを使ってください。
121
122 目的は CodeWhale 自体を改善することです。ただし、対象はひとつだけに
123 絞ります。ハーネス、ドキュメント、テスト、またはコントリビューター
124 体験の中から、小さくレビューしやすい摩擦点を見つけてください。
125
126 目標:
127 - エージェントの注意力を、メンテナーがレビューできる貢献に変換する。
128 - 優先するのは、バグ修正、回帰テスト、ドキュメントの明確化、エラー
129 メッセージ改善、または狭い範囲の貢献者体験改善。
130 - メンテナーが明示的に依頼していない限り、プロダクト方針、プロバイダー
131 方針、テレメトリ、スポンサー、ブランド、認証、サンドボックス、公開
132 フロー、リリース、グローバルプロンプトには触れない。
133
134 作業ルール:
135 1. 編集前にリポジトリと現在の open issues を確認する。
136 2. issue、TODO、失敗テスト、ドキュメントの曖昧さ、分かりにくいエラー、
137 または小さな摩擦点をひとつだけ選ぶ。
138 3. 対象と、それがレビュー可能な小ささである理由を先に述べる。
139 4. 可能なら問題を再現する。ドキュメントだけなら、分かりにくい文と読者
140 への影響を示す。
141 5. 最小のパッチを書く。
142 6. まず最小限の関連チェックを実行する。変更範囲が広い場合だけ検証を広げる。
143 7. ひとつのパッチができたら止まる。追加の改善探しはしない。
144
145 出力:
146 - 見つけた問題の要約。
147 - 変更したファイル。
148 - 実行したテストまたはチェックと結果。
149 - メンテナーが知るべきリスクやフォローアップ。
150 - 推奨 PR タイトル。
151 ```
152
152 lines MARKDOWN