Share Copilot capacity, not accounts: a TASK.md workflow

Most teams get Copilot through a company contract with GitHub or Microsoft, and each developer works against a personal limit per billing period: a per-user credit allowance, or a per-user budget that admins set on top of the organization's pool. Usage is uneven. One developer has a small limit and runs out early in the period. Another ends the period with credits left over. A third has no license at all.

A limit belongs to one user, so the leftover credits do nothing for the colleague who ran out. That's capacity the company already paid for, sitting idle. If you route work to the people who still have credits, you get more out of the same contract without buying extra seats. (If your org pools credits with no per-user caps, the credit argument is weaker, but the teammate with no license still needs a way in.)

The informal fix is a chat message: "can you run this through Copilot for me?" It sort of works, once. The context is half in your head, the delegate spends credits on clarifying questions, and everything Copilot learned disappears with the conversation.

So I wrote down a process for doing it properly. The owner of the work writes a Markdown task spec, commits it to the repo, and a teammate with spare Copilot capacity implements it. Nobody transfers tokens or shares a login, and the repo carries the context.

The full proposal and example files are here: share-tokens-using-spec-driven-dev on GitHub. This article covers the hands-on part: the files you add to a repo and how a task moves through them.

If you've used GitHub Spec Kit, the shape will look familiar. Spec-driven development makes the spec the source of truth and treats the AI as the one who implements it. This process keeps that idea and splits the steps between people:

You don't need Spec Kit to run this. Plain Markdown files work fine. If you want the toolkit, it supports Copilot:

uv tool install specify-cli specify init my-project --integration copilot Enter fullscreen mode Exit fullscreen mode In Spec Kit, you repeat implement and converge until converge reports "Converged". Here, the owner's validation plays that role.

Writing a good spec and validating the result cost zero AI credits. Implementation is where Copilot saves the most time. So the split is:

Upstream of all three, the business side (a product owner or analyst) writes the requirements and acceptance criteria, ideally in the existing docs/specs.

The owner stays responsible for what gets merged, and the delegate never needs access they don't already have. Delegated code goes through the same review, CI/CD and quality gates as any other change.

Here is the whole flow, one swimlane per role:

There are two loops in there. A task the reviewer rejects goes back to the owner before any credits are spent. A result that fails validation goes back to the delegate, but only after the owner fixes the task file, because a retry against the same spec will usually produce the same mistake.

Everything lives in the repository. A Copilot conversation is gone when the session ends, while the files stay in git history.

.github/ copilot-instructions.md # loaded into Copilot requests in this repo instructions/ tests.instructions.md # path-specific rules (applyTo glob) prompts/ implement-task.prompt.md # the shared /implement-task prompt agents/ ready-check.agent.md # optional: reviewer persona docs/ ARCHITECTURE.md CODING_GUIDE.md TESTING_GUIDE.md specs/report-generation/design.md backlog/ TASK-042-order-summary-report.md AGENTS.md # same guidance for other coding agents Enter fullscreen mode Exit fullscreen mode Per GitHub's docs, repository instructions go in.github/copilot-instructions.md, path-specific ones in.github/instructions/*.instructions.md, custom agents in.github/agents/*.agent.md and skills in.github/skills/<name>/SKILL.md. Prompt files live in.github/prompts/ as *.prompt.md and are documented by VS Code. Support differs between IDEs and the cloud agent, so check the docs for the surface your delegates use.

One file per task, named docs/backlog/TASK-NNN-short-slug.md. NNN is zero-padded and never reused. Each task also gets a GitHub issue labeled ai-delegation that links the file, so the issue board shows what is waiting and who picked up what.

Here is the example from the repo, TASK-042-order-summary-report.md:

# TASK-042: Generate order summary report Status: Draft | Approved | In progress | In validation | Done Owner: <name> Reviewer: <name> Delegate: <name> Issue: <link> ## Objective Generate the order summary report from normalized order records. ## Tech stack - Java 25, Spring Boot, PostgreSQL - Kafka where required ## Expected behavior 1. Load the report configuration. 2.

Retrieve the eligible orders. 3. Generate the report.

