Use this prompt to process one or more completed `ai-chat-rev-ops` review documents through `rev-content-1-triage`.

Replace `[SOURCE_PATHS]` with one or more absolute file paths. Do not change the rest unless the desired output scope changes.

```text
Run `/rev-content-1-triage` in registry and reconciliation mode against every document listed under SOURCE PATHS.

SOURCE PATHS
[SOURCE_PATHS]

Objective

Turn every content candidate in the supplied AI chat review documents into a verified lifecycle decision. Approve only genuinely new, evidence-backed ideas. Identify existing packages, merges, proof-first candidates, holds, and rejects without producing duplicate content.

Authority and source order

1. Load and follow the current `rev-content-1-triage` skill.
2. Load the current full/REFIT strategy, Revenue Content Pipeline SSOT, System Integrity Guardian, Four-Module TOV OS SSOT, and Modules A through D from their live paths.
3. Use current strategy and live lifecycle folders over status claims inside the input documents.
4. Read every supplied source document in full.
5. Inspect `01-CONTENT-IDEAS`, `02-IDEAS-APPROVED-FOR-PRODUCTION`, every active lifecycle stage, and `08-ARCHIVED-OR-KILLED` for duplicates before deciding.
6. Check current Airtable and Open Brain state only when available through an authorized read path. Do not block local triage when those surfaces are unavailable.

Execution stages

Stage 1: Extract

List every candidate found in the source documents. Preserve its source path, evidence anchor, claimed audience, proof status, and existing fingerprint when present.

Exit condition: every source candidate is accounted for exactly once.

Stage 2: Reconcile

Compute or normalize a Dedup Fingerprint for every candidate. Compare it with existing idea briefs, registries, active packages, published packages, and killed items.

Use only these statuses:

- `approved-produced`
- `approved-existing-package`
- `approved-future`
- `conditional-proof-first`
- `hold`
- `merge`
- `reject`

An existing package outranks a new idea brief. Recurrence enriches the existing item. It does not create another package.

Exit condition: every candidate has one status, one fingerprint, and one exact lifecycle or evidence path when one exists.

Stage 3: Apply the gates

Judge every candidate against:

- Source depth
- Module A live wire
- Module B Paul chair
- Module D hook gap
- Wider-audience fit
- Proof path
- Fluent-failure risk
- Paul Test
- Human Test
- Breadth Test
- Ad-Lib Test
- Brand-position test
- Proper-name HARD FAIL
- Content-led revenue gate

Founder narrative without a complete Human Source Record is `conditional-proof-first`, never production-ready. A brief, gate report, status note, or prior agent claim is not parent proof. No pricing belongs in public social content. Do not create warm outreach, revive retired offers or channels, or invent buyer demand.

Exit condition: every status is supported by a short gate decision and evidence pointer.

Stage 4: Write the registries

Write two new Markdown files to:

`/Users/paul/dev-4/1-fullREFIT/revenue-content-pipeline/01-CONTENT-IDEAS/`

Use ClearPath names with the executing agent code and current `_MMDDYY` date:

1. `approved-ai-chat-triage-[source-slug]-[agent-code]_[MMDDYY].md`
2. `held-rejected-ai-chat-triage-[source-slug]-[agent-code]_[MMDDYY].md`

The approved registry must include each `approved-produced`, `approved-existing-package`, or `approved-future` item with:

- Rank
- Title under 65 characters
- Registry status
- Dedup Fingerprint
- Description naming the tension
- Five framework bullets
- One-sentence value statement
- Opening-layer mechanic
- Trust-layer mechanic
- CTA disposition
- Parent proof
- Current lifecycle path
- Dedup or merge note
- Single next action

The held and rejected registry must include every `conditional-proof-first`, `hold`, `merge`, and `reject` item with:

- Title
- Registry status
- Dedup Fingerprint
- Decision reason
- Five supporting bullets
- Failed gate
- Fluent-failure warning
- Exact merge target or salvage condition
- Source path and evidence anchor

Include a reconciliation summary with counts that add up exactly to the number of source candidates.

Exit condition: both files exist and every source candidate appears in exactly one registry.

Stage 5: Verify and halt

Read both files back. Confirm:

- Source count equals final decision count.
- No candidate is missing or duplicated.
- Every approved item has a proof path and CTA disposition.
- Every existing or merged item names an exact target path.
- No unverified proper name appears.
- No script, post, carousel, package, schedule, or public content was produced.

Do not create Airtable rows, post to Slack, schedule content, publish anything, mint links, or advance lifecycle stages without the required explicit approval. Present the ranked result and wait at that gate.

Done means

Both registries exist, all counts reconcile, duplicates point to their existing lifecycle items, and the report names the top genuinely new approved idea. If no genuinely new idea survives, say that plainly and name the highest-priority existing package to advance instead.

Wrong looks like

- Treating every `ai-chat-rev-ops` candidate as approved.
- Recreating an idea or package that already exists.
- Producing content instead of triaging it.
- Calling a brief or agent claim proof.
- Ignoring current strategy because the input document is newer.
- Forcing a top new idea when the correct result is zero.
- Writing to Airtable or an external control surface before approval.
```

## Shape decision

- Shape: 04 Package
- Reason: the reusable run produces two durable registries and includes a mandatory halt before external writes.