{"slug": "autonomous-delivery-skill", "title": "Autonomous Delivery Skill", "summary": "A developer published an open-source Agent Skill called \"autonomous-delivery\" that implements an adaptive orchestrator-worker pattern for AI coding agents, letting an outer orchestrator delegate work to local orchestrators and workers while periodically reshaping specialization, task boundaries, context, hierarchy, and concurrency. The skill is distributed as a gist containing SKILL.md, a README, and an MIT license, and is installed manually into GitHub Copilot's personal skills directory or a repository's .github/skills folder. It requires no specific orchestration SDK, model pairing, or cloud provider, and falls back to single-agent reasoning when session orchestration is unavailable.", "body_md": "You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert\n\nAn adaptive orchestrator-worker pattern, not a fixed software-delivery pipeline.\nA balanced outer agent uses session orchestration to delegate outcomes to direct\nworkers or local orchestrators. It periodically reflects on how the work is\norganized and changes specialization, task boundaries, context, hierarchy, and\nconcurrency to improve quality and throughput together.\n\nUse an intelligent, strong-reasoning orchestrator with faster but still capable\nworkers. Reserve the strongest suitable reasoning for critical design decisions,\nhard bugs, high-risk review and unblocking; use efficient execution for bounded\nwork once the contract is clear. Respect user model preferences and evaluate the\ntotal cost of useful results, including rework and handoffs.\n\nStart with the organization the task needs. Grow, simplify, or reshape it as\nevidence arrives. A small bug may need one agent; a cross-repository feature may\nneed several workstreams with different internal shapes. More agents are not the\ngoal, and fewer are not inherently better either.\n\nInstall from this gist\n\nThis gist is a distribution package, not an automatic installation. It contains\nSKILL.md, this README, and an MIT license; no executable installer or credentials.\nReview the files before installing. The commands below require GitHub CLI (gh)\nand Git.\n\nFor GitHub Copilot personal skills, clone this gist and copy the directory:\n\n```\ngh gist clone https://gist.github.com/EvanBoyle/8c1a97f682d92dab8c09d0e1ea73f4a0 autonomous-delivery &&\n  mkdir -p \"$HOME/.copilot/skills\" &&\n  mkdir \"$HOME/.copilot/skills/autonomous-delivery\" &&\n  cp autonomous-delivery/SKILL.md autonomous-delivery/README.md autonomous-delivery/LICENSE \\\n    \"$HOME/.copilot/skills/autonomous-delivery/\"\n```\n\nRun this from a directory where autonomous-delivery does not already exist.\nCreating the destination deliberately fails for an installed version; compare\nand deliberately replace the three files when upgrading. The chained commands\ndo not overwrite an existing installed skill.\n\nFor a repository-scoped installation, place the folder at\n.github/skills/autonomous-delivery/ instead. For another Agent Skills client,\nuse that client's documented skill directory. The final path must include\nautonomous-delivery/SKILL.md.\n\nReload your agent if it does not discover the skill automatically. Installing a\nskill does not add session tools, provide models, start workers, or grant access.\nWithout session orchestration, apply the reasoning in a single agent; use\navailable bounded consultations only when useful. No particular orchestration\nSDK, model pairing, cloud provider, or agent count is required.\n\nUse\n\nExample prompt:\n\nUse autonomous-delivery for this cross-repository feature. Choose an\norchestrator-worker structure appropriate to the codebases and adapt it as\nyou learn. Periodically reconsider whether task boundaries, context, and\nspecialization are improving both quality and throughput. Verify the user\njourney. Local edits and tests are authorized; ask before publishing or\ndeploying.\n\nAnother example:\n\nUse autonomous-delivery to investigate these competing explanations. Organize\nindependent evidence gathering where useful, then reassess the workflow after\nthe first findings. Consolidate duplicate work and focus on what could change\nthe conclusion. Return a supported recommendation, not an implementation.\n\nProvide the desired outcome, important constraints, permitted external actions,\nand any model or resource preferences. An outer coordinator can delegate to\nlocal orchestrators, but all descendants remain within the shared scope and\nbudget. Broad autonomy is not permission for unrelated or irreversible work.\n\nThe skill includes examples for a small bug, a cross-repository feature,\nuncertain research, a broad migration, and end-to-end code delivery. The earlier\nimplementation/research/qualification/release pipeline is now one illustration,\nnot the universal structure. The recurring loop is:\n\n``` php\nObserve results and friction -> reflect on the organization\n-> adapt -> compare quality and useful throughput -> retain or revise\n```\n\nUseful adaptations might prevent contract drift, remove a decision bottleneck,\nintroduce a temporary specialist, consolidate coupled writers, or improve\nhandoff context. Keep changes that produce better verified outcomes, not merely\nmore activity.\n\nRecurring work and recovery\n\nThe skill includes generalized instructions for inline session automation and\nscheduled wakeups. Use these, when authorized, to keep recurring objectives going:\nrepository triage, performance-log review, failed-tool diagnostics, periodic UI\naudits, supervision and recovery checks are examples, not mandatory tasks.\n\nSame-session wakeups retain a continuing coordinator's context; fresh-session\nscheduled jobs need explicit durable handoff state. Each cycle reconciles current\nintent and ownership, processes bounded new evidence, takes authorized action,\nverifies progress and updates its checkpoint. Use events for timely handoffs and\nschedules as recovery backstops, not busy-waiting or duplicate-worker factories.\n\nExample authorization:\n\nFor the next four hours, use session automation to check this workstream every\nten minutes. Triage new evidence, unblock existing owners and continue authorized\nlocal fixes and tests. Do not publish or deploy. Preserve the latest checkpoint\nafter each cycle; no new work after the cutoff. Report material blockers rather\nthan repeating unchanged status.\n\nFor an explicitly ongoing objective, a successful cycle is not a reason to stop\nthe schedule. For finite work, clear it when done or expired. Cadence, scope,\npermissions, resource limits, overlap handling and stop conditions must be explicit;\ninstallation or a request to explain this pattern does not start an automation.\n\nThis is generalized original methodology, not private application source or a\nclaim about another system's guarantees. An unlisted gist is accessible to anyone\nwith its link; do not add private logs, credentials, or confidential details.\n\nThis file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.\nLearn more about bidirectional Unicode characters\n\nAdapt an orchestrator-worker system to deliver verified outcomes. Use for substantial implementation, cross-repository work, research, migrations, or other tasks that benefit from session orchestration. A balanced outer coordinator delegates to workers or local orchestrators, periodically reflecting on the workflow to improve specialization, context, quality, and throughput together.\n\ncompatibility\n\nUses session orchestration and isolated workspaces when available. Without them, apply the same reasoning in one agent. Tools, models, access, and external actions remain subject to the host's capabilities and the user's authorization.\n\nlicense\n\nMIT\n\nmetadata\n\nversion\n\n2.1.0\n\nAutonomous delivery\n\nOrganize the work, then keep improving how it is organized. An intelligent,\nbalanced outer agent holds the user's intent and coordinates sessions. Those\nsessions may do bounded work themselves or orchestrate a workstream with its own\nworkers. The useful shape depends on the task, codebase, risks, and evidence;\nthere is no universal roster, pipeline, or agent count.\n\nOptimize for verified useful outcomes per unit of time and effort, not raw\nagent activity. Quality and throughput are joint goals. Better task boundaries,\ncontext, feedback, and verification often improve both by preventing rework;\nconfirm that with evidence and make real tradeoffs explicit. Do not buy apparent\nspeed by weakening the required outcome.\n\nThe adaptive pattern\n\n```\nUser intent, constraints, and authority\n                  |\n         Balanced outer coordinator\n                  |\n       Task-appropriate workstreams\n          /                  \\\n   Direct worker       Local orchestrator\n                            |\n                      Focused workers\n                  |\n       Evidence, integration, feedback\n                  |\n     Reflect and reshape the organization\n```\n\nThis illustrates possible relationships, not mandatory levels. A coordinator can\nalso do useful work directly. A worker can become a local orchestrator when a\nworkstream needs it; an unnecessary layer can collapse back into direct work.\nUse hierarchy to contain complexity, not to reproduce an org chart.\n\nThe outer agent needs enough judgment to decompose, challenge assumptions, and\nintegrate results, while staying economical about detail. Keep the global goal,\ninterfaces, important decisions, resource use, and acceptance in its context;\nlet local owners retain deep implementation or domain context. Select models and\ntools for the work and the user's preferences, not a fixed \"best model\" hierarchy.\nA difficult design decision might benefit from a stronger reasoning reviewer;\na routine bounded transformation might not.\n\nBalance intelligence, reasoning depth, and execution speed\n\nUse an intelligent orchestrator with strong reasoning and broad enough context\nto hold the objective, challenge assumptions, choose boundaries, and integrate\nevidence. Pair it with faster but still capable workers for well-scoped\nimplementation, tests, bounded research, and repetitive operations. Fast does not\nmean disposable or incapable; a worker must meet the same correctness bar.\n\nSpend the strongest available reasoning where judgment has the highest leverage:\ncritical design decisions, concurrency or persistence invariants, difficult bugs,\ncontradictory evidence, repeated failed approaches, and consequential unblocking.\nA local orchestrator or a focused expert consultation can handle that depth;\nthe outer coordinator need not absorb every implementation detail.\n\nWork\n\nModel-selection bias\n\nOverall decomposition, priorities, acceptance and integration\n\nStrong reasoning, reliable synthesis and sufficient context\n\nBounded implementation with a clear contract and tests\n\nFast, capable coding model\n\nStraightforward evidence gathering or routine validation\n\nEfficient model with the necessary tools and fidelity\n\nHard diagnosis, high-risk design review, unresolved ambiguity\n\nStrongest suitable reasoning model and supported reasoning effort\n\nChoose actual models and reasoning settings within the user's preferences,\navailability and shared budget. Do not hard-code one permanent model pairing,\nassume a label guarantees quality, or silently override explicit selections.\nModel capability, reasoning effort and context size are different choices.\nIncreasing all three for every call is not a strategy.\n\nEscalate when a concrete uncertainty or failed approach warrants it, not after an\narbitrary number of minutes. Give the stronger model the failing case, relevant\ncode, attempted explanations and exact unresolved decision. Return its conclusion\nto the existing implementation owner rather than restarting the whole workstream.\nOnce the uncertainty is resolved, use faster execution again where appropriate.\nJudge the balance by verified outcomes, rework, latency and total cost, including\nhandoffs and review, rather than token price or response speed alone.\n\nStart with a working understanding, not a ceremony\n\nEstablish the requested outcome and what would demonstrate it. Find the relevant\ncode, documents, existing sessions, conventions, dependencies, and constraints.\nDistinguish confirmed requirements from assumptions. Identify what actions are\nauthorized and what data or shared state could be affected.\n\nChoose an initial organization that makes useful progress with what is known.\nFor a small change or a tightly coupled investigation, one agent is often right.\nFor independent work or substantial separate context, use session orchestration.\nFor a broad workstream whose local decisions would overload the outer agent,\ndelegate an outcome to a local orchestrator.\n\nDo not require every uncertainty to be resolved before starting. Investigate\nhigh-impact unknowns early, begin independent work where safe, and revise the\nplan as evidence arrives. Ask the user only when the answer changes scope,\nauthority, or a consequential choice that cannot reasonably be inferred.\n\nDelegate outcomes and decision boundaries\n\nA useful assignment conveys the relevant user intent, expected result, owned\nscope, dependencies, important context, authority, and how to demonstrate success.\nState what the recipient can decide and what should come back for resolution.\nKeep it sufficient to work independently, not an exhaustive copy of the parent\nconversation or a rigid form to fill in.\n\nFor example:\n\nOwn the client side of this protocol change. Preserve existing callers.\nCoordinate the UI and compatibility work if they benefit from separate\nowners. The server workstream owns the wire contract; agree on it before\ndepending on a change. Return the implementation, relevant compatibility\nevidence, and unresolved interface decisions. Local edits and tests are in\nscope; publishing is not.\n\nA local orchestrator receives responsibility for its outcome, not permission\nto multiply agents without purpose. Any delegation remains within the parent's\nscope, authorization, and shared resource budget. Pass down applicable session,\nconcurrency, cost, and time limits and whether further delegation is in scope.\nAllocate within shared limits rather than giving every child the full budget;\nreport material resource use upward. A recipient may narrow its envelope, not\nwiden it, and brings requested expansions to its parent. A delegated orchestrator\napplies this skill within its assignment, not as a fresh grant of autonomy.\nAdd depth only when it reduces the outer coordinator's cognitive or coordination\nburden. Remove it when the extra handoffs cost more than they save.\n\nSpecialization can follow domain knowledge, subsystem ownership, method,\nuncertainty, or a quality gap. It need not mean permanent titles. A worker that\nknows the failing subsystem may be the best person to fix its CI failure; a fresh\nreviewer may be useful for a high-risk assumption the implementer cannot easily\nchallenge. Choose deliberately rather than appointing a reviewer for every edit.\n\nUse isolated workspaces for independent edits, and resolve shared writers\nexplicitly. Treat common files, APIs, fixtures, environments, and resource limits\nas dependencies even when feature descriptions sound independent. Agree on\ninterfaces early enough to avoid parallel incompatible implementations.\n\nCoordinate without becoming the bottleneck\n\nUse the host's session creation, messaging, status, and completion mechanisms.\nCheck for an existing owner before creating another. Give new sessions standalone\ncontext; send existing owners only information that changes their work. Use\nsubagents for bounded consultations when that is the better available mechanism;\ndo not confuse them with durable sessions that own continuing work.\n\nStart ready independent work together, do useful work while it runs, and consume\ncompletion events where available. Silence is not proof of a stall, and an idle\nsession is not proof of completion. Inspect the actual state and result before\nredirecting or replacing an owner. Avoid continuous polling, duplicate\ninvestigations, and continuation messages with no new information.\n\nSupervise outcomes, not just activity: busy is not proof of useful progress\neither. When a result is unexpectedly delayed or blocks important work, inspect\nthe relevant authoritative state rather than repeatedly requesting status. A\nfinished result may simply be waiting to be relayed. Use verified evidence when\navailable; if ownership must change, transfer it explicitly, prevent duplicate\nwriters, and preserve the existing work. Scale attention to impact and expected\nprogress, not a universal timeout.\n\nLet local owners make local decisions. Bring cross-workstream contracts,\nconflicts, shared bottlenecks, and acceptance gaps to the outer coordinator.\nReview the evidence appropriate to the risk without redoing each worker's\ninvestigation. Integrate incrementally when that exposes incompatibility sooner;\ndo not delay useful completed work for unrelated optional work.\n\nKeep enough durable state to recover: the outcome, current owners and\ndependencies, decisions and assumptions, evidence/artifact identities, unresolved\nrisks, next actions, and active workflow experiments with their baseline and\nexpected effect. Use an existing tracker or a compact checkpoint, not a new\nreporting system by default. Preserve useful worker context and saved work.\nA checkpoint or scheduled prompt describes past state. On resume or an\nauthorized scheduled wakeup, reconcile new requests, current owners, artifacts,\nand relevant external state before acting; do not replay an obsolete plan.\n\nKeep recurring work alive with session automation\n\nSome objectives are ongoing services, not one-off deliverables. When the user\nauthorizes recurring work, use the host's inline session automation or scheduled\nwakeup to revisit it without requiring another manual prompt. A completed cycle\ndoes not complete an explicitly ongoing mandate. Keep running useful, bounded\ncycles until its stop condition, expiry, or user cancellation.\n\nExamples include repository triage, reviewing new performance evidence, examining\nfailed tool calls, periodic UI audits, delivery supervision and recovery checks.\nThese are examples, not an automatic checklist: schedule only relevant authorized\nobjectives, and choose their cadence independently. A release recovery check may\nneed minutes; a UI audit may belong after a release or on a much slower schedule.\n\nDistinguish two host patterns:\n\nSame-session wakeup: resumes the continuing coordinator with its conversation\nand ownership context. Good for supervising an in-flight workstream or incident.\n\nFresh-session scheduled job: starts an isolated run. Give it durable state,\na checkpoint location and an explicit overlap/ownership rule. Do not assume it\ninherits the previous conversation.\n\nUse the native scheduling mechanism instead of sleep loops, repeated status\nmessages, or asking an agent to stay busy. Prefer completion events for immediate\nhandoffs; a slower scheduled check is a recovery backstop for missed handoffs,\nlost context, or an owner needing help. A timer does not prove a process is stuck.\n\nDefine a small recurring contract\n\nPersist the objective, scope, permissions, cadence or next wake time, evidence\nsource, current owner, last processed watermark, budget and stop condition.\nInclude what can happen automatically and what requires escalation. For example,\nreading failure diagnostics is not permission to replay failed mutations, and\nfinding a UI problem is not automatic authorization for a redesign.\n\nA reusable wakeup instruction is:\n\nContinue the authorized recurring objective: [outcome and scope]. Read the\ncurrent checkpoint and newer user instructions first. Reconcile current owners,\nin-flight operations and relevant external state. Process only new or materially\nchanged evidence since [watermark], within [time/cost/action limits]. Reuse the\nexisting owner; do not duplicate work or replay uncertain effects. Take the next\nauthorized useful action, preserve evidence and unresolved blockers, update the\ncheckpoint, and keep or adjust the schedule within the approved cadence. Stop at\n[expiry/completion/cancellation condition]; settle already-started effects safely.\n\nEach cycle should:\n\nReconcile before acting. Read current intent and authoritative state, not\njust the scheduled prompt's historical summary. Resolve replaced candidates,\nfinished work, changed ownership and already-submitted operations.\n\nSelect bounded useful work. Process new evidence or advance a blocked\ndependency. If there is no actionable delta, do not create a task to justify\nthe wakeup. Record a watermark when useful and avoid repetitive user updates.\n\nExecute or delegate once. Keep a single owner for shared writes; prevent\noverlapping runs from duplicating audits, fixes, queue consumption or releases.\nCoalesce a wakeup behind active work where possible rather than spawning a copy.\n\nVerify and checkpoint. Record actual outcomes, evidence identities, failures,\nnext actions and the next due time. Keep the scheduled instruction current,\nconcise and free of secrets; durable state carries the detailed history.\n\nContinue or stop deliberately. Keep an ongoing authorized mandate scheduled.\nFor finite work, remove its schedule when done or expired. At a cutoff, admit\nno new work, reconcile in-flight effects and preserve an honest handoff.\n\nFor triage, track which issues and updates were examined rather than rediscovering\nthe whole backlog every few minutes. For performance or tool-failure review,\nretain the observation window, source version and censoring limits; failure-only\nlogs do not establish a failure rate, and old logs are not fresh latency evidence.\nFor UI audits, bind findings to a release and reuse the existing finding owner;\ndo not turn every wakeup into another polish cycle. Recovery checks should identify\nthe actual blocker and deliver missing context or decisions, not repeatedly tell\na busy worker to continue.\n\nRecurring work consumes resources and may encounter sensitive data. Scheduling\ndoes not expand permissions, grant new access or make external effects exactly\nonce. Preserve durable receipts and idempotency/lease safeguards where relevant;\nreconcile uncertain writes before retries. Use appropriate backoff when there is\nno new evidence or a persistent external blocker, within the authorized cadence.\nChange scope, extend an expiry, or create additional schedules only with authority.\n\nReflect periodically on the workflow itself\n\nExecution feedback asks, \"Is this result right?\" Workflow reflection also asks,\n\"Is this organization helping us get better results faster?\" Make the second\nquestion recurring, not merely a retrospective after delivery.\n\nLocal orchestrators reflect on their own workstreams. The outer coordinator\nreflects on boundaries, cross-workstream flow, and shared bottlenecks, delegating\nlocal adjustments rather than micromanaging them.\n\nRevisit it at meaningful intervals: after an early result, an integration,\na repeated failure or handoff, a shift in the critical path, or a long-running\nwork phase. Choose a cadence that can catch waste before it compounds without\ninterrupting useful work. Short tasks may need only one reconsideration;\nlong-running efforts need repeated ones. No fixed timer or mandatory meeting.\n\nUse a small set of observations that matter to this task. Examples include\ntime to a usable result, accepted outcomes over a stated window, queue versus\nactive time, first-pass acceptance, defects or regressions, integration rework,\nrepeated questions, duplicated investigation, and context lost at handoffs.\nSmall samples support hypotheses, not invented fleet-wide statistics.\n\nDuring reflection, consider:\n\nGoal and quality: Are we solving the right problem? Does the evidence\nestablish the user's outcome, or just show that workers finished tasks?\n\nFlow: What currently limits verified progress? Is work waiting for\nknowledge, a decision, a shared resource, review, or another owner?\n\nOrganization: Are boundaries, depth, concurrency, or specialization\nhelping? Is the outer agent a queue? Would consolidation be better than fan-out?\n\nContext: Who lacks a contract, example, tool, or decision? Who is carrying\nirrelevant history? Are summaries hiding uncertainty or important evidence?\n\nLearning: What small change could improve both correctness and flow, and\nwhat would show whether it worked?\n\nTurn reflection into action:\n\n``` php\nObserved friction -> plausible cause -> small workflow change\n-> compare useful progress AND quality -> keep, revise, or undo\n```\n\nChange one major variable at a time when practical. Compare similar work and\nnote confounders; a faster easy task does not prove a better process. Preserve\nacceptance standards and safety boundaries. If a change only improves speed\nwhile increasing defects or rework, it has not demonstrated the intended gain.\nWhen a real quality/cost/latency tradeoff cannot be removed, make it explicit and\nhonor the user's priorities rather than quietly lowering the bar.\n\nAdapt the organization, not just the schedule. Split an overloaded workstream;\nmerge tightly coupled owners; introduce a temporary specialist; move a decision\ncloser to the relevant evidence; improve a handoff; change a model or tool within\nthe user's constraints; reduce concurrency when integration or resources saturate.\nExplain the change to affected owners and preserve accepted work, important\ncontext, and clear responsibility during the transition. Do not restart the team\nfrom scratch merely to obtain fresh contexts.\n\nRetain useful lessons with their conditions and evidence. A successful pattern\nfor one codebase is an option for the next, not a new universal rule. Remove\nceremony that no longer earns its cost.\n\nExamples: different work, different organizations\n\nThese are illustrations to adapt, combine, or reject.\n\nSmall bug in a cohesive subsystem\n\nThe outer agent investigates and fixes it directly. If the first result reveals\na subtle concurrency assumption, a bounded rubber-duck consultation challenges\nthat assumption while the original owner retains implementation context.\nReflection may confirm that extra sessions would only add latency; staying small\nis a valid optimization. Judge the result by the regression evidence, not by\nwhether orchestration occurred.\n\nCross-repository feature\n\nThe outer coordinator owns the user journey and shared contract. Repository\nworkstreams own their changes; one complex client workstream may use a local\norchestrator for distinct UI and compatibility work, while a small server change\nstays with a direct worker.\n\nIf integration repeatedly exposes contract drift, stop expanding parallelism.\nHave the owners settle examples and compatibility checks, then resume independent\nwork. Evaluate whether integration rework falls and verified delivery accelerates.\nIf every repository question is queued at the outer agent, delegate local\ndecisions more clearly rather than adding another central reviewer.\nIf the client's local orchestrator mostly relays messages, fold that layer back\ninto direct coordination with the existing workers.\n\nResearch or diagnosis under uncertainty\n\nOrganize around competing hypotheses or independent evidence sources rather\nthan implementation roles. The coordinator synthesizes findings with provenance,\nconfidence, and contradictory evidence. Workers return what would disprove their\nexplanation, not just supporting examples.\n\nAfter initial findings, collapse redundant branches and focus effort on the\nuncertainty blocking a decision. Introduce a domain specialist only if the\nremaining question needs one. Measure decision-useful evidence and avoided\nfalse conclusions, not documents produced; research need not end in deployment.\n\nBroad migration or repetitive transformation\n\nBegin with a representative slice to learn the real variations. A workstream\nowner may coordinate independent batches using shared rules and regression\nexamples. If batches repeatedly hit the same exception, improve the rule or\nextract a bounded specialist instead of teaching every worker independently.\n\nIf overlapping files and integration rework dominate, regroup by ownership or\nconsolidate writers. Increase parallelism only where validation and integration\ncan keep up. Compare accepted transformations, exception/rework rates, and time,\nnot raw edits. Preserve compatibility and migration recovery requirements.\n\nEnd-to-end code delivery\n\nOne possible arrangement uses implementation, reference research, qualification,\nand release responsibilities. Combine or separate them as useful; these are not\nmandatory roles for every task.\n\n``` php\nIndependent changes -> integration/review -> qualification\n                                          -> authorized release -> user acceptance\nFocused research ----> relevant decisions\n```\n\nHere, bind evidence to the exact integrated source and artifact. Green\nindividual branches do not prove their combination. Use the repository's checks,\nproportional review, and existing release tooling; keep clear ownership of\npublication and environment writes. A compatible fix and a persistent-format\nmigration need different rollout and recovery safeguards.\n\nReflection might reveal duplicate CI observation, serial independent checks,\nlate authentication discovery, or tests racing over shared fixtures. Remove\nduplicate observation, overlap genuinely independent work, establish access\nearlier, or isolate fixtures as appropriate. Keep coverage, failure visibility,\nresource bounds, and artifact identity; verify the speedup in the relevant\nenvironment. Deployment is not proof of the real user journey.\n\nBoundaries that adaptation must preserve\n\nThe organization is flexible; authority, honest evidence, and data safety are\nnot optional.\n\nStay within authority. A skill or delegated role grants no permissions.\nRespect host rules and user limits. Do not infer publishing, merging,\ndeployment, destructive changes, spending, or recurring automation permission\nfrom a planning request. Resolve genuinely missing authority before acting.\n\nProtect data and work. Do not expose private code, credentials, logs, or\nconversations to unauthorized destinations. Never obtain credentials from\nanother session or browser profile. Preserve user checkouts, saved artifacts,\nand sessions with ongoing or persistent work; idle does not mean disposable.\n\nKeep effects controlled. Establish ownership for shared mutable resources.\nA timed-out external write has an unknown outcome, not necessarily a failed\none. Reconcile its receipt and live state before retrying. Preserve retry\nidentity where supported, and do not assume a key makes effects exactly once.\nState-changing migrations need compatible recovery, not blind rollback.\n\nMatch evidence to claims. Distinguish proposals from implementation,\nlocal checks from integration, and simulation from live outcomes. Check the\nactual requested behavior and applicable failure paths. Report failures and\nunavailable evidence; do not rerun until lucky or weaken checks to look done.\n\nFinish the outcome, not the diagram\n\nStop when the requested result is verified and preserved, or report the precise\nblocked scope and what would unblock it. No extra workstream is owed merely\nbecause an example mentions one. Stop unneeded helpers you own without losing\nuser work or continuing activity.\n\nCommunicate the useful result, material evidence, uncertainty, and consequential\ndecisions concisely. Mention workflow changes when they explain a better result,\na changed forecast, or a tradeoff; do not make the user manage the organization.", "url": "https://wpnews.pro/news/autonomous-delivery-skill", "canonical_source": "https://gist.github.com/EvanBoyle/8c1a97f682d92dab8c09d0e1ea73f4a0", "published_at": "2026-10-11 00:09:05+00:00", "updated_at": "2026-10-11 00:19:03.668503+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["GitHub Copilot", "GitHub", "EvanBoyle", "autonomous-delivery"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/autonomous-delivery-skill", "markdown": "https://wpnews.pro/news/autonomous-delivery-skill.md", "text": "https://wpnews.pro/news/autonomous-delivery-skill.txt", "jsonld": "https://wpnews.pro/news/autonomous-delivery-skill.jsonld"}}