用途：kitaru-scoping 是 Kitaru 的解决方案架构技能，帮助用户判断工作流是否真正受益于持久化执行，并设计出可被 kitaru-authoring 干净实现的流程架构。它针对四类常见问题：把规划、执行、审批、重试、副作用和报告混成一体的“万能流程”；每个小函数都做成检查点的过度检查点设计；需要流式聊天、亚 100ms 服务或普通脚本的“用错工具”；以及适合 Kitaru 但未确定等待、重放锚点和副作用位置的模糊持久化设计。
主要能力：通过分阶段访谈理解工作流（触发方式、昂贵步骤、人工介入、外部系统、数据流、失败点、运维需求），评估 Kitaru 适配度，设计持久化边界（哪些工作适合做检查点、哪些不适合），选择操作界面（SDK、KitaruClient、CLI、MCP），制定重放策略与稳定检查点命名，给出 PydanticAI 适配建议，检查反模式，定义 2-4 个检查点的 MVP 流程，并输出约 60-120 行的 flow_architecture.md 架构文档。
必要用法：访谈中优先使用结构化提问工具（如 Codex 的 AskUserQuestion 或 request_user_input），没有则在聊天中用简短编号问题。设计需遵守运行时约束：flow 与 checkpoint 均不可嵌套；wait() 只能在 flow 主体中运行；save()/load() 需要检查点作用域；llm() 仅在 @flow 内有效；默认等待超时为 600 秒。重放锚点只能使用检查点选择器，不支持 wait.* 覆盖键。
适用场景：昂贵步骤、需跨进程重启存活的人工审批、多步可重放工作流、运维调试与审计、清晰的副作用边界。
限制：不适合一次性廉价 LLM 调用、流式聊天 UI、低延迟服务、无持久状态的简单脚本和持续监控循环。当前 PydanticAI 适配器不支持延迟工具流程（ApprovalRequired、CallDeferred）。架构文档不应包含实现代码、基础设施细节、时间或成本估算。