agentleFS
markoblogomarkoblogo/abvx-agent-skills/skills/dynamic-workflow-packets/SKILL.md

dynamic-workflow-packets

Skill16 starsChanged 5 months agoMITView on GitHub

Plan and run large Codex tasks with compact dynamic workflow packets, risk gates, integration, and verification. Use when the user explicitly asks for dynamic workflows, packets, subagents, swarm, orchestration, long-running audits, multi-track coding/research work, job or client search agent design, migrations, repo-wide reviews, or tasks where independent discovery, implementation, review, and verification tracks would reduce drift.

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. About 0 are common, 20 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈20

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

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

    line 12
  2. Distinctive:

    Use packet orchestration when at least two are true:

    line 16
  3. Distinctive:

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

    line 25
  4. Distinctive:

    Keep critical-path work local.

    line 32
  5. Distinctive:

    Use subagents only if available and appropriate.

    line 33
  6. Distinctive:

    Verify against the original success criteria.

    line 36
  7. Distinctive:

    Ask one clear approval question before:

    line 41
  8. Distinctive:

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

    line 50
  9. Distinctive:

    Create a local run directory only for substantial tasks:

    line 54
  10. Distinctive:

    Use packets for discovery, implementation, tests, docs, security review, and final verification.

    line 128
  11. Distinctive:

    Use packets for loop design, tool registry, context assembly, memory policy, permission/sandbox review, eval fixtures, observability, and …

    line 132
  12. Distinctive:

    Use packets for source discovery, primary-source verification, synthesis, counter-evidence, and final citation review.

    line 136
  13. Distinctive:

    Use packets for market/source mapping, opportunity scoring, profile/resume positioning, outreach drafts, follow-up schedule, CRM schema, …

    line 140
  14. Distinctive:

    Use packets for inventory, risk triage, deep dives, fix candidates, verification plan, and final report.

    line 144
  15. Distinctive:

    After packets complete, synthesize:

    line 148
  16. Distinctive:

    If packets disagree, inspect the authoritative source before choosing.

    line 161
  17. Distinctive:

    Run the narrowest reliable checks first, then broaden as risk warrants:

    line 167
  18. Distinctive:

    Do not call the workflow complete until evidence satisfies the original success criteria.

    line 179
  19. Distinctive:

    When a run produces a reusable pattern, save a concise recipe only if useful:

    line 183
  20. Distinctive:

    Do not save transcripts, secrets, bulky logs, credentials, private contacts, resumes, or sensitive personal details.

    line 194

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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.

Workflow Artifact

Create a local run directory only for substantial tasks:

.workflow/<slug>/
|-- plan.md
|-- state.json
|-- packets/
|-- results/
`-- final-report.md

For smaller tasks, keep the packet plan in the chat or a temporary note.

plan.md should contain:

Goal:
Success criteria:
Context:
Constraints:
Risks and approvals:
Packets:
Integration policy:
Verification:
Reusable artifacts:

For long-running packets, add:

Budgets:
Checkpoint / resume:
Loop detection:
Scheduler or trigger:
Eval / acceptance noise:

Packet Template

Each packet must be bounded and self-contained:

Packet ID:
Objective:
Context:
Sources / files:
Ownership:
Do:
Do not:
Expected output:
Verification:
Risk level:
Status:

Good packet types:

  • repo discovery,
  • API or market research,
  • implementation slice,
  • tests and fixtures,
  • UX/product review,
  • security or privacy review,
  • job/client sourcing,
  • outreach message drafting,
  • CRM/data-model design,
  • final verification.

For code packets, assign non-overlapping files or modules. Tell workers or simulated packet passes not to revert unrelated changes.

Domain Patterns

Coding

Use packets for discovery, implementation, tests, docs, security review, and final verification. Keep edits scoped by module. The parent agent owns final patch quality and runs the checks.

Agent Harness Work

Use packets for loop design, tool registry, context assembly, memory policy, permission/sandbox review, eval fixtures, observability, and managed-agent deployment boundaries. Keep classifier-based permissions separate from deterministic denial rules.

Research

Use packets for source discovery, primary-source verification, synthesis, counter-evidence, and final citation review. Track source, date, unit, and uncertainty.

Job And Client Search

Use packets for market/source mapping, opportunity scoring, profile/resume positioning, outreach drafts, follow-up schedule, CRM schema, and risk/privacy review. External messages, applications, profile changes, and public posting require user approval.

Long-Running Audits

Use packets for inventory, risk triage, deep dives, fix candidates, verification plan, and final report. Prefer one highest-confidence fix over broad speculative churn.

Integration

After packets complete, synthesize:

Accepted:
Rejected:
Conflicts:
Decisions:
Final changes:
Verification evidence:
Remaining risks:
Reusable follow-up:

If packets disagree, inspect the authoritative source before choosing. Reject outputs that are stale, unsupported, duplicate, unsafe, or outside scope.

For subagents, preserve context isolation: give each packet only its needed files, sources, and constraints. The parent agent owns final synthesis, safety decisions, and user-facing claims.

Verification

Run the narrowest reliable checks first, then broaden as risk warrants:

  • unit, integration, or e2e tests,
  • lint, typecheck, build,
  • script dry run,
  • browser/UI smoke test,
  • source citation check,
  • migration dry run,
  • outreach/privacy review,
  • manual checklist for non-code work.
  • eval fixture replay or acceptance-noise check for agent harness changes.

Do not call the workflow complete until evidence satisfies the original success criteria. Report skipped checks honestly.

Reusable Recipes

When a run produces a reusable pattern, save a concise recipe only if useful:

Trigger:
Plan shape:
Packet list:
Approval gates:
Verification checklist:
Known risks:

Do not save transcripts, secrets, bulky logs, credentials, private contacts, resumes, or sensitive personal details.

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.