mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-06-14 04:01:30 +08:00
feat: add dynamic workflow team orchestration surface
Adds dynamic workflow/team orchestration skills, the content pack, and control-pane work-item/Kanban state DB support. Includes reviewer hardening for state-db CLI validation, optional state DB failure handling, and mergeStateStatus projection.
This commit is contained in:
Affaan Mustafa
@@ -0,0 +1,123 @@
|
||||
---
|
||||
name: dynamic-workflow-mode
|
||||
description: "Design task-local harnesses, eval gates, and reusable skill extraction for Claude dynamic workflow mode and other adaptive agent harnesses."
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Dynamic Workflow Mode
|
||||
|
||||
Use this skill when a coding agent can generate or adapt a task-local harness instead of only following a static command flow. The goal is to turn dynamic workflow mode into a disciplined system: temporary harnesses for one-off work, shared skill extraction for repeated work, and observable control pane checkpoints for teams.
|
||||
|
||||
## When To Activate
|
||||
|
||||
- The user mentions dynamic workflows, custom harnesses, harness-per-task, adaptive workflows, or Claude Code dynamic workflow mode.
|
||||
- A task needs a custom loop, evaluator, crawler, fixture generator, watcher, or local dashboard.
|
||||
- Multiple agents need the same repeatable process but the process is not yet captured as a shared skill.
|
||||
- A workflow needs durable handoff artifacts, eval evidence, or operator approval before merge.
|
||||
|
||||
## Core Contract
|
||||
|
||||
Dynamic workflow mode should produce a task-local harness only when the harness is cheaper and safer than manually driving the same steps. The harness must have:
|
||||
|
||||
- **Objective**: the outcome it owns and the outcome it explicitly does not own.
|
||||
- **Inputs**: files, URLs, prompts, data sources, credentials policy, and user-provided constraints.
|
||||
- **Outputs**: commits, reports, screenshots, status files, or control pane snapshots.
|
||||
- **Eval**: at least one pass/fail check tied to the task, not only "it ran".
|
||||
- **Handoff**: a short artifact that tells the next operator what happened, what is blocked, and how to resume.
|
||||
|
||||
## Dynamic Harness Decision Tree
|
||||
|
||||
1. **One-shot task**: keep it inline. Do not invent a harness.
|
||||
2. **Repeated task with changing inputs**: create a task-local harness and keep it under a temp or project-local working area.
|
||||
3. **Repeated task across teammates or repos**: extract the pattern into a shared skill.
|
||||
4. **Task with external state, queueing, or approvals**: add control pane visibility before adding more automation.
|
||||
5. **Task with safety risk**: add an eval gate and a human merge gate before autonomous execution.
|
||||
|
||||
## Task-Local Harness Template
|
||||
|
||||
Use this structure before writing code:
|
||||
|
||||
```markdown
|
||||
# Dynamic Workflow Harness
|
||||
|
||||
Objective:
|
||||
- Ship:
|
||||
- Do not ship:
|
||||
|
||||
Inputs:
|
||||
- Repo or workspace:
|
||||
- External systems:
|
||||
- Credentials policy:
|
||||
|
||||
Loop:
|
||||
1. Discover current state.
|
||||
2. Generate or update the smallest useful artifact.
|
||||
3. Run eval checks.
|
||||
4. Record status and handoff.
|
||||
5. Stop on failed gate, unclear ownership, or unsafe external action.
|
||||
|
||||
Eval:
|
||||
- Command:
|
||||
- Expected pass signal:
|
||||
- Failure owner:
|
||||
|
||||
Handoff:
|
||||
- Status:
|
||||
- Evidence:
|
||||
- Next action:
|
||||
```
|
||||
|
||||
## Shared Skill Extraction
|
||||
|
||||
Promote a task-local harness into a shared skill only when at least two of these are true:
|
||||
|
||||
- The same workflow appears in multiple sessions, repos, teams, or launches.
|
||||
- The workflow needs specific language, tool, or safety sequencing.
|
||||
- Failures repeat because operators skip a gate or lose context.
|
||||
- The workflow has a stable input/output contract.
|
||||
- The workflow benefits from a control pane, status board, or team handoff.
|
||||
|
||||
When extracting, write the skill first in `skills/<name>/SKILL.md`. Add command shims only if a legacy slash-entry surface is still required.
|
||||
|
||||
## Control Pane Checkpoints
|
||||
|
||||
Dynamic workflow mode becomes team-usable when it exposes state. Record these checkpoints whenever the task spans more than one session:
|
||||
|
||||
- **Plan**: objective, owner, acceptance criteria, and risky external systems.
|
||||
- **Queue**: work items, assigned agent role, branch/worktree, and dependency edges.
|
||||
- **Run**: active harness, current loop step, recent eval result, and token/cost signal if available.
|
||||
- **Gate**: test results, browser screenshots, security review, and merge readiness.
|
||||
- **Handoff**: what is done, what failed, what needs a human decision.
|
||||
|
||||
If the repo has ECC2 state enabled, prefer adding or reading checkpoints through the ECC control pane or state-store-backed scripts instead of scattering untracked notes.
|
||||
|
||||
## Eval Gates
|
||||
|
||||
Every dynamic harness needs a task-specific eval. Pick the cheapest reliable gate:
|
||||
|
||||
| Work Type | Eval Gate |
|
||||
| --- | --- |
|
||||
| Code feature | Focused test, lint, coverage, and one integration path |
|
||||
| UI/control pane | Browser smoke with screenshot and overflow/error checks |
|
||||
| Agent workflow | Fixture transcript or seeded work item with expected routing |
|
||||
| Research/content | Source-neutral brief, claim checklist, and publish-ready outline |
|
||||
| Integration | Dry-run command, config validation, and no-secret scan |
|
||||
|
||||
Do not claim a dynamic workflow is reusable until the eval can be rerun by another teammate.
|
||||
|
||||
## Anti-Patterns
|
||||
|
||||
- Generating scripts that hide the real decision logic from the operator.
|
||||
- Treating dynamic workflow mode as permission to skip tests.
|
||||
- Creating one-off docs when a shared skill or status artifact is the real product.
|
||||
- Running multiple agents without ownership, merge gate, or conflict policy.
|
||||
- Letting raw private research data leak into public docs.
|
||||
|
||||
## Output Standard
|
||||
|
||||
Finish with:
|
||||
|
||||
- The harness or skill path.
|
||||
- The eval commands and results.
|
||||
- The control pane or handoff artifact path.
|
||||
- The next reusable extraction candidate.
|
||||
@@ -0,0 +1,110 @@
|
||||
---
|
||||
name: team-agent-orchestration
|
||||
description: "Run team-based orchestration for agent squads using work items, ownership, agent Kanban, merge gates, and control pane handoffs."
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Team Agent Orchestration
|
||||
|
||||
Use this skill when agents are being managed like a team rather than a single assistant. The purpose is to make team-based orchestration reliable: clear work items, explicit ownership, agent Kanban state, branch isolation, control pane visibility, and merge gates.
|
||||
|
||||
## When To Activate
|
||||
|
||||
- The task spans multiple agents, tools, harnesses, branches, or worktrees.
|
||||
- The user mentions team orchestration, agent Kanban, squad, conductor, control pane, manager, desktop app, Zellij, tmux, Hermes, Devin, Codex, Claude Code, or multi-agent work.
|
||||
- A project needs shared workflow state across people and agents.
|
||||
- Existing agent fan-out is producing output but not mergeable product.
|
||||
|
||||
## Operating Model
|
||||
|
||||
Treat every agent as a teammate with a narrow contract:
|
||||
|
||||
- **Owner**: the person or agent accountable for the work item.
|
||||
- **Scope**: files, branch, tool surface, and forbidden areas.
|
||||
- **State**: backlog, ready, running, review, blocked, merged, or archived.
|
||||
- **Evidence**: tests, screenshots, logs, review notes, or eval reports.
|
||||
- **Merge gate**: the exact condition that allows integration.
|
||||
|
||||
## Agent Kanban
|
||||
|
||||
Use agent Kanban when work must be visible across sessions.
|
||||
|
||||
| Column | Meaning | Exit Criteria |
|
||||
| --- | --- | --- |
|
||||
| Backlog | Candidate work item, not yet shaped | Acceptance criteria written |
|
||||
| Ready | Shaped and assignable | Owner and branch/worktree assigned |
|
||||
| Running | Agent is actively working | Handoff artifact and changed files exist |
|
||||
| Review | Work is complete but not merged | Tests, diff review, and risk check pass |
|
||||
| Blocked | Needs external input or failed gate | Blocker has owner and next action |
|
||||
| Merged | Integrated into mainline | PR merged or local main updated |
|
||||
| Archived | No longer relevant | Reason recorded |
|
||||
|
||||
Each card should fit this schema:
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "agent-card-001",
|
||||
"title": "Build dynamic workflow skill",
|
||||
"owner": "codex",
|
||||
"state": "running",
|
||||
"branch": "product/dynamic-workflow-team-orchestration",
|
||||
"worktree": ".",
|
||||
"acceptance": [
|
||||
"Skill exists",
|
||||
"Tests cover required concepts",
|
||||
"Content artifact contains video and article angles"
|
||||
],
|
||||
"merge_gate": "lint, focused tests, and catalog check pass",
|
||||
"handoff": "path/to/handoff.md"
|
||||
}
|
||||
```
|
||||
|
||||
## Team-Based Orchestration Flow
|
||||
|
||||
1. **Shape the board**: convert fuzzy ambition into work items with owners and merge gates.
|
||||
2. **Pick execution mode**: single-agent, dynamic workflow mode, dmux/tmux, worktree fan-out, or external desktop orchestrator.
|
||||
3. **Assign boundaries**: one owner per card, clear file scope, and no overlapping writes without an integrator.
|
||||
4. **Run agents**: each agent writes evidence and handoff notes, not just code.
|
||||
5. **Review in sequence**: tests first, then diff review, then security/risk checks, then content/product polish.
|
||||
6. **Merge deliberately**: one integrator resolves conflicts and updates the control pane or status artifact.
|
||||
7. **Extract reusable skill**: if the card pattern repeats, promote it into `skills/`.
|
||||
|
||||
## Control Pane Requirements
|
||||
|
||||
A useful control pane for team orchestration should show:
|
||||
|
||||
- Active work items and their agent Kanban state.
|
||||
- Owner, harness, branch, worktree, and last heartbeat.
|
||||
- Links to handoff artifacts, tests, screenshots, and PRs.
|
||||
- Blockers grouped by owner and unblock action.
|
||||
- Merge readiness by gate, not vibes.
|
||||
- Reusable workflow candidates that should become shared skills.
|
||||
|
||||
Do not add more automation until the operator can answer: who owns this, what changed, what gate failed, and what can safely merge?
|
||||
|
||||
## Dynamic Workflow Compatibility
|
||||
|
||||
When a card needs dynamic workflow mode:
|
||||
|
||||
- Put the task-local harness under the card owner.
|
||||
- Store inputs and outputs on the card.
|
||||
- Require an eval before moving from Running to Review.
|
||||
- Promote the harness to a shared skill only after repeat use.
|
||||
|
||||
## Failure Modes To Watch
|
||||
|
||||
- **Agent soup**: many agents running, no owner or merge gate.
|
||||
- **Invisible work**: useful output exists only in a chat transcript.
|
||||
- **Board theater**: a Kanban board exists but cards have no acceptance criteria.
|
||||
- **Overlapping writes**: parallel agents edit the same files without worktrees.
|
||||
- **No product artifact**: the process produces docs but no runnable or publishable surface.
|
||||
|
||||
## Output Standard
|
||||
|
||||
Finish each orchestration pass with:
|
||||
|
||||
- Board/card changes.
|
||||
- Merged or pending branches.
|
||||
- Tests and eval evidence.
|
||||
- Blockers with owner and next action.
|
||||
- New shared skill candidates.
|
||||
Reference in New Issue
Block a user