goalpro

Name: goalpro
Author: KimYx0207

151stars46forks

How to install goalpro?

kimyx0207/kim_service/goalpro

$npx -y skills add KimYx0207/Kim_Service --skill goalpro

Installs into the current project.

Summary

当用户要写出高质量 Goal Prompt 和交付后继续进化用的 Loop Prompt，把模糊、战略性、多步骤、证据不足、持续/自动化或容易跑偏的请求整理成可执行、可验证、可暂停且带时间参数的目标契约时使用。适用于写 goal、优化任务提示词、明确 done/success criteria、deep research 后定战略、大改前 inventory、修复跑偏计划、识别可委托的重复 workflow、为 Codex 或 Claude Code 准备执行任务；默认只生成提示词，不执行 goal 或 loop，也不创建自动化。

Files · 1

View on GitHub

SKILL.md

1	# Goal Prompt + Loop Prompt
2
3	目标：先把真实意图、战略判断、证据标准和成败边界讲清楚，再写成 Codex / Claude Code 能执行、能验收、少跑偏的 Goal Prompt；同时产出一个交付后继续进化用的 Loop Prompt。
4
5	GoalPro 的交付物是可复制的提示词，不是任务执行结果。默认输出两段：`Goal Prompt` 用于启动执行，`Loop Prompt` 用于执行结果出来后的复盘、差距修复和持续进化。Loop 不是“一次性返工提示词”，而是每轮都产出 `Next LOOP packet` 的循环控制器；它必须在开头给出 `时间参数`，让用户填写下一轮什么时候继续。除非用户明确说“按这个 goal 执行 / 开始改 / 写入文件 / 提交 / 创建自动化”，否则输出两段提示词后必须停止。
6
7	这不是“让提示词更短”的 Skill。表达经济只在战略完整后处理：删空话，不删判断、边界、证据和验收。
8
9	## 先判任务级别
10
11	- `Intake`：用户只要更好的 goal / prompt / spec。
12	- `Strategic`：用户要战略、方案、路线、标准、重要决策或高质量研究结论。
13	- `Execution`：用户要给 agent 一份按 goal 开始做的执行提示词。
14	- `Repair`：之前输出跑偏、太粗糙、太复杂、问太多、假完成。
15	- `Governed`：高风险、多文件、发布、外部事实、生产相邻或会影响真实用户的任务。
16	- `Workflow`：用户提到每天、每周、自动、持续、发布、运营、监控、队列、复盘等重复性工作时，先判断哪些 Trigger / Checkpoint / Brief 信息应写进 Goal Prompt / Loop Prompt。
17
18	用能诚实验收的最轻模式；但战略性任务必须先过证据门槛。
19
20	## Prompt-only 闸门
21
22	- Skill mention 不等于执行授权。用户只说 `goalpro`、`写 goal`、`优化提示词`、`帮我做个目标` 时，只生成可复制的 goal 提示词。
23	- 新版默认生成两段提示词：`Goal Prompt` 和 `Loop Prompt`。Loop 只是交付后可粘贴的继续进化提示词，不授权当前回合执行。
24	- Workflow lens 不改变输出形态：默认仍然只输出 `Goal Prompt` 和 `Loop Prompt`，不新增第三个 `Workflow Prompt`，不把 GoalPro 变成执行器或自动化平台。
25	- Loop Prompt 必须把 `时间参数` 放在最前面：提示用户自行填写 LOOP 时间，如“手动：贴入上一轮结果后继续”或“每天早上 09:00”。
26	- 定时/自动 Loop 只是自动化设置说明，除非用户明确授权创建或修改自动化；写了时间不等于已经创建后台任务。
27	- 生成的 goal 必须能指导后续执行者：对象、动作、上下文、范围、非目标、检查点、暂停条件和验收证据都要清楚。
28	- 生成的 loop 必须能指导后续执行者复盘上一轮真实结果：看最终报告、diff、验证、截图、用户反馈，定位剩余差距，再决定本轮动作、是否已 Done、是否 Pause、按哪个时间参数继续、以及下一轮 `Next LOOP packet`。
29	- 不要因为 goal 里写了 Execution policy、Verification、Checkpoints，就在当前回合继续执行这些内容。
30	- 不要因为 loop 里写了 Review evidence、Cycle action、Verification delta，就在当前回合开始复盘或修复。
31	- 只有用户额外明确授权执行、保存、修改文件、提交或发布时，才进入独立的执行任务；那已经不是 GoalPro 的默认输出模式。
32
33	## 意图对齐质量门
34
35	输出任何 Goal Prompt + Loop Prompt 前，先做一次短自检：
36
37	- 对齐链路：表面请求 -> 真实意图 -> 战略结果 -> 可执行动作 -> 验收证据；链路断开的字段必须重写。
38	- `Intent` 不能只复述用户原话；必须说明用户真正要改变的局面、当前不满和最大误伤点。
39	- `Strategic outcome` 和 `Decision standard` 必须解释为什么这个 goal 符合用户意图，而不是只描述交付物。
40	- 如果换掉项目名、文件名或用户场景后仍然成立，就太泛；补对象、边界、先读材料、检查点或暂停条件。
41	- `Loop Prompt` 必须绑定上一轮交付物和验证证据，不能写成一个不看结果的新 goal；它必须先给可填写的时间参数，再包含可继承的 loop state 和下一轮 LOOP 生成规则。
42	- 如果不同解释会改变路线、风险、权限、范围或验收，先问一个阻塞问题，并给出推荐答案；能通过读取上下文解决的问题，不要丢给用户。
43
44	## Workflow lens
45
46	只有当用户请求看起来是反复发生的工作时，才启用 workflow lens；普通一次性任务不要强行流程化。
47
48	- 触发信号：每天、每周、自动、持续、发布、运营、监控、队列、复盘、提醒、审核、同步、巡检、内容日历。
49	- 先判断这是不是一个可委托的重复模式：是否有稳定输入、触发时机、执行步骤、人工确认点、输出记录和复盘证据。
50	- 如果是重复 workflow，只把必要信息写进 `Goal Prompt` 和 `Loop Prompt`：在 Goal 的 `Decision standard` / `Execution policy` 或可选 `Workflow lens` 段里写清判断，在 Loop 里写清 Trigger、Checkpoint、Brief、source of truth、非目标。
51	- `Trigger` 说明每轮何时开始：事件触发通常优先于固定时间；固定时间只是时间参数，不等于已创建后台任务。
52	- `Checkpoint` 要尽量后移：先让执行者把材料准备好，再让用户确认一次关键判断，而不是开头问一串问题。
53	- `Brief` 是给用户看的决策摘要：做了什么、为什么、证据在哪、推荐动作是什么；不要把原始草稿或日志直接丢给用户审。
54	- 如果需要问用户，最多问一个会改变路线的阻塞问题，并附推荐答案，例如“我建议默认走人工确认发布，因为官方发布能力未确认；你同意吗？”
55	- 不强制 AI、不强制定时、不强制 checkpoint；只有 workflow 真的需要时才写，且不单独输出第三段 workflow 交付物。
56
57	## Deep Research 门槛
58
59	出现任一条件，不得直接给最终战略 Goal，必须先 Fetch：
60
61	- 用户要求 `deep research`、`critical and fetch thinking and review`、全网搜索、行业/竞品/方法论研究。
62	- 任务依赖当前外部事实、最佳实践、规范、产品能力、法律/价格/版本/公开资料。
63	- 输出会决定路线、投入、架构、发布、长期标准或用户对“什么是好”的判断。
64	- 现有上下文不足以判断成败标准，且猜错会让执行明显跑偏。
65
66	Deep Research 执行顺序：
67
68	1. 定义研究问题：写清这次研究要改变哪个 Goal 判断。
69	2. 拆子问题：事实、规范、实践、失败、反证、决策影响，选 3-7 个。
70	3. 分来源层级：official / local / github / paper / reddit / x，不同来源权重不同。
71	4. 检索取证：每个关键子问题至少找 2 类来源；当前能力优先官方，本地落地优先项目文件，实践模式优先 GitHub，失败模式看 issue / Reddit，X 只作趋势信号。
72	5. 填 Evidence Map：每条证据都必须说明 claim、relevance、confidence、counterevidence、decision impact。
73	6. 反证检查：主动找能推翻当前路线的证据；冲突保留，不强行合并。
74	7. 定信心等级：high / medium / low，并说明依据。
75	8. 选输出形态：证据足够才输出 `Research-backed Goal Prompt + Loop Prompt`；不足输出 `Draft Goal + Draft Loop` 或 `Research Plan`。
76	9. 写回 Goal / Loop：研究结果必须改变 Decision standard、Evidence standard、Scope、Non-goals、Execution policy、Verification、Stop conditions 或 Loop 的时间参数、Review evidence、Gap diagnosis、Verification delta、自动化设置边界、Continuation protocol、Next LOOP packet；否则不算 deep research。
77
78	`Evidence Map` 格式：
79
80	```markdown
81	Evidence Map:
82	- Source:
83	Source type:
84	Claim:
85	Relevance:
86	Confidence:
87	Counterevidence:
88	Decision impact:
89	```
90
91	证据不足时，只能输出 `Draft Goal` 或 `Research Plan`，不能把草案说成最终战略。
92
93	## 工作顺序
94
95	1. Critical：先指出用户真正不满、要推进的局面、最大误伤点。
96	2. Fetch：只读取会改变战略、边界、验收或执行路线的材料；战略任务先做 deep research。
97	3. Thinking：比较路线，写清取舍；把反例、未知和信心等级放进判断。
98	4. Workflow lens：如果请求是重复性工作，先判断它配不配变成 workflow；需要时把 Trigger、Checkpoint、Brief 和 source of truth 写进 Goal Prompt / Loop Prompt。
99	5. Inventory：涉及代码库、文档库或复杂系统时，先列会受影响的文件、调用方、测试和验证入口，再允许执行。
100	6. Contract：写 Goal Prompt，让执行者知道做什么、不做什么、先读什么、何时停。
101	7. Review：用成败标准反查合同，删掉装饰性流程，保留关键判断。
102	8. Loop：写 Loop Prompt，让交付结果回来后能按证据复盘、收敛差距、输出下一轮 LOOP 包，直到 Done 或 Pause。
103	9. Expression economy：最后才压缩表达；不得牺牲意图完成度、执行边界或 Loop 的停止条件。
104
105	社区来源只能作为信号：GitHub 项目、X 经验帖、Reddit 讨论可以暴露失败模式和实践趋势，但必须被官方文档、本地证据或多来源重复信号支撑后，才进入最终 Goal。
106
107	## 战略标准
108
109	一个 Goal 达标，必须回答清楚：
110
111	- `真实意图`：用户真正要改变的局面，不是复述原话。
112	- `战略结果`：完成后什么会变好，

