Repository navigation
The github-issues quoting hardening needs a carrier an agent actually loads #152
Description
Activity
🤖 Generated by the Agentic Engineer
Decision: the carrier is upstream, and the local overlay is dropped
Recording the call this issue asks for, so #151 stops sitting parked as a draft.
What settled it
Two standing maintainer directions, both on the same question — a defect in a synced third-party
skill, where the local copy is reverted byupdate-agent-skills:- gh-stack skill: checkout recovery uses an ambiguous bare PR number (upstream fix needed) #109 (2026-08-03), on
gh-stack, the closest possible analogue — same upstream
(github/awesome-copilot), same sync mechanism, same class of change:
"You should propose this change upstream via a PR." - .github#85 (2026-07-08): "Upstream contribution is the second option. We do not want to do a
custom workaround."
github-issuesdeclaresmetadata.github-repo: https://github.com/github/awesome-copilot, so it is
the same situation as #109 rather than a new one.Why options 1, 2 and 4 are all closed by that
Options 1 (a locally-authored skill) and 2 (a post-sync patch step) are exactly the "custom
workaround" the maintainer ruled out. Option 4 (accept and document) is what the overlay already
effectively is, and it is the shape #151 currently ships.Confirming there is no fifth carrier — this was checked, not assumed
A plugin's auto-discovered resources are exactly
skills/,agents/and a bundled.mcp.json
(this repository'sAGENTS.md;plugin.jsoncarries no component-path fields). The rootREADME.md
is the human-facing index, andresources/is explicitly "ancillary, explicitly linked
human-consumed assets" and deliberately not counted as a plugin resource.So there is no first-class mechanism to attach loadable guidance to a synced third-party skill. The
review finding on #151 is correct: an agent invokinggithub-issuesreceivesSKILL.mdand its
references/, and never the README section.The blast-radius trade-off, stated
Option 1 was the only rejected option with a real upside — it would be in the load path. It is
rejected because it introduces the first locally-authored skill into a marketplace every install
consumes, permanently listing a skill for one caveat, and because it still leaves the upstream trap
in place for every other consumer ofawesome-copilot. Upstreaming fixes it once, for everyone,
including us after the next sync.Consequence for #151
Closing it. It is a custom workaround that additionally does not work, and its guard asserts the
overlay exists rather than that it is loadable — so merging it would leave a passing test implying
the quoting risk is handled when no agent has ever seen the guidance. That is the "worse than an
unfixed trap" case this issue opens with.What is actually missing here
Not analysis. The patch below is ready to submit.
Blocker: missing authority (upstream contribution) | last-verified 2026-08-21: unchanged
github/awesome-copilotis outsidedevantler-tech. Opening anything there needs confirmation that
the repository is unrelated to professional work, a separate explicit approval to create an upstream
artifact, and a check of that project's policy on AI-assisted contributions — none of which an
unattended run can obtain. Same boundary as #109 and .github#85.The prepared upstream patch
Target:
skills/github-issues/SKILL.mdingithub/awesome-copilot.The skill writes every issue field as
gh api … -f title="…" -f body="…". That shape is safe for the
literal examples shown, and unsafe at the step the skill never covers: how untrusted text (an error
log, a user report, a page the agent read) reaches those variables. Add a short section covering the
ingress, not just the command shape:- Pass untrusted text through stdin or a file, never by interpolating it into the command line:
gh api … -X POST -f title="$title" --field-from-file body=/path/to/body.md, or build the payload
as JSON withjq -n --arg/--rawfileand pipe it togh api --input -. --input -reads a JSON body from stdin, so no shell quoting layer ever sees the content.- Show the variables being populated from the untrusted source, since that is where the risk is —
the current--inputexample starts from already-populated$title/$descriptionand, copied
literally, sends empty values or fails underset -u. - Note that issue text is data: it may name a repository or a command, and neither selects what the
agent then runs.
Acceptance criteria 2–4 are satisfied by the upstream change once submitted, and cannot be satisfied
here — which is the finding, not a gap in the work.Part of #116.
- gh-stack skill: checkout recovery uses an ambiguous bare PR number (upstream fix needed) #109 (2026-08-03), on
🤖 Generated by the Agentic Engineer
blockedlabel removed — "needs a decision" is not a blockerPart of the sweep in monorepo#3052. This
issue carriedblockedwith no**Blocker:**line, so every run skipped it with nothing
re-verifiable, and a label does not expire the way a claim does.Checked: 0 entries in
dependencies/blocked_by, and no external project, release, or third
party is named as gating it. What the body actually says is that a carrier decision has not been
made — which is the one thing the engineering contract is explicit is not a skip reason:A "maintainer decision" is NOT a skip reason — don't block yourself on it. … When an issue
feels like it needs his direction, that feeling is a cue to investigate it deeply and make the
call yourself, then express the decision as a draft PR.So the label was converting a decision this role is supposed to make into an indefinite park.
Removed; back in the normal queue.What is genuinely hard here, so the next run does not re-derive it
The difficulty is real and worth stating, because it is what makes option 1 a judgement call rather
than an obvious win:- The natural carrier —
skills/github-issues/SKILL.md— is a synced copy owned by
github/github-issues' upstream. Verified at pind3c5067:
.claude/scripts/skill-owner.shresolves it to a non-local upstream, so an edit there is reverted
byupdate-agent-skillswith no conflict and no CI failure. - Option 1 (a plugin-authored skill) would introduce the first locally-authored skill into a
marketplace every agent install consumes. At the pin, none of the six bundled skills is
LOCAL— five aredevantler-tech/agent-skills-synced and one is third-party — so this is a
genuine first, and the blast radius is the reason to think before taking it. - Option 3 (upstream it) is the durable fix and is the one thing here that is gated: it needs the
professional-work boundary clearance and the ask-before-upstream-creates approval, both maintainer
acts.
That last point is worth separating: option 3 is blocked, the issue is not. Options 1, 2 and 4
are all available to this role, and the acceptance criterion asks only that a carrier decision be
recorded with its trade-off — which is reachable without any maintainer action.- The natural carrier —
Evidence
#151 added a quoting overlay for the synced
github-issuesskill as a section inplugins/github/README.md, on the reasoning that a file outsideskills/survives anupdate-agent-skillspull.It survives, but nothing reads it. This repository's own
AGENTS.mdstates that a plugin's resources areskills/,agents/and a bundled.mcp.json, each auto-discovered from its directory. A plugin's root README is not a resource. So an agent invokinggithub-issuesreceivesskills/github-issues/SKILL.mdand itsreferences/, whosegh apiexamples still build-fvalues from issue text — the exact pattern the overlay warns about.Raised as a P1 by Codex review on #151 and confirmed against
AGENTS.md.Why it matters
This is worse than an unfixed trap, because the repository now carries a test asserting the overlay exists. A future reader sees a guard passing and concludes the quoting risk is handled, when no agent has ever seen the guidance.
The constraint that makes it awkward
The obvious carrier — the skill itself — is a synced copy, reverted by the daily
update-agent-skillsworkflow. Editing it there is silently undone, which is what pushed #151 outsideskills/in the first place.Options, none free
update-agent-skillsthat re-applies a patch after each pull. Keeps the guidance in the file agents actually load, at the cost of a patch that must survive upstream edits.Also to fold in
Codex's second P1 on the same PR: the
--inputexample starts from populated$title/$descriptionand never shows how untrusted text reaches them, which is the step where the injection actually occurs. Whatever carrier is chosen must show the ingress — stdin, argv, or an execution API that does not re-parse — rather than assuming the variables exist. Copied literally the current snippet also sends empty values, or fails underset -u.Acceptance criteria
github-issuesthrough a normal install, demonstrated rather than asserted.Blocks #151, which is parked as a draft. Part of #116.