mcpField
P
pstack-omp

pstack-omp

github.com/dsebbanAgent 工作流68113 次安装1 周前更新
代码仓库

关于 pstack-omp

pstack-omp 将 poteto-mode 的委派约定适配到 OMP。它把标准角色映射到 OMP Agent,并规定任务分派、生命周期、报告和验证流程。

主要功能

  1. 01将标准角色映射到 OMP Agent
  2. 02定义任务批次与简报格式
  3. 03说明限时会话、评审组和负责人流程
  4. 04规定观察者与后续消息的规则
  5. 05要求检查产物并独立验证

适用场景

  1. 01将 poteto-mode 角色转换为 OMP Agent
  2. 02以任务批次分派相互独立的工作
  3. 03管理 OMP 的评审或实现流程
  4. 04在接收委派产物前进行验证

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/dsebban/skills --skill pstack-omp

安装后在 Claude Code 中输入/pstack-omp确认已加载。

详细介绍

OMP 上的 pstack

poteto-mode 是唯一的路由器。它会选择 playbook、规范角色、步骤顺序和生命周期协议。此适配器只会将这些选择转换为 OMP。它绝不会选择 playbook、重复 playbook 索引或更改 playbook 门控。

此技能处于活动状态时,其角色映射就是特定的 pstack 执行约定。在 pstack 工作之外,通用 OMP 指令仍然有效。

规范角色映射

使用以下确切的 OMP Agent 名称。

规范角色OMP Agent
explorerscout
watcherscout
plannertask
designertask
reviewerreviewer
researcherlibrarian
synthesizerreviewer
implementerpoteto-agent
ownerpoteto-agent
mechanicalsonic

角色职责定义在 skill://poteto-mode 中。此表仅用于指定 Agent。

规范 OMP 名单是封闭的:

scout
reviewer
security-reviewer
librarian
task
sonic
poteto-agent
comment-sicko
seance

规范路由任务项的 agent 值必须是这些内置名称之一。规范角色标签和模型别名都不是 Agent 名称。task 是默认工作者,因此使用它时应省略 agent。

poteto-agent 按照 poteto 的风格执行 implementer 和 owner 工作。对于直接提及 comment-sicko 的导入技能,应使用 comment-sicko 审查注释。

规划与设计

关于内置规划子 Agent 的导入警告,描述的是一种绕过技能约定的源主机机制。此 OMP 版本没有内置的 plan Agent,也没有 designer Agent。规范的 planner 和 designer 工作使用 task。任务说明应注明具体方向,例如技术规划或视觉与交互设计,且不得包含源主机子 Agent 字段。

安全审查

独立的安全工作流应使用 security-reviewer。当安全审查和普通代码审查都必需时,应让安全审查保持只读,并与普通代码审查分开。之后的 reviewer 会话可以综合已冻结的报告,但不能取代主要的安全审查。

任务约定

根节点负责执行每次 task 调用。子节点不得调用 task、启动其他子节点或直接询问用户。每份子节点任务说明的 FORBIDDEN 部分都必须包含 Do not call task or start subagents。task.maxRecursionDepth 允许嵌套,因此让任务树保持扁平的是任务说明,而不是主机。

子节点启动时不会获得父节点的对话内容。每条提示都必须能够独立理解。它们会收到 OMP 提供的已配置工作区、上下文文件、技能和获批计划资源。

调用格式

一次 task 调用就是一个批次。context 是共享的不可变背景信息,会呈现在每个子节点的系统提示中;tasks[] 则包含参与者。单个派发是只有一项的批次,而不是不同的格式。

{
  "context": "Repository root, base SHA, frozen artifacts, constraints, and verification context shared by every item.",
  "tasks": [
    {
      "name": "ParserOverflowFix",
      "solutionSpace": "one fix: bounds check in parse_header, call site given",
      "task": "GOAL\n...\n\nROLE\n...\n\nSCOPE\n...\n\nCONTEXT\n...\n\nACCEPTANCE\n...\n\nVERIFY\n...\n\nTIMEBOX\n...\n\nFORBIDDEN\n...\n\nREPORT\n...\n\nSTANDING\n..."
    }
  ]
}

每个任务项都必须包含 task 和 solutionSpace。solutionSpace 说明子节点的问题有多开放,而不是工作量有多大:是已经给出修复方案,还是仍有多个原因和设计方案待定。它绝不能提及兄弟任务项或协作安排。

name 使用 CamelCase,最多 32 个字符,并且在一次调用中必须唯一。它会成为子节点的 agent:// 标识符,因此应选择一个根节点过一小时仍能认出的名称。

