AI Agent PR Metadata

Use this when a repository needs traceable AI assistance metadata in GitHub while keeping commit history human-authored and attribution-free.

Rules

• Commit attribution follows system-level/core.md (Git: do not add AI co-author lines or AI attribution to commit messages). This skill governs where the traceable detail goes instead: PR bodies, PR comments, and PR review bodies only.
• Never guess the model name. Read the authoritative resolved model+version from the runtime or orchestrator; a product alias is not evidence of a model ID.
• Include a run URL when the work was produced by GitHub Actions or another traceable runner.
• Public issues, PRs, comments, and review records must never include credential values or local credential-file paths. Use Credential details: [redacted] instead.
• Never write a third-party issue/PR reference as literal owner/repo#123 text, or a full https://github.com/... URL to it, in any repo's own PR title, PR body, commit message, or issue text. This isn't only a tracker/automation-repo risk. Both forms trigger the cross-reference, confirmed by two separate incidents:
  • A tracker PR's body containing bare shopware PR #20080 text created a public "mentioned this pull request" backlink on that PR's timeline, disproving an earlier (wrong) version of this rule that claimed the bare form was safe. GitHub creates this cross-reference regardless of the referencing repo's visibility: non-collaborators can't open the private repo, but they do see your username and the referencing PR/commit's title, exposing that a private multi-repo campaign tool exists.
  • An ordinary skill-repo PR's commit message, citing a real upstream PR as measured evidence for a new rule, created the same kind of backlink on that upstream PR's timeline (source: our own merged PR, not a tracker repo at all). The rule applies any time a commit message cites another public repo's issue/PR number as evidence, reference, or context, regardless of what kind of repo you're committing to.
  • Confirmed safe by direct testing: a repo name with no owner prefix (gscan#908) and an owner/repo name with a space before the # (fabric-samples #1438) do not trigger the cross-reference. GitHub's autolinker requires the unbroken owner/repo#number (or github.com URL) pattern.
  • Preferred safe form when a PR/issue body must reference one: wrap it in inline code backticks, e.g. `owner/repo#123`. GitHub's autolinker does not activate inside a code span, and this stays readable as the real identifier.
  • For commit messages, don't rely on code-span rendering (git tools display commit messages as plain text, and GitHub's own commit-message rendering is less consistently backtick-aware than issue/PR bodies). Break the adjacency outright instead: write repo, PR 123 or repo PR #123 (space before the #) rather than owner/repo#123.
  • Content committed to tracked files (a markdown tracker doc, a JSON record) is not itself scanned for cross-references, only PR/issue titles, bodies, comments, and commit messages are. A full owner/repo#123 string sitting in a data file's prose is safe; the risk is specifically in what you type into a PR/issue/commit-message field.
  • If a leak already happened in a PR/issue title or body: renaming it to a neutral title fixes what's displayed on the target's timeline going forward (GitHub renders the title live at read time), but the cross-reference event itself cannot be removed. Prevention is the only real fix.
  • If a leak happened in a commit message that's already merged to a shared default branch, there is no safe fix at all: correcting the message means rewriting that branch's history, and every repo's own git-workflow rules forbid force-pushing main/staging with no exception for cleaning up your own commit. Check before you write a commit message that cites another repo's issue/PR number, not after.