安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install recon
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 recon。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

Recon 是一个面向非简单编码任务的研究与提案关卡。它会审查代码仓库指南、相关文件、应用程序入口点和配置，以了解项目背景；随后对任务进行分类，并提出 3–7 条针对该工作的具体且可检查的规则。作为 Openclaw Skills 的一部分，Recon 可帮助编码代理在开始实施之前识别约束条件和可能的故障类别。
它的核心特性是停止：Recon 会生成一份结构化报告，并等待用户确认或要求修改。它不会编写代码、运行检查以外的命令，也不会按照未经确认的计划继续执行。它旨在避免浪费精力，并明确报告未知事项，而不是猜测。

应用场景

开始涉及多个文件的工作。
准备涉及网络调用、数据处理或向当前工作目录之外写入内容的任务。
评估用户描述为规模大、耗时长或风险高的工作——即使它起初看起来很简单。
在开始错误修复、功能开发、重构、数据处理、训练或部署任务之前，确立针对任务且可验证的约束。
在确定实施方案之前，指出缺失的信息和预期的故障类别。

工作原理

检查代码仓库： 阅读可用的 README.md、AGENTS.md 和 CLAUDE.md 文件，识别相关文件和应用程序入口点，并审查项目配置。
了解背景： 根据检查到的材料，识别语言、框架、测试设置、构建系统和部署目标。
对任务分类： 将任务标记为错误修复、功能开发、重构、数据处理、训练、部署或其他。
提出自我规则： 起草 3–7 条编号规则，确保规则针对具体任务、范围适合该工作且可以检查。
报告发现和风险： 使用规定的侦察报告格式，呈现任务、具体发现、未知事项、预期的故障类别和提议的规则。
停止并等待确认： 请用户回复“confirmed”或“change: [what to change]”；等待回复期间，不得编写代码或继续执行检查以外的操作。
处理回复： 用户确认后，将提议的规则视为有约束力。收到修改请求或任何不是“confirmed”的回复时，修订报告并再次停止。

配置指南

将 Recon 用作符合条件的编码任务的前置工作流程。SKILL.md 内容未指定安装命令、软件包依赖项或其他配置步骤。
使用 Openclaw Skills 环境的安装流程，让编码代理能够使用 Recon 技能。
在任何符合其触发条件的任务开始时调用它：涉及多个文件、网络调用、数据处理、向当前工作目录之外写入内容，或被描述为规模大、耗时长或风险高的工作。
允许检查代码仓库，并要求代理生成规定的报告。
审阅提议的自我规则，并回复“confirmed”以继续，或回复“change: [what to change]”以要求修订报告。

SKILL.md 中未指定 CLI 安装或配置命令。

数据架构

Recon 不定义持久化数据存储、生成文件或机器可读的元数据分类体系。它的输出是在代理对话中生成的结构化 Markdown 报告。
报告部分 内容
任务 用一个段落描述所请求的工作
我的发现 在检查代码仓库期间收集到的具体事实
未知事项 尚未解决的问题、缺口或阻碍因素
预期的故障类别 编号列出的可能故障类别
提议的自我规则 3–7 条针对任务且可检查的约束，按编号列出
等待确认 要求确认或请求修改的说明
该技能将任务分类为错误修复、功能开发、重构、数据处理、训练、部署或其他。代码仓库检查可能包括 README.md、AGENTS.md、CLAUDE.md、相关源文件、入口点，以及存在时的 package.json、pyproject.toml 或 Cargo.toml 等配置文件。

高级特性

明确的确认关卡：
在用户确认报告之前阻止开始实施；停止是核心行为，而非可选的暂停。
任务专属约束：
生成 3–7 条范围明确、可验证的自我规则，而不是泛泛的建议，并在后续工作中将已确认的规则视为有约束力。
风险与不确定性报告：
要求同时列出未知事项和预期的故障类别，使代理能够指出信息缺口，而不是猜测。
结合代码仓库背景的准备：
利用项目文档、相关文件、入口点和配置，让报告以检查到的背景为依据。
修订循环：
将“change: X”及其他未确认的回复视为修订报告的请求，然后再次停止并等待确认。
严格的前置工作边界：
确认之前仅允许检查；禁止更改代码、运行检查以外的命令，以及制定报告之外的计划。

