mirror of
https://github.com/affaan-m/ECC.git
synced 2026-09-18 07:37:59 +02:00
d29cf651c7
* fix(skills): move version into metadata and normalize to semver 29 skills declared `version` at the top level of their frontmatter. The schema reads it from `metadata`, so tooling that follows the schema either misses it or has to special-case the top level. Three motion skills also declared `version: 1.0`, which is not a valid semantic version; normalized to `1.0.0`. No behavioral change — frontmatter metadata only. * fix(skills): state activation triggers in skill descriptions 148 skills described what they cover but never named the situation that should trigger them. Since the description is what Claude matches against to decide whether to load a skill, a description without a trigger makes activation guesswork — the skill is either missed or loaded at the wrong time. Added a "Use when ..." clause to each, derived from the skill's own body (most already stated the trigger under "## When to Use" or in the opening line; that intent is now reflected in the frontmatter where it is actually read from). Descriptions were only appended to; no existing wording was removed. * fix(skills): sync activation triggers into the Codex skill mirror 10 of the skills whose descriptions changed are also mirrored under `.agents/skills/`, where the description was previously a verbatim copy. Left alone, the two surfaces would disagree about when the skill applies. Only the description line is synced; the Codex copies keep their reduced frontmatter, since that validator accepts only name, description, metadata, license, and allowed-tools. * fix(skills): correct three activation clauses from review - autonomous-loops: the clause pulled new loop work into a skill that its own body marks as a compatibility shim retained for one release. It now points at the canonical continuous-agent-loop instead. - continuous-learning: the description carried the v1 routing directive twice; collapsed to one. - homelab-pihole-dns: the clause fired on any broken home DNS. Narrowed to tasks that actually involve Pi-hole. * chore: retain current main lockfile --------- Co-authored-by: Çağrı Solakoğlu <cagri.solakoglu@vtcenerji.com> Co-authored-by: haelyra <49814733+haelyra@users.noreply.github.com>
4.7 KiB
4.7 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| team-agent-orchestration | Run team-based orchestration for agent squads using work items, ownership, agent Kanban, merge gates, and control pane handoffs. Use when coordinating an agent squad with work items, ownership, Kanban, and merge gates. |
|
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:
{
"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
- Shape the board: convert fuzzy ambition into work items with owners and merge gates.
- Pick execution mode: single-agent, dynamic workflow mode, dmux/tmux, worktree fan-out, or external desktop orchestrator.
- Assign boundaries: one owner per card, clear file scope, and no overlapping writes without an integrator.
- Run agents: each agent writes evidence and handoff notes, not just code.
- Review in sequence: tests first, then diff review, then security/risk checks, then content/product polish.
- Merge deliberately: one integrator resolves conflicts and updates the control pane or status artifact.
- 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.