claude-dev-env 2.11.0 → 2.13.0

package/skills/autoconverge/workflow/converge.precatch.test.mjs

@@ -148,5 +148,5 @@ test('COMMIT_RECOVERY_MAX_ATTEMPTS is one and bounds the commitWithRecovery loop
   assert.match(convergeSource, /const COMMIT_RECOVERY_MAX_ATTEMPTS = 1/, 'expected a dedicated commit-recovery cap of one');
   assert.match(convergeSource, /const FIX_RECOVERY_MAX_ATTEMPTS = 2/, 'expected the wider verify-recovery cap to stay at two');
   const commitBody = functionSource('commitWithRecovery');
-  assert.match(commitBody, /attempt < COMMIT_RECOVERY_MAX_ATTEMPTS/, 'expected commitWithRecovery to bound its loop by the dedicated cap');
+  assert.match(commitBody, /attempt <= COMMIT_RECOVERY_MAX_ATTEMPTS/, 'expected commitWithRecovery to bound its loop by the dedicated cap');
 });

package/skills/bugteam/CONSTRAINTS.md

@@ -13,7 +13,7 @@
 - **Clean-room audits, every loop.** Each bugfind subagent's spawn prompt contains only the PR scope, audit rubric, and the current loop number. Prior loop history stays in the lead.
 - **Targeted fixes.** Each fix subagent sees ONLY the most recent audit's findings. Prior loops are invisible to the fix subagent.
 - **Fix subagent receives the latest audit as its input contract.** Each loop's fix run operates on the current audit's output and only that.
