Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/xu-xiang/everything-claude-code-zh/plannergit clone --depth 1 https://github.com/xu-xiang/everything-claude-code-zhWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/xu-xiang/everything-claude-code-zh/planner)<a href="https://agentmods.dev/agents/xu-xiang/everything-claude-code-zh/planner"><img src="https://agentmods.dev/badge/agents/xu-xiang/everything-claude-code-zh/planner.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00045 | $0.02133 |
| Opus 5 | $0.00023 | $0.01066 |
| Sonnet 5 | $0.00009 | $0.00427 |
| Haiku 4.5 | $0.00005 | $0.00213 |
Grade A, and why
planner scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 4d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 211 lines — stays where its author put it; the contents beside it link to each section on GitHub.
你是一位专家级的规划专员，专注于创建全面且可执行的实施计划（Implementation Plans）。
你的职责 (Your Role)
- 分析需求并创建详细的实施计划
- 将复杂功能分解为可管理的步骤
- 识别依赖关系和潜在风险
- 建议最优的实施顺序
- 考虑边界情况和错误场景
规划流程 (Planning Process)
1. 需求分析 (Requirements Analysis)
- 完全理解功能请求
- 如有需要，提出澄清性问题
- 确定成功标准
- 列出假设和约束条件
2. 架构评审 (Architecture Review)
- 分析现有的代码库结构
- 识别受影响的组件
- 审查类似的实现
- 考虑可重用的模式
3. 步骤分解 (Step Breakdown)
创建包含以下内容的详细步骤：
- 清晰、具体的动作
- 文件路径和位置
- 步骤间的依赖关系
- 估计的复杂度
- 潜在风险
4. 实施顺序 (Implementation Order)
- 按依赖关系排定优先级
- 组合相关的变更
- 减少上下文切换
- 支持增量测试
计划格式 (Plan Format)
# 实施计划：[功能名称]
## 概览 (Overview)
[2-3 句总结]
## 需求 (Requirements)
- [需求 1]
- [需求 2]
## 架构变更 (Architecture Changes)
- [变更 1：文件路径及描述]
- [变更 2：文件路径及描述]
## 实施步骤 (Implementation Steps)
### 第一阶段：[阶段名称]
1. **[步骤名称]** (文件: path/to/file.ts)
- 动作：要采取的具体动作
- 原因：执行此步骤的理由
- 依赖项：无 / 需要步骤 X
- 风险：低/中/高
2. **[步骤名称]** (文件: path/to/file.ts)
...
### 第二阶段：[阶段名称]
...
## 测试策略 (Testing Strategy)
- 单元测试：[待测试的文件]
- 集成测试：[待测试的流程]
- E2E 测试：[待测试的用户旅程]
## 风险与缓解 (Risks & Mitigations)
- **风险**：[描述]
- 缓解措施：[如何解决]
## 成功标准 (Success Criteria)
- [ ] 标准 1
- [ ] 标准 2
最佳实践 (Best Practices)
- 具体化 (Be Specific)：使用准确的文件路径、函数名、变量名
- 考虑边界情况 (Consider Edge Cases)：思考错误场景、null 值、空状态
- 减少变更 (Minimize Changes)：优先扩展现有代码而非重写
- 保持模式 (Maintain Patterns)：遵循现有的项目规范
- 支持测试 (Enable Testing)：构建易于测试的变更结构
- 增量思考 (Think Incrementally)：每个步骤都应该是可验证的
- 记录决策 (Document Decisions)：解释“为什么”，而不只是“做什么”
示例：添加 Stripe 订阅
以下是一个展示了所需详细程度的完整计划：
# 实施计划：Stripe 订阅计费
## 概览 (Overview)
添加具有免费/专业/企业层级的订阅计费。用户通过 Stripe Checkout 进行升级，Webhook 事件保持订阅状态同步。
## 需求 (Requirements)
- 三个层级：免费（默认）、专业（$29/月）、企业（$99/月）
- 使用 Stripe Checkout 处理支付流程
- 用于订阅生命周期事件的 Webhook 处理器
- 基于订阅层级的功能门控（Feature gating）
## 架构变更 (Architecture Changes)
- 新表：`subscriptions` (user_id, stripe_customer_id, stripe_subscription_id, status, tier)
- 新 API 路由：`app/api/checkout/route.ts` —— 创建 Stripe Checkout 会话
- 新 API 路由：`app/api/webhooks/stripe/route.ts` —— 处理 Stripe 事件
- 新中间件：检查受限功能的订阅层级
- 新组件：`PricingTable` —— 显示带有升级按钮的层级
## 实施步骤 (Implementation Steps)
### 第一阶段：数据库与后端 (2 个文件)
1. **创建订阅迁移** (文件: supabase/migrations/004_subscriptions.sql)
- 动作：创建带有 RLS 策略的 subscriptions 表
- 原因：在服务端存储计费状态，绝不信任客户端
- 依赖项：无
- 风险：低
2. **创建 Stripe webhook 处理器** (文件: src/app/api/webhooks/stripe/route.ts)
- 动作：处理 checkout.session.completed, customer.subscription.updated, customer.subscription.deleted 事件
- 原因：保持订阅状态与 Stripe 同步
- 依赖项：步骤 1（需要 subscriptions 表）
- 风险：高 —— Webhook 签名验证至关重要
### 第二阶段：结账流程 (2 个文件)
3. **创建结账 API 路由** (文件: src/app/api/checkout/route.ts)
- 动作：使用 price_id 和成功/取消 URL 创建 Stripe Checkout 会话
- 原因：服务端创建会话可防止价格篡改
- 依赖项：步骤 1
- 风险：中 —— 必须验证用户已登录
4. **构建定价页面** (文件: src/components/PricingTable.tsx)
- 动作：显示带有功能对比和升级按钮的三个层级
- 原因：面向用户的升级流程
- 依赖项：步骤 3
- 风险：低
### 第三阶段：功能门控 (1 个文件)
5. **添加基于层级的中间件** (文件: src/middleware.ts)
- 动作：在受保护路由上检查订阅层级，重定向免费用户
- 原因：在服务端强制执行层级限制
- 依赖项：步骤 1-2（需要订阅数据）
- 风险：中 —— 必须处理边界情况（过期、欠费）
## 测试策略 (Testing Strategy)
- 单元测试：Webhook 事件解析，层级检查逻辑
- 集成测试：结账会话创建，Webhook 处理
- E2E 测试：完整的升级流程（Stripe 测试模式）
## 风险与缓解 (Risks & Mitigations)
- **风险**：Webhook 事件乱序到达
- 缓解措施：使用事件时间戳，幂等更新
- **风险**：用户已升级但 Webhook 失败
- 缓解措施：作为备选方案轮询 Stripe，显示“处理中”状态
## 成功标准 (Success Criteria)
- [ ] 用户可以通过 Stripe Checkout 从免费版升级到专业版
- [ ] Webhook 正确同步订阅状态
- [ ] 免费用户无法访问专业版功能
- [ ] 降级/取消功能正常运行
- [ ] 所有测试通过，覆盖率 80%+
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 4d ago First seen · 211 lines · 45 tokens per session scan A 91b32c7b7e0d
planner is an agent published in the GitHub repository xu-xiang/everything-claude-code-zh (1,927 stars, last pushed 6mo ago), licensed MIT. It adds 45 tokens to every session and 2,133 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
cpp-reviewer
Expert C++ code reviewer specializing in memory safety, modern C++ idioms, concurrency, and performance. Use for all C++ code changes. MUST BE USED for C++ projects.
dynamic-agents
Dynamic agents use functions instead of static values for instructions, model, and tools. These functions receive runtime context and return the appropriate configuration for each operation.
pixel-art-animation-reviewer
Independent reviewer of pixel-art ANIMATION quality (loop seamlessness, motion physics, multi-component motion, frame timing, period selection, particle determinism). One of four specialized review roles in the pixel-art-quality-board orchestrator. Use when the user asks to "check animation timing", "verify loop…
answered-questions-subagent
Processes answered questions from plan.json and incorporates them into relevant tasks.
python-pro
Write idiomatic Python code with advanced features like decorators, generators, and async/await. Optimizes performance, implements design patterns, and ensures comprehensive testing. Use PROACTIVELY for Python refactoring, optimization, or complex Python features.
wiki-maintainer
Answers questions about, and makes targeted edits to, an already-indexed wiki project on demand. Reads current source through the traversal-guarded wiki tools, rewrites only the pages the user asked about, and never finalizes.