只有启用了相应设置时,才能使用可选字段。编写前先检查设置:

  • isolated 需要启用 task.isolation.enabled,且不能处于计划模式。需要专用工作树的写入者应使用此选项,然后核实 OMP 报告的补丁、分支或已应用的更改。必须在同一工作区接受后续任务的长期 owner 应保持非隔离状态。
  • effort(lo、med、hi)需要启用 task.enableEffort。关闭时,推理深度由 Agent 配置的模型角色决定,而不是由调用决定。
  • outputSchema 和 schemaMode 需要启用 task.structured。
  • tools 会向子节点公开由 eval 定义的工具。

任务项中绝不能包含 model 字段。OMP 不支持此字段。

任务说明应简短,并将大量内容放入 local://<name>.md,供父节点和子节点共享。不要在行内粘贴大量内容。

批处理面板

对相互独立的参与者使用一次批量调用:

{
  "context": "Shared immutable repository, base SHA, artifacts, constraints, and verification context.",
  "tasks": [
    {
      "name": "CandidateA",
      "solutionSpace": "architecture open; candidate A explores the event-sourced shape",
      "task": "Standalone brief for architecture candidate A."
    },
    {
      "name": "CandidateB",
      "solutionSpace": "architecture open; candidate B explores the state-machine shape",
      "task": "Standalone brief for architecture candidate B."
    }
  ]
}

每个 name 都必须唯一。context 包含通用且不可变的材料。每个任务项仍须注明其确切角色、工作切片、验收标准、验证方式、禁止事项和报告约定。

在读取任何结论前,先在一次批处理中启动所有参与者。为撰写者提供隔离的工作区或互不重叠的输出路径。启动审查者前,冻结候选产物。启动单独的综合者会话前,冻结审查报告。

默认情况下,task.maxConcurrency 将同时运行的子任务数限制为 32;更大的批次会排队,而不会失败。

后台完成与后续操作

生成的任务会作为后台作业运行,并自动传回结果。记录返回的作业和 Agent 标识符。传回的预览可能会被截断。

  • 从 agent://<id> 读取完整结果。嵌套子任务的地址为 agent://<parent>.<child>。
  • 当报告不完整、含糊或可疑时,从 history://<id> 读取会话记录。
  • read proc:// 会列出正在运行的作业,read proc://<id> 会检查单个作业,但不会取走其传回结果。
  • write agent://<id> 用于发送一条范围内的更正、答复、授权或下一阶段的关联任务。它会唤醒已暂停的会话。agent://all 会向所有对象广播,且仅用于写入。
  • write proc://<id>/kill 会取消过时、已被取代或超出范围的任务。
  • 仅当根任务受阻且无其他可做事项时才调用 wait。切勿轮询。
  • 切勿引导审查者得出预期结论。
  • 忽略重复的终态传回结果,拒绝过时的产物版本。

任务结果只是证据,不代表任务已完成。根任务必须检查产物并运行验证。

任务简报格式

简报必须包含以下内容,方可派发任务:

GOAL
用一句话说明陌生人也能执行的目标结果。

ROLE
规范角色、映射的 OMP Agent、权限和预期立场。

SCOPE
可写和不可写的路径、确切的工作切片或竞争分支、适用时的工作树和分支,以及所有输出路径。说明唯一写入者的分配情况。

CONTEXT
仓库根目录、相关源路径、基础 SHA、已冻结的产物、当前生效的技能和操作手册路径、已确定的假设及已知注意事项。

ACCEPTANCE
每行列出一项可检查的可观察结果。

VERIFY
确切的命令、测试夹具、运行时探测、对比基准、环境要求,以及已知的假阳性或假阴性风险。

TIMEBOX
大致时限。到时后返回部分证据并停止,不要扩大范围。

FORBIDDEN
至少包括:不得调用子任务;不得生成子 Agent;不得修复范围外的问题;不得执行未请求的迁移;不得编辑所有权范围之外的共享路径;不得合并;不得直接向用户提问;未执行验证时不得声称完成。

REPORT
要求报告包含 PASS | ISSUES | BLOCKED、语义化会话名称、适用时的分支和确切 SHA、结论和证据、已更改的文件或产物、实际执行的验证命令及其结果、偏离情况、未解决的风险,以及父任务的后续操作。

STANDING
如果当前生效的操作手册提供了常设政策文本,请逐字复制。

规范流程

