# dvn skill invocation packet Skill: public/execute-task-cycles Status: CURRENT Age: 0 seconds; source check: verified - devin-thomas/skills @ dce5977166216e8e88fcf56b6b53c76aaf91be5c; verified 2026-10-24T08:08:27.633Z Main source: execute-task-cycles/SKILL.md Main Git blob: 6e9161e79e866f5e88ebb2b33932e85471adadf7 --- name: execute-task-cycles description: Continue an authorized backlog or multi-task workflow through repair, verification and delivery, including AFK runs. Resume an existing run from its saved scope. Keep human-blocked items pending while completing independent ready work. --- # Execute Task Cycles Complete the authorized backlog using `execute-task` for each task. One completion is one verified task, not one debug attempt or retry. Resume saved run scope when the user says to continue; an ordinary request to resume a single task does not expand it into a backlog run. ## Autonomous progress and human blockers Automatic diagnosis, repair, and verification are the default. Carry forward the user's existing authorization. Resolve routine dependency, environment, implementation, validation, Git and transient service failures without a new confirmation. Retry with evidence and a changed approach; reconcile uncertain writes before repeating them. A human blocker is a material owner decision, unavailable permission or credential that cannot be recovered through authorized means, or a protected/destructive boundary outside the task. Ask a concise actionable question through the available asynchronous input surface and send an authorized owner notification when a configured route exists. Missing optional notification tooling is work to repair or route around, not a reason to abandon the task. Respect message recipients and transport authorization. While an answer is pending, preserve the blocked task and continue authorized independent investigation, preparation, repairs, or other ready backlog tasks. Record dependencies and return to the blocked item when the answer arrives. Never infer approval from elapsed time. Do not consume the run in repeated slow question waits, and do not report the whole workflow blocked while useful authorized work remains. Stop only at an explicit user/resource limit, completion of the authorized scope, or when every remaining useful action depends on a genuine human blocker. Record unfinished work honestly. ## Scope and limits Use an explicit task count or resource limit when the user supplies one. Otherwise continue until the authorized scope is complete; do not invent a default task-count cutoff or ask for a number. Honor host execution limits and preserve a resumable checkpoint when one is reached. Keep task selection tied to the user's project and current task-source state. ## Controller 1. Refresh repository, task-source, dependency and Git state. Reuse the established canonical prompt and user decisions. 2. Resume the current ready task or select the next ready task in the authoritative order. Treat recorded human blockers as pending dependencies, not a reason to reselect the same blocked item forever. 3. Diagnose failures, repair ordinary implementation/environment problems and verify uncertain external writes before retrying. Use evidence to change a failing approach. Technical retries do not consume a completed-task count. 4. If a material owner decision is necessary, send one actionable asynchronous question and an authorized notification. Record what is needed and continue independent preparation or another ready task. Avoid repeated unchanged notices. Revisit pending items when answers or external state change. 5. Count a task complete only after required checks and repository/task-source reconciliation pass. Keep partial, blocked and failed results distinct. Follow the repository's actual commit, push and delivery policy. 6. Continue until the requested scope or explicit limit is reached, the user stops the run, a host limit requires a checkpoint, or every remaining useful authorized action depends on the owner. Do not terminate because a procedural label or failed intermediate check says Incomplete. One task is owned at a time by default. Background work must fit existing authorization and avoid competing writes. Use parallel agents only when the active environment and user authorize them. Creating an unattended scheduled watcher or messaging a new recipient requires its own authorization; ordinary continued work within this run does not. ## Progress and completion Maintain a compact run record with completed task IDs, pending dependencies/questions, current work, checks, delivery state and next steps. Give concise progress updates while working. On a checkpoint or final result, report the actual completed count, remaining work, evidence and exact stopping condition. Preserve useful work and a clear resume path; never turn partial progress into overall success. --- Supporting source: execute-task/SKILL.md Git blob: dcfbca4396c56444c56d41090ea80e9e381106bf --- name: execute-task description: Complete a selected repository task through automatic repair, verification and authorized delivery. Use only when the user explicitly invokes `/execute-task`, explicitly asks to select and execute one next task/ticket/issue, explicitly supplies a TASK-EXECUTION-PROMPT.md for execution, or clearly requests one task pass from Linear, GitHub Issues, or repository-local Markdown. Do not trigger for generic continuation language such as "continue from here," "resume," or "follow the handoff," nor for ordinary implementation work already scoped by the conversation. If the request explicitly asks for multiple tasks, repeated execution, a loop, or completion of a backlog/project, delegate to execute-task-cycles. Prefer a repository's canonical task execution prompt when one exists; otherwise use the portable workflow. --- # Execute Task Complete one selected task from fresh repository and task-source state. Work through implementation, diagnosis, repair, verification and authorized delivery before reporting its result. One task means one scope, not one attempt. ## Autonomous progress and human blockers Automatic diagnosis, repair, and verification are the default. Carry forward the user's existing authorization. Resolve routine dependency, environment, implementation, validation, Git and transient service failures without a new confirmation. Retry with evidence and a changed approach; reconcile uncertain writes before repeating them. A human blocker is a material owner decision, unavailable permission or credential that cannot be recovered through authorized means, or a protected/destructive boundary outside the task. Ask a concise actionable question through the available asynchronous input surface and send an authorized owner notification when a configured route exists. Missing optional notification tooling is work to repair or route around, not a reason to abandon the task. Respect message recipients and transport authorization. While an answer is pending, preserve the blocked task and continue authorized independent investigation, preparation, repairs, or other ready backlog tasks. Record dependencies and return to the blocked item when the answer arrives. Never infer approval from elapsed time. Do not consume the run in repeated slow question waits, and do not report the whole workflow blocked while useful authorized work remains. Stop only at an explicit user/resource limit, completion of the authorized scope, or when every remaining useful action depends on a genuine human blocker. Record unfinished work honestly. ## Trigger conservatively Enter this workflow only when the user clearly asks for one repository task to be selected and executed. Generic continuation or handoff phrases alone do not invoke this skill. When the user says `continue from here`, `resume`, `keep going`, or `follow the handoff`, continue the already scoped work through the standard agent workflow unless the request separately contains an explicit task-selection signal. Do not infer task execution merely because a handoff mentions a tracker issue, a task connector is installed, or repository task files exist. ## Delegate cycle requests Before reading task-source state or beginning a task pass, inspect the user's request for an explicit repetition signal: `max_cycles`, a positive cycle count, "N times", "next N tasks", "repeatedly", "in a loop", "all remaining tasks", "until the project is complete", or equivalent wording. When the request clearly asks for more than one pass: - Hand off to `execute-task-cycles`, preserving any user-supplied maximum and all task-source, repository, or canonical-prompt context. - When the user does not supply a valid positive maximum, let `execute-task-cycles` continue to the authorized scope endpoint without asking for a number. - Do not execute a single task, choose a task, or reinterpret the request as one pass before handing off. Only continue with this skill's one-pass workflow when the user explicitly requests one task. If there is neither an explicit one-task request nor a clear multi-task repetition signal, do not use either task-execution skill. ## Preserve the outer invariants - Obey higher-level user, repository, and safety instructions. - Keep the selected task as the unit of ownership and verified completion; repair attempts are part of that task. - Preserve pre-existing work and protected resources. - Stop and report an irreconcilable conflict instead of weakening these boundaries. Follow the user's current intent and existing authorization when applying workflow instructions. Use judgment for routine implementation choices, dependency setup, debugging, retries and reversible recovery. A failed test, review finding or transient tool error normally calls for diagnosis and repair within the task, not an immediate handoff or permission request. Report a task-level human dependency when needed; continue independent preparation, and return it to an authorized backlog controller so other ready work proceeds. Use a canonical repository prompt for project-specific policy and task selection. Preserve real constraints while interpreting procedural steps in context; historical examples and intermediate failure labels must not override the user's current direction. Do not replace the canonical workflow with portable defaults merely for convenience. ## Resolve the reporting clock Use `America/Chicago` for every reporting-clock timestamp. Never ask the user for their time zone, offer a time-zone choice, or pause execution because of time-zone information. Change this setting only when the user explicitly initiates a conversation requesting a different time zone. Capture start evidence before task selection and include start/end/elapsed evidence in the final report. ## Discover a canonical prompt Resolve `TASK-EXECUTION-PROMPT.md` in this order: 1. Use a path explicitly supplied by the user. 2. Read the active host's applicable repository instructions and enabled rules; use a prompt they designate. Include scoped `AGENTS.md`, `CLAUDE.md`, documented host rule files, and any repository-designated instruction files such as `CODEX.md` when applicable. Respect the host's scope and precedence; do not assume every host automatically loads every filename. 3. Search the repository for exact filename matches. Prefer `rg --files -g TASK-EXECUTION-PROMPT.md` when available. 4. If multiple matches remain, search README files, runner documentation, implementation plans, agent documentation, and other repository docs for canonical-path or source-of-truth guidance. 5. Ask the user only when repository documentation cannot resolve multiple plausible canonical prompts. 6. If no prompt exists, use the portable workflow. Read the resolved prompt completely before acting. If it embeds a prompt or autostart instruction, treat the current invocation as the request to execute it. Do not ask for a task ID or restate a plan when the prompt says to select and begin automatically. Apply the current user-authorized scope when a canonical prompt assumes a different task count or earlier scope. Use `execute-task-cycles` for an authorized multi-task request. Resolve apparent procedural conflicts from the conversation and repository evidence; ask only when a consequential decision remains unresolved. Report an actual irreconcilable conflict with its exact source. ## Run the portable workflow When no canonical prompt exists: 1. Read [references/portable-workflow.md](references/portable-workflow.md) completely. 2. Read [references/task-sources.md](references/task-sources.md) completely, select one authoritative source, and use only the relevant source procedure. 3. Read current repository instructions, the applicable `GLOSSARY.md` files (follow `GLOSSARY-MAP.md` if present), `PROJECT.md` when available, architecture decisions, plans, relevant source and tests, and Git state before selecting work. Do not automatically turn an unrelated `CONTEXT.md` task brief into a glossary. 4. Execute the portable workflow through one terminal result. Do not select a tracker merely because its connector is installed or a Git remote exists. Do not invent a task source, lifecycle vocabulary, priority, or task identifier. ## Finish once Apply either the canonical prompt's report contract or the portable report contract after completing the task or exhausting reasonable authorized recovery. Report execution result separately from persisted task state, including failed or skipped validation. For a single-task request, stay within that scope. For an authorized AFK or backlog run, return the result and any pending human dependency to the controller so useful ready work continues.