dynamic-workflow-packets

Dynamic Workflow Packets

Use this skill to coordinate big work without turning small tasks into process overhead.

Decision Rule

Use packet orchestration when at least two are true:

• The task has independent coding, research, data, UX, security, docs, review, sourcing, or verification tracks.
• A clear success contract would prevent drift.
• The task is risky, broad, expensive, external-facing, or long-running.
• Separate review would likely catch mistakes.
• The workflow pattern may be reused.
• The user explicitly asks for packets, swarm, subagents, dynamic workflow, or orchestration.

If the task is small, do it directly and mention that packet orchestration is unnecessary.

Operating Contract

1. Restate the goal and success criteria.
2. Identify risks and approval gates before execution.
3. Split only genuinely independent work into packets.
4. Keep critical-path work local; delegate or simulate sidecar work.
5. Use subagents only if available and appropriate. Otherwise simulate packets with isolated notes.
6. Set turn/time/tool budgets and stop rules before any long-running or repeated packet.
7. Integrate results explicitly; never paste raw packet dumps as the final answer.
8. Verify against the original success criteria.
9. Save reusable artifacts only when they will help future work.

Risk Gates

Ask one clear approval question before:

• deleting, overwriting many files, mass-renaming, force-pushing, or rewriting history,
• deploying, publishing, emailing, messaging, posting, applying to jobs, or mutating external systems,
• running migrations, broad codemods, dependency upgrades, or expensive jobs,
• touching credentials, secrets, billing, production data, user accounts, private customer data, resumes, contacts, or outreach history,
• creating public resources or changing third-party accounts,
• spawning many agents or long-running compute.

If risk is ambiguous, do a read-only inspection, draft the exact action, explain likely effect, then ask.