Use to decompose approved context, dispatch ready task nodes, or execute a task under exclusive ownership.
Scanned 9/3/2026
Install to Claude Code
npx -y skills add Eduardo-Salvador/Agent-Harness-Kit --skill graph-execution --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Graph Execution?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/eduardo-salvador-graph-execution)More formats (shields.io, HTML) on the badges page.
---
name: graph-execution
description: Use to decompose approved context, dispatch ready task nodes, or execute a task under exclusive ownership.
---
# Graph execution
Apply `../../../docs/ADAPTIVE-EXECUTION.md`: lane and assurance are orthogonal; resume probes real state before artifacts; same-context nodes use inline spec/transition; packets exist only for actual separate consumers; planned units target 15–30 active minutes; tests climb the five-rung ladder; and in-scope technical recovery needs no fresh approval.
After verification, for `assurance: light|full` only, automatically launch the distinct reviewer in a fresh context—prefer a proven subagent—and send only the pinned SPEC-led packet, never prompt or conversation memory. Same-context review is invalid.
Every technical event is persisted in a new `TASK-GRAPH.md` revision before it is reported: dispatch/start, material progress, dependency changes, block/unblock, remediation, completion, lease/context changes, and newly ready nodes. Never record technical movement only in `PENDING.md`; revise pending state only for a related human action or macro outcome and backlink the new graph revision. Before graph creation or dispatch, follow `writing-plans`: non-simple work requires a ready implementation plan and every node requires a self-contained executable task spec. A specialist executes that spec; contradictions, missing decisions/dependencies/paths, unevaluable acceptance, or materially oversized work return `needs-replan` rather than improvisation. Code behavior and bug-fix tasks also load `test-driven-task`; completion requires meaningful RED before production code, GREEN with the same focused test, and proportional regression evidence. When automatic model routing is human-approved, do not stop at `model_tier`: resolve the current Codex model/effort, pass both into the actual task/message/subagent dispatch, and pin adapter confirmation through `harness.model-dispatch/v1` before activation. Same-context self-switch claims and silent host defaults are invalid.
For a first-call status or resume, follow `../../../harness/playbooks/status-resume.md` before any broad scan. `PENDING.md` owns human actions and macro incomplete areas; `TASK-GRAPH.md` owns technical order, dependencies, and execution. For user-pending questions, report human-owned items first and group human/technical pending items by workstream. Otherwise read only the relevant neutral playbook: `discovery-to-graph.md`, `task-dispatch.md`, `context-routing.md`, `model-routing.md`, or `parallel-execution.md`. Load the pinned context revision, pending-work authority, local graph neighborhood, task brief, scoped rules, approved capabilities, approved model-routing revision, and linked execution budget. Prefer the node's `read_set` over a broad scan, lease only its `write_set`, and use its `impact_set` for proportional regression checks. Verify derived relationships in source and record `context_provenance`; an approved, fresh Graphify index may enrich these fields but never becomes a second operational graph. Keep different workstreams in distinct execution contexts except a bounded integration node; create visible threads or internal subagents only when current capability evidence permits it. Respect dependency readiness, exclusive write sets, isolation evidence, routing escalation triggers, and orchestrator-only graph mutation. Enforce `../../../docs/EXECUTION-BUDGET.md`: reconcile the goal-lineage counters before another cycle or context expansion; never reset them by changing model, agent, task, review, decomposition, or session; at a ceiling persist evidence and `stop-and-replan`. Enforce `../../../docs/REVIEW-ROUNDS.md` for every dispatched reviewer: one initial review, at most one focused remediation review, and no third loop. Follow `../../../docs/STATUS-AND-COMPLETION.md` and `../../../docs/contracts/STATUS.md`: explicit status views and milestone closeouts label current stage, progress, continuing-without-user-action work, human and macro pending items from `PENDING.md`, active/ready/blocked nodes and technical pending work from `TASK-GRAPH.md`, blockers, next action, and inspectable paths. Routine progress updates may be concise result/evidence, human action, and next action; do not reread artifacts or create a full status form without a state/status need. Mark passing work `completed`, report it, release ownership, dispatch only nodes whose product and technical gates pass, and run declared assurance review automatically as non-blocking work. Follow `../../../docs/ACCOMPANIED-DELIVERY.md`: demonstrate client milestones and genuinely await approval before affected expansion. Every new spec has explicit completion conditions, mirrored in graph `acceptance_criteria`; current criterion-level, required TDD, and affected-flow evidence must pass before technical completion. Write durable results through shared templates; do not store state inside `.agents/`.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!