@lifeaitools/rdc-skills 0.24.42 → 0.25.1

package/skills/rdc-extract-verifier-rules/SKILL.md

@@ -1,191 +1,191 @@
----
-name: rdc-extract-verifier-rules
-version: 0.1.0
-description: |
-  Read recent enhancement-log entries, cluster failures by pattern, generate candidate verifier rules, test them against the known-good corpus and the failure corpus, and propose pull requests adding the highest-confidence rules to forbidden-patterns.json. Use this skill on a nightly cadence (3 AM PT), or manually when the user says "extract verifier rules", "promote enhancement log", "what new rules should we add", or after a significant brochure run produced many failures.
-triggers:
-  - "rdc:extract-verifier-rules"
-  - "extract verifier rules"
-  - "promote enhancement log"
-  - "what new rules should we add"
-  - "verifier corpus update"
-  - nightly cron at 3:00 AM PT
----
-
-# rdc:extract-verifier-rules
-> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
-> Return candidate rules, evidence, and PR status directly; do not dump raw tool logs.
-
-The self-learning loop. The verifier corpus is the moat (per `DECISIONS-LOG.md` D-009). This skill is how the corpus grows.
-
-## What it does
-
-1. Read `enhancement-log.jsonl` entries since last run timestamp
-2. Cluster entries by fingerprint similarity + reason text
-3. For each cluster with `N >= 3` occurrences:
-   - Generate a candidate regex or AST pattern
-   - Test the pattern against the **known-good corpus** (last 100 successful brochures) for false positives
-   - Test the pattern against the **failure cluster** for recall
-   - If false-positive rate = 0 AND recall ≥ 80%, mark as `propose`
-4. For each `propose` candidate:
-   - Open a PR on `regen-root` adding the rule to `verifiers/forbidden-patterns.json`
-   - Auto-merge if confidence ≥ 95% AND a maintainer's auto-merge flag is enabled
-   - Otherwise, await human review
-5. Write a markdown summary to `.rdc/reports/verifier-{YYYY-MM-DD}.md`
-
-## Cluster algorithm
-
-Two-stage clustering:
-
-**Stage 1 — Fingerprint clustering:**
-- Each enhancement-log entry has an `input_fingerprint` (sha256 of the offending JSX block)
-- Entries with identical fingerprints cluster trivially (same exact mistake)
-
-**Stage 2 — Semantic clustering:**
-- For unique fingerprints, embed the `reason` and `pattern` fields with `@xenova/transformers` (384-dim, local — no API)
-- Cosine similarity ≥ 0.85 → same cluster
-- Use HDBSCAN with min_samples=3 to identify real clusters vs. noise
-
-## Candidate rule generation
-
-For each cluster, generate one of:
-
-### Regex candidate
-- Take all `pattern` strings in the cluster
-- Find common substring or template
-- Generalize literal values to character classes
-- Validate the regex is well-formed and not catastrophic
-
-Example:
-```
-Cluster patterns:
-  <div className="flex flex-col gap-4">
-  <div className="flex flex-col gap-6">
-  <div className="flex flex-row items-center">
-
-Generated regex:
-  <div[^>]*className="[^"]*\\bflex\\b
-```
-
-### AST candidate
-- For cluster entries with rich AST context, build an AST query string
-- Test with @typescript-eslint/parser
-
-Example:
-```
-AST candidate:
-  JSXOpeningElement[name.name='div'] > JSXAttribute[name.name='className'] CallExpression[callee.name='clsx']
-```
-
-## False-positive check
-
-Run the candidate against the known-good corpus:
-- The 12 Phase 1 reference brochures
-- All design-partner brochures with `final_grade >= 85`
-- Any brochure tagged `corpus:reference` in Supabase
-
-If the candidate matches any known-good output → reject the candidate. False positives in the verifier corpus are unacceptable because they break working flows.
-
-## Recall check
-
-Run the candidate against the failure cluster:
-- Must match ≥ 80% of cluster entries
-- Below 80%, the candidate is too specific; widen and retry
-
-## PR generation
-
-For each promoted candidate, create a PR on `LIFEAI/regen-root`:
-
-```
-Title: [verifier-corpus] Add rule FP0{N} — {short description}
-
-Body:
-This rule was generated by rdc:extract-verifier-rules on {date}.
-
-**Cluster size:** {N} occurrences over {time span}
-**False positive rate:** {rate}
-**Recall:** {percent}
-
-**Sample failures:**
-{3-5 example enhancement-log entries}
-
-**Generated rule:**
-```json
-{rule JSON}
-```
-
-**Reviewer checklist:**
-- [ ] Verify the rule doesn't match any known-good brochure
-- [ ] Verify the suggested fix is reasonable
-- [ ] Confirm severity level
-- [ ] Confirm category
-
-Auto-merging: {yes/no based on confidence}
-```
-
-## Auto-merge policy
-
-Auto-merge if **all** are true:
-- False-positive rate = 0
-- Recall ≥ 95%
-- Cluster size ≥ 10
-- The rule pattern is a strict subset of an existing pattern (not a fundamentally new category)
-- A maintainer's auto-merge flag is enabled in `.rdc/config.json`
-
-Otherwise, await human review.
-
-## Output: nightly report
-
-`.rdc/reports/verifier-{YYYY-MM-DD}.md`:
-
-```markdown
-# Verifier Corpus Update — {date}
-
-## Summary
-
-- Enhancement log entries since last run: {N}
-- Clusters identified: {C}
-- Rules proposed: {R}
-- Rules auto-merged: {A}
-- Rules awaiting review: {W}
-
-## Top clusters
-
-| Cluster | Size | Pattern | Status |
-|---|---|---|---|
-| ...
-
-## Open PRs
-
-- #{N}: FP0{X} — {description}
-- ...
-
-## False-positive rejections
-
-Candidates that failed the known-good test:
-- {summary}
-
-## Corpus growth
-
-- Total rules in forbidden-patterns.json: {before} → {after}
-- Total component-allowlist entries: unchanged
-- Pagination rules: unchanged
-```
-
-## Manual invocation
-
-A maintainer can run this skill manually after a significant brochure run to immediately promote lessons learned:
-
-```
-rdc:extract-verifier-rules --since "2026-05-27" --auto-merge=false
-```
-
-The `--auto-merge=false` flag forces human review on all proposals regardless of confidence.
-
-## Why this matters
-
-The verifier corpus is the asset. Anyone can copy the kit. Anyone can copy the ESLint plugin. **Replicating 12 months of customer-tested failure patterns is the moat.** This skill is how that moat compounds. Every brochure run feeds it. Every nightly run grows it.
-
-After 12 months at moderate scale, the corpus will contain ~500-2,000 rules, calibrated against real customer documents, with each rule's hit count visible. New competitors entering this category will face a starting position 12 months behind.
-
-That is the point.
+---
+name: rdc-extract-verifier-rules
+version: 0.1.0
+description: |
+  Read recent enhancement-log entries, cluster failures by pattern, generate candidate verifier rules, test them against the known-good corpus and the failure corpus, and propose pull requests adding the highest-confidence rules to forbidden-patterns.json. Use this skill on a nightly cadence (3 AM PT), or manually when the user says "extract verifier rules", "promote enhancement log", "what new rules should we add", or after a significant brochure run produced many failures.
+triggers:
+  - "rdc:extract-verifier-rules"
+  - "extract verifier rules"
+  - "promote enhancement log"
+  - "what new rules should we add"
+  - "verifier corpus update"
+  - nightly cron at 3:00 AM PT
+---
+
+# rdc:extract-verifier-rules
+> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
+> Return candidate rules, evidence, and PR status directly; do not dump raw tool logs.
+
+The self-learning loop. The verifier corpus is the moat (per `DECISIONS-LOG.md` D-009). This skill is how the corpus grows.
+
+## What it does
+
+1. Read `enhancement-log.jsonl` entries since last run timestamp
+2. Cluster entries by fingerprint similarity + reason text
+3. For each cluster with `N >= 3` occurrences:
+   - Generate a candidate regex or AST pattern
+   - Test the pattern against the **known-good corpus** (last 100 successful brochures) for false positives
+   - Test the pattern against the **failure cluster** for recall
+   - If false-positive rate = 0 AND recall ≥ 80%, mark as `propose`
+4. For each `propose` candidate:
+   - Open a PR on `regen-root` adding the rule to `verifiers/forbidden-patterns.json`
+   - Auto-merge if confidence ≥ 95% AND a maintainer's auto-merge flag is enabled
+   - Otherwise, await human review
+5. Write a markdown summary to `.rdc/reports/verifier-{YYYY-MM-DD}.md`
+
+## Cluster algorithm
+
+Two-stage clustering:
+
+**Stage 1 — Fingerprint clustering:**
+- Each enhancement-log entry has an `input_fingerprint` (sha256 of the offending JSX block)
+- Entries with identical fingerprints cluster trivially (same exact mistake)
+
+**Stage 2 — Semantic clustering:**
+- For unique fingerprints, embed the `reason` and `pattern` fields with `@xenova/transformers` (384-dim, local — no API)
+- Cosine similarity ≥ 0.85 → same cluster
+- Use HDBSCAN with min_samples=3 to identify real clusters vs. noise
+
+## Candidate rule generation
+
+For each cluster, generate one of:
+
+### Regex candidate
+- Take all `pattern` strings in the cluster
+- Find common substring or template
+- Generalize literal values to character classes
+- Validate the regex is well-formed and not catastrophic
+
+Example:
+```
+Cluster patterns:
+  <div className="flex flex-col gap-4">
+  <div className="flex flex-col gap-6">
+  <div className="flex flex-row items-center">
+
+Generated regex:
+  <div[^>]*className="[^"]*\\bflex\\b
+```
+
+### AST candidate
+- For cluster entries with rich AST context, build an AST query string
+- Test with @typescript-eslint/parser
+
+Example:
+```
+AST candidate:
+  JSXOpeningElement[name.name='div'] > JSXAttribute[name.name='className'] CallExpression[callee.name='clsx']
+```
+
+## False-positive check
+
+Run the candidate against the known-good corpus:
+- The 12 Phase 1 reference brochures
+- All design-partner brochures with `final_grade >= 85`
+- Any brochure tagged `corpus:reference` in Supabase
+
+If the candidate matches any known-good output → reject the candidate. False positives in the verifier corpus are unacceptable because they break working flows.
+
+## Recall check
+
+Run the candidate against the failure cluster:
+- Must match ≥ 80% of cluster entries
+- Below 80%, the candidate is too specific; widen and retry
+
+## PR generation
+
+For each promoted candidate, create a PR on `LIFEAI/regen-root`:
+
+```
+Title: [verifier-corpus] Add rule FP0{N} — {short description}
+
+Body:
+This rule was generated by rdc:extract-verifier-rules on {date}.
+
+**Cluster size:** {N} occurrences over {time span}
+**False positive rate:** {rate}
+**Recall:** {percent}
+
+**Sample failures:**
+{3-5 example enhancement-log entries}
+
+**Generated rule:**
+```json
+{rule JSON}
+```
+
+**Reviewer checklist:**
+- [ ] Verify the rule doesn't match any known-good brochure
+- [ ] Verify the suggested fix is reasonable
+- [ ] Confirm severity level
+- [ ] Confirm category
+
+Auto-merging: {yes/no based on confidence}
+```
+
+## Auto-merge policy
+
+Auto-merge if **all** are true:
+- False-positive rate = 0
+- Recall ≥ 95%
+- Cluster size ≥ 10
+- The rule pattern is a strict subset of an existing pattern (not a fundamentally new category)
+- A maintainer's auto-merge flag is enabled in `.rdc/config.json`
+
+Otherwise, await human review.
+
+## Output: nightly report
+
+`.rdc/reports/verifier-{YYYY-MM-DD}.md`:
+
+```markdown
+# Verifier Corpus Update — {date}
+
+## Summary
+
+- Enhancement log entries since last run: {N}
+- Clusters identified: {C}
+- Rules proposed: {R}
+- Rules auto-merged: {A}
+- Rules awaiting review: {W}
+
+## Top clusters
+
+| Cluster | Size | Pattern | Status |
+|---|---|---|---|
+| ...
+
+## Open PRs
+
+- #{N}: FP0{X} — {description}
+- ...
+
+## False-positive rejections
+
+Candidates that failed the known-good test:
+- {summary}
+
+## Corpus growth
+
+- Total rules in forbidden-patterns.json: {before} → {after}
+- Total component-allowlist entries: unchanged
+- Pagination rules: unchanged
+```
+
+## Manual invocation
+
+A maintainer can run this skill manually after a significant brochure run to immediately promote lessons learned:
+
+```
+rdc:extract-verifier-rules --since "2026-05-27" --auto-merge=false
+```
+
+The `--auto-merge=false` flag forces human review on all proposals regardless of confidence.
+
+## Why this matters
+
+The verifier corpus is the asset. Anyone can copy the kit. Anyone can copy the ESLint plugin. **Replicating 12 months of customer-tested failure patterns is the moat.** This skill is how that moat compounds. Every brochure run feeds it. Every nightly run grows it.
+
+After 12 months at moderate scale, the corpus will contain ~500-2,000 rules, calibrated against real customer documents, with each rule's hit count visible. New competitors entering this category will face a starting position 12 months behind.
+
+That is the point.