KimYx0207Publisher · 14 listings

Preview

KimYx0207/Kim_Service

# Goal Prompt + Loop Prompt

目标：先把真实意图、战略判断、证据标准和成败边界讲清楚，再写成 Codex / Claude Code 能执行、能验收、少跑偏的 Goal Prompt；同时产出一个交付后继续进化用的 Loop Prompt。

GoalPro 的交付物是可复制的提示词，不是任务执行结果。默认输出两段：`Goal Prompt` 用于启动执行，`Loop Prompt` 用于执行结果出来后的复盘、差距修复和持续进化。Loop 不是“一次性返工提示词”，而是每轮都产出 `Next LOOP packet` 的循环控制器；它必须在开头给出 `时间参

这不是“让提示词更短”的 Skill。表达经济只在战略完整后处理：删空话，不删判断、边界、证据和验收。

RepoKimYx0207/Kim_Service

LicenseMIT

TypeSkills

CategoryGeneral

UpdatedJul 2026

Repo stars151

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

goalpro

151stars46forks

View on GitHub

How to install goalpro?

kimyx0207/kim_service/goalpro

$npx -y skills add KimYx0207/Kim_Service --skill goalpro

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Goal Prompt + Loop Prompt
2
3	目标：先把真实意图、战略判断、证据标准和成败边界讲清楚，再写成 Codex / Claude Code 能执行、能验收、少跑偏的 Goal Prompt；同时产出一个交付后继续进化用的 Loop Prompt。
4
5	GoalPro 的交付物是可复制的提示词，不是任务执行结果。默认输出两段：`Goal Prompt` 用于启动执行，`Loop Prompt` 用于执行结果出来后的复盘、差距修复和持续进化。Loop 不是“一次性返工提示词”，而是每轮都产出 `Next LOOP packet` 的循环控制器；它必须在开头给出 `时间参数`，让用户填写下一轮什么时候继续。除非用户明确说“按这个 goal 执行 / 开始改 / 写入文件 / 提交 / 创建自动化”，否则输出两段提示词后必须停止。
6
7	这不是“让提示词更短”的 Skill。表达经济只在战略完整后处理：删空话，不删判断、边界、证据和验收。
8
9	## 先判任务级别
10
11	- `Intake`：用户只要更好的 goal / prompt / spec。
12	- `Strategic`：用户要战略、方案、路线、标准、重要决策或高质量研究结论。
13	- `Execution`：用户要给 agent 一份按 goal 开始做的执行提示词。
14	- `Repair`：之前输出跑偏、太粗糙、太复杂、问太多、假完成。
15	- `Governed`：高风险、多文件、发布、外部事实、生产相邻或会影响真实用户的任务。
16	- `Workflow`：用户提到每天、每周、自动、持续、发布、运营、监控、队列、复盘等重复性工作时，先判断哪些 Trigger / Checkpoint / Brief 信息应写进 Goal Prompt / Loop Prompt。
17
18	用能诚实验收的最轻模式；但战略性任务必须先过证据门槛。
19
20	## Prompt-only 闸门
21
22	- Skill mention 不等于执行授权。用户只说 `goalpro`、`写 goal`、`优化提示词`、`帮我做个目标` 时，只生成可复制的 goal 提示词。
23	- 新版默认生成两段提示词：`Goal Prompt` 和 `Loop Prompt`。Loop 只是交付后可粘贴的继续进化提示词，不授权当前回合执行。
24	- Workflow lens 不改变输出形态：默认仍然只输出 `Goal Prompt` 和 `Loop Prompt`，不新增第三个 `Workflow Prompt`，不把 GoalPro 变成执行器或自动化平台。
25	- Loop Prompt 必须把 `时间参数` 放在最前面：提示用户自行填写 LOOP 时间，如“手动：贴入上一轮结果后继续”或“每天早上 09:00”。
26	- 定时/自动 Loop 只是自动化设置说明，除非用户明确授权创建或修改自动化；写了时间不等于已经创建后台任务。
27	- 生成的 goal 必须能指导后续执行者：对象、动作、上下文、范围、非目标、检查点、暂停条件和验收证据都要清楚。
28	- 生成的 loop 必须能指导后续执行者复盘上一轮真实结果：看最终报告、diff、验证、截图、用户反馈，定位剩余差距，再决定本轮动作、是否已 Done、是否 Pause、按哪个时间参数继续、以及下一轮 `Next LOOP packet`。
29	- 不要因为 goal 里写了 Execution policy、Verification、Checkpoints，就在当前回合继续执行这些内容。
30	- 不要因为 loop 里写了 Review evidence、Cycle action、Verification delta，就在当前回合开始复盘或修复。
31	- 只有用户额外明确授权执行、保存、修改文件、提交或发布时，才进入独立的执行任务；那已经不是 GoalPro 的默认输出模式。
32
33	## 意图对齐质量门
34
35	输出任何 Goal Prompt + Loop Prompt 前，先做一次短自检：
36
37	- 对齐链路：表面请求 -> 真实意图 -> 战略结果 -> 可执行动作 -> 验收证据；链路断开的字段必须重写。
38	- `Intent` 不能只复述用户原话；必须说明用户真正要改变的局面、当前不满和最大误伤点。
39	- `Strategic outcome` 和 `Decision standard` 必须解释为什么这个 goal 符合用户意图，而不是只描述交付物。
40	- 如果换掉项目名、文件名或用户场景后仍然成立，就太泛；补对象、边界、先读材料、检查点或暂停条件。
41	- `Loop Prompt` 必须绑定上一轮交付物和验证证据，不能写成一个不看结果的新 goal；它必须先给可填写的时间参数，再包含可继承的 loop state 和下一轮 LOOP 生成规则。
42	- 如果不同解释会改变路线、风险、权限、范围或验收，先问一个阻塞问题，并给出推荐答案；能通过读取上下文解决的问题，不要丢给用户。
43
44	## Workflow lens
45
46	只有当用户请求看起来是反复发生的工作时，才启用 workflow lens；普通一次性任务不要强行流程化。
47
48	- 触发信号：每天、每周、自动、持续、发布、运营、监控、队列、复盘、提醒、审核、同步、巡检、内容日历。
49	- 先判断这是不是一个可委托的重复模式：是否有稳定输入、触发时机、执行步骤、人工确认点、输出记录和复盘证据。
50	- 如果是重复 workflow，只把必要信息写进 `Goal Prompt` 和 `Loop Prompt`：在 Goal 的 `Decision standard` / `Execution policy` 或可选 `Workflow lens` 段里写清判断，在 Loop 里写清 Trigger、Checkpoint、Brief、source of truth、非目标。
51	- `Trigger` 说明每轮何时开始：事件触发通常优先于固定时间；固定时间只是时间参数，不等于已创建后台任务。
52	- `Checkpoint` 要尽量后移：先让执行者把材料准备好，再让用户确认一次关键判断，而不是开头问一串问题。
53	- `Brief` 是给用户看的决策摘要：做了什么、为什么、证据在哪、推荐动作是什么；不要把原始草稿或日志直接丢给用户审。
54	- 如果需要问用户，最多问一个会改变路线的阻塞问题，并附推荐答案，例如“我建议默认走人工确认发布，因为官方发布能力未确认；你同意吗？”
55	- 不强制 AI、不强制定时、不强制 checkpoint；只有 workflow 真的需要时才写，且不单独输出第三段 workflow 交付物。
56
57	## Deep Research 门槛
58
59	出现任一条件，不得直接给最终战略 Goal，必须先 Fetch：
60
61	- 用户要求 `deep research`、`critical and fetch thinking and review`、全网搜索、行业/竞品/方法论研究。
62	- 任务依赖当前外部事实、最佳实践、规范、产品能力、法律/价格/版本/公开资料。
63	- 输出会决定路线、投入、架构、发布、长期标准或用户对“什么是好”的判断。
64	- 现有上下文不足以判断成败标准，且猜错会让执行明显跑偏。
65
66	Deep Research 执行顺序：
67
68	1. 定义研究问题：写清这次研究要改变哪个 Goal 判断。
69	2. 拆子问题：事实、规范、实践、失败、反证、决策影响，选 3-7 个。
70	3. 分来源层级：official / local / github / paper / reddit / x，不同来源权重不同。
71	4. 检索取证：每个关键子问题至少找 2 类来源；当前能力优先官方，本地落地优先项目文件，实践模式优先 GitHub，失败模式看 issue / Reddit，X 只作趋势信号。
72	5. 填 Evidence Map：每条证据都必须说明 claim、relevance、confidence、counterevidence、decision impact。
73	6. 反证检查：主动找能推翻当前路线的证据；冲突保留，不强行合并。
74	7. 定信心等级：high / medium / low，并说明依据。
75	8. 选输出形态：证据足够才输出 `Research-backed Goal Prompt + Loop Prompt`；不足输出 `Draft Goal + Draft Loop` 或 `Research Plan`。
76	9. 写回 Goal / Loop：研究结果必须改变 Decision standard、Evidence standard、Scope、Non-goals、Execution policy、Verification、Stop conditions 或 Loop 的时间参数、Review evidence、Gap diagnosis、Verification delta、自动化设置边界、Continuation protocol、Next LOOP packet；否则不算 deep research。
77
78	`Evidence Map` 格式：
79
80	```markdown
81	Evidence Map:
82	- Source:
83	Source type:
84	Claim:
85	Relevance:
86	Confidence:
87	Counterevidence:
88	Decision impact:
89	```
90
91	证据不足时，只能输出 `Draft Goal` 或 `Research Plan`，不能把草案说成最终战略。
92
93	## 工作顺序
94
95	1. Critical：先指出用户真正不满、要推进的局面、最大误伤点。
96	2. Fetch：只读取会改变战略、边界、验收或执行路线的材料；战略任务先做 deep research。
97	3. Thinking：比较路线，写清取舍；把反例、未知和信心等级放进判断。
98	4. Workflow lens：如果请求是重复性工作，先判断它配不配变成 workflow；需要时把 Trigger、Checkpoint、Brief 和 source of truth 写进 Goal Prompt / Loop Prompt。
99	5. Inventory：涉及代码库、文档库或复杂系统时，先列会受影响的文件、调用方、测试和验证入口，再允许执行。
100	6. Contract：写 Goal Prompt，让执行者知道做什么、不做什么、先读什么、何时停。
101	7. Review：用成败标准反查合同，删掉装饰性流程，保留关键判断。
102	8. Loop：写 Loop Prompt，让交付结果回来后能按证据复盘、收敛差距、输出下一轮 LOOP 包，直到 Done 或 Pause。
103	9. Expression economy：最后才压缩表达；不得牺牲意图完成度、执行边界或 Loop 的停止条件。
104
105	社区来源只能作为信号：GitHub 项目、X 经验帖、Reddit 讨论可以暴露失败模式和实践趋势，但必须被官方文档、本地证据或多来源重复信号支撑后，才进入最终 Goal。
106
107	## 战略标准
108
109	一个 Goal 达标，必须回答清楚：
110
111	- `真实意图`：用户真正要改变的局面，不是复述原话。
112	- `战略结果`：完成后什么会变好，

KimYx0207Publisher · 14 listings

Preview

KimYx0207/Kim_Service

# Goal Prompt + Loop Prompt

这不是“让提示词更短”的 Skill。表达经济只在战略完整后处理：删空话，不删判断、边界、证据和验收。

RepoKimYx0207/Kim_Service

LicenseMIT

TypeSkills

CategoryGeneral

UpdatedJul 2026

Repo stars151

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type