feat(pr-workflow): add the pull request loop plugin, and sync the marketplace versions

.claude-plugin/marketplace.json

@@ -5,14 +5,14 @@
     "email": "opensource@codelitt.com"
   },
   "metadata": {
-    "version": "1.2.0",
-    "description": "Claude Code skills for AI-native development: quality assurance, supply chain security, and architecture patterns"
+    "version": "1.3.0",
+    "description": "Claude Code skills for AI-native development: quality assurance, supply chain security, the pull request loop, and architecture patterns"
   },
   "plugins": [
     {
       "name": "qa-check",
-      "version": "3.1.0",
-      "description": "Review code changes for AI Quality Paradox violations and AI-native architecture anti-patterns. Complements Claude Code's built-in /code-review: /code-review hunts correctness bugs; qa-check owns AI-specific quality decay and architecture, including rework risk, test integrity (weakened or gamed tests), dependency provenance, spec discipline, validation gaps, and maintainability smells. Ships a deterministic push gate (PreToolUse hook, no LLM calls): repos with a .qa-check-required file block git push until /qa-check has run.",
+      "version": "4.0.0",
+      "description": "Examine code changes for AI Quality Paradox problems, AI-native architecture problems, and agent-buildability. This plugin is an addition to the /code-review command in Claude Code. The /code-review command finds correctness defects. This plugin finds AI-specific quality decay and architecture defects: rework risk, test integrity (weak tests, error paths with no test, tests that use external resources), dependency source, specification discipline, secrets in the code, agent configuration files, prompt injection paths, missing data checks, and maintainability problems. It also supplies a deterministic push gate as a PreToolUse hook, with no LLM calls: in a repository that has a .qa-check-required file, git push stops until /qa-check runs.",
       "author": {
         "name": "Codelitt",
         "email": "opensource@codelitt.com",
@@ -23,13 +23,24 @@
     {
       "name": "supply-chain-check",
       "version": "1.1.0",
-      "description": "Single-command supply chain security audit. Queries live advisory sources (npm audit, OSV.dev, GitHub Advisory Database) and scans for dangerous version ranges, lock file issues, typosquatting, slopsquatting and hallucinated dependencies, and local IOC artifacts. Wraps npm audit with active threat heuristics.",
+      "description": "Single-command supply chain security audit. Scans for compromised packages, dangerous version ranges, lock file issues, CVEs, typosquatting, slopsquatting (hallucinated dependencies), and local IOC artifacts. Wraps npm audit and live advisory sources (OSV.dev, GitHub Advisory Database) with active threat heuristics.",
       "author": {
         "name": "Codelitt",
         "email": "opensource@codelitt.com",
         "url": "https://github.com/codelittinc"
       },
       "source": "./plugins/supply-chain-check"
+    },
+    {
+      "name": "pr-workflow",
+      "version": "1.0.0",
+      "description": "Five skills that make one pull request loop: write the pull request, review it, answer the review, and record the work that you defer. /pr-create writes a title and a description from the branch diff. /pr-create-reviewed opens a draft, examines the diff with subagents that have no session context, and marks the pull request ready after you triage the findings. /review-pr examines a pull request and writes the feedback in Simplified Technical English (ASD-STE100); it prints the review for your own pull request and posts comments on a pull request from a different author. /pr-address-comments collects every unresolved comment, triages each one with you, applies the fixes, and answers each thread. /issue-create files the work that you defer. The skills share two rules: the description states the end state and does not narrate the session, and the author decides each finding.",
+      "author": {
+        "name": "Codelitt",
+        "email": "opensource@codelitt.com",
+        "url": "https://github.com/codelittinc"
+      },
+      "source": "./plugins/pr-workflow"
     }
   ]
 }

README.md

@@ -35,18 +35,24 @@ Then install the plugins you want:
 ```
 claude plugin install qa-check@ai-native-development
 claude plugin install supply-chain-check@ai-native-development
+claude plugin install pr-workflow@ai-native-development
 ```
 
 Installed plugins receive updates when new versions are published.
 
 ### Or copy individually
 
-Copy a skill folder from `plugins/<name>/skills/<name>/` to `~/.claude/skills/` to use it without the plugin system.
+Copy a skill folder from `plugins/<plugin>/skills/<skill>/` to `~/.claude/skills/` to use it without the plugin system. The five pull request skills live in one plugin, `pr-workflow`, because they call each other; copy the whole set if you copy any of them.
 
 | Skill | Command | What it does |
 |-------|---------|-------------|
 | [qa-check](plugins/qa-check/skills/qa-check/) | `/qa-check` | Reviews code changes for rework risk, weakened or missing tests, dependency provenance, missing specs, AI slop, and validation gaps. Complements the built-in /code-review, which hunts correctness bugs. Based on the AI Quality Paradox research. |
 | [supply-chain-check](plugins/supply-chain-check/skills/supply-chain-check/) | `/supply-chain-check` | Single-command supply chain security audit. Queries live advisory sources (npm audit, OSV.dev, GitHub Advisory Database) and scans for dangerous version ranges, lock file issues, typosquatting, slopsquatting, and local IOC artifacts. |
+| [pr-create](plugins/pr-workflow/skills/pr-create/) | `/pr-create` | Reads the branch diff, writes a title and a description, and opens the pull request. The description states the end state of the diff, inside a sentence and bullet budget. It never narrates the session. |
+| [pr-create-reviewed](plugins/pr-workflow/skills/pr-create-reviewed/) | `/pr-create-reviewed` | Opens the pull request as a draft, reviews it with subagents that get only the diff, and marks it ready after you triage the findings. The reviewers get no session context, so they do not inherit the reasoning of the author. |
+| [review-pr](plugins/pr-workflow/skills/review-pr/) | `/review-pr` | Reviews a pull request for code quality, security, and the rules of the repository. Writes every finding in Simplified Technical English. Prints the review for your own pull request; posts comments on someone else's, after you approve them. |
+| [pr-address-comments](plugins/pr-workflow/skills/pr-address-comments/) | `/pr-address-comments` | Collects every unresolved comment from all three GitHub comment APIs, triages each one with you, applies the accepted fixes, and answers each thread. |
+| [issue-create](plugins/pr-workflow/skills/issue-create/) | `/issue-create` | Files an issue that matches the conventions of the repository. Searches for a duplicate, names the mechanism and the files, and separates a confirmed fact from a hypothesis. |
 
 ## Related projects
 

plugins/pr-workflow/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "pr-workflow",
+  "version": "1.0.0",
+  "description": "Five skills that make one pull request loop: write the pull request, review it, answer the review, and record the work that you defer. /pr-create writes a title and a description from the branch diff. /pr-create-reviewed opens a draft, examines the diff with subagents that have no session context, and marks the pull request ready after you triage the findings. /review-pr examines a pull request and writes the feedback in Simplified Technical English (ASD-STE100); it prints the review for your own pull request and posts comments on a pull request from a different author. /pr-address-comments collects every unresolved comment, triages each one with you, applies the fixes, and answers each thread. /issue-create files the work that you defer. The skills share two rules: the description states the end state and does not narrate the session, and the author decides each finding.",
+  "author": {
+    "name": "Codelitt",
+    "email": "opensource@codelitt.com",
+    "url": "https://github.com/codelittinc"
+  }
+}