4. Store the delivery metadata. ## Architecture constraints - Follow../ARCHITECTURE.md and../CODING_GUIDE.md. - Do not bypass the defined service boundaries. ## Acceptance criteria - [ ] The report is generated for all eligible orders. - [ ] The job can be restarted after a failure. - [ ] A failed run is recorded. - [ ] Unit tests cover the new code. - [ ] Integration tests cover the end-to-end flow. ## Out of scope - File transport - Customer notification ## References -../TESTING_GUIDE.md -../specs/report-generation/design.md ## Implementation notes Filled in by the delegate at handback. - Changed: - Decisions: - Open questions: Enter fullscreen mode Exit fullscreen mode A few sections pull more weight than they look like they should:

Copilot burns credits fastest when it has to guess. The reviewer approves a task only when every box is ticked:

- [ ] The objective fits in one or two sentences. - [ ] Each expected behavior is a concrete step, not a wish. - [ ] Each acceptance criterion can be checked by a test or a visible result. - [ ] Out of scope is listed. - [ ] Every referenced doc exists and is current. - [ ] Input and output examples are included where the format matters. - [ ] No secrets, credentials or production data. - [ ] Small enough for one session (a PR one person can review in under an hour). Enter fullscreen mode Exit fullscreen mode The last item is the easiest one to skip. If the task won't fit in one reviewable PR, split it into TASK-043 and TASK-044 before anyone starts.

Not everything is worth delegating, either. Every delegated task pays for a spec, a review, a handoff and a validation. That overhead pays off for new endpoints, services or jobs with a clear spec, test suites for existing code, mechanical refactors across many files, and boilerplate like DTOs, mappers and migrations. Keep one-line fixes, exploratory design work and live incidents with the owner.

If you want help with the review, a custom agent can run the checklist. A minimal.github/agents/ready-check.agent.md:

--- name: ready-check description: Checks a TASK-NNN.md file against the definition of ready before credits are spent. --- You review task files in docs/backlog/. Do not edit code. For the given task, check each item of the definition of ready in docs/spec/PRD-copilot-capacity-sharing.md section 8. Report each item as PASS or FAIL with one line of reasoning, then list the questions the owner must answer before approval. Enter fullscreen mode Exit fullscreen mode description is the only required frontmatter field for a custom agent. The human reviewer still makes the call; the agent just catches the obvious gaps.

.github/copilot-instructions.md holds the conventions every request should know about, so no delegate has to re-explain them in chat:

# Copilot instructions ## Stack Java 25, Spring Boot, Maven, PostgreSQL. Kafka only where a task says so. ## Read before changing code - docs/ARCHITECTURE.md: service boundaries and layering (api -> service -> repository/client) - docs/CODING_GUIDE.md: records for DTOs, constructor injection, 120-char lines - docs/TESTING_GUIDE.md: JUnit 5 + Mockito, Testcontainers for integration tests ## Rules - A layer never calls the layer above it. No business logic in controllers. - Schema changes go through versioned migrations, never manual DDL. - No hardcoded secrets or environment-specific values. - Every acceptance criterion in a task maps to at least one test. - When working from docs/backlog/TASK- *.md, stay inside its "Out of scope" limits.

Enter fullscreen mode Exit fullscreen mode Keep it short. It rides along with every request in the repo, so each line you add is context you pay for again and again. Rules that only matter for tests or migrations go into a path-specific file with an applyTo glob:

--- applyTo: " src/test/**" --- Use JUnit 5 and Mockito. Integration tests use a real PostgreSQL via Testcontainers. Name tests after the behavior: shouldSkipCompletedRunForSamePeriod(). Never retry a flaky test until it passes; fix it or remove it. Enter fullscreen mode Exit fullscreen mode Step 4: the shared implement-task prompt This is the file that makes every delegate run tasks the same way. Save it as.github/prompts/implement-task.prompt.md:

--- description: Implement a TASK-NNN.md file from docs/backlog end to end agent: agent argument-hint: Path to the task file, e.g. docs/backlog/TASK-042-order-summary-report.md --- You are implementing the task in ${input:task:docs/backlog/TASK-NNN-slug.md}. 1. Read the task file and every document listed under References.

Read.github/copilot-instructions.md conventions as binding. 2. If Status is not "Approved", stop and say so.

3. Produce a short plan: files to create or change, tests per acceptance criterion. Wait for my confirmation before editing.

