agentleFS
Xwen0857Xwen0857/agent-orchestrator/planner-core/SKILL.md

planner-core

Skill2 starsChanged 9 months agoMITView on GitHub

负责任务需求建模、拆解与前置分派决策,不负责并发调度循环。

The file

Files
SKILL.md

Planner Core

Agent Identity

planner-core 是专用 planning agent,不是通用 helper 脚本。

  • 它负责规划理解、第一层初次拆分决策、拆分决策、首波释放决策。
  • 它不负责持续运营、轮询、worker/tester 执行、长期心跳控制。
  • 它产出的核心结果是结构化 PlannerDecision 与 SplitPlan,后续脚本只负责应用这些决策。

Decision Priority Ladder

以下优先级是硬规则,不允许实现层随意改变:

  1. planner-managed ingress(入口不再存 mode 字段)
  2. child task internal guardrail
  3. agent-first initial meta decomposition
  4. soft granularity guardrails / fallback
  5. decision apply path

Two-Layer Planning Semantics

  • planner ingress 是隐式且始终由 planner 管理。
  • planner-core 总是执行第一层 Initial Meta Decomposition。
  • 第一层主原则是 functional_decoupling:优先识别功能/职责边界。
  • 第二层 Worker Refinement 是必经阶段,主原则是 engineering_decoupling。
  • 规则系统只做软约束:限制碎片上限与下限,避免过粗或过碎。

Leaf Dependency Model (Current Scope)

  • refinement_partition.leaf_units 必须形成最小可消费链路:
    • module_id/module_title
    • component_candidate
    • depends_on_component_candidates
    • depends_on_leaf_ids
  • 该链路是 planning-time coordination hint,不是完整 DAG 调度系统。
  • 当前允许的语义模式固定为 component_semantic_linearized。
  • 必须 fail-fast 校验:缺失引用、自依赖、未来依赖、组件依赖不一致都直接失败。
  • Planner 不变量唯一规范来源:templates/coordination/orchestrator/planner_invariants.md。
  • Planner 依赖语义与默认值分离:
    • templates/coordination/orchestrator/planner_dependency_semantics.json 负责组件依赖映射。
    • templates/coordination/orchestrator/planner_dependency_defaults.json 负责 mode/note/fallback summary 默认值。
  • split_plan.schema_version = planner-split-plan-v1、dependency_mode = component_semantic_linearized、summary_note = planning_hint_not_scheduler_dag 由契约与配置一致性测试守护,变更时必须同步更新文档与测试。

Planner Projection Boundary

  • orchestrate-planner-projection.ts 负责把 SplitPlan + PlannerDecision 投影成可渲染语义。
  • orchestrate-view-model.ts 仅负责组装 status/run 响应参数,不再承载 planner 语义推导核心逻辑。

Planner Boundary Matrix

  • orchestrate-planner-contract.ts 仅允许 types + re-exports。
  • orchestrate-planner-split-plan-contract.ts 仅允许 normalize/validate/fail-fast/fallback split plan 逻辑。
  • orchestrate-planner-projection.ts 是 planner 语义唯一投影入口。
  • orchestrate-view-model.ts 只做响应参数编排。

业务逻辑独立分层图(Split-plan):

  1. orchestrate-planner-split-plan-schema.ts:schema normalize/migration
  2. orchestrate-planner-split-plan-parse.ts:字段提取与类型收紧
  3. orchestrate-planner-split-plan-validate.ts:不变量与依赖一致性校验
  4. orchestrate-planner-split-plan-summary.ts:依赖摘要与 fallback 构造
  5. orchestrate-planner-split-plan-contract.ts:外部 facade 编排入口

允许依赖方向:

  1. projection -> contract/errors/hints
  2. view-model -> projection/response
  3. response -> dependency-semantics

禁止依赖方向:

  1. view-model -> split-plan-contract
  2. run/status/agent-runtime -> split-plan-contract

变更约束:

  • 新增 split-plan 字段时,必须同步更新 parse + validate + summary 以及对应对账测试。

