@baimingtao/lbs-agent 1.0.0

package/extensions/skills/optional/software-development/subagent-driven-development/SKILL.md

@@ -0,0 +1,352 @@
+---
+name: subagent-driven-development
+description: "通过 delegate_task subagent 执行计划（两阶段审查）。"
+version: 1.1.0
+author: Hermes Agent (adapted from obra/superpowers)
+license: MIT
+platforms: [linux, macos, windows]
+metadata:
+  hermes:
+    tags: [delegation, subagent, implementation, workflow, parallel]
+    related_skills: [plan, requesting-code-review, test-driven-development]
+---
+
+# Subagent-Driven 开发
+
+## 概览
+
+通过为每个任务分配全新的 subagent 并配合系统化的两阶段审查来执行实施计划。
+
+**核心原则：** 每个任务分配全新的 subagent + 两阶段审查（先规范后质量）= 高质量、快速迭代。
+
+## 何时使用
+
+在以下情况使用此 skill：
+- 你有一份实施计划（来自 `plan` skill 或用户需求）
+- 任务之间基本相互独立
+- 质量和规范合规性很重要
+- 你希望在任务之间进行自动化审查
+
+**对比手动执行：**
+- 每个任务都有全新的上下文（不会因状态累积而产生混淆）
+- 自动化审查过程能尽早发现问题
+- 对所有任务进行一致的质量检查
+- Subagent 可以在开始工作前提出问题
+
+## 流程
+
+### 1. 读取并解析计划
+
+读取计划文件。预先提取所有任务及其完整文本和上下文。创建一个待办列表：
+
+```python
+# Read the plan
+read_file("docs/plans/feature-plan.md")
+
+# Create todo list with all tasks
+todo([
+    {"id": "task-1", "content": "Create User model with email field", "status": "pending"},
+    {"id": "task-2", "content": "Add password hashing utility", "status": "pending"},
+    {"id": "task-3", "content": "Create login endpoint", "status": "pending"},
+])
+```
+
+**关键点：** 只读取计划一次。提取所有内容。不要让 subagent 去读取计划文件——直接在上下文中提供完整的任务文本。
+
+### 2. 每个任务的工作流
+
+对于计划中的每一个任务：
+
+#### Step 1: 分配实施 Subagent
+
+使用 `delegate_task` 并提供完整的上下文：
+
+```python
+delegate_task(
+    goal="Implement Task 1: Create User model with email and password_hash fields",
+    context="""
+    TASK FROM PLAN:
+    - Create: src/models/user.py
+    - Add User class with email (str) and password_hash (str) fields
+    - Use bcrypt for password hashing
+    - Include __repr__ for debugging
+
+    FOLLOW TDD:
+    1. Write failing test in tests/models/test_user.py
+    2. Run: pytest tests/models/test_user.py -v (verify FAIL)
+    3. Write minimal implementation
+    4. Run: pytest tests/models/test_user.py -v (verify PASS)
+    5. Run: pytest tests/ -q (verify no regressions)
+    6. Commit: git add -A && git commit -m "feat: add User model with password hashing"
+
+    PROJECT CONTEXT:
+    - Python 3.11, Flask app in src/app.py
+    - Existing models in src/models/
+    - Tests use pytest, run from project root
+    - bcrypt already in requirements.txt
+    """,
+    toolsets=['terminal', 'file']
+)
+```
+
+#### Step 2: 分配规范合规审查员
+
+实施者完成后，对照原始规范进行验证：
+
+```python
+delegate_task(
+    goal="Review if implementation matches the spec from the plan",
+    context="""
+    ORIGINAL TASK SPEC:
+    - Create src/models/user.py with User class
+    - Fields: email (str), password_hash (str)
+    - Use bcrypt for password hashing
+    - Include __repr__
+
+    CHECK:
+    - [ ] All requirements from spec implemented?
+    - [ ] File paths match spec?
+    - [ ] Function signatures match spec?
+    - [ ] Behavior matches expected?
+    - [ ] Nothing extra added (no scope creep)?
+
+    OUTPUT: PASS or list of specific spec gaps to fix.
+    """,
+    toolsets=['file']
+)
+```
+
+**如果发现规范问题：** 修复差距，然后重新运行规范审查。只有在符合规范后才继续。
+
+#### Step 3: 分配代码质量审查员
+
+规范合规性通过后：
+
+```python
+delegate_task(
+    goal="Review code quality for Task 1 implementation",
+    context="""
+    FILES TO REVIEW:
+    - src/models/user.py
+    - tests/models/test_user.py
+
+    CHECK:
+    - [ ] Follows project conventions and style?
+    - [ ] Proper error handling?
+    - [ ] Clear variable/function names?
+    - [ ] Adequate test coverage?
+    - [ ] No obvious bugs or missed edge cases?
+    - [ ] No security issues?
+
+    OUTPUT FORMAT:
+    - Critical Issues: [must fix before proceeding]
+    - Important Issues: [should fix]
+    - Minor Issues: [optional]
+    - Verdict: APPROVED or REQUEST_CHANGES
+    """,
+    toolsets=['file']
+)
+```
+
+**如果发现质量问题：** 修复问题，重新审查。只有在获得批准后才继续。
+
+#### Step 4: 标记完成
+
+```python
+todo([{"id": "task-1", "content": "Create User model with email field", "status": "completed"}], merge=True)
+```
+
+### 3. 最终审查
+
+所有任务完成后，分配最终的集成审查员：
+
+```python
+delegate_task(
+    goal="Review the entire implementation for consistency and integration issues",
+    context="""
+    All tasks from the plan are complete. Review the full implementation:
+    - Do all components work together?
+    - Any inconsistencies between tasks?
+    - All tests passing?
+    - Ready for merge?
+    """,
+    toolsets=['terminal', 'file']
+)
+```
+
+### 4. 验证并提交
+
+```bash
+# Run full test suite
+pytest tests/ -q
+
+# Review all changes
+git diff --stat
+
+# Final commit if needed
+git add -A && git commit -m "feat: complete [feature name] implementation"
+```
+
+## 任务粒度
+
+**每个任务 = 2-5 分钟的专注工作。**
+
+**太大：**
+- “实现用户身份验证系统”
+
+**合适的大小：**
+- “创建带有 email 和 password 字段的 User model”
+- “添加密码哈希函数”
+- “创建登录端点”
+- “添加 JWT token 生成”
+- “创建注册端点”
+
+## 危险信号——绝对不要这样做
+
+- 没有计划就开始实施
+- 跳过审查（规范合规性或代码质量）
+- 带着未修复的严重/重要问题继续推进
+- 为涉及相同文件的任务分配多个实施 subagent
+- 让 subagent 读取计划文件（改为在上下文中提供完整文本）
+- 跳过场景设置的上下文（subagent 需要了解任务所处的位置）
+- 忽略 subagent 的问题（在让它们继续之前回答问题）
+- 在规范合规性上接受“差不多就行”
+- 跳过审查循环（审查员发现问题 → 实施者修复 → 再次审查）
+- 让实施者自我审查取代实际审查（两者都需要）
+- **在规范合规性通过之前开始代码质量审查**（顺序错误）
+- 在任何一个审查还有未决问题时进入下一个任务
+
+## 处理问题
+
+### 如果 Subagent 提出问题
+
+- 清晰完整地回答
+- 如有必要，提供额外的上下文
+- 不要催促它们开始实施
+
+### 如果审查员发现问题
+
+- 实施 subagent（或新的 subagent）进行修复
+- 审查员再次审查
+- 重复直到获得批准
+- 不要跳过重新审查
+
+### 如果 Subagent 任务失败
+
+- 分配一个新的修复 subagent，并针对出错的地方提供具体指令
+- 不要在控制器会话中尝试手动修复（会导致上下文污染）
+
+## 效率说明
+
+**为什么每个任务都要分配全新的 subagent：**
+- 防止累积状态造成上下文污染
+- 每个 subagent 都能获得干净、专注的上下文
+- 避免受到先前任务代码或推理的干扰
+
+**为什么采用两阶段审查：**
+- 规范审查能及早发现构建不足或过度构建的问题
+- 质量审查确保实现构建良好
+- 在问题随着任务复合增加之前发现它们
+
+**成本权衡：**
+- 更多的 subagent 调用次数（每个任务需要实施者 + 2 名审查员）
+- 但能尽早发现问题（比后期调试复合问题成本更低）
+
+## 与其他 Skill 集成
+
+### 与 plan 一起使用
+
+这个 skill 用于执行由 `plan` skill 创建的计划：
+1. 用户需求 → plan → 实施计划
+2. 实施计划 → subagent-driven-development → 可运行的代码
+
+### 与 test-driven-development 一起使用
+
+实施 subagent 应遵循 TDD：
+1. 先编写失败的测试
+2. 实现最少的代码
+3. 验证测试通过
+4. 提交
+
+在每个实施者的上下文中包含 TDD 指令。
+
+### 与 requesting-code-review 一起使用
+
+两阶段审查流程本身就是代码审查。对于最终的集成审查，请使用 requesting-code-review skill 的审查维度。
+
+### 与 systematic-debugging 一起使用
+
+如果 subagent 在实施过程中遇到 bug：
+1. 遵循 systematic-debugging 流程
+2. 在修复之前找到根本原因
+3. 编写回归测试
+4. 恢复实施
+
+## 示例工作流
+
+```
+[Read plan: docs/plans/auth-feature.md]
+[Create todo list with 5 tasks]
+
+--- Task 1: Create User model ---
+[Dispatch implementer subagent]
+  Implementer: "Should email be unique?"
+  You: "Yes, email must be unique"
+  Implementer: Implemented, 3/3 tests passing, committed.
+
+[Dispatch spec reviewer]
+  Spec reviewer: ✅ PASS — all requirements met
+
+[Dispatch quality reviewer]
+  Quality reviewer: ✅ APPROVED — clean code, good tests
+
+[Mark Task 1 complete]
+
+--- Task 2: Password hashing ---
+[Dispatch implementer subagent]
+  Implementer: No questions, implemented, 5/5 tests passing.
+
+[Dispatch spec reviewer]
+  Spec reviewer: ❌ Missing: password strength validation (spec says "min 8 chars")
+
+[Implementer fixes]
+  Implementer: Added validation, 7/7 tests passing.
+
+[Dispatch spec reviewer again]
+  Spec reviewer: ✅ PASS
+
+[Dispatch quality reviewer]
+  Quality reviewer: Important: Magic number 8, extract to constant
+  Implementer: Extracted MIN_PASSWORD_LENGTH constant
+  Quality reviewer: ✅ APPROVED
+
+[Mark Task 2 complete]
+
+... (continue for all tasks)
+
+[After all tasks: dispatch final integration reviewer]
+[Run full test suite: all passing]
+[Done!]
+```
+
+## 记住
+
+```
+Fresh subagent per task
+Two-stage review every time
+Spec compliance FIRST
+Code quality SECOND
+Never skip reviews
+Catch issues early
+```
+
+**质量绝非偶然。它是系统化流程的结果。**
+
+## 延伸阅读（在相关时加载）
+
+当编排涉及显著的上下文消耗、漫长的审查循环或复杂的验证检查点时，请加载这些针对特定原则的参考文档：
+
+- **`references/context-budget-discipline.md`** —— 四级上下文降级模型（PEAK / GOOD / DEGRADING / POOR）、随上下文窗口大小缩放的读取深度规则，以及静默降级的早期警告信号。在运行明确会消耗大量上下文时（多阶段计划、大量 subagent、庞大制品）加载。
+- **`references/gates-taxonomy.md`** —— 四种标准关卡类型（Pre-flight, Revision, Escalation, Abort）及其行为、恢复和示例。在设计或审查任何带有验证检查点的工作流时加载——明确使用这些词汇，以便每个关卡都有明确的进入条件、失败行为和恢复规则。
+
+以上参考资料均改编自 gsd-build/get-shit-done (MIT © 2025 Lex Christopherson)。

