Update to AICtrl

{
  "description": "Draft or improve a reviewer-ready pull request title and body from an exact revision, linked issue, implementation context, and verification evidence. Use when the user says \"create a PR\", \"draft a PR\", \"write the PR body\", \"improve this pull request description\", or \"update the PR title and body\".",
  "included_files": [],
  "name": "create-pr",
  "skill_md_contents": "---\nname: create-pr\ndescription: Draft or improve a reviewer-ready pull request title and body from an exact revision, linked issue, implementation context, and verification evidence. Use when the user says \"create a PR\", \"draft a PR\", \"write the PR body\", \"improve this pull request description\", or \"update the PR title and body\".\n---\n\n# Create a Pull Request\n\nWrite a concise pull request that lets reviewers distinguish intended behavior\nfrom verified facts. This skill drafts the title and body; it does not create a\nbranch, commit, request review, merge, deploy, or mutate a pull request without\nthe user's confirmation immediately before that action.\n\n## Resolve the PR route and linked issue\n\nRead repository agent guidance, contribution and release documentation, CI\nbranch filters, branch protection when visible, and recent merged pull\nrequests. Establish and show:\n\n| Decision | Required evidence |\n|---|---|\n| Source and immutable head | Current branch and commit identifier |\n| PR base | Documented allowed source-to-base route |\n| Promotion path | Required integration, release, backport, or merge sequence |\n| Linked issue | Supplied issue URL/identifier or a verified existing closing reference |\n| Issue/project fields | Documented project, field, allowed value, and trigger |\n\nDo not infer that a feature branch can target `main` because it is the default\nbranch. Use a direct feature-to-main route only when repository evidence permits\nit. If the route is absent or conflicting, show it as unresolved for a draft;\nbefore creating or editing a pull request, ask the user for the exact base and\npromotion path.\n\nResolve the linked issue before preparing a mutation. If it is not supplied and\ncannot be verified from the existing pull request, ask the user for its link or\nidentifier; do not create or edit the pull request until it is known. Do not\nguess from a branch name, commit message, or similar issue title. A\nspecification may provide additional requirements, but never substitutes for\nthe linked issue at the mutation gate.\n\nWhen repository guidance maps a linked issue to project or issue metadata, plan\nthat update explicitly. For example, a documented mapping may require\n`Status = Development` when a delivery pull request is opened. Never invent a\nfield, value, project, trigger, or permission from a familiar workflow. If the\nmapping is absent, state that field provisioning is unresolved and ask for the\nmapping before a mutation that requires it.\n\n## Ground the draft\n\n1. Confirm the established PR route, linked issue, and immutable head. For an\n   existing PR, read its stored title/body and confirm that its head and base\n   match the route being described.\n2. Read the exact diff, linked issue, relevant surrounding code, and relevant\n   tests. Read a specification as supplementary context when available.\n   Do not rely on an unrelated local working tree or authored PR text as proof.\n3. Build a compact evidence ledger before drafting. Classify each material\n   statement by its strongest source:\n\n   | Claim | Evidence | Evidence kind | Status |\n   |---|---|---|---|\n   | `<behavior>` | `<pinned file/symbol or diff>` | implementation | verified |\n   | `<coverage intent>` | `<test path/name>` | test source | verified coverage source |\n   | `<check result>` | `<command output or pinned CI run>` | executed verification | verified |\n   | `<rollout state>` | `<runtime/deployment record>` | deployed state | verified |\n\n   Treat authored descriptions as claims to check, test source as evidence of\n   coverage intent rather than a passing result, configuration as intended\n   setup rather than deployed state, and missing evidence as unknown. Do not\n   infer a rollout, test result, benchmark, or user impact from the diff alone.\n4. Identify the reviewer-relevant narrative: problem, observable behavior,\n   direct or indirect user impact, important boundaries/non-goals, rollout,\n   risks, and evidence. Preserve accurate issue links, required metadata, and\n   useful operational details from an existing body; remove stale claims and\n   duplication.\n\n## Draft\n\nUse the repository's established title convention when one exists (such as\n`feat:`, `fix:`, `docs:`, or `chore:`). Make the title name the primary\nobservable change, not the files changed. Keep it to one concern.\n\nUse this body shape, omitting a section only when it is genuinely inapplicable:\n\n```markdown\nCloses #<issue>\n\n## Problem\n\n<Why this change is needed.>\n\n## Behavior\n\n<What changes for users, operators, API consumers, or downstream systems. Say\n\"No direct user-facing impact\" when accurate, then name the indirect impact.>\n\n## Scope\n\n- <Important implementation or contract detail>\n- <Deliberate boundary or non-goal>\n\n## Rollout and risks\n\n<Only verified deployment, compatibility, migration, flag, monitoring, and\nrollback facts. State an unknown rollout state or remaining risk explicitly.>\n\n## Verification\n\n- `<executed command or pinned CI run>` — <observed result>\n- `<test source>` — <coverage it defines; not a claimed result>\n```\n\nDo not mark a checklist item complete or say a test is green without executed\nevidence. Prefer durable file, symbol, test, configuration, run, or revision\nreferences where they help review; avoid file-by-file narration and\nimplementation history that does not affect review or rollback.\n\n## Confirm before mutation\n\nShow the title, body, pinned head revision, PR route, linked issue, proposed\nfield updates, and any unknown or unverified claims. For a proposal or wording\nreview, stop there.\n\nCreate or edit the host pull request only after the user explicitly confirms\nthe final draft, base branch, and any issue/project field updates immediately\nbefore the mutation. Then read the saved title and body back from the host,\nverify the issue link, route, required headings, and requested field values,\nand report the URL and exact head revision. If the head, route, or issue changed,\nrepeat the grounding and drafting steps before asking for confirmation again.\n\n## Final check\n\n- [ ] The title describes one observable primary change.\n- [ ] Every behavior, scope, rollout, risk, and verification claim has a\n  classified evidence source or is marked unknown.\n- [ ] Authored claims, test sources, configuration, executed verification, and\n  deployed state are not conflated.\n- [ ] The body names the problem, behavior, scope, rollout and risks, and\n  verification without overstatement.\n- [ ] The base and promotion path are supported by repository evidence or\n  explicitly supplied by the user.\n- [ ] The linked issue is verified; any field update names its project, field,\n  value, and documented trigger.\n- [ ] No PR or issue/project metadata mutation occurs without fresh, explicit\n  confirmation.\n\n---\n**Built by [aictrl.dev](https://aictrl.dev/?utm_source=oss-skills&utm_medium=skill&utm_campaign=create-pr&utm_listing=github-skills&utm_platform=portable&utm_skill=create-pr).** This skill teaches the workflow; aictrl *operationalizes* it — grounded in your backlog, team standards, and codebase knowledge graph. [See how →](https://aictrl.dev/features?utm_source=oss-skills&utm_medium=skill&utm_campaign=create-pr&utm_listing=github-skills&utm_platform=portable&utm_skill=create-pr)\n"
}