jackin-goal-prompt

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

jackin-goal-prompt

Distill a roadmap item (and any plan files the operator hands you) into a single self-contained

/goal

prompt — one an executor agent with zero prior context can run to completion. The prompt is the product; its tightness decides whether the goal succeeds.

Capped at 4000 characters, hard. Structure borrowed from

/improve

's plans: self-contained, verification-gated, hard-boundaried. The skeleton that carries execution — objective, scope, verify gates, done criteria, STOP conditions — stays; everything the executor can read from files (code excerpts) or inherits from jackin❯'s auto-loaded rules (

AGENTS.md

COMMITS.md

ENGINEERING.md

) is pointed at, never restated.

Distinct from

jackin-research

: that authors a dossier brief (a multi-page

prompt.mdx

file run via

/goal Follow

). This produces a compact inline prompt run via

/goal Implement

/goal Run

将路线图项（以及操作者提供的所有计划文件）提炼为一个独立完整的

/goal

提示词——确保无前置上下文的executor agent可以直接执行并完成任务。提示词本身就是最终产物，其严谨性直接决定目标能否成功达成。

严格限制在4000字符以内。结构借鉴自

/improve

的计划：独立完整、验证驱动、边界明确。承载执行的核心框架——目标、范围、验证关卡、完成标准、STOP条件——需保留；所有executor可从文件（代码片段）中读取的内容，或从jackin❯自动加载的规则文件（

AGENTS.md

、

COMMITS.md

、

ENGINEERING.md

）中继承的内容，只需指向对应来源，切勿重复表述。

与

jackin-research

的区别：后者生成的是研究简报（多页

prompt.mdx

文件，通过

/goal Follow

执行）。而本工具生成的是紧凑的内联提示词，通过

/goal Implement

或

/goal Run

执行。

When to use

使用场景

Operator asks for a goal prompt / wants to kick off
```
/goal
```
on a roadmap item.
Operator has a roadmap item plus
```
/improve
```
plan files and wants them fused into one runnable prompt.

操作者需要生成目标提示词，或希望针对路线图项启动
```
/goal
```
命令时。
操作者拥有路线图项及
```
/improve
```
计划文件，希望将它们融合为一个可直接执行的提示词时。

When NOT to use

不适用场景

Authoring a research dossier brief →
```
jackin-research
```
.
Designing the roadmap item itself →
```
jackin-brainstorm
```
.
Opening the PR →
```
jackin-create-pr
```
/
```
jackin-propose
```
.

撰写研究简报 → 使用
```
jackin-research
```
。
设计路线图项本身 → 使用
```
jackin-brainstorm
```
。
提交PR → 使用
```
jackin-create-pr
```
/
```
jackin-propose
```
。

Arguments

参数

```
<slug>
```
— the roadmap item (slug, path, or the
```
.mdx
```
). Always required.
```
--plan <path|glob>
```
— plan markdown to fold in (a folder, a file, or a glob). Usually
```
/improve
```
output.

```
<slug>
```
— 路线图项（slug、路径或
```
.mdx
```
文件）。为必填项。
```
--plan <path|glob>
```
— 需整合的计划markdown文件（文件夹、单个文件或通配符路径）。通常为
```
/improve
```
的输出结果。

Process

流程

Gather the change. Read the roadmap
```
.mdx
```
. Anchor on
```
title:
```
and
```
**Status**:
```
only — real items drift from the
```
Problem/Why/Design/Tasks
```
scaffold, so tolerate any heading set. If
```
--plan
```
is given, read every plan file and lift its scope, steps, verify commands, done criteria, and STOP conditions.
Done when you can state, in two sentences, what this change builds and where its code lives.
Read the repo's real verification gates. The verify commands come from the repo, never invented. Pull them from
```
CONTRIBUTING.md
```
(the merge-readiness block),
```
.github/workflows/ci.yml
```
, and
```
mise.toml
```
— for jackin❯ that is
```
cargo fmt --check
```
,
```
cargo clippy --all-targets --all-features -- -D warnings
```
,
```
cargo nextest run --all-features
```
, the
```
e2e
```
profile, plus the
```
bun
```
docs gate when
```
docs/
```
is touched.
Done when every gate you cite is a command the repo actually runs, with its expected result.
Compose the prompt — the compressed
```
/improve
```
skeleton:
- Objective — one or two lines: what to build, pulled from the roadmap/plan.
- Scope — in-scope paths; out-of-scope boundaries (what looks related but must not be touched).
- Verify gates — the commands from step 2, each with its expected result.
- Done criteria — machine-checkable, one line each (a command + result, or a greppable absence), never prose like "works correctly."
- STOP conditions — drift vs the plan, a scope boundary that won't hold, a gate that won't go green honestly.
- Conventions — one line pointing at jackin❯'s auto-loaded rule files; do not copy their content.
Enforce the 4000-character cap. Write the prompt to a temp file and
```
wc -c
```
it. Over the cap, compress in this priority order until it fits: drop code excerpts (name the file + the contract, not the code), collapse conventions to a pointer, tighten the objective, cut the "why" narrative, merge done criteria into the verify gates. Re-count. The cap is hard — never emit over 4000.
Done when
```
wc -c
```
reports ≤ 4000 and the prompt still carries objective + scope + verify gates + done criteria + STOP conditions.
Emit + report. Print the prompt in a single code block, ready to paste after
```
/goal Implement <slug>
```
or
```
/goal Run
```
. State the character count. Name what you compressed or dropped to fit, so the operator can ask for it back inline if they'd rather raise the cap.

