claude-dev-env 4.3.0 → 7.1.0

package/.agents/skills/pr-shared-extraction/SKILL.md

@@ -1,177 +0,0 @@
----
-name: pr-shared-extraction
-description: Audits pull requests and packages for general helpers living in workflow-specific code instead of shared_utils, then applies extraction fixes by default in small tested CLs. Use when reviewing PRs for architectural layering, migrating utilities out of cert_fix_queue/theme_dialer_pipeline/skills, auditing "similar offenses", or when the user mentions extraction audit, shared_utils migration, orchestration-only packages, thin wrappers, or layer inversions.
----
-
-# Shared Extraction Audit
-
-Audit PRs and packages for reusable behavior placed in workflow code. Keep **orchestration packages thin** and **shared_utils canonical**.
-
-## When to use
-
-- User points at a PR (e.g. `#1954`, `#1965`) and asks for the same review loop
-- A package grew `fix_one`, `_default_*`, backup upload, rembg session, or residual gates alongside orchestration
-- Before merge: confirm consumers are adapters, not second implementations
-
-## Mode routing
-
-Resolve the first matching mode before the audit steps:
-
-1. `preflight-proposal` runs `pr-shared-extraction preflight-proposal <pr_number> --base-sha <base_sha> --head-sha <head_sha> --worktree <isolated_worktree>` under the [shared preflight proposal contract](../_shared/pr-loop/preflight-proposal.md). Record each finding with priority and target.
-2. `audit-only` is report-only and ends after the findings report.
-3. Normal mode follows the existing audit workflow and applies the prioritized fix band by default.
-
-## Target architecture
-
-| Layer | Holds | Examples |
-|-------|--------|----------|
-| **shared_utils** | Reusable actions, I/O, DB flips, inference, constants used by 2+ workflows | `status_promotion`, `background_removal`, `drive_production_backup`, `stp_filenames` |
-| **Workflow package** | Orchestration, CLI, sweep loops, workflow-specific constants only | `cert_fix_queue/pipeline/queue_run.py`, `theme_dialer_pipeline` compose runners |
-| **Skills / scripts** | Operator entrypoints that **delegate** to shared_utils | No parallel rembg/session stacks |
-
-**Load-bearing rule:** If another package would import it, put it in `shared_utils`. After the move, every former caller imports the shared symbol and the old module is deleted.
-
-## Audit workflow
-
-Register this checklist with `update_plan` and mark each step complete with evidence:
-
-```
-Shared extraction audit:
-- [ ] 1. Scope the PR (base branch, changed packages, stated goal)
-- [ ] 2. Map canonical homes already in shared_utils
-- [ ] 3. Grep for offense patterns (see reference/offense-taxonomy.md)
-- [ ] 4. Write prioritized findings (P0–P3)
-- [ ] 5. Apply **Mode routing** after the report
-- [ ] 6. Extract in small CLs + move/adjust tests
-- [ ] 7. Run scoped pytest, then follow the selected mode's mutation boundary
-- [ ] 8. When the mode is `preflight-proposal`, record proposal evidence from the [shared preflight proposal contract](../_shared/pr-loop/preflight-proposal.md) and require downstream owner selection before reapplication
-```
-
-### Step 1 — Scope
-
-```bash
-git fetch origin pull/<N>/head:pr-<N>   # or checkout feature branch
-git diff <base>...<head> --stat
-git diff <base>...<head> --name-only | rg 'shared_utils|cert_fix_queue|theme_dialer|clean_room|\.claude/skills'
-```
-
-Read the PR summary, then verify **what landed correctly** before listing offenses.
-
-### Step 2 — Search patterns
-
-Run these greps on the PR diff scope:
-
-```bash
-# Rename-only seams and re-export facades
-rg '_default_|def _.*_flipper|def _.*_one\b|promote_one|fix_one|backup_upload' <package> shared_utils
-rg '^from shared_utils\..* import \w+$' <package>
-
-# Layer inversions (shared importing consumer)
-rg 'from (cert_fix_queue|theme_dialer_pipeline|clean_room_theme_icons)\.' shared_utils/
-
-# Parallel stacks (second session/cache for same concern)
-rg 'new_session|lru_cache.*session|rembg\.remove' .claude/skills shared_utils
-
-# Duplicate constants
-rg 'ALPHA_CHANNEL_INDEX|RGBA_ALPHA|DEFAULT_.*_PREFIX|ONEUI_STP_BASENAME' --glob '*.py'
-
-# Duplicate test support
-rg 'fail_if_called|build_rejected_theme_row|preserve_supplied_alpha' --glob '**/tests/**'
-```
-
-### Step 3 — Classify offenses
-
-Use [reference/offense-taxonomy.md](reference/offense-taxonomy.md). Assign priority:
-
-| Priority | Meaning |
-|----------|---------|
-| **P0** | Layer inversion or duplicate production stack (must fix before merge) |
-| **P1** | General helper/constants/tests still in consumer package |
-| **P2** | Module shape, I/O overlap, monolith size |
-| **P3** | Stale names, docstrings, test attribute bugs |
-
-### Step 4 — Report template
-
-```markdown
-## PR #<N> extraction audit
-
-### Done well
-- [canonical modules and deletions]
-
-### P0 — …
-| Offense | Where | Target module | Tests |
-|---------|-------|---------------|-------|
-
-### Suggested fix order
-1. …
-```
-
-## Fix workflow
-
-### Extraction rules
-
-1. **Move behavior** — delete the consumer copy; every caller imports the shared symbol
-2. **Wire shared APIs at the call site** — e.g. `db_flipper=promote_theme_to_status` with `filename_prefix=...`
-3. **Retarget every caller, then delete the old module** — grep the old import path; remove re-export facades
-4. **Constants:** one source; workflow CLI keeps only workflow-specific names (`LEDGER_FILENAME`, exit codes)
-5. **Tests move with behavior** — shared module gets shared tests; orchestration keeps integration tests only
-6. **Small CLs** — one concern per commit; run scoped pytest after each
-
-### Canonical target map (this repo)
-
-| Need | Home |
-|------|------|
-| Theme DB status flip | `shared_utils/theme_db/status_promotion.py` |
-| Account folder ↔ ThemeAccount | `shared_utils/theme_persistence/account_adapter.py` |
-| STP basename parsing | `shared_utils/samsung_utils/stp_filenames.py` |
-| Drive backup upload | `shared_utils/files/drive_production_backup.py` |
-| Timestamp scratch dirs | `shared_utils/files/timestamp_directory_retention.py` |
-| Foreground extraction | `shared_utils/theme_assets/background_removal.py` |
-| Cert fix / promote actions | `shared_utils/theme_assets/cert_closeout/` |
-| Fixed-STP promotion sweep | `shared_utils/samsung_utils/promote_fixed_stp_sweep.py` |
-| Cert queue orchestration only | `cert_fix_queue/pipeline/` (`queue_run`) and `run_cli` |
-
-See also `.claude/rules/reuse-existing-tooling.md` before adding helpers.
-
-### Verification
-
-```bash
-# Package under change (from its directory or shared_utils)
-cd shared_utils && python -m pytest path/to/tests -n 0 -q
-cd cert_fix_queue && python -m pytest tests/ -n 0 -q
-
-# After moving tests: bump CI collect floor in .github/workflows/standalone-packages-tests.yml if applicable
-```
-
-Provide evidence: pytest output counts, not "should work".
-
-### Git / PR
-
-- Branch: `cursor/<topic>-593d` or existing PR branch
-- Commit message: `Extract <what> from <package> into shared_utils`
-- Update PR body: architecture table + test counts
-- Do not merge; draft PR unless user says otherwise
-
-## Anti-patterns (flag these)
-
-- `_default_*` adapter around a shared_utils function in a consumer module
-- Workflow module that only does `from shared_utils... import foo as foo`
-- `fix_one.py` / `promote_one.py` / `promote_run.py` / `backup_upload.py` in orchestration packages
-- `shared_utils` importing `theme_dialer_pipeline` or `cert_fix_queue`
-- Second rembg/BiRefNet session in a skill while `background_removal` exists
-- Identical `tests/support.py` in two packages
-- `config/constants.py` that only aliases extracted helpers
-
-## Examples
-
-See [reference/examples.md](reference/examples.md) for cert_fix_queue (#1965) and background_removal (#1954) audits.
-
-## File index
-
-| File | Purpose |
-|------|---------|
-| `SKILL.md` | Hub — architecture, routing, audit checklist, and fix workflow |
-| `reference/offense-taxonomy.md` | Offense signals and priority guide |
-| `reference/examples.md` | Audit examples and fix order |
-| `../_shared/pr-loop/preflight-proposal.md` | Shared isolated proposal mode and evidence record |
-| `../_shared/pr-loop/preflight-proposal.contract.test.mjs` | Cross-skill mode and contract test |

package/.agents/skills/pr-shared-extraction/reference/examples.md

@@ -1,46 +0,0 @@
-# Audit examples (this repo)
-
-## cert_fix_queue — PR #1965
-
-**Goal:** `cert_fix_queue` holds orchestration only; general cert-fix utilities in `shared_utils`.
-
-**Done well:**
-- `locate_cert_folder_for_row`, `select_production_stp`, atomic copy, drive staged upload → shared_utils
-- Deleted `fix_one.py`, `promote_one.py`, `backup_upload.py` from pipeline
-
-**Offenses found and fixed:**
-- `_default_db_flipper` in `fix_theme.py` → wire `db_flipper=promote_theme_to_status` at the call site; delete the wrapper
-- `production_backup.py` under cert_closeout → `shared_utils/files/drive_production_backup.py`
-- Duplicate test `support.py` → `shared_utils/theme_assets/testing/cert_fix_test_support.py`
-- `fix_queue_constants.py` misnamed → `fix_outcomes.py`
-- `_account_by_fixed_stps_folder` → `cert_failure_folder_to_theme_account_map()` in `account_adapter`
-- `_fresh_run_directories` / scratch helpers → `allocate_timestamp_run_directory()`
-
-**Pipeline after:**
-```
-cert_fix_queue/pipeline/
-  queue_run.py
-  promote_run.py
-run_cli.py
-```
-
----
-
-## background_removal — PR #1954
-
-**Goal:** One BiRefNet CPU path in `shared_utils/theme_assets/background_removal.py`.
-
-**Done well:**
-- Deleted `clean_room_theme_icons/chroma.py`, dialer `art_masks.py`, `png_io.py`
-- Added `pixel_masks.py`, `png_canonical.py`
-- Clean-room and dialer call `extract_foreground` / `extract_foreground_file`
-
-**Remaining offenses (audit):**
-- P0: Residual gates in `theme_dialer_pipeline/pipeline/chroma_extract.py` (shared algorithm output)
-- P0: `_extract_component_foreground` wrapper; same pattern inlined in `compose_from_masters.py`
-- P0: Parallel rembg in `misc-asset-remaster/scripts/generated_alpha_mask.py`
-- P1: Duplicate extraction test fixtures (dialer conftest vs clean-room conftest)
-- P1: `ALPHA_CHANNEL_INDEX` duplicated across dialer/clean-room/color_constants
-- P2: Atomic write helpers inside 723-line `background_removal.py`; PNG path vs `png_canonical`
-
-**Suggested fix order:** residual gates → shared test fixtures → dedupe constants → migrate misc rembg → I/O split (optional).

package/.agents/skills/pr-shared-extraction/reference/offense-taxonomy.md

@@ -1,100 +0,0 @@
-# Offense taxonomy
-
-## O1 — General action in workflow package
-
-**Signal:** Per-item function named `*_one`, `fix_*`, `promote_*`, `upload_*` in orchestration tree.
-
-**Example:** `cert_fix_queue/pipeline/fix_one.py` → `shared_utils/.../fix_theme.py` (`fix_cert_rejected_theme`).
-
-**Fix:** Move module; consumer passes workflow-specific `filename_prefix` / folder ids at call site.
-
----
-
-## O2 — Thin wrapper / default seam / re-export facade
-
-**Signal:** `_default_db_flipper`, `_default_*` that only renames kwargs and calls shared_utils. Also: a workflow module that only re-exports a shared symbol under the old path.
-
-**Example:** Wrapper around `promote_theme_to_status` with `db_flip_log_filename_prefix`. After a move, `clean_room_theme_icons.rebuild_nine_patch` still contains `from shared_utils... import rebuild_nine_patch`.
-
-**Fix:** Update every caller to the shared symbol (`filename_prefix`, `shared_utils.theme_assets.nine_patch_rebuild`, etc.) and delete the wrapper or facade.
-
----
-
-## O3 — Layer inversion
-
-**Signal:** `shared_utils/...` imports from `cert_fix_queue`, `theme_dialer_pipeline`, `clean_room_theme_icons`, or `.claude/skills/...`.
-
-**Fix:** Move imported symbol into shared_utils; consumer imports shared.
-
----
-
-## O4 — Parallel production stack
-
-**Signal:** Second implementation of same concern (rembg session, despill, STP walk, DB flip) in skill or sibling package.
-
-**Example:** `misc-asset-remaster/.../generated_alpha_mask.py` vs `background_removal.py`.
-
-**Fix:** Delegate to canonical module; delete duplicate constants and session cache.
-
----
-
-## O5 — Validation/gates on shared output in consumer
-
-**Signal:** Functions that only inspect output of shared algorithm (residual alpha, edge green excess) live in dialer/clean-room.
-
-**Example:** `theme_dialer_pipeline/pipeline/chroma_extract.py` using `edge_green_excess_mask` from shared.
-
-**Fix:** `shared_utils/theme_assets/background_removal/residual_gates.py` (or sibling); optional `extract_foreground_gated`.
-
----
-
-## O6 — Duplicate constants
-
-**Signal:** Same literal or semantic constant in workflow `config/constants.py` and shared config.
-
-**Examples:** `ALPHA_CHANNEL_INDEX`, `ONEUI_STP_BASENAME_RE`, two `DEFAULT_*_DB_FLIP_*` with same value.
-
-**Fix:** Single definition in shared config; delete consumer copies.
-
----
-
-## O7 — Misplaced config module
-
-**Signal:** Constants named for workflow A live under package B's config (e.g. `fix_queue_constants` under `cert_closeout`).
-
-**Fix:** Rename/move to owning workflow or shared outcomes module; drop re-export-only facades.
-
----
-
-## O8 — Duplicate test support
-
-**Signal:** Identical or near-identical `tests/support.py`, conftest bypass fixtures, synthetic PNG writers in multiple packages.
-
-**Fix:** `shared_utils/theme_assets/testing/` or `shared_utils/.../tests/fixtures.py`; one import path.
-
----
-
-## O9 — General I/O in domain module
-
-**Signal:** Atomic staged writes, Drive upload, UTC helpers duplicated inside a 700-line domain file.
-
-**Fix:** `shared_utils/files/` (e.g. `drive_production_backup`, `timestamp_directory_retention`, `record_persist`).
-
----
-
-## O10 — Stale identifiers
-
-**Signal:** Docstrings/tests still say `fix_one`, `promote_one`, `backup_upload` after rename.
-
-**Fix:** Update docs; no behavior change.
-
----
-
-## Priority guide
-
-| Offense | Typical priority |
-|---------|------------------|
-| O3, O4 | P0 |
-| O1, O2, O5, O6, O7, O8 | P1 |
-| O9, monolith size | P2 |
-| O10 | P3 |

package/.agents/skills/pr-small-cl/SKILL.md

@@ -1,52 +0,0 @@
----
-name: pr-small-cl
-description: >-
-  Scope or split a pull request into a self-contained reviewable increment. Use
-  when a user asks to "split this PR", "make this change smaller", or "small CL".
----
-
-# Focused Pull Request Guide
-
-## When to Use This Guide
-
-Use this guide to plan, assess, or split a pull request into a reviewable unit.
-The pull request boundary is conceptual: one coherent outcome that a reviewer
-can understand with its context and verification.
-
-## What a Focused Pull Request Contains
-
-A focused pull request contains the implementation, related tests, documentation,
-and configuration needed for one outcome. It leaves the system in a usable state
-and gives the reviewer the information needed to assess the change.
-
-Use the [description guide](../descriptions/SKILL.md#required-content) to record
-the scope, verification, risks, and follow-up work.
-
-## Splitting a Change
-
-Choose a split that gives each increment a coherent purpose and a clear test
-boundary. Useful seams include:
-
-- Preparation refactors followed by behavior changes.
-- Independent vertical features that each deliver a user-visible capability.
-- Layer-specific work when each layer remains independently understandable.
-- Stacked changes when each earlier change supplies the next change's stable
-  foundation.
-
-State dependencies between related pull requests and keep each increment safe to
-merge or revert on its own.
-
-## Reviewable Scope
-
-Ask to split a change when its breadth prevents a reliable assessment of design,
-behavior, or verification. Identify the first coherent increment and the
-remaining increments so the author has an actionable path forward.
-
-Use [reviews](../reviews/SKILL.md#evaluation-criteria) to evaluate the resulting
-scope and [emergencies](../emergencies/SKILL.md#emergency-classification) when an
-active incident sets the immediate boundary.
-
-## Responding to Review
-
-Use the [comment guide](../comments/SKILL.md#responding-to-feedback) to respond
-to feedback and resolve pushback.

package/.agents/skills/pr-title-description/SKILL.md

@@ -1,96 +0,0 @@
----
-name: pr-title-description
-description: Review one or more pull requests and write plain titles and descriptions from the full diff.
-disable-model-invocation: true
----
-
-Accept one or more pull request links as arguments. Apply the prompt below to each link.
-
-With no argument, use the current task, browser, worktree, or GitHub context to find the pull request or pull requests. If the context does not show a clear pull request, ask for a pull request link.
-
-Review this pull request: <PR link>
-
-Read the PR and its full diff. Do not use the branch name, commit message, labels, current title, or a shallow summary.
-
-## Full-diff behavior standard
-
-Before writing, inventory every independently observable behavior in the full diff. A behavior is independent when a user, caller, operator, automation, output, error, exit status, fallback, or side effect can observe it separately. Lead with the central behavior for readability, then give every other behavior its own short paragraph or bullet.
-
-For each behavior, state the trigger or observer, the Before -> After result, the affected surface/caller when shared, and focused proof. Include important preserved behavior and fallback paths when they help a coder rule a regression in or out. Describe outcomes, not line-by-line implementation, and do not hide multiple behaviors under vague umbrella wording.
-
-
-Write like the reader is smart but knows nothing about this code. Pretend they asked you to explain it like they are five and feel stupid. If a word needs another sentence to explain it, replace the word — or turn it into a tiny story.
-
-Your job is not a dry API blurb. Your job is an illustrative before/after a person can picture.
-
-Gold voice for titles and “What this adds”:
-
-The theme package has a phone icon somewhere. We need to find it.
-
-Before: yell “anyone know how to find icons?” and wait for a hand.
-
-After: call the finder by its name tag: “icon finder, go.”
-
-That’s all “operation id” is — the finder’s name tag.
-
-Rules for that voice:
-
-Start from a concrete scene (what’s in someone’s hand, what they’re hunting for).
-Prefer Before / After when the change is “how you ask” or “how you look it up.”
-Use picture words: hand it, open, find, check, save, skip, stop, call by name, name tag.
-Prefer spoken results: “found it,” “missing,” “duplicated,” “couldn’t.”
-When the diff uses an abstract word (operation id, registry, envelope, adapter, digest, schema), do one of two things:
-Drop it and say what the person does with their hands, or
-Keep it once, then gloss it in the same breath with a name-tag / mailbox / checklist metaphor — like the “finder’s name tag” line above.
-Never leave jargon unexplained. Never write as if the reader already knows the jargon.
-Add a tiny concrete example in parentheses when a name is abstract (like “the phone icon”).
-Few words. Small words. Clear on first read.
-Return:
-
-Recommended title
-
-Few words. Small words. Clear on first read.
-Say what you hand it, what it does, and what you get back — or the Before/After of how you ask.
-Prefer picture words and spoken results.
-Good title: “Call the icon finder by its name tag instead of asking around”
-Good title: “Given a theme STP and an asset name, report whether that asset was found, missing, or duplicated”
-Bad title: anything that only says operation id / registry / typed envelope / adapter / digest / schema with no picture.
-Use “Add” only if it helps. Do not force it.
-No vague words like “improve,” “enhance,” or “update.”
-Return one title only.
-Why this title fits
-
-1–2 short sentences in the same voice.
-If needed, one Before / After beat, then what you get back.
-If this section is needed to decode the title, rewrite the title.
-Evidence
-
-Key files or functions that support the title.
-If you cannot read the PR or full diff, say so and do not propose a title.
-
-Then write a short, paste-ready PR description.
-
-Use this structure:
-
-What this adds
-
-Why
-One short paragraph. Same plain level. Say who needs this and what goes wrong without it (the “yell and wait for a hand” problem). If this is needed to decode the feature, rewrite “What this adds.”
-
-Verification
-List only proof from the PR, CI, or your own checks.
-
-Reported in the PR
-
-…
-Checked by you / CI here
-
-…
-Rules:
-
-Few words. Small words. Clear on first read. ELI5 I-am-stupid mark.
-Do not invent behavior, tests, or benefits.
-Strip branch names, hashes, draft notes, agent notes, and merge notes.
-No vague words like “improve,” “enhance,” or “update.”
-Illustrative first. Abstract labels only if glossed in the same breath.
-Use the recommended title and paste-ready description to run `gh pr edit <PR link> --title ... --body-file ...`, then run `gh pr view <PR link> --json title,body` to confirm the saved title and body. Report the saved result.

package/.agents/skills/prototype/SKILL.md

@@ -1,85 +0,0 @@
----
-name: prototype
-description: >-
-  Isolated hookless worktree sandbox for zero-friction proof-of-concept builds, then a clean-room re-verification that promotes a successful POC into a real deploy. Triggers: prototype, /prototype, proof of concept, POC, spike, throwaway build, build without hooks, sandbox this idea, hookless worktree, prototype then ship, promote the prototype.
----
-
-# Prototype
-
-## Principle
-
-Give a build the freedom to move fast, then make it earn the right to ship. Two phases, one hard wall between them:
-
-- **Sandbox** — an isolated worktree where an agent runs under `claude --bare`, so the normal TDD, code-rules, plain-language, and stage hooks do not run. The agent builds a proof-of-concept with zero friction.
-- **Promotion** — back in the normal, fully-hooked session, the successful POC receives clean-room review and verification under the [review guide](../reviews/SKILL.md#review-workflow) before it becomes a commit and a pull request.
-
-Two safety gates stay live even in the sandbox: personal-data blocking and destructive-command blocking. A worktree shares the real repo's `.git` store and `rm` reaches the whole disk, so these are containment, not the "delays" the sandbox is meant to shed.
-
-## Gotchas
-
-Highest-signal content. Append a bullet each time a run fails in a new way.
-
-- A `--settings` file's hooks still load under `--bare` (the file is passed explicitly). That is the mechanism for keeping the two safety gates, not a bug.
-- The two safety hooks must point at the real installed scripts and import their `*_constants` packages at runtime. `scripts/build_sandbox_settings.py` resolves each hook's command from the live `~/.claude/settings.json` and registers it on the matchers the sandbox needs — personal-data on Write, Edit, MultiEdit, and Bash; destructive-command on Bash — so the paths stay correct on any machine and both gates cover the write surface. Do not hand-write the hook paths or matchers, and do not inherit whatever matcher the live config happens to use (a personal-data gate wired only to a narrow tool leaves disk writes ungated).
-- Under `--dangerously-skip-permissions` an `ask` decision is auto-resolved, so only a hard `deny` blocks a destructive command. The settings file carries an `env` block that sets `CLAUDE_DESTRUCTIVE_DENY_MODE`, which turns the destructive gate's terminal `ask` into a `deny`. The probe runs the gate under that env block and passes only on the hard deny.
-
-**Refusal cases — first match wins:**
-
-- **Not in a git repository.** Respond: `Prototype needs a git repo to branch a worktree from. Run this from inside one.`
-- **The `fresh-branch` skill is not installed.** Respond: `Prototype composes fresh-branch to make the sandbox worktree, and it is not installed. Install claude-dev-env first.`
-- **The `claude` CLI is not on PATH.** Respond: `The sandbox launches a headless claude session, and the claude CLI is not on PATH.`
-
-## Process
-
-Two phases. Run the sandbox phase first; run the promotion phase only when the POC succeeds and the user wants it shipped.
-
-### Phase 1 — Sandbox
-
-Follow `workflows/sandbox.md`. In short:
-
-1. Invoke the `fresh-branch` skill to create an isolated worktree off `origin/main`. Keep its returned `worktree_path` and `base_commit`.
-2. Run `scripts/build_sandbox_settings.py` to emit the minimal safety settings (personal-data and destructive-command gates only).
-3. Run `scripts/probe_sandbox_safety.py --settings <path>` and confirm both gates block. Do not continue on a non-zero exit.
-4. Run `scripts/launch_sandbox.py` to start the hookless `claude -p --bare` session in the worktree with those settings and the POC task.
-5. Read what the sandbox built. Decide whether the POC proves the idea.
-
-### Phase 2 — Promotion
-
-Run only in the normal, fully-hooked session — never inside the sandbox. Follow `workflows/promotion.md`, which drives the clean-room task seeds in `reference/promotion-tasks.md`: fresh branch off live `origin/main`, POC content as an uncommitted diff, cleanup and privacy sweep, review and verification under the [review guide](../reviews/SKILL.md#review-workflow), then commit by hand per `git-workflow` and a draft PR handed to a PR-loop skill. State the two honest limitations from `reference/honest-limitations.md`.
-
-## Task seeding
-
-At the start of Phase 2, register every item in `reference/promotion-tasks.md` as a session task (`TaskCreate`, or `TodoWrite` if that is the host tool). Work only from the task list. Mark each complete with evidence. Do not track promotion as a markdown checklist.
-
-## Sub-skills
-
-| Skill / agent | When | Produces | If missing |
-|---|---|---|---|
-| `fresh-branch` | Sandbox step 1; Promotion step 2 | isolated worktree JSON (`worktree_path`, `base_commit`, `repo_root`) | Refuse — see refusal cases |
-| `privacy-hygiene` | Promotion step 5 | personal-data and secret sweep of the diff | Warn; do a manual review before continuing |
-| [Review guide](../reviews/SKILL.md#review-workflow) | Promotion step 6 | review and verification of the real diff | Stop and report the incomplete promotion |
-| `autoconverge` (default; `pr-converge` or `bugteam` as alternatives) | Promotion step 9 | the PR converged to ready | Stop after the draft PR; tell the user to converge manually |
-
-## Degree of freedom
-
-Low on the skill's own mechanics — the launch flags and the promotion order are fragile with cliffs, so they live in scripts and a fixed task list, not in prose the agent reconstructs. High inside the sandbox — the sandboxed agent's build freedom is the whole point.
-
-## File index
-
-| File | Purpose |
-|---|---|
-| `SKILL.md` | This hub — principle, gotchas, when-applies, process, sub-skills, file index |
-| `workflows/sandbox.md` | Phase 1 steps: worktree, safety settings, probe, hookless launch |
-| `workflows/promotion.md` | Phase 2 steps: the clean-room re-verification that drives the promotion task seeds |
-| `reference/promotion-tasks.md` | Task-seed catalog for the clean-room protocol (register via the task tool) |
-| `reference/honest-limitations.md` | The two fixed statements to make on every promotion |
-| `scripts/build_sandbox_settings.py` | Emit the minimal safety `--settings`: resolve each hook's command from live settings, register it on the required matchers |
-| `scripts/launch_sandbox.py` | Launch the hookless `claude -p --bare` sandbox session in the worktree |
-| `scripts/probe_sandbox_safety.py` | Prove both safety gates block before trusting the sandbox |
-
-## Folder map
-
-- `SKILL.md` — hub.
-- `workflows/` — the two phase workflows.
-- `reference/` — promotion task seeds and the honest-limitation statements.
-- `scripts/` — the settings builder, the launcher, the safety probe, their `prototype_scripts_constants` package, and paired tests.

package/.agents/skills/prototype/reference/honest-limitations.md

@@ -1,23 +0,0 @@
-# Honest limitations of a promoted prototype
-
-State both of these to the user, in these terms, whenever a proof-of-concept is promoted. Do not soften or drop them. They are the price of building without standards gates.
-
-## 1. Write-time code rules never ran on this code
-
-`code_rules_enforcer` is a Write/Edit gate: it checks content as it is written. Prototype code is built under `--bare`, so that gate never fired, and content brought into promotion as a git diff (apply, checkout, cherry-pick) does not pass through it either.
-
-Promotion records the controls applied to the real diff:
-
-- review and verification under the [review guide](../../skills-archived/reviews/SKILL.md#review-workflow);
-- the `privacy-hygiene` sweep for personal data and secrets;
-- the pull-request review criteria and any PR-loop reviewers.
-
-Say plainly: the write-time rule engine did not see this code; the verifier and review are what cover it.
-
-## 2. TDD ordering is waived on promoted prototype lines
-
-The sandbox agent wrote code first and tests, if any, after. Red-green-refactor ordering did not happen. So the honest claim on promoted prototype code is exactly this, and nothing more:
-
-> Review and verification completed, privacy swept — TDD ordering waived.
-
-Do not claim red-green compliance on these lines. A prototype is a reference build, not a test-first build. Promotion reviews and verifies the code against the current standards.

package/.agents/skills/prototype/reference/promotion-tasks.md

@@ -1,23 +0,0 @@
-# Promotion task seeds (clean-room protocol)
-
-Register every numbered item below as a session task (`TaskCreate`, or `TodoWrite` if that is the host tool) at the start of the promotion phase. Work only from the task list. Mark each complete only with evidence — a command result, a path, a verdict, or a skill's return. This is not a checkbox board; it is a seed catalog for the task tool.
-
-Promotion runs in the **normal, fully-hooked session** — never inside the `--bare` sandbox. Nothing from the sandbox history is carried; only its file content is re-applied and re-verified.
-
-1. **Confirm the prototype is worth promoting.** The sandbox build works and the user (or the standing goal) wants it shipped. Evidence: the working behavior observed, one sentence on what the POC proves.
-
-2. **Fresh branch off live upstream.** Re-fetch `origin/main` and branch from it via the `fresh-branch` skill. Evidence: the returned `base_commit` matches current `origin/main`. This starts clean history and keeps the work based on live upstream.
-
-3. **Bring prototype content as an uncommitted working-tree diff, by allowlist.** Take the sandbox diff against its `base_commit` and copy only the product files you intend to ship into the fresh branch's working tree. Do NOT cherry-pick or merge the sandbox commits, and do NOT bulk-copy the worktree. Exclude the sandbox settings file (`.prototype-sandbox-settings.json`) and every scratch, debug, or artifact file the POC produced — name the files you are bringing, not the ones you are dropping. Evidence: the allowlist of copied paths; `git status` shows only those unstaged; `git log` shows no sandbox commits.
-
-4. **Cleanup pass.** Remove every scratch file, debug dump, and temp helper the prototype created (see the `cleanup-temp-files` rule). Evidence: the removed paths, or a stated "none created".
-
-5. **Privacy sweep.** Run the `privacy-hygiene` skill over the full applied working tree, not only the diff — a POC that pulled live data can leave a secret in a file the diff view hides. Evidence: its clean report, or the leak it found and how it was removed. If the skill is missing, do a manual PII and secret review and say so.
-
-6. **Review and verify the real diff.** Apply the [review guide](../../skills-archived/reviews/SKILL.md#review-workflow). Evidence: the checks run and each required finding repaired. Do not rely on sandbox testing as promotion evidence.
-
-7. **Commit and open a draft PR.** After the review and verification record is complete, commit by hand per the `git-workflow` rule, then open a draft PR. Evidence: the commit hash and the PR URL.
-
-8. **State the honest limitations.** Post the two statements from `reference/honest-limitations.md` — write-time rules never ran; TDD ordering waived — in the PR body or to the user. Evidence: the text was included.
-
-9. **Hand to a PR-loop skill.** Hand the PR to `autoconverge` by default — one autonomous run to ready. Reach for `pr-converge` when paced ticks fit better, or `bugteam` for an open-loop audit-fix. Evidence: the skill was invoked, or the user chose to converge manually.