Release Aur

Release AUR

Use this skill for AUR package creation, updates, release readiness reviews, publishing decisions, and /release-aur-setup prerequisite workflows.

Mandatory workflow

1. Start with /release-aur plan <target> unless the user explicitly asks only to create a repo.
2. Review the generated preflight output and inspect files when needed:
   • PKGBUILD
   • .SRCINFO
   • git status --porcelain=v1
   • git diff -- PKGBUILD .SRCINFO
   • git diff --cached if anything is staged
3. Confirm these gates before GO:
   • makepkg --printsrcinfo succeeds.
   • .SRCINFO is present or will be regenerated by publish mode.
   • makepkg --verifysource succeeds.
   • full makepkg build/check/package succeeds.
   • no namcap E: findings unless the user explicitly accepts a justified exception.
   • no build artifacts, secrets, or unrelated files are staged or likely to be auto-staged.
   • dependencies are direct and explicit, not merely transitive.
   • latest-release update check ran against the configured source (global/per-package/auto) or was explicitly skipped with justification.
   • pkgver matches upstream and pkgrel is reset to 1 when upstream pkgver is bumped.
   • checksum arrays were refreshed with updpkgsums after a version bump.
   • VCS packages are not committed for a mere upstream pkgver bump.
4. Return GO only when publish is appropriate. Include the exact command:

   textCopy code
   /release-aur publish <target>
   

5. Return NO-GO with exact fixes when any blocker remains.
6. Never push manually with raw git push unless the user explicitly bypasses the package workflow. Prefer /release-aur publish because it regenerates .SRCINFO, stages conservatively, commits, and pushes to AUR master.

Setup flow

Use /release-aur-setup when the user needs AUR release workflow prerequisites prepared. The setup workflows are:

textCopy code
/release-aur-setup dir [path-to-aur-repos]
/release-aur-setup source [global <source>|package <pkgbase> <source>|clear <pkgbase>|status]
/release-aur-setup ssh

The extension should use native Pi UI to prompt for the directory where the user stores AUR package repos. Persist it in ~/.pi/agent/release-aur/config.json; bare /release-aur should use it to list repos and prompt where the release should run. If no directory is configured, current-directory discovery is the fallback.

For upstream release checks, the setup flow should use native Pi UI to configure a global release source and optional per-package overrides in the same config file. auto means detect GitHub from PKGBUILD; custom sources may be github:owner/repo, GitHub URLs, git:<clone-url>, or git clone URLs. Per-package overrides must win over the global source.

For SSH access, the extension should use native Pi UI, follow ArchWiki AUR authentication guidance, check ~/.ssh/config first for an existing Host aur.archlinux.org block, directly test that existing connection before creating keys or editing config, make /release-aur-setup status run local file/config checks, release source status, and the AUR SSH connection test, create/configure only under ~/.ssh after confirmation when setup is still needed, prefer a dedicated ~/.ssh/aur key, show/copy the public key for the user to add in AUR My Account, and test SSH auth only after the user confirms the public key was added. Do not claim remote AUR auth is complete until the SSH test succeeds.

Create flow

For a new or partially prepared AUR package repo:

textCopy code
/release-aur create <pkgbase>

create is convergent: it handles a missing/empty directory, an existing git repo, or an existing non-git directory containing PKGBUILD. It sets up the AUR remote, generates .SRCINFO when possible, then runs plan checks and queues review.

If PKGBUILD is missing, the extension must use Pi native UI to ask whether the user wants the agent to create it, copy it from a path, create a bundled Python/Rust/Go GitHub-source template via template selector, or add it later.

For a single command that continues to push after setup and checks, use only with explicit user intent:

textCopy code
/release-aur create <pkgbase> --push

This still requires interactive confirmation before the commit/push. Only recommend --push after a GO review or when the user explicitly accepts the risk.

Evidence standard

Cite observed local command output and local ArchWiki guidance when making release decisions. Relevant local ArchWiki sections include:

• /usr/share/doc/arch-wiki/html/en/AUR_submission_guidelines.html — Authentication
• /usr/share/doc/arch-wiki/html/en/AUR_submission_guidelines.html — Creating package repositories
• /usr/share/doc/arch-wiki/html/en/AUR_submission_guidelines.html — Publishing new package content
• /usr/share/doc/arch-wiki/html/en/.SRCINFO.html — .SRCINFO
• /usr/share/doc/arch-wiki/html/en/Creating_packages.html — Testing the PKGBUILD and package
• /usr/share/doc/arch-wiki/html/en/Creating_packages.html — Checking package sanity
• /usr/share/doc/arch-wiki/html/en/Arch_package_guidelines.html — Reproducible builds
• /usr/share/doc/arch-wiki/html/en/SSH_keys.html — Generating an SSH key pair
• /usr/share/doc/arch-wiki/html/en/SSH_keys.html — Choosing the key location and passphrase

Decision format

markdownCopy code
## AUR Release Review — <target>

Verdict: GO / NO-GO
Confidence: NN/100

Checks:
- latest release update check: PASS/WARN/FAIL/SKIPPED
- makepkg --printsrcinfo: PASS/FAIL
- .SRCINFO sync: PASS/WARN/FAIL
- makepkg --verifysource: PASS/FAIL
- makepkg build/check/package: PASS/FAIL
- namcap: PASS/WARN/FAIL/SKIPPED
- git staging safety: PASS/FAIL
- versioning policy: PASS/FAIL

Decision:
- If GO: `/release-aur publish <target>`
- If NO-GO: blocking fixes in order