efficient-fable
BuilderIO/skills
通过将范围有限的任务委派给成本较低的子代理,来统筹协调涉及大量令牌的研究、编码和测试工作,同时将Claude Fable保留用于架构设计、综合设计和最终审查。
...展开全部高效寓言
将克劳德·法布尔(Claude Fable)用作统筹者、架构师、综合者及最终裁决者。 对于那些标记密集型且无需法布尔全面判断的研究、编码、测试和 摘要生成任务,可使用成本较低的子代理。
Fable 的优势所在
将 Fable 保留用于:
- 将模糊的工作分解为清晰的并行片段。
- 架构、产品及安全方面的权衡取舍。
- 阅读相互矛盾的子代理报告并判断哪些内容重要。
- 将部分实现整合为一个连贯的计划。
- 最终审查、风险评估及面向用户的综合总结。
委托模式
- 为“资源消耗型”风险命名:大型仓库搜索、冗长日志、庞大文档,还是 重复性编辑。
- 在亲自阅读所有内容之前,将独立工作拆分为子代理。
- 使用成本较低的模型进行研究扫描、清点、搜索摘要、针对性 的漏洞排查、浏览器/测试运行、测试输出简化以及范围有限的代码 编辑。
- 要求子代理提供简明证据:文件、行号引用、已执行命令、 差异对比、不确定性以及它们触发的停止条件。
- 将 Fable 代币用于决策层:比较结果、解决冲突、 选择实现路径以及审查最终补丁。
当各切片之间互不依赖时,优先使用并行子代理。将 阻塞性或高度耦合的工作保留在本地处理。
交接数据包
编写委托提示时,应假设子代理没有任何有用的聊天上下文。仅包含 其所需的上下文:
- 仓库路径和确切目标。
- 范围内的文件、包或表面,以及任何明确不在 范围内的内容。
- 要返回的证据格式:文件、行引用、命令、差异、失败、 屏幕截图和不确定性。
- 需执行的验证命令或浏览器操作流程,以及在可判断的情况下, 成功应呈现何种状态。
- 停止条件:如果代码与提示不匹配,或在 合理次数的重试后命令失败,或者任务需要范围外的文件,则应停止并报告 情况,而不是即兴处理。
审核委托工作
将子代理的报告视为线索,而非事实。在采用高影响力的发现、 提交 PR 或告知用户工作已完成之前,Fable 应重新打开 引用的重要文件,确认相关的行引用或失败情况,并根据任务要求 审查最终的差异报告。 让轻量级代理收集信号;将 真相判断权留给 Fable。
常见场景
将这些视为柔性默认方案,而非僵化的规则:
- 研究:让轻量级代理扫描文档、现有技术、API 和代码库表面; 由 Fable 决定哪些证据会改变计划。
- 编码:将范围有限的修改或候选补丁交给成本较低的代理;Fable负责 共享文件的协调、集成和最终审查。
- 测试:让 Fable 建议验证方向以及关键的脚本或 浏览器检查。让轻量级代理运行针对性测试、浏览器 流程、截图和日志精简,然后报告确切的命令、故障、 可能原因,以及故障是偶发、环境因素还是真实问题。
- 调试:使用成本较低的代理对日志进行聚类分析、复现问题并尝试 小范围修复;由 Fable 决定哪种诊断结果最值得信赖。
如果任务非常简单,或者验证本身需要精细的判断,则将其 交由 Fable 处理。
示意图
在 assets/fable-orchestrator.excalidraw 当可视化说明有助于理解时。
主张
对于代码量较大的工作,如果独立的研究、编码或测试 模块可以并行运行,将其描述为成本效率提高3-5倍 且速度提升2-4倍是合理的。请将这些视为取决于工作负载的估计值,而非 保证。
优质的发布文案:
通过使用成本更低的子代理来处理涉及大量令牌的 研究、编码和测试任务,从而提高 Claude Fable 的效率,并将 Fable 保留用于判断、架构、 综合和最终审查。
---
name: efficient-fable
description: Orchestrate token-heavy research, coding, and testing by delegating bounded tasks to cheaper subagents while reserving Claude Fable for architecture, synthesis, and final review.
---
# Efficient Fable
Use Claude Fable as the orchestrator, architect, synthesizer, and final judge.
Use cheaper subagents for token-heavy research, coding, testing, and
summarization that do not require Fable's full judgment.
## Where Fable Shines
Reserve Fable for:
- Decomposing ambiguous work into clean parallel slices.
- Architecture, product, and safety tradeoffs.
- Reading conflicting subagent reports and deciding what matters.
- Integrating partial implementations into one coherent plan.
- Final review, risk assessment, and user-facing synthesis.
## Delegation Pattern
1. Name the expensive-token risk: large repo search, long logs, broad docs, or
repetitive edits.
2. Split independent work into subagents before reading everything yourself.
3. Use cheaper models for research scans, inventory, search summaries, narrow
bug hunts, browser/testing passes, test output reduction, and bounded code
edits.
4. Ask subagents for concise evidence: files, line references, commands run,
diffs, uncertainties, and stop conditions they hit.
5. Spend Fable tokens on the decision layer: compare results, resolve conflicts,
choose the implementation path, and review the final patch.
Prefer parallel subagents when the slices do not depend on each other. Keep
blocking or highly coupled work local.
## Handoff Packets
Write delegated prompts as if the subagent has no useful chat context. Include
only the context it needs:
- The repo path and exact objective.
- The files, packages, or surfaces in scope and anything explicitly out of
scope.
- The evidence format to return: files, line refs, commands, diffs, failures,
screenshots, and uncertainty.
- The verification commands or browser flows to run, plus what success should
look like when that is knowable.
- Stop conditions: if the code does not match the prompt, a command fails after
a reasonable retry, or the task needs out-of-scope files, stop and report
instead of improvising.
## Vetting Delegated Work
Treat subagent reports as leads, not facts. Before using a high-impact finding,
opening a PR, or telling the user the work is done, Fable should reopen the
important cited files, confirm the relevant line refs or failures, and review
the final diff against the task. Let lighter agents gather signal; keep
truth-judgment with Fable.
## Common Scenarios
Treat these as soft defaults, not rigid rules:
- Research: ask lighter agents to scan docs, prior art, APIs, and repo surfaces;
Fable decides what evidence changes the plan.
- Coding: give cheaper agents bounded edits or candidate patches; Fable owns
shared-file coordination, integration, and final review.
- Testing: have Fable suggest the validation direction and the scripts or
browser checks that matter. Let lighter agents run targeted tests, browser
flows, screenshots, and log reduction, then report exact commands, failures,
likely causes, and whether failures look flaky, environmental, or real.
- Debugging: use cheaper agents to cluster logs, reproduce issues, and try
small fixes; Fable decides which diagnosis is most trustworthy.
If a task is tiny or the validation itself needs delicate judgment, keep it
with Fable.
## Diagram
Use `assets/fable-orchestrator.excalidraw` when a visual explanation helps.
## Claims
For codebase-heavy work, it is reasonable to describe this as up to 3-5x more
cost-efficient and 2-4x faster when independent research, coding, or testing
slices can run in parallel. Treat those as workload-dependent estimates, not
guarantees.
Good launch copy:
> Make Claude Fable more efficient by using cheaper subagents for token-heavy
> research, coding, and testing, saving Fable for judgment, architecture,
> synthesis, and final review.





首页