package/extensions/skills/optional/software-development/subagent-driven-development/references/context-budget-discipline.md

@@ -0,0 +1,53 @@
+# Context Budget Discipline
+
+在生成 subagent 或读取大型 artifact 时，保持 orchestrator context 精简的实用规则。当你运行会消耗大量 context 的多步骤 agent 循环（如计划执行、subagent 编排、审查流水线、多文件重构）时，请遵循这些规则。
+
+改编自 GSD (Get Shit Done) 项目的 context-budget 参考文档 —— MIT © 2025 Lex Christopherson ([gsd-build/get-shit-done](https://github.com/gsd-build/get-shit-done))。
+
+## Universal rules
+
+每个生成 agent 或读取大量内容的工作流都必须遵循以下规则：
+
+1. **绝对不要读取 agent 定义文件。** `delegate_task` 会自动加载它们 —— 如果你再次读取，只会让成本翻倍。
+2. **绝对不要将大型文件内联到 subagent 提示词中。** 相反，应使用 `read_file` 让 agent 从磁盘读取文件。subagent 能获取完整内容；而你的 context 保持精简。
+3. **读取深度随 context 窗口缩放。** 参见下表。
+4. **将繁重的工作委托给 subagent。** orchestrator 负责路由；它不执行操作。
+5. **主动警告** 用户你已消耗了大量 context（“Context 正在变得沉重 —— 建议在继续之前对进度进行 checkpoint”）。
+
+## Read depth by context window
+
+检查模型的实际 context 窗口（不要默认“因为是 Claude 所以是 200K”）。某些 Sonnet 部署版本是 1M，有些是 200K。如果你不确定，请假定较小的值 —— 保持精简。
+
+| Context 窗口 | Subagent 输出读取 | 摘要文件 | 验证文件 | 其他阶段的计划 |
+| ---------------- | ------------------------- | --------------- | -------------------- | ----------------------- |
+| < 500k (例如 200k) | 仅 frontmatter | 仅 frontmatter | 仅 frontmatter | 仅当前阶段 |
+| >= 500k (1M 模型) | 允许读取完整正文 | 允许读取完整正文 | 允许读取完整正文 | 仅当前阶段 |
+
+“仅 frontmatter”意味着：只需读取足够的内容以查看最终状态/结论/判定。如果 subagent 写了一份 3000 行的调试日志，请读取它生成的摘要部分，而不是日志本身。
+
+## Four-tier degradation model
+
+监控你的 context 使用情况，并随着你攀升层级而调整行为。关键在于在碰壁*之前*察觉，而不是在响应开始截断时。
+
+| 层级 | 使用量 | 行为 |
+| ------ | ------- | ---------- |
+| **PEAK** | 0 – 30% | 完全操作。读取正文，并行生成多个 agent，自由内联结果。 |
+| **GOOD** | 30 – 50% | 正常操作。优先读取 frontmatter。积极进行委托。 |
+| **DEGRADING** | 50 – 70% | 节省使用。仅读取 frontmatter，尽量减少内联，向用户**发出警告** budget 情况。 |
+| **POOR** | 70%+ | 紧急模式。**立即对进度进行 checkpoint。** 除非关键，否则不读取新内容。完成当前任务并干净地停止。 |
+
+## Early warning signs (before panic thresholds fire)
+
+在达到硬性限制之前，质量会*逐渐*下降。请注意以下情况：
+
+- **静默的部分完成。** subagent 声称已完成，但实现并不完整。自检只能捕获文件是否存在，而非语义上的完整性。始终根据计划中的“必备项”验证 subagent 的输出，而不仅仅是检查“文件是否出现？”。
+- **越发含糊。** agent 开始使用诸如“适当的处理”或“标准模式”等短语，而不是具体的代码。这是在 budget 警告触发之前 context 压力的表现。
+- **跳过协议步骤。** agent 省略了它通常会遵循的步骤。如果成功标准有 8 项，而报告只涵盖了 5 项，请怀疑是 context 压力，而不是“agent 认为 5 项就够了”。
+
+当出现这些迹象时，请对工作进行 checkpoint，并重置 context 或将其移交给一个新的 subagent。
+
+## Fundamental limitation
+
+当你进行编排时，你无法验证 subagent 输出的语义正确性 —— 只能验证结构完整性（“文件是否出现？”、“测试是否通过？”）。语义验证需要你自己运行代码，或者将审查过程委托给另一个全新的 subagent。
+
+**缓解措施：** 在你委托的每个任务中，包含明确的“必备”事实，要求 subagent 在其响应中确认（例如，“确认你的测试实际上测试了 X，而不仅仅是导入了 X”）。subagent 重申具体事实是证据，而含糊的摘要则不是。

package/extensions/skills/optional/software-development/subagent-driven-development/references/gates-taxonomy.md

@@ -0,0 +1,93 @@
+# Gates 分类体系
+
+适用于任何包含生成 subagent、执行 review 循环或人工审批暂停的 workflow 中，用于验证 checkpoint 的标准 gate 类型。每个验证 checkpoint 都会映射到这四种类型之一——明确命名它们可以使 workflow 清晰易懂，并避免产生“如果这个检查失败了该怎么办？”的困惑。
+
+改编自 GSD (Get Shit Done) 项目的 gates 参考文档 — MIT © 2025 Lex Christopherson ([gsd-build/get-shit-done](https://github.com/gsd-build/get-shit-done))。
+
+## 四种 gate 类型
+
+### 1. Pre-flight gate
+
+**目的：** 在开始操作之前验证 preconditions。
+
+**行为：** 如果条件不满足则阻止进入。不会产生任何部分完成的工作——在任何改变发生之前退出。
+
+**恢复：** 修复缺失的 precondition，然后重试。
+
+**示例：**
+- 实现阶段在开始编写代码之前检查 plan 文件是否存在。
+- 被委派的 subagent 在发起 API 调用之前检查所需的 env vars 是否已设置。
+- 提交代码时在 push 之前检查测试是否通过。
+
+### 2. Revision gate
+
+**目的：** 评估输出质量，如果未达标则路由至 revision。
+
+**行为：** 携带具体反馈返回给生产者。受限于 iteration cap（通常为 3）。
+
+**恢复：** 生产者处理反馈；检查者重新评估。如果连续迭代之间的问题数量没有减少（停滞检测），循环会提前升级。达到最大迭代次数后，无条件升级给用户——永远不会无限循环。
+
+**示例：**
+- Plan 审查者阅读草稿 plan，返回具体问题，规划者进行修订，审查者再次阅读（最多 3 个循环）。
+- 代码审查者根据 must-haves 检查 subagent 生成的代码；如果任何 must-have 未通过，则将修复任务派发回给实现者。
+- 测试覆盖率检查者验证新测试是否覆盖了新路径；如果没有，则退回给作者。
+
+### 3. Escalation gate
+
+**目的：** 将无法解决的问题提交给人类决策。
+
+**行为：** 暂停 workflow，提供选项，并等待人类输入。绝不猜测，也绝不挑选默认值。
+
+**恢复：** 人类选择操作；workflow 沿着选定的路径继续执行。
+
+**示例：**
+- 3 次迭代后 Revision 循环耗尽。
+- 自动化 worktree 清理期间发生合并冲突。
+- 模糊的需求——存在两种合理的解释，且选择不同会改变处理方式。
+- Subagent 报告“plan 上说 X，但 codebase 实际上做的是 Y”——由人类决定哪一个是正确的。
+
+### 4. Abort gate
+
+**目的：** 终止操作以防止损害或浪费。
+
+**行为：** 立即停止，保留状态（对当前进度进行 checkpoint），报告具体原因。
+
+**恢复：** 人类调查根本原因，进行修复，然后从 checkpoint 重启。
+
+**示例：**
+- 执行期间 context window 严重不足（POOR 级别，>70%）——干净地中止，而不是产生被截断的输出。
+- 运行期间关键依赖不可用（网络断开，API key 被吊销）。
+- 不可恢复的 filesystem 状态（磁盘已满，权限丢失）。
+- 违反安全不变量（agent 试图在批准范围之外执行不可逆的破坏性操作）。
+
+## 如何在 skill 中使用
+
+当你编写包含验证 checkpoint 的编排 skill 时，**显式地通过 gate 类型来命名每个 checkpoint**，并回答三个问题：
+
+1. **什么条件触发了这个 gate？**（例如，“缺少 plan 文件”，“问题数量没有减少”，“context >70%”）
+2. **失败时会发生什么？**（阻止 / 循环返回 / 询问人类 / 中止）
+3. **谁负责恢复，从哪里恢复？**（修复 precondition + 重试，修订 + 重新检查，人类决策，从 checkpoint 重启）
+
+预先回答这三个问题意味着你的 skill 在运行时永远不会遇到“现在该怎么办？”的情况。
+
+## 示例 — 包含全部四种 gate 类型的 review 循环
+
+```
+[Pre-flight] plan.md exists and is non-empty?   → no: bail, ask user to write a plan first
+                ↓ yes
+[Execute]  subagent implements task
+                ↓
+[Revision] reviewer checks against must-haves  → fail: loop back to subagent (max 3)
+                ↓ pass
+[Pre-flight] tests pass?                       → no: bail, report failing tests
+                ↓ yes
+[Commit]
+                ↓
+(on revision loop exhaustion)
+[Escalation] "3 review cycles failed to converge on issue X — pick: force-merge, rewrite task, abandon"
+                ↓ user picks
+(on any tier-POOR context pressure during loop)
+[Abort] "context at 73%, checkpointing and stopping"
+```
+
+这套词汇表是故意保持得很小的。每个 workflow 中的每个 gate 都应该归入这四种类型之一。如果你发现自己发明了第五种，它很可能是一个带有额外分支的 revision gate，或者是一个伪装的 escalation gate。

package/extensions/skills/optional/web-development/DESCRIPTION.md

@@ -0,0 +1,5 @@
+# Web 开发
+
+面向客户端 Web 开发工作流的可选技能——将 agents、copilots 和 AI 原生的 UX 模式嵌入到面向用户的 Web 应用中。
+
+这与 Hermes 自身的浏览器自动化（Browserbase、Camofox）不同，后者是从外部对网站进行操作。此处的 Web 开发技能旨在帮助用户将功能构建*到*他们自己的网站中。

package/extensions/skills/optional/web-development/cloudflare-temporary-deploy/SKILL.md

@@ -0,0 +1,127 @@
+---
+name: cloudflare-temporary-deploy
+description: 通过 wrangler --temporary 部署实时 Worker，无需账号。
+version: 1.0.0
+author: Hermes Agent
+license: MIT
+platforms: [linux, macos, windows]
+metadata:
+  hermes:
+    tags: [cloudflare, workers, wrangler, deploy, temporary, agent, serverless, web-development]
+    category: web-development
+---
+
+# Cloudflare Temporary Deploy 技能
+
+使用 `wrangler deploy --temporary` 将 Cloudflare Worker 部署到实时的 `workers.dev` URL，完全不需要进行账号配置。Cloudflare 会分配一个临时账号，执行部署，并打印出一个有效期为 60 分钟的认领 URL；未被认领的账号会自动删除。这为 agent 提供了一个紧凑的 编写 → 部署 → 验证 循环，无需进行任何 OAuth、注册或 Token 复制粘贴。
+
+本技能**不**涵盖生产环境部署（请使用 `wrangler login` + 永久账号），也**不**涉及超出下文临时账号限制的其他非 Worker Cloudflare 产品。
+
+## 何时使用
+
+当用户想要实现以下需求时，请加载此技能：
+
+- **将 agent 编写的代码发布到实时 URL**，而无需先创建 Cloudflare 账号 —— “部署这段代码并给我一个链接”
+- **在后台/自动化会话中进行迭代**，在这种场景下，浏览器 OAuth 步骤会造成硬性阻碍
+- **使用一次性的、可认领的目标快速构建原型或评估 Workers**
+- **建立自验证的部署循环** —— 部署、`curl` 实时 URL、确认输出与代码匹配、重新部署
+
+## 何时不使用
+
+- **生产环境或 CI/CD** → 使用永久账号（`wrangler login` 或 `CLOUDFLARE_API_TOKEN`）。如果存在任何凭证，`--temporary` 会报错。
+- **Wrangler 已通过身份验证** → `--temporary` 会在机制上返回错误。只有在用户明确希望进行一次性部署时，才先运行 `wrangler logout`。
+- **长期托管** → 除非被认领，否则临时部署将在 60 分钟后被删除。
+
+## 前置条件
+
+- **Wrangler 4.102.0 或更高版本。** 这是引入 `--temporary` 的版本。早期版本没有此功能。请通过 `npx wrangler@latest --version` 进行验证。
+- **Node 18+ / npm**（或 `npx`、`yarn`、`pnpm`）。无需全局安装 —— `npx wrangler@latest` 即可正常运行。
+- **不存在任何 Cloudflare 凭证。** `--temporary` 仅在 Wrangler 未通过身份验证时有效：没有 OAuth 登录，没有 `CLOUDFLARE_API_TOKEN` / `CLOUDFLARE_API_KEY` 环境变量，没有 `~/.wrangler` / `~/.config/.wrangler` 缓存的 OAuth。按原样使用 `terminal` 工具的环境；不要设置这些变量。
+- 网络可连接至 `cloudflare.com` 和 `workers.dev`。
+- 使用 `--temporary` 即表示接受 Cloudflare 的服务条款和隐私政策。
+
+## 如何运行
+
+每一步都使用 `terminal` 工具。务必锁定版本（`wrangler@latest` 或 `wrangler@4.102.0` 或更高版本），以免意外运行缺少该标志的旧版全局 wrangler。
+
+1. **构建最小化的 Worker**（如果项目已存在则跳过）。一个 Worker 需要一个 `wrangler.toml`（或 `wrangler.jsonc`）和一个入口脚本。最小化的 TypeScript 示例 —— 使用 `write_file` 写入以下文件：
+
+   `wrangler.jsonc`:
+   ```jsonc
+   {
+     "name": "hello-agent",
+     "main": "src/index.ts",
+     "compatibility_date": "2025-01-01"
+   }
+   ```
+
+   `src/index.ts`:
+   ```typescript
+   export default {
+     async fetch(): Promise<Response> {
+       return new Response("hello cloudflare");
+     },
+   };
+   ```
+
+2. 在项目目录下**使用 `--temporary` 进行部署**：
+   ```
+   npx wrangler@latest deploy --temporary
+   ```
+   工作量证明检查会增加较短的自动延迟。成功后，Wrangler 会打印出 `Account: <name> (created)`（或 `(reused)`）行、一个 `Claim URL` 以及实时的 `https://<worker>.<account>.workers.dev` URL。
+
+3. 从该输出中**解析 URL**。运行辅助脚本以可靠地提取它们，而不是凭肉眼查看：
+   ```
+   npx wrangler@latest deploy --temporary 2>&1 | python3 scripts/parse_deploy_output.py
+   ```
+   （将 `scripts/parse_deploy_output.py` 解析为该技能的绝对路径。）它会输出 JSON：`{"live_url", "claim_url", "account", "account_state", "expires_minutes", "deployed"}`。
+
+4. **验证部署是否真正上线** —— 不要仅相信部署日志。对实时 URL 执行 `curl` 并确认正文与代码返回的内容匹配：
+   ```
+   curl -sS <live_url>
+   ```
+
+5. **迭代。** 编辑代码，使用相同的 `npx wrangler@latest deploy --temporary` 重新部署。在 60 分钟的时间窗口内，Wrangler 会复用缓存的临时账号（`Account: <name> (reused)`），因此 URL 会保持稳定。再次执行 `curl` 以确认更改。
+
+6. **将认领 URL 交给用户。** 告知他们：在 60 分钟内打开它即可保留部署及相关资源；如果他们不认领，所有内容将自动删除。请将认领 URL 视为机密 —— 它拥有该账号的所有权。
+
+## 快速参考
+
+| 步骤 | 命令 |
+| --- | --- |
+| 检查版本 (需要 4.102.0+) | `npx wrangler@latest --version` |
+| 部署 (无账号) | `npx wrangler@latest deploy --temporary` |
+| 部署 + 解析 URL | `npx wrangler@latest deploy --temporary 2>&1 \ | python3 scripts/parse_deploy_output.py` |
+| 验证实时状态 | `curl -sS <live_url>` |
+| 清除缓存的临时账号 | `npx wrangler@latest logout` |
+
+### 临时账号产品限制
+
+| 产品 | 临时账号限制 |
+| --- | --- |
+| Workers | 部署至 `workers.dev` |
+| Static Assets | 最多 1,000 个文件，每个 5 MiB |
+| KV | 允许 |
+| D1 | 1 个数据库，每个 100 MB / 总计 100 MB |
+| Durable Objects | 允许 |
+| Hyperdrive | 2 个配置，10 个连接 |
+| Queues | 最多 10 个 |
+| SSL/TLS 证书 | 允许 |
+
+## 避坑指南
+
+- **`--temporary` 不在 `wrangler deploy --help` 中，且不是全局标志。** 它是刻意隐藏并动态提供的：当未经身份验证的 `wrangler deploy` 失败时，Wrangler 会打印“rerun with `--temporary`”。不要仅仅因为 `--help` 中遗漏了该标志就认为它不存在 —— 请检查版本。
+- **旧版全局 wrangler。** 陈旧的全局安装的 `wrangler` (`< 4.102.0`) 会因机制原因缺少此标志。务必调用 `npx wrangler@latest`（或锁定的 `>=4.102.0`），以便您能控制版本。
+- **存在身份验证 → 硬错误。** 如果曾运行过 `wrangler login`，或者设置了 `CLOUDFLARE_API_TOKEN` / `CLOUDFLARE_API_KEY`，`--temporary` 会报错。请在此 shell 中取消设置该变量，或执行 `wrangler logout`。在未告知用户的情况下，切勿剥离用户的真实凭证。
+- **速率限制。** 过快创建临时账号会失败。在 60 分钟的窗口内，请复用缓存的账号（直接重新部署），而不是强制创建新账号；如果被限制速率，请等待或使用永久账号。
+- **60 分钟硬性过期，无法延长。** 如果部署必须超过一小时，用户必须对其进行认领。请向用户明确指出这一点。
+- **重新部署后，`curl` 可能会短暂提供旧的内容。** `workers.dev` 具有短暂的边缘缓存；`(reused)` 行加上新的 `Current Version ID` 可确认部署成功，即使 `curl` 在几秒钟内显示的是陈旧内容。在断定重新部署失败之前，请重新执行 `curl`，或添加清除缓存的查询字符串。
+- **不要将认领 URL 作为“普通链接”记录到共享记录中。** 它等同于凭证。
+
+## 验证
+
+- `npx wrangler@latest --version` 返回 `>= 4.102.0`。
+- `npx wrangler@latest deploy --temporary` 打印出 `workers.dev` 实时 URL 和 `claim-preview?claimToken=` 认领 URL。
+- `curl -sS <live_url>` 返回 Worker 代码生成的确切正文。
+- 第二次部署会报告 `Account: <name> (reused)` 并且实时 URL 保持不变。
+- 解析器脚本的自检通过：`python3 scripts/parse_deploy_output.py --selftest`。