-- **Lead owns the final PR description rewrite only** (Step 4 Close substep via `pr-loop-lifecycle`), composed directly against `docs/PR_DESCRIPTION_GUIDE.md`.
+- **Lead owns the final PR description.** The lead applies the [description guide](../descriptions/SKILL.md#required-content) through `pr-loop-lifecycle`.
 
 ## Why this design
 

package/skills/bugteam/SKILL.md

@@ -29,6 +29,15 @@ and take `true` as the pass. When any check fails, run the
 `pr-loop-cloud-transport` skill first and route every `gh` operation in this
 skill through its substitution matrix.
 
+## Judgment guides
+
+Use the [review guide](../reviews/SKILL.md#review-workflow) to decide whether a
+changed behavior is a finding. Use the [comment guide](../comments/SKILL.md#writing-useful-review-comments)
+for posted findings and replies, the [description guide](../descriptions/SKILL.md#reviewing-a-description)
+for final PR context, the [emergency guide](../emergencies/SKILL.md#while-the-incident-is-active)
+for active incidents, and the [small-change guide](../small-cl/SKILL.md#reviewable-scope)
+when the diff needs a narrower review boundary.
+
 ## Pre-flight
 
 ```bash

package/skills/bugteam/reference/audit-and-teammates.md

@@ -104,8 +104,10 @@ Repeat until an exit condition fires.
       action** below). Instructions: read the gate script’s stderr, edit the
       repo until a **re-run** of the **same** gate command exits **0**. On
       tiers 1 and 3 the headless worker edits and runs tests but never
-      commits or pushes — the lead stages with explicit `git add`, mints the
-      code-verifier verdict, then commits and pushes. Tier 2 keeps in-agent
+      commits or pushes — the lead stages with explicit `git add`, confirms the
+      gate output and changed behavior against the
+      [review guide](../../reviews/SKILL.md#review-workflow), then commits and
+      pushes. Tier 2 keeps in-agent
       commit and push with `mode="bypassPermissions"`. Repeat standards-fix
       spawns until the gate exits **0** or **5** failed gate rounds (each
       round = one worker session after a non-zero gate). If still non-zero
@@ -219,8 +221,9 @@ worker session after a non-zero gate).
      headless worker edits and runs tests but never commits or pushes. The
      lead session stages the worker's files itself with an explicit `git add`
      (the session edit tracker does not see files the lead did not edit),
-     mints the code-verifier verdict in its own context, then commits and
-     pushes — so the commit gate and the staged-commit scans fire on the real
+     confirms the gate output and changed behavior against the
+     [review guide](../../reviews/SKILL.md#review-workflow), then commits and
+     pushes — so the commit gate and the staged-commit scans run on the real
      diff. Re-run the gate command; if still non-zero, start the next round.
    - **`claude_agent_required`** (exit `2`, attempts include tier `2` with
      that reason): spawn the Agent-tool worker with in-agent commit and push:
@@ -283,8 +286,9 @@ Pass finding comment URL, comment id, and thread node id for each finding
      and 3 the headless worker edits and runs tests but never commits or
      pushes. The lead session stages the worker's files itself with an
      explicit `git add` (the session edit tracker does not see files the lead
-     did not edit), mints the code-verifier verdict in its own context, then
-     commits and pushes — so the commit gate and the staged-commit scans fire
+     did not edit), confirms the gate output and changed behavior against the
+     [review guide](../../reviews/SKILL.md#review-workflow), then commits and
+     pushes — so the commit gate and the staged-commit scans run
      on the real diff. Read the outcome XML at
      `<worktree_path>/.bugteam-pr<N>-loop<L>.fix-outcomes.xml`. The **lead**
      posts one reply per finding using the unified template at

package/skills/bugteam/test_skill_additions.py

@@ -18,3 +18,12 @@ def test_skill_names_implementer_subagent_type():
 def test_skill_documents_bugbot_retrigger_flag():
     skill_text = _read_skill_text()
     assert "--bugbot-retrigger" in skill_text
+
+
+def test_skill_routes_judgment_to_canonical_guides() -> None:
+    skill_text = _read_skill_text()
+    assert "../reviews/SKILL.md#review-workflow" in skill_text
+    assert "../comments/SKILL.md#writing-useful-review-comments" in skill_text
+    assert "../descriptions/SKILL.md#reviewing-a-description" in skill_text
+    assert "../emergencies/SKILL.md#while-the-incident-is-active" in skill_text
+    assert "../small-cl/SKILL.md#reviewable-scope" in skill_text

package/skills/comments/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: comments
+description: >-
+  Draft, refine, or respond to pull-request review comments. Use when a user
+  asks to "write a review comment", "address review feedback", or "reply to a reviewer".
+---
+
+# Review Comment Guide
+
+## When to Use This Guide
+
+Use this guide to draft a finding, refine its tone, reply to reviewer feedback,
+or resolve a comment thread. Use the [review guide](../reviews/SKILL.md#review-judgment)
+to decide whether a concern merits a finding.
+
+## Writing Useful Review Comments
+
+Each comment names the affected behavior, the observed concern, the relevant
+evidence, and the expected outcome. Give the author enough context to choose an
+effective fix.
+
+- Use `Required` for a change that materially affects the review judgment.
+- Use `Consider`, `Nit`, or `FYI` for improvement, polish, and context.
+- Explain the technical rationale when the connection from evidence to outcome
+  needs context.
+- Recognize strong decisions and completed fixes with the same specificity.
+
+## Respectful and Actionable Feedback
+
+Treat every contributor as capable and acting in good faith. Keep feedback
+about the code, its behavior, and its effect on users or maintainers.
+
+- Consolidate a disagreement into one focused exchange with the relevant
+  context and reasoning.
+- Use proportionate language that directs attention to the required change.
+- Respect repository tooling and established formatting conventions.
+- Close a thread when its outcome satisfies the applicable review judgment.
+
+## Responding to Feedback
+
+Start with the substance of the feedback. Clarify the code, its tests, or its
+documentation when that gives future readers the needed context.
+
+Ask for clarification when the requested outcome remains unclear. Reply with
+the trade-off, evidence, and proposed resolution when an alternative approach
+better serves the stated goal.
+
+## Resolving Pushback
+
+Reassess a disputed finding against the repository rubric and the change's
+evidence. Keep advocating for a material improvement when the rationale remains
+sound, and accept an evidence-backed alternative that meets the same quality
+goal.
+
+Escalate to a maintainer or lead when product direction or code ownership is
+needed. Record the resulting decision in the pull request thread.
+
+## Related Guides
+
+- Use [reviews](../reviews/SKILL.md#review-workflow) for substantive code
+  assessment.
+- Use [small-cl](../small-cl/SKILL.md#responding-to-review) for author-side
+  review responses and focused follow-up work.
+- Use [emergencies](../emergencies/SKILL.md#while-the-incident-is-active) for
+  urgent production-change communication.

package/skills/descriptions/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: descriptions
+description: >-
+  Draft or revise a pull-request description. Use when a user asks for a "PR
+  description", "pull request summary", or "change description".
+---
+
+# Pull Request Description Guide
+
+## When to Use This Guide
+
+Use this guide to prepare or revise the written context for a pull request. A
+description explains the change to reviewers and future readers; it records the
+intent and evidence that source code alone cannot express.
+
+## Required Content
+
+Start with a short, specific summary line. Follow it with the information needed
+to understand the change:
+
+- The problem, motivation, and affected users or systems.
+- The implemented approach and meaningful design decisions.
+- Verification performed, including test commands and observed results.
+- Risks, migrations, compatibility effects, and rollback or recovery context.
+- Related issues, design records, and scoped follow-up work.
+
+Use durable prose for every essential fact when linked material has restricted
+access or a limited retention period.
+
+## Description Shape
+
+```text
+Summarize the delivered change.
+
+Explain the problem and the approach.
+
+Verification: <commands and results>
+Risk: <migration, compatibility, or recovery context>
+```
+
+Keep tags short and use them according to the repository's established format.
+
+## Reviewing a Description
+
+Compare the description with the changed files and the review findings. Keep the
+summary, scope, verification, and risk information aligned with the pull
+request's current contents.
+
+Use [reviews](../reviews/SKILL.md#review-workflow) for substantive code
+assessment and [small-cl](../small-cl/SKILL.md#what-a-focused-pull-request-contains)
+to establish a focused scope.

package/skills/emergencies/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: emergencies
+description: >-
+  Classify an urgent production change and guide its focused emergency review.
+  Use when a user asks about an "emergency hotfix", "production incident", or "urgent security fix".
+---
+
+# Emergency Review Guide
+
+## Emergency Classification
+
+Use emergency handling for a narrow change that mitigates an active, severe
+consequence:
+
+- A production failure materially affecting users or a critical service.
+- An active security or legal exposure requiring prompt mitigation.
+- A contractual, hardware, or market deadline where a missed delivery causes a
+  severe external consequence.
+
+Record the incident, affected system, immediate consequence, and the proposed
+mitigation before assessing the change.
+
+## Standard Priority
+
+Use the [review guide](../reviews/SKILL.md#review-workflow) for feature
+schedules, end-of-day timing, ordinary delivery targets, and build remediation.
+Use a focused rollback or remediation change when it restores service safely.
+
+## While the Incident Is Active
+
+Keep the change as small as the mitigation permits. Evaluate whether it resolves
+the incident, introduces a new immediate risk, and has sufficient validation for
+the affected path.
+
+State the incident context, verification performed, observed result, and any
+remaining recovery work in the pull request. Use the [comment guide](../comments/SKILL.md#writing-useful-review-comments)
+to communicate required mitigation work clearly.
+
+## Follow-up Assessment
+
+After service is stable, use the [review guide](../reviews/SKILL.md#evaluation-criteria)
+for the broader maintainability, testing, documentation, and prevention work.

package/skills/imagegen/SKILL.md

@@ -0,0 +1,21 @@
+---
+name: imagegen
+description: Generate prompt-driven images at exact requested resolutions through OpenAI API or Codex OAuth, with verified Pillow dimensions, truthful receipts, and safe atomic publication.
+argument-hint: --backend openai-api|codex-oauth --prompt "..." --size 2880x2880 --output path.png
+---
+
+# Exact-resolution image generation
+
+Use `scripts/imagegen.py` for reusable image generation.
+
+Prerequisites: Python 3.11 or newer and Pillow. The direct backend requires `OPENAI_API_KEY`; the OAuth backend requires an authenticated `codex` installation.
+
+```text
+python scripts/imagegen.py --backend openai-api --prompt "..." --size 2880x2880 --output generated.png
+```
+
+`openai-api` reads `OPENAI_API_KEY` from the environment and requests `gpt-image-2`. `codex-oauth` invokes the authenticated `codex` executable in an isolated temporary directory and measures its single PNG artifact.
+
+Native provider dimensions publish unchanged source bytes. A mismatch fails with the default `--resize-policy forbid`; `--resize-policy allow` applies Pillow resizing and records `resized` in the JSON sidecar receipt.
+
+The receipt sits beside the PNG with a `.json` suffix. It contains hashes, observed dimensions, backend, model or tool, transformation classification, prompt hash, and credential source name. Existing output or receipt files require `--overwrite`.

package/skills/imagegen/scripts/config/__init__.py

@@ -0,0 +1 @@
+"""Configuration package for the imagegen skill."""

package/skills/imagegen/scripts/config/constants.py

@@ -0,0 +1,28 @@
+"""Named imagegen limits and provider settings."""
+
+OPENAI_API_URL = "https://api.openai.com/v1/images/generations"
+OPENAI_MODEL = "gpt-image-2"
+OPENAI_OUTPUT_FORMAT = "png"
+OPENAI_API_KEY_NAME = "OPENAI_API_KEY"
+CODEX_TOOL_NAME = "codex-imagegen"
+ALL_SUPPORTED_BACKENDS = ("openai-api", "codex-oauth")
+ALL_SUPPORTED_RESIZE_POLICIES = ("forbid", "allow")
+MAXIMUM_IMAGE_EDGE = 3840
+MINIMUM_PIXEL_COUNT = 655_360
+MAXIMUM_PIXEL_COUNT = 8_294_400
+SIZE_MULTIPLE = 16
+JSON_INDENT_LEVEL = 2
+MAXIMUM_PROVIDER_BYTES = 64 * 1024 * 1024
+CODEX_TIMEOUT_SECONDS = 300
+MAXIMUM_CODEX_OUTPUT_BYTES = 1 * 1024 * 1024
+OPENAI_TIMEOUT_SECONDS = 120
+SIZE_COMPONENT_COUNT = 2
+SIZE_SEPARATOR = "x"
+PNG_SUFFIX = ".png"
+PNG_FORMAT = "PNG"
+RECEIPT_SUFFIX = ".json"
+TEMPORARY_DIRECTORY_PREFIX = "imagegen-"
+TEMPORARY_FILE_TOKEN_BYTES = 8
+DEFAULT_PROVIDER_EDGE = 2048
+MINIMUM_DIMENSION = 1
+MAXIMUM_CODEX_ARTIFACT_COUNT = 1

package/skills/imagegen/scripts/imagegen.py

@@ -0,0 +1,45 @@
+"""Command-line entry point for exact-resolution image generation."""
+
+from __future__ import annotations
+
+import argparse
+from pathlib import Path
+
+from config.constants import ALL_SUPPORTED_BACKENDS, ALL_SUPPORTED_RESIZE_POLICIES
+from imagegen_core import ImagegenError, generate_image, parse_size
+
+
+def build_parser() -> argparse.ArgumentParser:
+    """Build the imagegen command-line parser.
+
+    Returns:
+        Parser for the imagegen command-line contract.
+    """
+    parser = argparse.ArgumentParser(description="Generate an exact-resolution image")
+    parser.add_argument("--backend", choices=ALL_SUPPORTED_BACKENDS, required=True)
+    parser.add_argument("--prompt", required=True)
+    parser.add_argument("--size", required=True)
+    parser.add_argument("--output", dest="destination_path", type=Path, required=True)
+    parser.add_argument("--resize-policy", choices=ALL_SUPPORTED_RESIZE_POLICIES, default=ALL_SUPPORTED_RESIZE_POLICIES[0])
+    parser.add_argument("--overwrite", action="store_true")
+    return parser
+
+
+def main() -> int:
+    """Run the CLI and return a process status.
+
+    Returns:
+        Zero for a published artifact and one for a generation failure.
+    """
+    arguments = build_parser().parse_args()
+    try:
+        all_receipt = generate_image(arguments.prompt, arguments.backend, parse_size(arguments.size), arguments.destination_path, arguments.resize_policy, arguments.overwrite)
+    except ImagegenError as error:
+        print(f"ERROR: {error}")
+        return 1
+    print(f"Generated {arguments.destination_path} ({all_receipt['transformation']})")
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())