---
name: jd-platform-agentify
description: >-
  把任意京东内部 web 平台改造成「agent 可用」形态——产出 LLM wiki + webcli CLI adapter，
  并通过自迭代闭环持续完善。内含 4 个子 skill：/jd-platform-agentify:collect（探查 loop）、
  /jd-platform-agentify:cli（造 CLI loop）、/jd-platform-agentify:wiki（建 wiki loop）、
  /jd-platform-agentify:employee（数字员工）。三个 loop 由自带的 autoloop 引擎驱动（skills/autoloop/，纯指令、无需装 plugin）。
  触发词：agentify、平台 agent 化、给平台造 wiki/CLI、webcli adapter、巡检平台 wiki、
  探查网页、探查这个 URL、采集这个页面、probe this page、probe this URL。
  当用户说"给 X 平台建 wiki"、"给 X 平台造 CLI"、"把 X 平台 agent 化"时触发。
  当用户给出一个内部平台 URL 并说"尝试用这个探查网页/探查这个页面/probe this page"时，
  必须路由到 /jd-platform-agentify:collect，并立即按 collect 固定配方进入 autoloop，而不是只做一次 probe。
---

# jd-platform-agentify

把一个京东内部 web 平台改造成 agent 可消费的形态。主线顺序是：

1. **探查饱和**：从入口页面出发，摸清可达页面、按钮、面板、接口、权限与风险。
2. **CLI 可执行化**：把已探明能力封装成 `webcli <site> <command>`，agent 可直接调用。
3. **wiki 沉淀**：最后把探查证据与 CLI 用法整理成面向 agent 的 LLM wiki，发布到 JoySpace。

三个 autoloop 各自迭代收敛，数字员工消费 CLI + wiki 产物并通过 trace 反哺。

## 架构

```mermaid
flowchart LR
    C[/jd-platform-agentify:collect\n探查 loop] --> L[/jd-platform-agentify:cli\nCLI loop]
    L --> W[/jd-platform-agentify:wiki\nwiki loop]
    W --> E[/jd-platform-agentify:employee\n数字员工]
    E -->|attribution.md 派工| C
    E -->|attribution.md 派工| L
    E -->|attribution.md 派工| W
```

## 子 skill 路由

| 子命令 | 触发场景 |
| --- | --- |
| `/jd-platform-agentify:collect` | 探查页面/按钮/面板/接口/权限/风险，直到探查三阶段分 100 |
| `/jd-platform-agentify:cli` | 基于已探明能力造/迭代 webcli 命令，真实数据冒烟收敛 |
| `/jd-platform-agentify:wiki` | CLI 跑通后沉淀 wiki，lint 收敛，发布 JoySpace |
| `/jd-platform-agentify:employee` | 端到端验收 + 业务跑 + trace 回流 |
| `/jd-platform-agentify:clieval` | 把已注册的 CLI 针对 cli-eval bench 自迭代优化到通过率达标（评分器=cli-eval agent+判官） |

**每个子 skill 基于 autoloop 引擎**（引擎随本 skill 自带，见 `skills/autoloop/`——纯指令，无需安装 plugin/hooks）。启动某阶段 loop 时，读对应子 skill，贴末尾的「固定配方」，按当前宿主使用 `$autoloop`（Codex）或 `/autoloop`（Claude Code）的循环语义自迭代：Verify 输出数字，Guard 必须通过，keep/discard 由 git checkpoint/revert 兜底。

## 自然语言 URL 探查入口

当用户说类似：

- "尝试用这个，探查下这个网页？http://..."
- "探查这个 URL"
- "采集这个页面"
- "probe this page / probe this URL"

并且目标是京东内部平台页面时，不要把它当作一次性浏览器操作。必须：

1. 路由到 `/jd-platform-agentify:collect`。
2. 先打印 `[autoloop] mode: classic`，然后使用 collect 的固定配方进入 `$autoloop`。
3. 把该 URL 作为第一轮增量目标；如 `expected_pages.txt` 里没有对应条目，先按 host + path 派生 slug 并登记。
4. 第一轮才运行 `bash .agentify/scripts/probe_page.sh "<url>" <slug> wiki/donginspect`，随后按 page-note spec 精修、Verify、commit/keep。

判断标准：只要用户意图是"继续探、尽量探全、网页/平台采集"，就应该看到 autoloop baseline 和迭代记录；看不到 `autoloop/loop-*` 或 loop TSV，说明没有真正进入 autoloop。

## 闭环编排

1. 顺序跑三个 loop：collect → cli → wiki。wiki 不是探查后的下一步，只有 CLI 对核心能力冒烟通过后才沉淀。
2. 数字员工（employee）消费 CLI + wiki 产出物，L1 验收产出 `attribution.md`（结构化派工：`module / issue / action`）。
3. 人工读 attribution 后重启对应子 loop 修复，再回到数字员工复验。
4. wiki loop 收敛后手动跑 `joyspace_sync.sh` 发布 JoySpace。

## 贯穿原则

1. **遵循前端真实文案命名**：CLI 命令名、wiki 术语对齐用户在平台页面看到的叫法。
2. **接口真值来自代码+实测**：从 controller 源码提取，不确定时浏览器抓真实请求。
3. **阶段化写操作策略**：collect 阶段测试写入默认已授权，用 agent-probe 测试对象抓真实接口；cli 阶段写命令必须带 `--confirm` 守卫，默认只预览。
4. **安全红线**：不写真实 ERP/Cookie/Token；不改生产对象，副作用外溢操作静默跳过并记录。
5. **验证闭环**：先证明命令能用真实数据跑通，再把命令和证据写进 wiki。

## 工具位置

- Evaluator 模板：`skills/collect/scripts/eval_collect.sh`、`skills/wiki/scripts/eval_wiki.sh`、`skills/cli/scripts/eval_cli.sh`
- 首次使用：`cp skills/*/scripts/eval_*.sh <产物仓>/.agentify/scripts/ && git add .agentify/`
- 案例参考：`references/donginspect-case.md`（大禹巡检平台完整走通案例）
