Pr

What the source does

• FilesystemNone observedNo reads or writes in the source
• NetworkNone observedNo outbound calls in the source
• ShellNone observedNo commands run in the source
• DependenciesPinnedNothing floats
• SecretsNone foundNo keys in source

Five audit layers

Gates applied: no behavioural pass.

.claude/agents

.claude/skills

.github/CLAUDE.md

CLAUDE.md

apps/backend/CLAUDE.md

import { test, expect } from "../../fixtures/test-base";

apps/web/generated/licenses.json

Audit 0.4.1 · source sha 786d4817799e · 18 Oct 2026Report an issue or request a re-scan

• Publisherkdlbs GitHub organizationOwner of the repository this skill is read from
• Source folderkdlbs/kandev/.agents/skills/prThe exact folder we audited
• LicenceAGPL-3.0As the repository states it
• Commit pinned for this verdict786d4817799eA new audit runs when the source changes
• Repository statusNot archivedPushed today
• Sandboxed runNot runSkills are read, not executed; layer L4 is skipped

Its description: Create a PR from a committed and pushed branch after task-defined checks pass. Ready PRs continue to fixup in the primary conversation.

---
name: pr
description: Create a PR from a committed and pushed branch after task-defined checks pass. Ready PRs continue to fixup in the primary conversation.
---

# PR

## Planner Entry

Create the PR directly in the primary conversation after commit, task-defined
checks, and push. Ready PR monitoring and remediation continue through
`/pr-fixup` in the same conversation.

> **Host detection:** This skill works on GitHub, GitLab, and Azure Repos. Detect the host before publication by inspecting `git remote get-url origin`:
> - URL contains `dev.azure.com`, `visualstudio.com`, or `ssh.dev.azure.com` → use the **Azure Repos flow** below.
> - URL contains `github.com` (or any host you have configured for GitHub) → use the **GitHub flow** below.
> - URL contains `gitlab` (e.g. `gitlab.com`, `gitlab.acme.corp`) → use the **GitLab flow** at the bottom of this file.
> - For self-managed hosts, the user's repository configuration determines the host.
>
> **GitHub tool selection:** The GitHub flow uses `gh` CLI by default. If `gh` is unavailable or fails, including a 401 authentication error, use structured GitHub connector/API tools for PR, check, and review data; authentication failure is unknown state, never clean state.
> **GitLab tool selection:** The GitLab flow prefers `glab` CLI when available; otherwise it shells `curl` against the REST v4 API using `$GITLAB_TOKEN` (which the agent runtime injects from the user's secrets store).
> **Azure Repos tool selection:** The Azure flow prefers `az repos pr create` with the Azure DevOps extension. Auth can come from an existing `az login` session or `AZURE_DEVOPS_EXT_PAT`.

## Available skills

- **`/commit`** — Creates the artifact after task-defined checks pass.
- **`/pr-fixup`** — Wait for CI checks and CodeRabbit, Greptile, Claude, OpenCode, and cubic review feedback, fix any failures or valid comments, and push.

## Options

- `--draft` — create the PR as draft and skip the fixup step. Use when the work is not ready for review.
- Default (no flag) — create as ready-for-review and continue with `/pr-fixup` in the same conversation.

**Publishing-state precedence:** explicit user state (`--draft` or an explicit
ready-for-review request) wins. If the `github:yeet` plugin is explicitly
selected, follow its draft default only when the user did not request either
state; otherwise `/pr` defaults to ready-for-review. Always report the result.

## Steps

Track these steps with an internal todo/checklist and mark them complete as you go.
Do not create, update, or delete Kandev subtasks for this workflow unless the user
explicitly requests task tracking.

1. **Uncommitted changes:** If there are dirty or staged changes, stop: commit
   and the affected task checks are required first.

2. **Branch:** If on `main` or `master`, stop and ask the user for a feature
   branch. Otherwise use the current feature branch as-is.

3. **Remote state:** Confirm the branch has an upstream and the remote contains
   the local `HEAD`. If not, run `/push` before creating the PR.

   **CI artifact bootstrap:** If the diff introduces a CI-consumed registry tag
   or artifact that a workflow on this branch must publish first, follow that
   publisher's documented bootstrap path before rerunning consumer checks.
   Request explicit user approval before a `workflow_dispatch` or other action
   writes a shared registry, and verify the target tag/digest exists.

4. **Screenshots — capture and validate before publication.** For GitHub UI
   changes, verify the attachment prerequisites in step 7 before capture. For
   every host, capture fresh screenshots for every affected viewport of a
   UI-visible change before creating the PR. For repository UI, use
   `/playwright-cli` with an isolated headless
   session or the managed `apps/web` E2E runner. See step 7 for capture routing
   and blocker classification. When the changed surface is structurally absent
   on another viewport, record that rationale instead of capturing an unrelated
   screen.
   Use synthetic or redacted data, validate the assets, and compress PNGs using
   the recipe in step 7. If capture is impossible, report the concrete blocker
   and stop before PR publication. For non-UI changes, record that screenshots
   are not required and continue.

5. **Create the PR.** Before creating, check open PRs for the current branch and
   inspect task-linked PR metadata. Reuse an existing PR; create a duplicate only
   when the user explicitly requests separate PRs. Use `--draft` if requested,
   otherwise create as ready-for-review.

   **Architecture and scope gate:** Before running any PR creation command, verify
   the authenticated actor's repository permission. Do not treat a user statement
   as proof of maintainer status. On GitHub, query
   `gh api repos/{owner}/{repo}/collaborators/{login}/permission`; `push`,
   `maintain`, and `admin` permissions are write-authorized, so those actors may
   open large or architectural PRs directly. On other hosts, use the equivalent
   repository permission check. When the host confirms write access, the
   permission itself satisfies this gate and no linked issue is required solely
   for this purpose. If permission cannot be verified, or the actor has no write
   access, require a linked issue with maintainer discussion before opening a
   large or architectural PR. If that issue or discussion is missing, stop and
   report the blocker. Do not create an issue or open a PR solely to start the
   discussion. Prefer one logical change and the smallest practical diff; split
   unrelated cleanup, refactoring, and feature work into separate PRs.

   **PR title** must follow Conventional Commits format (see `/commit` for full rules). CI validates via `pr-title.yml` — the PR title becomes the squash-merge commit used for release notes.

   **PR body** must be built from `.github/pull_request_template.md`; fail fast if it is missing. Read the whole template before writing the body.

Excerpt, first 6,000 characters of SKILL.md, verbatim from the audited commit. It is text from someone else’s repository, quoted so you can judge it before your agent reads it.

git clone https://github.com/kdlbs/kandev
git -C kandev checkout 786d4817799e

Works in

1. 2026-10-18
   !CAUTION B 89 / 100

   first audit · source 786d4817799e

Questions about Pr

• github.com/kdlbs/kandev/tree/main/.agents/skills/pr — the audited source at commit 786d4817799e and every finding aboveObserved · 18 Oct 2026

Spotted something wrong? Report a correction · Methodology