claude-skills/engineering/skills/agent-workflow-designer/references/workflow-patterns.md
Reza Rezvani 1851c8fb09 fix(plugins): restructure 9 multi-skill domain plugins into ./skills/ layout
Same root cause as #587/#591 — Claude Code's runtime loader rejects
array-form skills paths like ["./content-production", "./ai-seo", ...]
even when each entry is a valid subdirectory containing SKILL.md.
`claude plugin validate` accepts them but the loader does not.

The proven canonical layout (used by self-improving-agent in #536):

  <plugin>/
  ├── .claude-plugin/plugin.json    skills: "./skills"
  └── skills/
      ├── <skill-1>/SKILL.md
      ├── <skill-2>/SKILL.md
      └── ...

Restructured 9 multi-skill domain plugins:
- business-growth (4 skills moved)
- c-level-advisor (28)
- engineering (36)
- engineering-team (32)
- finance (2)
- marketing-skill (43)
- product-team (12)
- project-management (8)
- ra-qm-team (13)

Also fixed standalone plugins that had root SKILL.md + ./skills/ subdir
(agenthub, autoresearch-agent, executive-mentor, playwright-pro). The
loader rejected them despite skills="./skills" because of the conflicting
root SKILL.md (compare self-improving-agent which works because PR #536
moved its root SKILL.md). Moved each root SKILL.md into ./skills/<name>/.

Restored standalone plugin folders to their original paths after the
multi-skill restructure swept them into parent skills/ directories
(marketplace.json source paths require original locations).

Removed 7 orphaned marketplace entries that pointed to skill folders
without their own plugin.json (content-creator, demand-gen,
fullstack-engineer, aws-architect, product-manager, scrum-master,
skill-security-auditor) — these were already non-functional.

Bumped patch versions on every changed plugin and synced
marketplace.json. Marketplace now lists 29 working plugins (down
from 36).

After merge: users run `/plugin marketplace update claude-code-skills`
followed by `/plugin update --all` to pick up the working layout.
2026-05-02 22:51:20 +02:00

1.5 KiB

Workflow Pattern Templates

Sequential

Use when each step depends on prior output.

{
  "pattern": "sequential",
  "steps": ["research", "draft", "review"]
}

Parallel

Use when independent tasks can fan out and then fan in.

{
  "pattern": "parallel",
  "fan_out": ["task_a", "task_b", "task_c"],
  "fan_in": "synthesizer"
}

Router

Use when tasks must be routed to specialized handlers by intent.

{
  "pattern": "router",
  "router": "intent_router",
  "routes": ["sales", "support", "engineering"],
  "fallback": "generalist"
}

Orchestrator

Use when dynamic planning and dependency management are required.

{
  "pattern": "orchestrator",
  "orchestrator": "planner",
  "specialists": ["researcher", "analyst", "coder"],
  "dependency_mode": "dag"
}

Evaluator

Use when output quality gates are mandatory before finalization.

{
  "pattern": "evaluator",
  "generator": "content_agent",
  "evaluator": "quality_agent",
  "max_iterations": 3,
  "pass_threshold": 0.8
}

Pattern Selection Heuristics

  • Choose sequential for strict linear workflows.
  • Choose parallel for throughput and latency reduction.
  • Choose router for intent- or type-based branching.
  • Choose orchestrator for complex adaptive workflows.
  • Choose evaluator when correctness/quality loops are required.

Handoff Minimum Contract

  • workflow_id
  • step_id
  • task
  • constraints
  • upstream_artifacts
  • budget_tokens
  • timeout_seconds