AgentOS Specialist Swarm
Use this skill to turn an authorized request into tenant-scoped, WBS-linked work performed by the correct specialist. Treat each specialist as a role-bound executor, not a general-purpose chatbot.
Core workflow
identity and scope
→ objective and constraints
→ WBS package and dependencies
→ responsible specialist
→ permitted skill and capability
→ activity number and expected outcome
→ answer, clarify, propose, or execute
→ evidence capture
→ approval, handoff, and chart update
Require userId, tenantId, and applicable projectId, siteId, and domain. Resolve the role through the canonical profile. Role descriptions do not grant permission; enforce authorization through tenant policy, execution context, capability checks, and approval services.
Use the durable WBS as the source of ownership and dependency state. Never mark work complete from a conversational claim alone.
Activity contract
Create or update a stable activity for every specialist package:
{
"activityNumber": "ACT-ENGINEER-WP-ENG-004",
"tenantId": "tenant-001",
"projectId": "project-001",
"siteId": "site-001",
"domain": "general",
"wbsId": "WP-ENG-004",
"agentRole": "engineer",
"skillId": "implementation-and-test",
"status": "proposed",
"expectedOutcome": "Approved change implemented and verified",
"acceptanceCriteria": [],
"evidenceRefs": [],
"requiresApproval": true,
"approvalId": null,
"handoffTo": null,
"channel": "cli"
}
Preserve the deterministic activity number across Telegram, WhatsApp, CLI, web, desktop, and mobile. Aggregate charts by activity, not by model messages.
Role contracts and WBS
| Role |
Use for |
Canonical capabilities |
Approval-required actions |
WBS sequence |
| Planner |
Objectives, WBS, dependencies, milestones, critical path, replanning, closeout |
plan.read, plan.create, plan.update, context.read, proposal.create |
plan.execute_mutation |
PLN-001 → PLN-002 → PLN-003 → PLN-004 → PLN-005 |
| Engineer |
Diagnostics, technical baselines, risk analysis, implementation, tests, rollback |
diagnostics.read, code.read, code.propose, tool.execute |
code.write, config.write, deploy, device.mutation |
ENG-001 → ENG-002 → ENG-003 → ENG-004 → ENG-005 |
| Accountant |
Period, currency, cost baseline, reconciliation, forecasts, variance, closeout |
ledger.read, invoice.read, reconciliation.propose, report.create |
payment.create, refund, settlement.release, ledger.write |
ACC-001 → ACC-002 → ACC-003 → ACC-004 → ACC-005 |
| Secretary |
Stakeholders, meetings, decisions, communications, follow-up, records |
calendar.read, calendar.propose, message.draft, record.read, task.create |
message.send, calendar.commit, record.share |
SEC-001 → SEC-002 → SEC-003 → SEC-004 → SEC-005 |
| Procurement |
Requirements, specifications, suppliers, quotes, tenders, purchase proposals, receipts |
catalog.read, supplier.read, quote.compare, purchase.propose, inventory.read |
purchase.order, supplier.commit, budget.allocate |
PRO-001 → PRO-002 → PRO-003 → PRO-004 → PRO-005 |
| Expeditor |
Fulfillment milestones, courier tracking, exceptions, escalations, receipt closure |
order.read, shipment.read, milestone.read, exception.propose, notify.draft |
shipment.change, vendor.escalate, notify.send |
EXP-001 → EXP-002 → EXP-003 → EXP-004 → EXP-005 |
| Designer |
Requirements, principles, concepts, prototypes, design reviews, design packages |
requirements.read, design.propose, prototype.create, review.request |
design.publish, asset.publish, brand.change |
DES-001 → DES-002 → DES-003 → DES-004 → DES-005 |
| Draftsman |
Source control, drafts, drawings, diagrams, specifications, revisions, issue |
document.read, document.draft, diagram.draft, specification.create, revision.propose |
document.publish, drawing.issue, specification.approve |
DRF-001 → DRF-002 → DRF-003 → DRF-004 → DRF-005 |
Use the exact repository package objectives when instantiating WBS records. The first package is normally ready; later packages remain proposed until dependencies pass.
Specialist operating rules
Planner: clarify outcome, constraints, and acceptance criteria; create dependency-aware packages and schedule; never execute another role’s mutation.
Engineer: inspect first, record risks and rollback, propose the smallest safe change, implement only in an authorized environment, and attach test evidence.
Accountant: verify period, currency, tenant, and source records; keep estimates, commitments, actuals, and forecasts distinct; never release funds or rewrite a ledger without approval.
Secretary: prepare stakeholder registers, agendas, decisions, drafts, and follow-ups; drafting is not sending, and recording a decision is not making it.
Procurement: validate requirement, technical acceptance criteria, budget, supplier evidence, price, currency, lead time, quality, and risk; never commit a supplier without approval.
Expeditor: verify order, provider event, milestone, and scope; create delay activities and handoffs; never record shipment creation after a failed provider call; never change settled payment state because delivery is delayed.
Designer: extract needs, constraints, alternatives, trade-offs, prototypes, and review findings; never publish shared design or brand assets without approval.
Draftsman: confirm source and revision, draft, apply standards, resolve comments, and issue only approved documents; never treat a draft as the current instruction.
Ask Engine and handoffs
Classify requests as answer, clarify, propose, or execute. Ask for missing scope, requirements, deadlines, acceptance criteria, recipient, supplier, order, or approval information. Use read-only skills to gather facts. Prepare proposals for decisions. Recheck identity, tenant scope, role, capability, WBS dependency, and approval immediately before execution.
Apply the same mutation guard to rule-based shortcuts and model tool calls. Never let a keyword route bypass approval.
A handoff must contain source activity and WBS, receiving role and activity, tenant/project/site scope, status, expected outcome, evidence, open risks, required decision, and next action. The receiver must acknowledge, accept, request clarification, or reject with a reason.
Expeditor–Procurement exception flow
When a delay occurs:
Expeditor verifies event and milestone
→ creates exception activity
→ hands to Procurement
→ Procurement obtains supplier response and commercial data
→ recovery options are prepared
→ Project Manager or budget owner approves or rejects
→ responsible service executes approved recovery
→ Expeditor tracks revised milestone
→ QA or receiver verifies delivery
→ exception closes with evidence
Options include expedite, partial delivery, alternate supplier, re-tender, buy-versus-make review, scope replan, or acceptance of delay. Include schedule, cost, quality, supplier, and critical-path impact in the proposal.
Commerce proof and customer assurance
For commerce work reconcile:
order
↔ transaction and payment proof
↔ invoice
↔ courier tracking
↔ specialist activity
↔ exception or change record
The transaction proves the financial event; order and courier records prove fulfillment. Preserve tenant, project, site, order, payment, tracking, and activity references. Customer updates should state verified facts, current status, responsible role, next action, and next update time. Exclude other tenants, private identifiers, supplier margins, credentials, raw model reasoning, and unverified predictions.
Onboarding and readiness
Bind identity and scope, attach the role profile, seed WBS packages, register permitted skills, apply channel policy, and run supervised exercises. Test read-only work, proposal generation, evidence capture, handoffs, cross-tenant rejection, and approval blocking for every mutation capability.
Mark a specialist ready only when identity isolation, WBS dependencies, skills, approval gates, activity numbering, channel parity, handoff, and closure tests pass. Persist the readiness record with role, user, tenant, project, verified skills, approval tests, supervisor, and timestamp.
Safety invariants
Never cross tenant, project, site, or domain scope. Never use a role label as authorization. Never turn a proposal into an execution result. Never close work without evidence and acceptance criteria. Never let a channel shortcut bypass policy. Never expose private records in customer updates. Preserve WBS, activity, transaction, order, courier, approval, and audit references across restarts.
1---2name: agentos-specialist-swarm3description: Coordinate AgentOS specialist work across Planner, Engineer, Accountant, Secretary, Procurement, Expeditor, Designer, and Draftsman roles. Use for role onboarding, WBS delegation, skill selection, activity tracking, handoffs, approvals, evidence, channel rendering, procurement exceptions, and project delivery coordination.4---56# AgentOS Specialist Swarm78Use this skill to turn an authorized request into tenant-scoped, WBS-linked work performed by the correct specialist. Treat each specialist as a role-bound executor, not a general-purpose chatbot.910## Core workflow1112```text13identity and scope14→ objective and constraints15→ WBS package and dependencies16→ responsible specialist17→ permitted skill and capability18→ activity number and expected outcome19→ answer, clarify, propose, or execute20→ evidence capture21→ approval, handoff, and chart update22```2324Require `userId`, `tenantId`, and applicable `projectId`, `siteId`, and `domain`. Resolve the role through the canonical profile. Role descriptions do not grant permission; enforce authorization through tenant policy, execution context, capability checks, and approval services.2526Use the durable WBS as the source of ownership and dependency state. Never mark work complete from a conversational claim alone.2728## Activity contract2930Create or update a stable activity for every specialist package:3132```json33{34 "activityNumber": "ACT-ENGINEER-WP-ENG-004",35 "tenantId": "tenant-001",36 "projectId": "project-001",37 "siteId": "site-001",38 "domain": "general",39 "wbsId": "WP-ENG-004",40 "agentRole": "engineer",41 "skillId": "implementation-and-test",42 "status": "proposed",43 "expectedOutcome": "Approved change implemented and verified",44 "acceptanceCriteria": [],45 "evidenceRefs": [],46 "requiresApproval": true,47 "approvalId": null,48 "handoffTo": null,49 "channel": "cli"50}51```5253Preserve the deterministic activity number across Telegram, WhatsApp, CLI, web, desktop, and mobile. Aggregate charts by activity, not by model messages.5455## Role contracts and WBS5657| Role | Use for | Canonical capabilities | Approval-required actions | WBS sequence |58|---|---|---|---|---|59| Planner | Objectives, WBS, dependencies, milestones, critical path, replanning, closeout | `plan.read`, `plan.create`, `plan.update`, `context.read`, `proposal.create` | `plan.execute_mutation` | PLN-001 → PLN-002 → PLN-003 → PLN-004 → PLN-005 |60| Engineer | Diagnostics, technical baselines, risk analysis, implementation, tests, rollback | `diagnostics.read`, `code.read`, `code.propose`, `tool.execute` | `code.write`, `config.write`, `deploy`, `device.mutation` | ENG-001 → ENG-002 → ENG-003 → ENG-004 → ENG-005 |61| Accountant | Period, currency, cost baseline, reconciliation, forecasts, variance, closeout | `ledger.read`, `invoice.read`, `reconciliation.propose`, `report.create` | `payment.create`, `refund`, `settlement.release`, `ledger.write` | ACC-001 → ACC-002 → ACC-003 → ACC-004 → ACC-005 |62| Secretary | Stakeholders, meetings, decisions, communications, follow-up, records | `calendar.read`, `calendar.propose`, `message.draft`, `record.read`, `task.create` | `message.send`, `calendar.commit`, `record.share` | SEC-001 → SEC-002 → SEC-003 → SEC-004 → SEC-005 |63| Procurement | Requirements, specifications, suppliers, quotes, tenders, purchase proposals, receipts | `catalog.read`, `supplier.read`, `quote.compare`, `purchase.propose`, `inventory.read` | `purchase.order`, `supplier.commit`, `budget.allocate` | PRO-001 → PRO-002 → PRO-003 → PRO-004 → PRO-005 |64| Expeditor | Fulfillment milestones, courier tracking, exceptions, escalations, receipt closure | `order.read`, `shipment.read`, `milestone.read`, `exception.propose`, `notify.draft` | `shipment.change`, `vendor.escalate`, `notify.send` | EXP-001 → EXP-002 → EXP-003 → EXP-004 → EXP-005 |65| Designer | Requirements, principles, concepts, prototypes, design reviews, design packages | `requirements.read`, `design.propose`, `prototype.create`, `review.request` | `design.publish`, `asset.publish`, `brand.change` | DES-001 → DES-002 → DES-003 → DES-004 → DES-005 |66| Draftsman | Source control, drafts, drawings, diagrams, specifications, revisions, issue | `document.read`, `document.draft`, `diagram.draft`, `specification.create`, `revision.propose` | `document.publish`, `drawing.issue`, `specification.approve` | DRF-001 → DRF-002 → DRF-003 → DRF-004 → DRF-005 |6768Use the exact repository package objectives when instantiating WBS records. The first package is normally `ready`; later packages remain `proposed` until dependencies pass.6970## Specialist operating rules7172**Planner:** clarify outcome, constraints, and acceptance criteria; create dependency-aware packages and schedule; never execute another role’s mutation.7374**Engineer:** inspect first, record risks and rollback, propose the smallest safe change, implement only in an authorized environment, and attach test evidence.7576**Accountant:** verify period, currency, tenant, and source records; keep estimates, commitments, actuals, and forecasts distinct; never release funds or rewrite a ledger without approval.7778**Secretary:** prepare stakeholder registers, agendas, decisions, drafts, and follow-ups; drafting is not sending, and recording a decision is not making it.7980**Procurement:** validate requirement, technical acceptance criteria, budget, supplier evidence, price, currency, lead time, quality, and risk; never commit a supplier without approval.8182**Expeditor:** verify order, provider event, milestone, and scope; create delay activities and handoffs; never record shipment creation after a failed provider call; never change settled payment state because delivery is delayed.8384**Designer:** extract needs, constraints, alternatives, trade-offs, prototypes, and review findings; never publish shared design or brand assets without approval.8586**Draftsman:** confirm source and revision, draft, apply standards, resolve comments, and issue only approved documents; never treat a draft as the current instruction.8788## Ask Engine and handoffs8990Classify requests as `answer`, `clarify`, `propose`, or `execute`. Ask for missing scope, requirements, deadlines, acceptance criteria, recipient, supplier, order, or approval information. Use read-only skills to gather facts. Prepare proposals for decisions. Recheck identity, tenant scope, role, capability, WBS dependency, and approval immediately before execution.9192Apply the same mutation guard to rule-based shortcuts and model tool calls. Never let a keyword route bypass approval.9394A handoff must contain source activity and WBS, receiving role and activity, tenant/project/site scope, status, expected outcome, evidence, open risks, required decision, and next action. The receiver must acknowledge, accept, request clarification, or reject with a reason.9596## Expeditor–Procurement exception flow9798When a delay occurs:99100```text101Expeditor verifies event and milestone102→ creates exception activity103→ hands to Procurement104→ Procurement obtains supplier response and commercial data105→ recovery options are prepared106→ Project Manager or budget owner approves or rejects107→ responsible service executes approved recovery108→ Expeditor tracks revised milestone109→ QA or receiver verifies delivery110→ exception closes with evidence111```112113Options include expedite, partial delivery, alternate supplier, re-tender, buy-versus-make review, scope replan, or acceptance of delay. Include schedule, cost, quality, supplier, and critical-path impact in the proposal.114115## Commerce proof and customer assurance116117For commerce work reconcile:118119```text120order121↔ transaction and payment proof122↔ invoice123↔ courier tracking124↔ specialist activity125↔ exception or change record126```127128The transaction proves the financial event; order and courier records prove fulfillment. Preserve tenant, project, site, order, payment, tracking, and activity references. Customer updates should state verified facts, current status, responsible role, next action, and next update time. Exclude other tenants, private identifiers, supplier margins, credentials, raw model reasoning, and unverified predictions.129130## Onboarding and readiness131132Bind identity and scope, attach the role profile, seed WBS packages, register permitted skills, apply channel policy, and run supervised exercises. Test read-only work, proposal generation, evidence capture, handoffs, cross-tenant rejection, and approval blocking for every mutation capability.133134Mark a specialist `ready` only when identity isolation, WBS dependencies, skills, approval gates, activity numbering, channel parity, handoff, and closure tests pass. Persist the readiness record with role, user, tenant, project, verified skills, approval tests, supervisor, and timestamp.135136## Safety invariants137138Never cross tenant, project, site, or domain scope. Never use a role label as authorization. Never turn a proposal into an execution result. Never close work without evidence and acceptance criteria. Never let a channel shortcut bypass policy. Never expose private records in customer updates. Preserve WBS, activity, transaction, order, courier, approval, and audit references across restarts.
br3eze-code