pi-prompting

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pi Prompting

Pi提示词编写指南

Use this skill when

pi:pi-rescue

needs to ask Pi for help on a non-trivial coding or investigation task.

Pi runs whatever model the user has configured. By default this plugin targets DeepSeek V4 (Pro for review, Flash for everyday tasks). The guidance below assumes the prompt may run on either a non-reasoning model (Flash) or a reasoning model (Pro). Bias toward concrete, numbered checklists rather than abstract instructions — both model classes follow those reliably.

Core rules:

Prefer one clear task per Pi run. Split unrelated asks into separate runs.
Tell Pi what done looks like. Do not assume it will infer the desired end state.
State explicit grounding rules whenever an unsupported guess would degrade quality.
Use stable XML-style tag blocks so the prompt has obvious internal structure.
Keep prose short. Prefer numbered checklists over paragraphs for procedural work.

Default prompt recipe:

```
<task>
```
: the concrete job and the relevant repository or failure context. Include file paths.
```
<output_contract>
```
(or
```
<structured_output_contract>
```
for JSON): exact shape, ordering, and brevity requirements.
```
<grounding_rules>
```
: required for review, research, or anything that could drift into unsupported claims.
```
<action_safety>
```
: required for write-capable tasks — name the directories and file kinds Pi may touch.

When to add extra blocks:

Coding or debugging: add
```
<completeness_contract>
```
listing what counts as "done" (tests pass, lint clean, files touched).
Review or adversarial review: rely on the shipped
```
prompts/adversarial-review.md
```
and
```
prompts/review.md
```
. Do not hand-craft another review prompt.
Research or recommendation tasks: add a short
```
<sources>
```
block listing what Pi is allowed to consult.

How to choose prompt shape:

Use the built-in
```
/pi:review
```
or
```
/pi:adversarial-review
```
commands when the job is reviewing local git changes. Those prompts already carry the review contract.
Use
```
task
```
when the job is diagnosis, planning, research, or implementation and you need to control the prompt more directly.
Use
```
task --resume-last
```
for follow-up instructions on the same Pi session. Send only the delta instruction instead of restating the whole prompt unless the direction changed materially.

Working rules:

Prefer explicit prompt contracts over vague nudges.
Do not raise reasoning (
```
--effort high
```
) by default — DeepSeek Flash will not benefit, and DeepSeek Pro takes longer. Tighten the prompt before escalating effort.
For tool-heavy or long-running tasks, ask Pi for brief outcome-based progress updates inside its working notes.
Keep claims anchored to observed evidence. If something is a hypothesis, mark it as such.

Prompt assembly checklist:

Define the exact task and scope in
```
<task>
```
.
State the output contract — JSON, bullet list, plain prose — and the maximum length.
Decide whether Pi should keep going on its own judgment or stop for missing high-risk details.
Add
```
<grounding_rules>
```
and
```
<action_safety>
```
only where the task needs them.
Remove redundant instructions before sending the prompt.

当

pi:pi-rescue

需要请求Pi协助完成复杂的编码或调查任务时，使用此技能。

Pi会运行用户配置的任何模型。默认情况下，此插件以DeepSeek V4为目标（评审任务使用Pro版本，日常任务使用Flash版本）。以下指南假设提示词可能在非推理模型（Flash）或推理模型（Pro）上运行。优先使用具体的编号清单而非抽象指令——这两类模型都能可靠地遵循此类指令。

核心规则：

每次调用Pi时优先设置一个明确的任务。将不相关的请求拆分为单独的调用。
告知Pi完成的标准。不要假设它能自行推断期望的最终状态。
当无依据的猜测会降低结果质量时，明确说明基准规则。
使用稳定的XML风格标签块，使提示词具有清晰的内部结构。
保持文字简洁。对于流程性工作，优先使用编号清单而非段落。

默认提示词模板：

```
<task>
```
：具体任务以及相关的代码仓库或故障上下文。包含文件路径。
```
<output_contract>
```
（若需JSON格式则使用
```
<structured_output_contract>
```
）：明确的格式、顺序和简洁性要求。
```
<grounding_rules>
```
：评审、研究或任何可能产生无依据结论的任务都需要此标签。
```
<action_safety>
```
：具备写入权限的任务需要此标签——指定Pi可操作的目录和文件类型。

何时添加额外标签块：

编码或调试：添加
```
<completeness_contract>
```
标签，列出‘完成’的标准（测试通过、代码检查无问题、涉及的文件）。
评审或对抗性评审：使用内置的
```
prompts/adversarial-review.md
```
和
```
prompts/review.md
```
文件。不要手动编写其他评审提示词。
研究或推荐任务：添加简短的
```
<sources>
```
标签块，列出Pi可参考的资源。

如何选择提示词形式：

当任务是评审本地git变更时，使用内置的
```
/pi:review
```
或
```
/pi:adversarial-review
```
命令。这些提示词已包含评审约定。
当任务是诊断、规划、研究或实现，且需要更直接地控制提示词时，使用
```
task
```
标签。
针对同一Pi会话的后续指令，使用
```
task --resume-last
```
。仅发送增量指令，除非方向发生重大变化，否则无需重述整个提示词。

操作规则：

优先使用明确的提示词约定而非模糊的提示。
默认情况下不要提升推理等级（
```
--effort high
```
）——DeepSeek Flash不会从中受益，且DeepSeek Pro会耗时更久。在提升推理等级前先优化提示词。
对于工具密集型或长时间运行的任务，要求Pi在工作笔记中提供基于结果的简短进度更新。
确保结论基于观察到的证据。如果是假设，请明确标记。

提示词组装检查清单：

在
```
<task>
```
中明确定义具体任务和范围。
说明输出约定——JSON、项目符号列表、纯文本——以及最大长度。
决定Pi是应自行判断继续执行，还是在缺少高风险细节时停止。
仅在任务需要时添加
```
<grounding_rules>
```
和
```
<action_safety>
```
标签。
在发送提示词前移除冗余指令。