name: recon description: Research and proposal gate for non-trivial coding tasks. Inspects repository state, classifies task complexity, proposes 3-7 task-specific self-rules, produces a structured report (Task / What I found / Unknowns / Anticipated failure classes / Proposed self-rules / Awaiting confirmation), then stops for user confirmation before proceeding. Designed to prevent wasted effort on misaligned plans by surfacing constraints early. Not a substitute for domain expertise - flags unknowns instead of guessing. license: MIT

Recon

Research and proposal gate before any non-trivial task. This skill inspects your repository, proposes task-specific rules, and presents a structured report that you must confirm before any code is written or commands run. The stop is the point - without it, agents waste effort on misaligned plans.

When this runs

This skill activates on ANY of these triggers:

Start of any task that touches more than one file

Any task involving network calls

Any task involving data processing

Any task involving writing to disk outside the current working directory
Any task the user describes as "big", "long", or "risky"

State explicitly: do not skip this even for tasks that look simple, because simple-looking tasks are where the expensive mistakes come from.

Procedure

1. Inspect

Read these files to understand context:

README.md if present
AGENTS.md if present
CLAUDE.md if present

List of files relevant to the task

Entry points for the application

Configuration files (package.json, pyproject.toml, Cargo.toml, etc.)

Identify: language, framework, test setup, build system, deployment targets.

2. Classify

State the task type explicitly using one of these categories:

bugfix
feature
refactor
data-processing
training
deployment
other 3. Propose self-rules

Write 3-7 numbered rules. Each rule must be specific, checkable, and scoped to THIS task only (not forever). Rules should be narrow enough to verify but broad enough to matter.

Good self-rules:

All database migrations must be backward compatible: new columns nullable, new tables empty on first deploy. Checkable via migration diff inspection; scoped to schema changes.
Every new API endpoint must include rate-limit headers and response-time SLA documentation. Checkable via header inspection; scoped to public APIs.
UI component commits must include an accessibility checklist: color contrast >= 4.5:1, keyboard navigation, screen reader labels. Checkable via automated audit plus manual review; scoped to UI layer.

Bad self-rules:

Always write good code. Uncheckable, subjective, not specific to this task.
Security is important. Universal truth, adds no actionable constraint, cannot be verified.
Don't break things. Vague, everyone agrees, no guidance on what "breaking" means. 4. Produce the report

Output exactly this template so the agent knows the format:

Reconnaissance Report

Task

[one paragraph describing the task]

What I found

• [bullet list of concrete facts from inspection]
• [more findings]

Unknowns

• [things you could not determine; be honest about gaps]
• [missing information that blocks progress]

Anticipated failure classes

1. [class of failure, e.g. "data shape mismatch"]
2. [class of failure, e.g. "empty input file"]
3. [class of failure, e.g. "API rate limit"]

Proposed self-rules

1. [rule 1]
2. [rule 2]
3. [rule 3]

Awaiting confirmation

Reply "confirmed" or "change: [what to change]".

5. Stop

Do not write any code. Do not run any command beyond inspection. Do not make a plan beyond the report. Wait for the user.

The purpose of this skill is to prevent wasted effort, not to complete work. Stopping is the job.

Rules for this skill

If the user replies "confirmed", proceed using the proposed self-rules as binding constraints.
If the user replies "change: X", revise the report and stop again.
If the user replies with anything else, treat it as a change request.

Never skip the stop. The stop is the point.

Common mistakes

Writing code before the user confirms. The confirmation gate is the entire point of this skill.
Proposing vague self-rules like "be careful" or "write good code." Every rule must be checkable.
Skipping the inspection step and going straight to a report. The report must be grounded in what you actually read.
Treating the report as a formality. If you have nothing useful to say in "Unknowns" or "Anticipated failure classes," you did not inspect carefully enough.
Continuing after a "change: X" reply without revising and stopping again.
SAP Concur Expense Access (fpx)
OrangeInk 微信排版