有界会话
  1. 编写一份独立完整的简报。
  2. 使用映射的 Agent 启动一个任务。
  3. 记录其语义化名称、Agent ID、作业 ID、角色、范围、隔离方式、基础 SHA 和预期产物。
  4. 收到异步结果时读取。
  5. 读取 agent://<id>;必要时检查 history://<id>。
  6. 仅在同一工作单元内通过一次 write agent://<id> 发送更正。
  7. 检查产物并独立运行承诺的验证。
  8. 父任务验证所报告的输出后,方可接受该工作单元。

角色或工作单元发生变化时,必须创建新任务。

面板
  1. 将任务拆分为相互独立的切片或竞速分支,每位参与者对应一个任务项。
  2. 在使用任何结果之前,先在同一批次中启动所有参与者。
  3. 按语义名称和标识符跟踪参与者,绝不按到达顺序跟踪。
  4. 让结果自动送达;只有在没有其他工作可推进时才使用 wait,并使用 write proc://<id>/kill 明确取消已放弃的分支。
  5. 忽略重复的终止结果送达。
  6. 冻结实现产物、分支、head SHA、报告和哈希值。
  7. 仅在候选方案冻结后,才在新批次中启动所有独立评审者。
  8. 需要综合意见时,先冻结评审结论,再启动单独的 reviewer。
  9. 将综合意见视为建议。由根节点选择并验证。

不要在同一会话中混用实现者、评审者或综合者。不要让评审者评审不断变化的 head。

长期负责人
  1. 使用完整的负责人简报启动一个非隔离的 poteto-agent 会话。
  2. 记录其 Agent ID 并重复使用。不要为同一单元启动并行负责人。
  3. 负责人只能在分配给自己的分支和路径中工作,且绝不能启动子任务。
  4. 仅在进入下一个耦合阶段、修正职责范围内的问题、根据证据解答问题或获得明确授权时,才发送 write agent://<id> 后续消息。
  5. 要求在每个验证边界提交终止报告。
  6. 在授权进入下一阶段之前,独立验证该边界。
  7. 发生所有权违规、代次过期或终止时超出职责范围时,停止工作。
一次性监视器
  1. 启动一个后台 scout 任务。
  2. 在简报中写明准确的分支、head SHA、代次、监视谓词、停止谓词和时间限制。
  3. 要求提供一个有意义的事件和一份终止报告。
  4. 若报告的代次不再匹配,则丢弃该报告。
  5. 每个新代次都启动一个新的监视器。
  6. 达到停止谓词或工作被取代时,停止工作。

监视器只负责观察。它不会修复、合并、授权,也不会悄悄跟踪已变更的 head。

交互与决策

子任务根据源材料、既定策略、冻结的证据或简报来消除不确定性。否则,应采用最安全且可撤销的解释并报告假设,或返回 BLOCKED,明确指出缺少的决策及已收集的证据。

根节点负责解决子任务提出的问题,并通过 write agent://<id> 将答案发送给现有 Agent。只有在确实需要用户决定产品偏好、授予不可获得的权限,或执行既定指令未涵盖的不可逆操作时,才询问用户。

所有权与验证

  • 每个分支、工作树、可变状态和输出路径只能有一位写入者。
  • 实现、评审、判断和综合由不同会话负责。
  • 任务必须限定在分配的单元和角色范围内。
  • 除非并发写入者的输出在结构上互不相交,否则应将其隔离。
  • 工作人员的报告不能验证其自身工作。
  • 记录分支、基准 SHA,以及准确的 head SHA 或产物代次。
  • 优先采用行为证明,而非仅有类型检查的证据。
  • 新提交、重新堆叠、冲突解决或应用补丁都会创建新代次,并使先前的评审结论失效。
  • 评判者和综合者只提供建议。根节点负责选择、与用户交互、外部写入、合并、删除及最终结论。
  • 只有根据返回的已解析模型和回退元数据,才能声称模型彼此独立。

模型路由

OMP 会根据当前设置解析任务 Agent,包括 modelRoles、task.agentModelOverrides、Agent 定义和常规回退。Agent 选择与模型选择是两个独立的决策。

不要在任务条目中添加 model 字段。不要将模型别名用作 agent 值。使用 /skill:setup-pstack 配置路由;它会在根据检测到的目录验证每个选择器后,将两条记录写入当前配置文件的 config.yml。

/skill:setup-pstack --show 会显示实时的 Agent 到角色映射。这些属于设置,不是任务负载字段。当操作手册要求模型独立时,请读取每个子 Agent 报告的已解析模型;如果两个评审组 Agent 解析到同一模型,请如实说明,不要声称获得了第二种意见。

写作

对每条回复、简报、报告、评审、任务分派、提交消息和面向 Agent 的编辑都应用 unslop(skill://unslop)。

评论

支持 Markdown