Dependency Evolution Gate

只有当真实消费者进入实施时,才允许从最小链路升级为复杂 DAG:

  1. scheduler 需要按依赖控制 release/concurrency。
  2. replan 需要按依赖做局部重算。
  3. tester/observer 需要依赖阻塞定位。
  4. UI 需要交互式依赖图。

在未命中上述条件前,不继续扩展 leaf 依赖字段复杂度。

核心职责

  1. 接收并解析 strategy/primary/checklist,生成可执行计划。
  2. 产出 task split plan、child task skeleton、初始 worker 分派信息。
  3. 负责前置状态推进:CREATED -> PLANNED -> ASSIGNED。
  4. 记录计划追溯链(primary/checklist/subchecklist)。

非职责(禁止)

  1. 不负责轮询与并发窗口控制。
  2. 不负责 stale 检测与自动封堵。
  3. 不直接执行 worker/tester 交付动作。

Token Priority Policy

  • planner-core 在 orchestrator agents 中拥有最高 token priority。
  • 规划阶段必须为 planner-core 保留最低可用 token 预算。
  • 同等竞争下,优先保证 planner,再保证其他 agent。
  • 允许脚本在局部 override 中提高本次规划所需 token 上限,但不得绕过 runtime 默认值。
  • token 优先级策略必须由版本化 planner_policy.json 默认值 + 脚本局部覆盖共同实现,不能只依赖脚本 heuristics。

LLM Planning Role

  • 在 planner-managed ingress 下,LLM 是第一层 initial split decision 的 Primary Planner。
  • 规则系统不是 primary planner,而是:
    • 软约束器
    • 无 LLM / LLM 失败时的 fallback
    • 对越界结果的 deterministic safe-shape 校正

MCP Soft Boundary Policy

  • MCP namespace / profile / read-only / isolation 属于 soft boundary。
  • soft boundary 必须影响:
    • planning prompt
    • decomposition 建议
    • release_policy 建议
    • 决策理由与信号
  • soft boundary 默认不单独阻断任务。
  • 只有当 soft boundary 被规则系统识别为触碰硬边界时,才允许降级 / fallback / forced single。

Invocation Guidance

  • 优先读取 task-local strategy + meta。
  • 优先读取版本化 planner_policy.json;仅在缺失时回退到 agent_runtime.json 中的 legacy planner_agent。
  • 在 planner-managed ingress 下优先执行 LLM 规划。
  • 必须同时给出:
    • decision_reason
    • decision_signals
    • mcp_soft_boundary_signals
    • token_priority_context
    • decoupling_rationale
    • granularity_guardrails
  • 遇到不确定性时,应优先产出更保守的可解耦边界,而不是越权扩展职责。
  • 不得直接把软边界视为绝对禁止,除非规则明确升级为硬边界。
  • 本地 planner_entry.sh 只是当前兼容 provider;正式策略权威载体是版本化 policy 与 request/decision envelope。
  • planner_prepare_single_worker.sh / planner_prepare_workers.sh 当前代表两种 refinement 输入路径,不代表“拆/不拆”的对立。

权限声明(用于自动ACL生成)

  • allowed_read_paths: templates/coordination/planner, templates/coordination/tasks/task_folders, templates/coordination/tasks/completed_context.ndjson, runtime/workdomains, projects, ~/.openclaw-state/agent-orchestrator/planner, ~/.openclaw-state/agent-orchestrator/tasks/subchecklists, ~/.openclaw-state/agent-orchestrator/tasks/worker_tasks
  • allowed_write_paths: templates/coordination/planner, templates/coordination/tasks/task_folders, runtime/workdomains, ~/.openclaw-state/agent-orchestrator/planner, ~/.openclaw-state/agent-orchestrator/tasks/subchecklists, ~/.openclaw-state/agent-orchestrator/tasks/worker_tasks
  • forbidden_paths: templates/coordination/security/acl_denied.ndjson

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.