package/skills/regen-media/SKILL.md

@@ -0,0 +1,94 @@
+---
+name: rdc:regen-media
+description: "Usage `rdc:regen-media <generate|edit|upscale|upload> <brief-or-path>` - Primary image-generation and Regen Media asset workflow. Use for image generation, image editing/upscaling, GPT Image/gpt-image-2 requests, Codex built-in image_gen, and uploading finished images to regen-media/R2. The default path is keyless local Codex gpt-image-2 via the built-in image_gen tool; server-side regen-media MCP/API generation is fallback only."
+---
+
+> **⚠️ OUTPUT CONTRACT (READ FIRST):** `guides/output-contract.md`
+> Checklist-only output. No tool-call narration. No raw MCP/JSON/log dumps.
+> One checklist upfront, updated in place, shown again at end with a 1-line verdict.
+
+> **Sandbox contract:** This skill honors `RDC_TEST=1`. Under `RDC_TEST=1`, do not call Codex image generation, OpenAI, regen-media APIs, upload endpoints, clauth credentials, or external services. Print the planned command and output paths only.
+
+# rdc:regen-media
+
+Primary image-generation and asset-ingest workflow for Regen Media.
+
+## Default Decision
+
+Use local Codex built-in `image_gen` with `gpt-image-2` first when all are true:
+
+- The caller is local Codex with `codex` CLI available.
+- `codex login status` reports ChatGPT login.
+- `codex features list` includes stable `image_generation`.
+- The task is generation, editing, re-rendering, or upscaling an image.
+
+Use regen-media MCP/API generation only when the local keyless Codex path is unavailable, when running in a remote/cloud session, or when the user explicitly asks for server-side generation.
+
+Use regen-media upload/registration after the image file exists and should become a managed media asset.
+
+## Local Keyless gpt-image-2
+
+Preflight:
+
+```bash
+codex login status
+codex features list
+```
+
+Requirements for size to apply:
+
+1. Use `--enable image_generation`.
+2. Use `-c model=gpt-5.5`.
+3. Instruct Codex: `use the built-in image_gen tool DIRECTLY; do not write API keys, scripts, or MCP`.
+4. Name the target size in the instruction, such as `2048x1152`, `2048x2048`, or `3840x2160`.
+
+Text to image:
+
+```bash
+echo "Use the built-in image_gen tool DIRECTLY at size 3840x2160 (4K). No API keys/scripts/MCP. Copy the PNG to output/imagegen/<name>.png and reply with only that path + pixel dims. Prompt: <dense art-directed prompt>." | codex exec --enable image_generation --dangerously-bypass-approvals-and-sandbox --cd "$PWD" -c model=gpt-5.5
+```
+
+Image edit, re-render, or upscale:
+
+```bash
+echo "Use the built-in image_gen tool DIRECTLY to re-render the ATTACHED image at size 3840x2160 (4K), preserving its composition, subject, palette, and lighting. No API keys/scripts/MCP. Save to output/imagegen/<name>-4k.png and reply with only the path + dims." | codex exec -i "input/source.png" --enable image_generation --dangerously-bypass-approvals-and-sandbox --cd "$PWD" -c model=gpt-5.5
+```
+
+Notes:
+
+- The keyless path uses the local ChatGPT Pro OAuth in the Codex install, not `OPENAI_API_KEY`.
+- Output may land both in the requested path and under `~/.codex/generated_images/<session-id>/ig_*.png`.
+- Use a long timeout or background session; generation commonly takes 2-5 minutes.
+- Valid `gpt-image-2` sizes include `1024x1024`, `1536x1024`, `1024x1536`, `2048x2048`, `2048x1152`, `3840x2160`, `2160x3840`, and `auto`, subject to model constraints.
+
+## Upload to Regen Media
+
+After generation, upload finished images through the project uploader when available:
+
+```powershell
+powershell.exe -ExecutionPolicy Bypass -File "{PROJECT_ROOT}/scripts/upload-to-media.ps1" "output/imagegen/<name>.png"
+```
+
+The uploader obtains `regen-media-api` from clauth and posts to Regen Media. Never print credential values. If upload is not required, return the local artifact path and dimensions.
+
+## Server-Side Fallback
+
+Use the deployed regen-media MCP/API generation path only when the local Codex image tool is unavailable or inappropriate. This path is credentialed, server-side, and may require an OpenAI/API key configured for the service. Treat it as fallback for generation, not the default.
+
+## Procedure
+
+1. Classify the task: `generate`, `edit`, `upscale`, or `upload`.
+2. If `RDC_TEST=1`, print the selected path and planned commands without executing external calls.
+3. For generation/edit/upscale, attempt the local keyless Codex preflight.
+4. Build the Codex `exec` command with the requested size and explicit built-in `image_gen` instruction.
+5. Save to `output/imagegen/` or a caller-provided path.
+6. Verify the file exists and record pixel dimensions.
+7. If the artifact should be managed, upload it to Regen Media and return the media URL/slug plus local path.
+8. If local Codex is unavailable, use the server-side regen-media generation fallback and clearly say that it is the fallback path.
+
+## Boundaries
+
+- Do not write or expose API keys.
+- Do not silently downgrade from local keyless `gpt-image-2` to server-side MCP/API generation.
+- Do not use prompt-only size hints; always set the Codex command and instruction shape above.
+- Do not run generation or upload in test mode.