The workflow at a glance
Fix both input revisions, the inclusion rule, row IDs and read-only output first. Where available, choose Shared and review triggers, tools and billing ownership. Check complete inputs, a missing file and a duplicate ID before asking the successor to rerun.
Team ownership does not establish report correctness
GitHub’s October 28, 2026 announcement describes a gradual rollout of Shared Copilot Automations. Repository teams can maintain shared automations, with AI credits charged to the repository owner. An announcement does not establish that your account already has the Shared option.
Current Copilot Automations documentation limits availability to supported paid Copilot plans and eligible private or internal repositories, subject to organization, repository and cloud-agent settings. Check eligibility if the entry is absent; the case can still be practiced independently.
This article hands over a report-revision review. For investigating a Teams notification and moving toward a pull request, follow the separate Teams issue and PR trial. Those tasks have different permissions and completion conditions.
Point the handoff to one exact pair of revisions
Treat the following texts as fictional files: reports/baseline.csv, reports/current.csv and reports/reporting-rule.md. Both CSVs belong to October 2026; only their revisions differ. Each file requires unique line_id values, statuses are approved or draft, and only approved amounts enter this review.
Use the source and current-document version checks to establish the baseline and revision. Do not let AI choose whichever file looks newest or assume these example paths already exist in your repository.
line_id,team,amount_usd,status
L01,North,1200,approved
L02,South,800,approved
L03,West,500,draftline_id,team,amount_usd,status
L01,North,1350,approved
L02,South,800,approved
L03,West,500,approved
L04,East,400,draftrule_version=report-review-v1
report_period=2026-10
currency=USD
include_only_status=approved
line_id_must_be_unique_within_each_file=true
baseline_path=reports/baseline.csv
current_path=reports/current.csv
Compare revisions of the same October report, not month-over-month growth.
Missing files, duplicate IDs or unknown statuses require a blocked result.
No source edits, commits, PRs, comments, labels, emails or external messages are requested.Define a task that can answer and can stop
The prompt needs paths, inclusion rules, differences to explain and stop conditions. This trial only reads the material and returns review text. Publishing the report, correcting its source and sending messages are separate tasks.
A prompt does not guarantee a correct answer or replace tool permissions. Supply it with all inputs and use the reference result below to accept the output; fluent prose alone is insufficient.
Read reports/reporting-rule.md, reports/baseline.csv and reports/current.csv. Compare two revisions of this fictional October 2026 report.
Use only these inputs and match by line_id. IDs must be unique within each file. Include amount_usd only where status=approved.
Stop and list the blocker if a file is missing, an ID repeats or a status is not approved/draft. Do not guess.
Report the rule version, actual paths, both included amounts, difference and revision percentage relative to baseline. Explain each contribution by line_id, distinguishing amount changes, status changes and added excluded rows.
State business explanations the inputs do not establish. Do not call revisions month-over-month sales growth or include draft rows in approved totals.
Return review text only in the run result. Do not edit, commit, open a PR, comment, change labels, email or invoke external messaging tools. If additional actions are necessary, stop and explain.
Identical-input reruns may differ in wording but must agree on values, row IDs and inclusion decisions.Configure a bounded trial where Shared is available
GitHub’s creation and testing guide documents the Agents and Automations entry, manual form and testing through Run. Follow the currently visible interface and start with a task the team can inspect manually.
Check the actual trigger time and resource, arranging the first recurring trigger after manual acceptance. Select only the tools needed to read the agreed files. Review suggestions individually rather than granting file writes, comments or external-system writes for this example.
This article has not verified your account’s interface, tools or run result. If the needed reading capability is unavailable, record the limitation instead of treating empty output as success.
- Open the repository’s Agents → Automations → Create automation and follow the manual-creation guide to enter a name.
- Choose Shared, enter the prompt, and review triggers, tools, billing ownership and suitable trial credit limits.
- After saving, simulate a trigger through Run, inspect the session’s actual inputs and compare with the reference answer.
- After complete and failed inputs meet the contract, ask the successor to rerun and confirm the regular trigger arrangement.
Reference answer: 650 comes from two kinds of change
The baseline includes North’s 1200 and South’s 800, totaling 2000. The revision includes 1350, 800 and West’s 500, totaling 2650. The difference is 2650−2000=650; relative to baseline, the revision percentage is 650÷2000=32.5%.
L01 contributes 150 because its approved amount changes from 1200 to 1350. L03 contributes 500 because an existing amount changes from draft to approved. L04 is new but remains draft and contributes zero.
A successor should reconstruct the explanation from the row IDs. A status change must not become a new sale, and a same-period revision must not become a comparison of two months. The inputs do not establish those business explanations.
| Row ID | Baseline → revision | Included difference | Explanation |
|---|---|---|---|
| L01 | 1200/approved → 1350/approved | +150 | Amount revision; included in both versions. |
| L02 | 800/approved → 800/approved | 0 | Unchanged. |
| L03 | 500/draft → 500/approved | +500 | Existing row changes inclusion status; amount unchanged. |
| L04 | Absent → 400/draft | 0 | Added but excluded from approved totals. |
Rule report-review-v1; same 2026-10 report; USD.
Inputs reports/baseline.csv and reports/current.csv.
Baseline approved amount 2000; revised approved amount 2650.
Revision difference +650; revision percentage relative to baseline 32.5%.
L01 amount revision +150; L03 draft-to-approved inclusion +500; L02 unchanged; L04 still draft, contribution 0.
The inputs do not explain approval reasons or actual sales trends. Only review text is requested, with no publication or source edits.Check the handoff with a wrong draft and failed inputs
All raw amounts in the revised CSV do total 3050. Including the draft 400 changes the population, however, so its resulting 1050 and 52.5% do not answer this task.
Test a missing file and repeated ID separately. An absent current.csv should produce a missing-file blocker; another L02 in the revision should stop on duplicate IDs. Neither should return a definitive amount labeled as a completed review. Restore the inputs, shuffle their row order and check the same values and contributions.
These trials are recommended to the reader, not Copilot runs observed for this article. Keep input revisions, trigger context, sessions and human conclusions, distinguishing not run, failed execution and a wrong answer.
Consistent arithmetic can still use the wrong population
The revision totals 3050, up 1050 or 52.5%; West added 500 in new sales.
The approved-only amount was revised from 2000 to 2650, a difference of 650 or 32.5%. Existing L03 moved from draft to approved and contributes 500.
What the three trials establish
- Complete inputs: return 2000, 2650, 650 and 32.5%, tracing 150 and 500 to L01 and L03.
- Missing file or repeated ID: stop and identify the gap without inventing a definitive amount.
- Successor rerun: recompute from the original inputs; personnel handoff itself does not complete business review.
Hand over configuration, responsibility and reading access
Record the repository, automation name, visible configuration revision information, prompt, trigger time and time zone, tools, rule version, trial sessions and reviewer. Leave unavailable fields unknown rather than inventing official defaults.
The ownership and configuration documentation explains that shared automations belong to the repository and can continue after their creator leaves; runs are visible to people with the corresponding repository access. Configuration is not committed as repository code, so committing files does not back up the whole setup.
Name the owner of regular triggers, exceptions and credit use. This article has not configured your automation, promised execution timing or validated business records. It supplies material that can be recomputed, can identify failed inputs and can be handed over.
Before the successor takes over
- The inputs are the two agreed revisions of the same month.
- A person recomputes amounts and contributions instead of treating session completion as correctness.
- The successor can inspect required runs and manage shared configuration within their permissions.
- Prompt, tools and triggers remain traceable; the review has not silently changed source material.
- Exception ownership and billing are explicit; a credit limit is not a guarantee of no charges.
Common questions
Can an existing Personal automation be changed directly to Shared?
No. GitHub documents that its type cannot be changed after creation. Review the new shared setup and triggers before replacing a personal workflow so two tasks do not process the same material unintentionally.
Will this example send the report automatically?
Sending is outside this trial. It requests review text in the run result and limits tools. Later comments, file edits or messages would need their own authorized scope, destination and acceptance conditions.
