← Fullstack Dev KitCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to Fullstack Dev Kit
Snapshot Sep 30, 2026 · 23:14 UTC · version 0.19.10
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Create a branch, commit the work, and open a pull request for a completed user story, after all quality gates pass. Use when the user asks to open/create a PR or as the final step of the story workflow.",
"included_files": [],
"name": "create-pr",
"skill_md_contents": "---\nname: create-pr\ndescription: Create a branch, commit the work, and open a pull request for a completed user story, after all quality gates pass. Use when the user asks to open/create a PR or as the final step of the story workflow.\n---\n\n# Create PR\n\nFinal step of the story workflow. Runs when the **applicable** gates pass (gates are adaptive to the project — see `instructions/testing-standards.md`).\n\n## Preconditions (verify, do not assume)\n\n1. Unit tests for touched files pass — *when the project has a test framework*.\n2. `coverage-check` passes — *when the project has coverage tooling* (project's bar, default ≥ 95%, no regression).\n3. Related e2e tests pass — *when the project does e2e* (`e2e-generate` ran for user-facing changes).\n4. Lint passes for touched files — *when the project lints*.\n5. A `pr-review`-style self-review found no unresolved blocking findings.\n6. Security pass has no blocking findings (**always applies**).\n\nA gate that **does not apply** (no test/e2e/lint setup) is not a blocker — but it must be **called out in the PR \"How it was verified\" section** as *not applicable, recommend adding*, never omitted. A gate that applies and **fails** stops the PR: report what's missing instead of opening it. (A `gates` policy in `.claude/dev-kit.json` can force `required`/`off`.)\n\n## Branch & commit\n\n1. Branch from the repo's default integration branch. Naming: `<type>/<TICKET-KEY>-<short-slug>` (e.g. `feat/PROJ-1234-payment-status-filter`). Follow the repo's convention if one exists.\n2. Stage only files related to the story. List anything intentionally left out.\n3. Commit message: `<type>: <TICKET-KEY> <imperative summary>` plus a short body of key changes. Follow the repo's convention if one exists.\n\n## Pull request\n\nOpen the PR on the configured host (`prHost` in `.claude/dev-kit.json`; default `github`). Branch/commit/push are the same everywhere (plain git); only the \"open the PR\" call differs:\n\n- **github** — `gh pr create` (`gh` authenticated).\n- **bitbucket** — push the branch, then create the PR via the REST API: `POST https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/pullrequests` with `{title, source:{branch:{name}}, destination:{branch:{name}}}`, authenticated with a Bitbucket app password / access token from the environment (e.g. `BITBUCKET_TOKEN`). The `acli` CLI works too if the team uses it. Derive `{workspace}/{repo_slug}` from the `origin` remote.\n- **gitlab** — `glab mr create` (`glab` authenticated).\n- **azure** — `az repos pr create --source-branch <branch> --target-branch <base> --title <title> --description <body>` (Azure CLI with the `azure-devops` extension, `az login` authenticated; run `az extension add --name azure-devops` once if missing). The org/project/repo come from the `origin` remote or `az devops configure --defaults`.\n- **other/none** — print the branch and the ready-to-paste PR title/body and let the user open it.\n\nThe body must include (adapt field names to the host — GitHub/GitLab render Markdown; Bitbucket PR descriptions accept Markdown too):\n\n```\n\n\n## <TICKET-KEY>: <story title>\n\n### Summary\n<the product-facing summary: what was delivered in user terms and the\ndecisions taken, plain language — same content as the tracker comment>\n\n### What changed\n- ...\n\n### How it was verified\n- Unit tests: <command + result>\n- Coverage on touched files: <summary — meets the project's bar>\n- E2E: <suites run + result>\n- Security pass: <verdict>\n- Lint: clean\n\n### Notes for reviewers\n- <risks, follow-ups, technical decisions>\n\n### Delivery readiness\n<Include only the lines that apply — skip this whole section for trivial/internal changes; don't pad.>\n- Rollback: safe to revert this PR on its own? Flag anything that isn't.\n- Migrations: reversible and safe on a live DB (no long locks; backfill plan)?\n- Config/secrets: new keys have safe defaults; nothing required-but-undocumented.\n- Docs/contract: user-facing or API changes reflected in the docs.\n- Breaking change / behind a feature flag: called out explicitly.\n\nIssue: <link to the tracker item>\n\n---\n🤖 Generated with [Claude Code](https://claude.com/claude-code) via the\nfullstack-dev-kit plugin. Plan approved by a human before implementation;\nhuman review still required before merge.\n```\n\nUse the repo's PR template instead if one exists (`.github/PULL_REQUEST_TEMPLATE.md`), adding the badge, summary, verification evidence, and AI footer into it.\n\n**AI traceability metadata**, best effort after creation:\n\n- Add an `ai-generated` label/tag to the PR when the host supports it — GitHub: `gh pr edit <url> --add-label ai-generated` (create it once with `gh label create ai-generated --color 8A2BE2` if missing), then **verify it stuck** with `gh pr view <url> --json labels` — `gh pr edit` can error without applying anything on repos whose org ever used classic Projects; on a miss, apply via REST: `gh api repos/<owner>/<repo>/issues/<pr-number>/labels -f \"labels[]=ai-generated\"`. Bitbucket/GitLab: skip or use the host's equivalent. If not possible, skip silently — the badge and footer already carry the signal.\n\n## After creation\n\nReport the PR URL, the verification evidence, and any follow-up risks explicitly.\n"
}SHA-256 of public snapshot: 26349ef1ada85fc9ca0f64e89d421222d124bac7990be05d17a95f21aee74813