收集变更信息 读取路线图
```
.mdx
```
文件。仅聚焦
```
title:
```
和
```
**Status**:
```
部分——实际项目往往会偏离
```
Problem/Why/Design/Tasks
```
框架，因此需兼容任何标题结构。若提供了
```
--plan
```
参数，则读取所有计划文件，提取其范围、步骤、验证命令、完成标准和STOP条件。
完成标志：能用两句话说明本次变更要构建的内容及其代码所在位置。
读取仓库真实验证关卡 验证命令必须来自仓库本身，不得自行编造。从
```
CONTRIBUTING.md
```
（合并就绪模块）、
```
.github/workflows/ci.yml
```
和
```
mise.toml
```
中提取——对于jackin❯而言，这些命令包括
```
cargo fmt --check
```
、
```
cargo clippy --all-targets --all-features -- -D warnings
```
、
```
cargo nextest run --all-features
```
、
```
e2e
```
配置文件，以及当修改
```
docs/
```
目录时的
```
bun
```
文档检查关卡。
完成标志：所有引用的关卡均为仓库实际运行的命令，并附带预期结果。
撰写提示词 — 压缩版的
```
/improve
```
框架：
- 目标 — 1-2行：从路线图/计划中提取的待构建内容。
- 范围 — 包含的路径；排除的边界（看似相关但不得修改的内容）。
- 验证关卡 — 步骤2中提取的命令，每条命令附带预期结果。
- 完成标准 — 可机器校验的内容，每条一行（命令+结果，或可通过grep检查的缺失项），切勿使用“正常工作”这类描述性文字。
- STOP条件 — 偏离计划、无法维持范围边界、无法真实通过的关卡。
- 约定 — 一行文字指向jackin❯的自动加载规则文件；切勿复制文件内容。
执行4000字符上限限制 将提示词写入临时文件并通过
```
wc -c
```
统计字符数。若超出上限，按以下优先级压缩直至符合要求：删除代码片段（仅提及文件名及需满足的约定，而非代码内容）、将约定简化为指向链接、精简目标描述、删除“原因”类叙述、将完成标准合并至验证关卡。重新统计字符数。上限为硬性要求——绝对不得输出超过4000字符的内容。
完成标志：
```
wc -c
```
统计结果≤4000，且提示词仍包含目标+范围+验证关卡+完成标准+STOP条件。
输出并报告 将提示词打印在单个代码块中，可直接粘贴至
```
/goal Implement <slug>
```
或
```
/goal Run
```
之后。说明字符数。列出为符合上限而压缩或删除的内容，以便操作者若希望提高上限时可要求恢复相关内容。

Common mistakes

常见错误

Exceeding 4000 characters — the one hard constraint.
Inventing verify commands instead of reading the repo's real ones — a gate the repo doesn't run is noise.
Restating jackin❯'s auto-loaded rules (
```
AGENTS.md
```
,
```
COMMITS.md
```
,
```
ENGINEERING.md
```
) — the executor auto-loads them; point, don't copy.
Inlining code excerpts — the executor reads the files; name the file and the contract it must satisfy.
Producing a prompt that leans on chat context ("as discussed", "the approach we chose") — not self-contained, breaks on a fresh executor.
Ignoring
```
--plan
```
files when given — they carry the scope and done criteria; folding them in is the point.
Dropping the STOP conditions — they are the executor's only honest escape hatch.

超出4000字符——这是唯一的硬性约束。
自行编造验证命令而非读取仓库真实命令——仓库未运行的关卡属于无效信息。
重复表述jackin❯的自动加载规则（
```
AGENTS.md
```
、
```
COMMITS.md
```
、
```
ENGINEERING.md
```
）——executor会自动加载这些规则；只需指向，无需复制。
内联代码片段——executor可直接读取文件；只需提及文件名及需满足的约定。
生成依赖聊天上下文的提示词（如“如之前讨论”、“我们选择的方案”）——不具备独立性，会导致新的executor无法执行。
忽略提供的
```
--plan
```
文件——这些文件包含范围和完成标准；整合它们是核心目标。
遗漏STOP条件——这是executor唯一可靠的退出机制。

Tooling

工具说明

No xtask owns this. The skill orchestrates reads (the roadmap

.mdx

, the plan files, the repo's verify commands) and emits a single ≤ 4000-char string. The structure borrows from

/improve

's plan anatomy (self-contained, verification-gated, hard-boundaried) and the

/goal Run

brief shape jackin❯ already uses for gap-closure.

本功能未绑定至任何xtask。该技能负责协调读取操作（路线图

.mdx

、计划文件、仓库的验证命令）并输出单个≤4000字符的字符串。其结构借鉴自

/improve

的计划架构（独立完整、验证驱动、边界明确）以及jackin❯已用于缺口填补的

/goal Run

简报格式。