4. Implement the plan. Respect "Architecture constraints" and "Out of scope".

5. Run the full test suite (mvn verify). Fix failures until all tests pass.

If you fail twice on the same error, stop and explain instead of retrying. 6. Fill in "Implementation notes" in the task file: - Changed: files and what changed - Decisions: choices not dictated by the task, with reasons - Open questions: anything the owner must decide 7.

Set Status to "In validation". Do not commit or open a PR. Enter fullscreen mode Exit fullscreen mode The delegate types /implement-task in Copilot Chat, passes the task path, and gets the same plan-first, test-gated run every time.

Step 3 makes Copilot stop after the plan, because a wrong plan caught early costs one request while a wrong implementation costs many. Step 7 keeps the commit and the PR with the owner, who is still responsible for the change.

${input:...} is the prompt-file syntax for asking the user for a value, and agent: agent runs the prompt in agent mode so Copilot can edit files and run the build.

When the delegate is done, the task file explains what happened. A filled-in section might look like this (illustrative, not from a real run):

## Implementation notes - Changed: ReportJob, ReportRunRepository, V7__report_run.sql migration, ReportJobTest, ReportJobIT (Testcontainers). - Decisions: Restart check queries report_run by configuration and period in SQL, per CODING_GUIDE ("filter in SQL, not in Java"). - Open questions: Should a run stuck in STARTED for more than a day count as failed? The design doc does not say. Enter fullscreen mode Exit fullscreen mode Then the owner validates: JUnit, functional or simulation tests, the affected screens.

Small issues they fix themselves. Anything bigger means updating the task file (usually that open question becomes a new acceptance criterion) and sending it back for another iteration. When it's clean, the owner commits, links the task file in the PR, and CI/CD runs its usual gates.

The task's Status line tracks all of this, and only one state spends credits:

Last step: anything worth keeping from the implementation notes (a decision, a gotcha) moves into /docs. If it only exists in a Copilot conversation, the next delegate won't see it.

For background: GitHub announced that Copilot plans move to usage-based billing from June 1, 2026, with a monthly allotment of GitHub AI Credits consumed by tokens at each model's listed rate. Code completions don't draw on credits. Agent work does. That's why session hygiene matters:

The same habits help owners stretch their own small allowance.

Instead of working in the IDE, a delegate can assign the task's GitHub issue to the Copilot cloud agent, which works in the background and opens a draft PR. The owner then validates that draft PR exactly like a local handback. Two things to know before you do this. Per GitHub's docs, cloud agent sessions also use GitHub Actions minutes, shared with the rest of the account's workflows. And which allowance the AI usage counts against depends on how your organization bills Copilot, so check your billing setup before you count on it landing on the delegate's credits and not the owner's.

All public, all installed in the repo so every delegate gets the same setup:

Secrets in task files. A task file is committed and read by people and models. Use synthetic examples, never production data or credentials. The definition of ready has a checkbox for this; don't skip it.

Stale references. If design.md describes last quarter's schema, Copilot will happily implement last quarter's schema. That is why "every referenced doc exists and is current" sits in the checklist.

Too many iterations. If a task needs more than two round trips, it usually wasn't ready. Look at the template and the review before blaming the delegate.

Company policy. Use Copilot inside your organization's approved AI settings (public code filtering, content exclusions). This process doesn't grant anyone access they didn't already have, and it shouldn't be used to route around policy.

Clone the repo, copy docs/backlog/TASK-042-order-summary-report.md as your template, add the prompt file and instructions above to.github/, and run one small task through the loop with a teammate. The full process, including what to measure per sprint (tasks merged, iterations per task, queue length), is in docs/spec/PRD-copilot-capacity-sharing.md.

How does your team handle uneven Copilot capacity today? Chat messages, pairing, or something more structured? I'd like to hear in the comments.

I wrote this article with AI assistance, then reviewed, fact-checked and edited it myself.

Examples repository: every example in this article (the PRD, the TASK-042 task spec, the team guides, the Copilot instructions, the prompt file and the diagrams) is in https://github.com/wallaceespindola/share-tokens-using-spec-driven-dev.

Need more tech insights? Check out my GitHub, LinkedIn, and Speaker Deck. Happy coding!