plugins/pr-workflow/skills/issue-create/SKILL.md

@@ -0,0 +1,187 @@
+---
+name: issue-create
+version: 1.0.0
+description: |
+  File a GitHub issue that obeys the title, label, and body conventions of the
+  repository. The skill learns those conventions from the issues that exist,
+  and it does not use a fixed template. It works from a short description or
+  from the current conversation, such as a defect that you just found or a
+  finding that a review deferred. It searches for a duplicate before it files,
+  it grounds the issue in the code by naming the file and the mechanism, it
+  separates a confirmed fact from a hypothesis, it records where the issue came
+  from, and it reads the label list of the repository instead of inventing a
+  label.
+  Use this skill to file a defect, a feature request, or work that a pull
+  request review deferred.
+  Triggers: "create an issue", "file a bug", "open a GitHub issue", "track this
+  as an issue", "file a follow-up".
+allowed-tools:
+  - Read
+  - Write
+  - Bash
+  - Grep
+  - Glob
+---
+
+# Create a GitHub issue
+
+File an issue that agrees with the conventions of this repository. The conventions are in the issues that exist, not in a fixed template. Read them first.
+
+The skill works from the context that is available: the current conversation, such as a defect that you found, a review follow-up, or an edge case that a triage deferred; or a short description in the argument.
+
+## Technical names in this document
+
+This document uses Simplified Technical English (ASD-STE100). These technical names have no approved equivalent:
+
+| Technical name | Meaning |
+|---|---|
+| Provenance | The place that the issue came from, such as a pull request review or an investigation |
+| Mechanism | The code path that causes the problem, not the symptom that a user sees |
+| Taxonomy | The set of labels that the repository uses |
+| Load-bearing domain | The part of a repository where a defect is most expensive |
+
+## Usage
+
+```bash
+/issue-create <a short description of the defect, feature, or follow-up>
+/issue-create                    # take the issue from the current conversation
+```
+
+---
+
+## Step 1: Collect the context
+
+**Find the subject of the issue.**
+
+- From the conversation: use the defect, the finding, or the follow-up that you discussed most recently. If there is more than one candidate, ask the user which one. You can also offer to file more than one issue.
+- From the argument: use the description as the start, then add what you find in the code.
+
+**Ground the issue in the code.** A good issue names the mechanism, not only the symptom:
+
+- Find the files and the functions, and put each path in backticks, for example `src/charges/candidates.ts`.
+- Separate what you confirmed from what you suspect. Write "Confirmed:" for a fact that you verified. Write "Suspected, not yet reproduced" for a hypothesis.
+- Record the provenance: the pull request review, the investigation, or the conversation that found this. For example: "Follow-up from the review of PR #121".
+
+## Step 2: Learn the conventions of this repository
+
+Read the issues that exist. Do not assume a format.
+
+```bash
+gh issue list --state all --limit 30 --json number,title,labels \
+  --jq '.[] | [(.number|tostring), .title, ([.labels[].name] | join(","))] | @tsv'
+gh issue view <a recent issue number>   # read two or three bodies in full
+```
+
+Record these items:
+
+- The title format. Many repositories use `scope: a specific description`. Some use a `BUG:` prefix. Some use plain prose.
+- The weight of a body. Some repositories write dense prose. Some use headings.
+- If the repository has an issue template in `.github/ISSUE_TEMPLATE/`. If a template exists, **the template controls the structure**.
+
+## Step 3: Search for a duplicate
+
+Search before you file:
+
+```bash
+gh issue list --state all --search "<key terms>" --limit 10
+gh issue list --state open --limit 30      # read the titles if the search terms are unclear
+```
+
+- If an **open** issue agrees, stop and report it. Offer to add the new context as a comment with `gh issue comment <N> --body-file <path>`.
+- If a **closed** issue agrees, name it in the new body, for example "This is a regression of #N".
+
+## Step 4: Classify the issue
+
+**The type controls the shape of the body:**
+
+- **Defect.** The behavior is wrong today. The body starts with the defect and the evidence.
+- **Feature.** This is a new capability. The body starts with the scope bullets. Name the specification file if one exists.
+- **Follow-up.** This is a known gap that a review deferred and that is safe today. The body starts with the provenance and the reason for the deferral.
+
+**Propose a priority. Do not choose one silently.** Use the priority scale of the repository, which is frequently `P0` for a blocker, then `P1`, `P2`, and `P3`. If the issue touches the load-bearing domain of the repository, say so, and propose a high priority.
+
+## Step 5: Choose the labels
+
+Read the label list on each run. Never use a list from memory, because the taxonomy changes:
+
+```bash
+gh label list --limit 50 --json name,description --jq '.[] | [.name, .description] | @tsv'
+```
+
+Choose one label from each group that the repository uses, such as the area, the priority, the timeline, and the type. Use a label only if it fits. A small follow-up with no label is better than a label that is wrong. **Never create a new label without approval from the user.**
+
+## Step 6: Write the title
+
+Use the format of the repository. If the repository has no clear format, use `scope: a specific description`. The scope is the component name that a person searches by.
+
+- State the real defect or the real work. Do not state a vague area.
+- Add the consequence in parentheses when that helps: `(this avoids many alerts on a backdate of more than one year)`.
+- Give the phase for a feature that has more than one phase: `Lease renewal — Phase 1: …`.
+
+Correct: `move-out: a non-rent monthly charge is not prorated on a mid-month move-out`
+
+Correct: `reconciliation: block a reopen when the period is closed`
+
+Incorrect: `Fix proration bug` — this has no scope and no specifics
+
+Incorrect: `feat(leases): add proration` — the conventional commit format is for a pull request title, not for an issue
+
+## Step 7: Write the body
+
+Follow `references/issue-bodies.md` for the guidance for each type. The necessary parts:
+
+- **The provenance first**, when a review or an investigation found the issue.
+- **The problem with its mechanism**: what is wrong, *where*, with the file paths in backticks, and *why it happens*.
+- **The evidence**: what you confirmed, and what you suspect.
+- **The recommended fix**: the approach, and where it belongs. Name the alternative in one line if there is a real choice.
+- **The acceptance**: what "done" looks like. For a defect, this always includes a regression test that fails today.
+- **The cross-references**: related issues as `#N`, and the specification files.
+
+Match the weight of the body to the weight of the issue. A follow-up of two sentences is two sentences. A small issue needs no heading.
+
+## Step 8: Show the issue, then create it
+
+Show the issue for approval before you create it:
+
+```markdown
+## Proposed issue
+
+**Title**: <title>
+**Labels**: <label>, <label>
+
+**Body**:
+<body>
+
+---
+Do you want me to create this issue?
+```
+
+After the user approves, write the body to a file with the Write tool and create the issue:
+
+```bash
+gh issue create --title "<title>" --label "<label1>" --label "<label2>" --body-file <path-to-body>
+```
+
+Use `--body-file`. A body that contains a backtick or a single quotation mark breaks an inline `--body` argument.
+
+Then report the issue URL. If the user asked you to file the issue without a review, skip the approval step, but still show what you created.
+
+## Quality checklist
+
+- [ ] You read the issues that exist, and matched their title and body conventions
+- [ ] You read `.github/ISSUE_TEMPLATE/` and used the template if one exists
+- [ ] You searched for a duplicate in the open issues and the closed issues, and reported a match instead of filing again
+- [ ] The title states the real defect or the real work, with its scope
+- [ ] You read the label list on this run. The labels fit, and you invented none
+- [ ] The body gives the provenance when a review or an investigation found the issue
+- [ ] The problem statement names the files in backticks and explains the mechanism
+- [ ] The body separates a confirmed fact from a hypothesis
+- [ ] The body gives the recommended fix and the acceptance criteria. For a defect, it names the regression test that fails today
+- [ ] An issue in the load-bearing domain names the invariant at risk, and proposes a high priority
+- [ ] The body cross-references the related issues and the specification files
+- [ ] You wrote the body to a file and used `--body-file`
+- [ ] The user approved before you created the issue, unless the user asked you to file it directly
+
+## Reference
+
+`references/issue-bodies.md` gives the body shape for a defect, a follow-up, and a feature, plus the universal rules and the anti-patterns.