Clara

View saved version →

---
name: advisory-brief-planner
description: Use internally when Clara receives a new or materially reframed advisory assignment and must turn the natural request into a reviewable assignment contract and generation handoff. Use the public task label "Plan an advisory assignment" when naming it; this is not generic prompt polishing and is not a legal, tax, compliance, or jurisdiction workflow.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

## Output Location Rule

Never write run outputs inside this Git workspace, `static/shared`,
`protected_downloads`, or another published folder. Write them in the user's
assignment or case folder, or in a sibling output folder chosen for the run.

# Plan an advisory assignment

This workflow is Clara's internal planning stage for a new advisory assignment
or a material change to an existing one. The user describes the work naturally.
Do not ask whether to optimize a prompt and do not make the user select a skill.

Use this workflow directly when the user asks to define, plan, scope, or hand
off an advisory assignment. Use it internally before substantial advisory
generation when the current request has no reviewed assignment contract. Do not
rerun it for a narrow continuation whose existing contract is still current, or
replace a specialist workflow's own accepted intake contract merely to add
ceremony.

The planner owns only the assignment contract. After handoff, the selected
`clara:*` workflow is the procedural authority. For a durable advisory case,
handoff normally goes to `clara:advisory-case-director`; bounded specialist
evidence gates, validation, presentation review, and professional approval
boundaries remain in force.

## Meaning and mechanical boundary

Clara uses model-led judgement to understand the assignment and choose:

- the decision, purpose, audience, and deliverable;
- included and excluded scope;
- the evidence and data plan;
- assumptions and material unresolved questions;
- the analytical approach and success criteria;
- the existing Clara workflow that should execute the work;
- validation, correction, and professional-judgement policies; and
- the generation instructions handed to that workflow.

Do not add or use a keyword classifier for assignment meaning, workflow
selection, source strategy, scope, or analytical framing. Do not make any
hidden model API call. Clara performs the semantic work in the active host
model session.

The local helper is deterministic because schema validation, exact ID
references, declared workflow availability, literal source anchors, declared
date and number values, hashes, and stable JSON packaging are mechanically
verifiable. It inventories recognizable dates, numbers, URLs, and question
sentences from supplied UTF-8 source text for observation only. The inventory
does not decide which source details are material and is not a completeness
gate. The helper never calls a model API and does not certify the contract's
advisory quality.

## Required artifact

The canonical cross-workflow artifact is always:

```text
advisory_contract.json
```

It uses `schema_version: "1.0"`. Its exact structure and sta

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: advisory-case-director
description: "Use when Clara must direct a durable advisory case after initial assignment framing: state the answer first, keep a living analytical spine, choose and coordinate the next analysis or research branch, integrate new evidence and partner judgement, revise the position when warranted, and decide when the working deliverable should change. This is the case-direction workflow, not a fixed analytical schema, generic prompt optimizer, data-analysis engine, deck builder, or final validator."
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

## Retain bound build artifacts

Content-addressed build directories under `<output_root>/<sha256>/` must remain
in place once their appearances are bound to the claim register. Never delete a
previous bound build after rebuilding; retain superseded builds alongside new
ones. Claim appearances are append-only and refer to the exact original bytes.
Before any proposed cleanup, run from the plugin root:

```bash
python scripts/advisory_evidence_lineage.py check-safe-to-delete <case_dir> <path>
```

A nonzero exit blocks cleanup when this case references the path or a file below
it, or its lineage cannot be checked. A zero exit means only that this case has
no bound appearance there; check every other case using that output root too.
The command is read-only and does not prevent manual filesystem deletion.


## Output Location Rule

Never write case outputs inside the Clara plugin, `static/shared`,
`protected_downloads`, or another published folder. Write them in the user's
case folder or a sibling output folder chosen for the engagement.

# Direct an advisory case

This workflow is Clara's model-led case director. It owns the evolving answer
and the work needed to improve that answer. It starts after the assignment is
understood well enough to work and remains active across research, interviews,
data analysis, partner challenge, and deliverable revisions.

Use it when Clara must:

- start or resume a durable advisory case;
- answer “where are we, what do we think, and what should we do next?”;
- decide which question, dataset, interview, comparison, or external research
  branch is now most valuable;
- integrate evidence that supports, weakens, contradicts, or reframes the
  current position;
- incorporate partner judgement without hiding who supplied it; or
- decide whether a working deck, memo, or brief must be created or revised.

Do not use it merely to package a new assignment contract, run one bounded
specialist analysis, mechanically correct an already settled deck, or validate
a completed deliverable. Route those tasks to the planner or specialist. When
their result could change the case answer, return it to this workflow.

In Codex or Cowork, read `references/operating-model.md` completely before
directing a durable case. The ChatGPT upload does not carry reference files, so
use the complete operating instructions below when that reference is absent.
Before receiving a bounded branch or validator result in Codex or Cowork, also
read [references/case-direction-return.md](references/case-direction-return.md).

## Au

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: advisory-deliverable-validator
description: Use when Clara must validate a completed advisory memo, report, analysis, presentation, or other supported professional document against advisory_contract.json and available evidence. Review contract fit, support, calculations and provenance, reasoning, contradictions, recommendation fit, judgement boundaries, correction needs, uncertainty, and delivery readiness without turning the workflow into legal, tax, compliance, or jurisdictional research.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Validate an advisory deliverable

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

## Output Location Rule

Never write run outputs inside this Git workspace, `static/shared`,
`protected_downloads`, or another published folder. Use a project output folder
beside the user's source material or another user-selected working directory.
Preserve the supplied deliverable. A correction always has a different path and
is a separate reviewed artifact.

## Generation-time binding prerequisite

Before handing a non-deck memo or report to validation, bind its final bytes
and each claim's location from the plugin root:

```bash
python scripts/advisory_evidence_lineage.py bind-output <case_dir> <deliverable_path> <locations_json>
```

`locations_json` is a JSON file, for example
`[{"claim_id":"cl-a","locator":"Recommendation, paragraph 2"}]`; include an
entry for every claim appearing in the deliverable, using existing claim IDs
and precise locations. A case-bound HTML build uses `build_html_deck.py
--case-dir <case_dir>` to bind automatically. Keep each bound artifact immutable;
write revisions to a new path and bind their new appearances before validation.
If validation reports "no hash-bound appearance", return to this binding step
for the exact prepared deliverable, then prepare the validation inventory again.

## Retain bound build artifacts

Content-addressed build directories under `<output_root>/<sha256>/` must remain
in place once their appearances are bound to the claim register. Never delete a
previous bound build after rebuilding; retain superseded builds alongside new
ones. Claim appearances are append-only and refer to the exact original bytes.
Before any proposed cleanup, run from the plugin root:

```bash
python scripts/advisory_evidence_lineage.py check-safe-to-delete <case_dir> <path>
```

A nonzero exit blocks cleanup when this case references the path or a file below
it, or its lineage cannot be checked. A zero exit means only that this case has
no bound appearance there; check every other case using that output root too.
The command is read-only and does not prevent manual filesystem deletion.


## Purpose and boundary

Use this workflow for a completed advisory deliverable: a memo, report,
analysis, presentation, or another supported professional document. Validate it
against `advisory_contract.json` and the evidence actually available. This is a
domain-neutral advisory review. It does not perform legal, tax, compliance, or
jurisdictional source selection and must not

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 6 — file references are metadata, not package contents.

View saved version →

---
name: attribute-reporting
description: Use when a user wants Clara to map retail product attributes, preserve the existing new-versus-rest or best-seller-versus-other analysis, create a private local HTML report, or answer whether that report is correct.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Attribute Reporting

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

Resolve `../../modules/attribute-reporting` from this skill directory when it
exists; otherwise resolve `../../../attribute-reporting` in the repository.
Read that component's `skills/attribute-reporting/SKILL.md` completely and
follow it. Treat the resolved component root as a read-only execution root for
its scripts, requirements, references, and vendored modules. Run component
helpers with that root as the working directory, but create every user run and
artifact outside the resolved component root, every Git repository, and every
plugin cache. Never place run artifacts in the packaged component.

Before running component helper scripts, delegate the dependency check from
the Clara root:

```bash
python scripts/check_dependencies.py --module attribute-reporting
```

Attribute Reporting is a self-contained analytical workflow. Do not register
its report in an advisory case, convert it into a 16:9 presentation, or upload
it to Mparanza unless the user separately asks for that follow-on work. If the
user asks for a presentation after the checked HTML report is complete, hand
the finished report to Clara's `html-deck` workflow as a new, explicit step.

Report files and image bytes remain local. Mapping and report evidence that
Codex reads may enter model context through the user's existing ChatGPT plan;
the component helper scripts make no separate model API call. The authenticated
retail-data bridge remains a distinct Mparanza-hosted service.

Do not use this workflow for Brand Fit. When the user wants to compare completed
retailer signals with both a brand's current presence at that retailer and the
brand-owned catalogue, route to Clara's distinct `brand-fit` skill.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: brand-fit
description: Use when a user wants Clara to compare completed retailer signals with a brand's current presence at that retailer and the brand's owned catalogue, create a private local HTML Brand Fit report, or ask whether that report is correct.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Brand Fit

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

Resolve `../../modules/attribute-reporting` from this skill directory when it
exists; otherwise resolve `../../../attribute-reporting` in the repository.
Read that component's `skills/brand-fit/SKILL.md` completely and follow it.
Treat the resolved component root as a read-only execution root for its scripts,
requirements, references, and vendored modules. Run component helpers with that
root as the working directory, but create every user run and artifact outside
the resolved component root, every Git repository, and every plugin cache.
Never place run artifacts in the packaged component.

Before running component helper scripts, delegate the dependency check from
the Clara root:

```bash
python scripts/check_dependencies.py --module attribute-reporting
```

Brand Fit is distinct from Retailer Signals. Start only from a completed,
checked Retailer Signals analysis, then compare its signals with both the
brand's current presence at the selected retailer and the brand-owned catalogue
in the stored database snapshot. Do not describe that snapshot as a live shelf
check. The local Retailer Signals report is not uploaded to the server.

Codex owns semantic interpretation, report authorship, and independent review.
That model work uses the user's existing ChatGPT plan and needs no separate API
key. Product images and the HTML report remain local unless the user explicitly
asks to share a finished output.
Do not register the report in an advisory case, convert it to a presentation, or
publish it unless the user separately asks for that follow-on work.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: business-planning
description: Prepare one business plan for a startup, new venture or established company: assess customers, market, operations, economics, cash needs, options and next actions. Vera and Clara use the same workflow and report.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Business Planning

Resolve `../../modules/business-planning` from this directory when it exists;
otherwise resolve `../../../business-planning` in the repository. Read that module's
`skills/business-planning/SKILL.md` completely and follow it. Run dependency checks
and helpers from that module root, the plugin working directory.

This is the same Business Planning function in Vera and Clara. The user's business
question determines the analysis, evidence and report. Both cover the business
proposition, demand, operations, economics, cash, options and recommendation.
Neither product has a different angle or supplies a separate contribution.
Use one case, financial model and report compiler throughout. Resume the same case
for successive pricing, market, competition and financing decisions; preserve each
iteration and distinguish bank debt from venture equity assessment.

The shared skill handles the invoking product's existing storage integration.
This affects file location and access checks only, never analytical scope,
required sections, calculations, conclusions or report content.

## Plugin Improvement Feedback

Use only the feedback rule for the installed entry product:
After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../vera/SKILL.md`.
After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: claim-basis-map
description: "Use when Clara or Codex generates, revises, or audits a clean PPTX/deck and needs a fully automatic readable sidecar that maps each slide claim to its basis and checks whether current deck text has drifted from the generation-time claim snapshot. Use for AI-generated decks where visible citations, claim IDs, reviewer attestations, hashes, thumbnails, and HTML are explicitly not wanted."
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Claim Basis Map

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

Create a clean companion file for a deck:

```text
deck.pptx
deck.claims.json
deck.claims.md
```

The PPTX stays visually clean. Do not add visible claim IDs, footnotes,
speaker-note dumps, thumbnails, HTML, reviewers, certifications, or file hashes.
Internal `claim_key` values are allowed in JSON when they make cross-slide
references more robust, but never show them in the PPTX.

## Core Rule

Track claim basis during deck generation whenever possible. Do not reconstruct
the "source of origin" after the deck is complete unless the user explicitly
accepts that the result is only matched support.

For each slide, emit `deck.claims.json` as the generation-time record. Treat the
exact normalized claim text in that JSON as the snapshot for later edit checks.
Then render `deck.claims.md` deterministically from that record with:

```bash
python plugins/clara/skills/claim-basis-map/scripts/render_claim_basis_map.py \
  deck.claims.json \
  --output deck.claims.md
```

The command also writes `deck.claims.audit.json`. Its authoritative
`source: clara_claim_basis_map_audit` and `result` fields are what the advisory
deliverable validator consumes. An ungrounded claim, broken reference, or
current-deck drift makes the command exit non-zero.

This is not tamper-proofing and does not certify the PPTX. It is a text-drift
check: if the deck changes later, rerun the renderer against the current PPTX.
Changed, missing, untracked, or broken-reference claims fail closed and are
surfaced as requiring refresh.

## JSON Contract

Use this minimal shape:

```json
{
  "deck": "deck.pptx",
  "slides": [
    {
      "slide_number": 4,
      "slide_title": "Market direction",
      "claims": [
        {
          "claim": "The market grew 12% in 2025.",
          "source_refs": [
            {
              "title": "Example Market Research Category Report 2025",
              "locator": "p. 14, table 2",
              "url": "https://example.com/report"
            }
          ]
        },
        {
          "claim": "Premium SKUs contributed 62% of growth.",
          "calculation_ref": {
            "inputs": ["sell-out extract rows 114-189"],
            "method": "premium growth / total category growth"
          }
        },
        {
          "claim": "Premiumization is likely to remain the main growth vector.",
          "claim_key": "claim-4",
          "advisory_claim_id": "claim-4",
          "evidence_receipt_ids": ["ev-category-growth", "ev-sell-out-run"],
          "reasoning_inputs": [
         

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 2 — file references are metadata, not package contents.

View saved version →

---
name: clara
description: Use whenever Clara is explicitly invoked, including through @clara, and for advisory work that Clara may organize, analyze, research, document, or present, including commercial due-diligence preparation. Always activate Clara's router, select the narrowest supported workflow, identify unsupported professional work as a capability gap with a consent-gated change-request offer, and return unrelated work as out of scope instead of answering as general ChatGPT.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

## Output Location Rule

Never write run outputs inside this Git workspace, `static/shared`, `protected_downloads`, or any GitHub Pages/static-site folder unless the task is explicitly plugin packaging/release. For user-data runs, choose an output directory outside the repo, preferably a sibling `output/<plugin-name-or-run-id>` folder next to the user-provided input folder, and pass that path to every `--output-dir` or `--out` argument. If a script has a safe default next to the input folder, use that default instead of inventing `out/...` under the repo.

# Clara

<!-- CLARA_OPENAI_VERSION_BEGIN -->
## Installed version check

For Codex with local tools, once per conversation run the **currently exposed
installed plugin's** `scripts/check_for_update.py --version-only` before ordinary
work if startup did not already provide its installed-version context. Resolve
that script from this skill's own plugin root; never substitute a repository,
download or another cache. Show any update notice in the user's language.
A local marketplace package does not update merely because a new version was
published: use the official listing in the notice to update, then verify the
plugin exposed in a fresh conversation. Do not edit generated cache files.
If the script is missing or the version cannot be checked, say the active version
is unverified when discussing a fix; never infer it from a successful build.
This check sends no case or tutorial content and does not start CR polling.
It does not require onboarding and does not block the requested work.
<!-- CLARA_OPENAI_VERSION_END -->


## Invocation and scope contract

An explicit host invocation of Clara, including `@clara`, always activates this
router. Treat the host invocation as an exact routing signal; do not depend on
keyword matching in the message text. Invocation selects Clara, but it does not
make every request a supported Clara task.

Before giving a substantive answer, interpret the request semantically and
choose one routing outcome:

| Outcome | Required behavior |
| --- | --- |
| Supported professional work | Select the narrowest Clara workflow, read its skill completely, follow it, and disclose the workflow used. |
| Professional capability gap | Do not improvise a generic Codex answer under Clara's name. State that Clara has no reliable workflow for the task and offer to draft a sanitized change request. Show the exact request and obtain separate consent before transmitting it. |
| Unrelated work | State that the request is outside Clara's professional scope and direct the user to ordinary ChatGPT. Do not answer 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 6 — file references are metadata, not package contents.

View saved version →

---
name: deck-correction
description: "Correct, revise, or rebuild an existing PPTX or Clara HTML deck from spoken feedback, a call transcript, screen recording, review notes, or partner comments. Use when the user says record feedback on this deck or when the requested outcome is a changed deck rather than only a transcript: open Clara Voice Capture when needed, interpret every requested change, preserve untouched content, require a reviewable understanding and approval checkpoint for PPTX work, apply changes to a copy, render, verify, and inspect the final audience-facing deck. Do not use for transcription alone or for creating a new deck without revision feedback."
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Deck Correction

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

## Output Location Rule

Never write run outputs inside this Git workspace, `static/shared`,
`protected_downloads`, or another static-site folder. Keep the corrected deck,
rendered slides, revision artifacts, and `codex_run_review.md` in the user's case
or adjacent project/output folder.

Use this skill when feedback must become a verified deck change. The analytical
meaning of the feedback is model-led work; deterministic helpers may prepare
evidence, validate contracts, apply explicit patches, and verify mechanics, but
must never decide what the speaker meant from keywords, slide numbers, or visual
matching alone.

Complete interpretation, user review, application, rendering, verification,
and final output review. Use a persistent goal only when explicitly requested
by the user; otherwise use a proportionate plan without pausing intake to
create a goal.

## Route by Target Format

- **PPTX:** use the Clara deck-revision harness below and the installed
  presentation-editing capability. Keep the original untouched and edit a copy.
- **Clara HTML deck:** use the `html-deck` preservation-aware revision workflow.
  Build a revision map from the approved change ledger, protect untouched
  slides/components/runtime, apply only mapped changes, and prove before/after
  fidelity through browser and render QA.
- **No existing deck:** this is creation, not correction. Route to the normal
  presentation or `html-deck` creation workflow after clarifying the target
  format.

If the feedback comes from audio or video, use `transcribe` first when no clean
reviewed transcript exists. A hosted external interview is not a deck-correction
input until its bundle has been retrieved and the user explicitly asks to use
that evidence.

When the deck belongs to a case with advisory lineage, preserve that history as
well as the original file. An unchanged claim keeps its upstream claim ID and
gains an appearance for the corrected deck. Changed wording creates a new claim
whose `supersedes_claim_id` points to the old claim; removed wording leaves the
old claim withdrawn or superseded rather than deleting it. New or changed
evidence gets a new receipt. Rerun Claim Basis Map, HTML Deck, or Reporting
Engine checks as applicable. These lineage updates do not replace this

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: hosted-interview
description: "Prepare and operate Clara-hosted external voice interviews: select an exact versioned research campaign or define a scoped one-off case interview, create an expiring no-login participant link, check its status, and retrieve the completed JSON bundle and post-interview quality review. Use when the user asks to interview a client, stakeholder, expert, research participant, or other external respondent through a hosted browser link, or asks to retrieve or review that interview's result. Do not use for interviewing the user in chat, advisor voice debriefs, uploading or transcribing existing recordings, bulk outreach or email campaigns, or importing Hosted Voice bundles."
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Interview

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

## Output Location Rule

Never write run outputs inside this Git workspace, `static/shared`,
`protected_downloads`, or another static-site folder. Keep receipts, briefs,
bundles, reviews, and `codex_run_review.md` in the user's project/output folder.

Use this skill for the external-participant workflow. An authenticated preparer
defines the brief and creates a bearer link; the participant opens that link
without signing in and speaks with Clara's adaptive browser interviewer for up
to 15 minutes. This is separate from `transcribe`, which captures or imports an
advisor discussion or existing recording.

## Boundaries

This skill owns:

- selecting one exact registered campaign or drafting one scoped custom brief;
- choosing `case_interview` or `research_interview` from the intended output;
- creating a participant-specific expiring link only when the user asks;
- checking a known link's status;
- retrieving its JSON bundle and post-call quality review before expiry;
- handing the retrieved evidence to the main `clara` case workflow only when
  the user explicitly asks to add it to a case.

It does not own:

- interviewing the user in chat;
- consultant debriefs, uploaded recordings, or Hosted Voice bundles—use
  `transcribe`;
- deck changes from spoken feedback—use `deck-correction`;
- bulk outreach, invitation email, campaign-registry changes, revocation,
  raw-media download, or cross-interview synthesis;
- treating the generated review as proof that every statement is correct.

The participant URL is a bearer credential. Show it to the requesting user, but
never send it to another person or mailing list unless the user explicitly asks
for that external action. Keep it in the private `0600` receipt written by the
helper; never put the URL/token, authentication cookies, or magic links directly
in command arguments, shell history, ordinary logs, or source files.

## Interview Modes

Use `case_interview` when the output should represent one situation deeply:
context, chronology, constraints, decisions, risks, bottlenecks, and unresolved
questions. Use `research_interview` when the output must preserve natural
conversation while covering common dimensions well enough for later comparison.

Do not turn either mod

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: html-deck
description: Build or revise source-faithful, cinematic, animated standalone HTML slide decks for Clara or Codex from Word, PDF, Markdown, spreadsheet, case-workspace, or mixed source materials. Use for a premium HTML presentation, web deck, animated talk, responsive keynote-style deck, speaker notes, preservation-aware HTML deck changes, or an alternative to PPTX/PDF that must remain self-contained and browser-presentable.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# HTML Deck

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

Create a decision-ready HTML presentation with bespoke editorial craft and a
repeatable authoring, provenance, revision, and browser-QA system. Keep source
material authoritative. Use motion to clarify meaning, not decorate it.

## Non-negotiables

- Preserve names, numbers, periods, dates, qualifications, examples, and
  advisory logic. Never make a deck prettier by making it less true.
- For a Clara case, build only after the Advisory Intelligence Loop and from
  `advisory_workpaper.md`, `presentation_storyline.md`, relevant sources, and
  advisor judgement actually supplied. Keep material evidence gaps visible.
- Keep user data and outputs outside plugin source. Put the work folder and
  deliverables beside the user's project outputs or in the requested folder.
- Produce a dependency-free `index.html`: no CDN, web font, remote script,
  analytics, tracking, or required network request.
- Publish below a lowercase 64-character hexadecimal directory by default and
  include `noindex,nofollow,noarchive` unless discovery is requested.
- Use Clara's shared fixed 16:9 runtime. Letterbox rather than stretch. Every
  slide needs a stable ID, audience-facing title, and speaker notes.
- Keep operator chrome outside slide content. Persistent visual page numbers
  and decorative counters are prohibited; the auto-hiding HUD may show state.
- Preserve keyboard, touch, reduced-motion, accessibility, and print behavior.
- Treat a difficult URL as convenient obscurity, not access control.

## Retain bound build artifacts

Content-addressed build directories under `<output_root>/<sha256>/` must remain
in place once their appearances are bound to the claim register. Never delete a
previous bound build after rebuilding; retain superseded builds alongside new
ones. Claim appearances are append-only and refer to the exact original bytes.
Before any proposed cleanup, run from the plugin root:

```bash
python scripts/advisory_evidence_lineage.py check-safe-to-delete <case_dir> <path>
```

A nonzero exit blocks cleanup when this case references the path or a file below
it, or its lineage cannot be checked. A zero exit means only that this case has
no bound appearance there; check every other case using that output root too.
The command is read-only and does not prevent manual filesystem deletion.


## Decision boundary

The model owns semantic work: source interpretation, storyline, claims,
qualifications, layout choice, visual type, analytical filters and periods,
speaker notes, and editorial j

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 51 — file references are metadata, not package contents.

View saved version →

---
name: learn-with-clara
description: Teach only this installation's supported Clara workflows through a native voice conversation and a parallel working chat that runs real examples. Use for first onboarding, demonstrations, guided practice, discovering what Clara can do, revisiting an example, or applying it to user-selected files. Starts in desktop Codex; Claude Cowork is outside this feature.
---

# Impara con Clara

Help the consultant obtain and understand a useful result by describing their
work naturally. Use native voice first, a teaching chat and a parallel working
chat. Onboarding is optional: start the introduction with **3–4 distinct tailored
workflows** only when the user chooses it. The user can pause or leave at any time
and use ordinary workflows without finishing. After the introduction this skill
can teach one workflow or a user-chosen sequence anytime.
Do not require the user to know skill names or how to write technical prompts.

## Required file access before any course step

Before the interview, lesson explanation, window/voice setup or first exercise,
read `references/file-access.md`, connect the shared course workspace and run
its setup command to save and reload the actual profile. This applies
to every course and language, first onboarding, repeated lessons and resumes.
If access or saving fails, stop teaching and guide the user through the exact
permission request and verified retry. Do not continue with prompt preparation,
text-only practice or theory while files cannot be saved. Each working chat must
verify its own access. A permission click is not a successful write test.

## Clara workflows only

Teach only operational workflows listed in Clara's current
`../clara/references/workflow-catalog.md` whose `../<workflow-id>/SKILL.md` exists
inside this same Clara installation. Read that Clara skill and follow its declared
components. Another installed plugin, a similarly named skill, a shared Python
environment or a saved example does not extend Clara's teaching scope. This rule
applies to the teacher, the working chat, first onboarding, repeated lessons and
practice on the user's files.

Brand Fit, Hosted Interview and Research Video require hosted services and are
unavailable as local lessons. They remain Clara professional workflows; do not
describe them as nonexistent or simulate their output. Exclude them from first
onboarding and repeated lesson dispatch. If asked, explain this limit in the
user's language and offer an available local lesson without starting hosted work.

If the requested skill is outside Clara, say that Clara cannot teach it. Offer
relevant workflows from Clara's own catalog, explain their actual scope, and let
the user choose before preparing materials or dispatching work. Never teach,
invoke or hand off to Vera, Lucia or a standalone plugin as a Clara lesson, even
when that plugin is installed. Do not relabel another workflow with a valid Clara
ID or recreate its method in an improvised script or lesson.

For example, Vera's `fatture-xml-check` is outside Clara. Clara's own
`reporting-engine` is eligible when its actual contract fits the requested goal.

## Start from the user's goal

Read `../clara/references/local-onboarding.md` and use its installed-root discovery
and shared OS-user profile. For this user-requested tutorial, if onboarding is
unfinished, explain the optional introduction and follow its interview and 3–4
lesson plan only if the user chooses it. If they decline or want ordinary work,
route directly to the requested specialist. A tutorial setup or recovery error
must never prevent that transition. Never reset a completed
profile or use repeated teaching to manufacture onboarding completion.

For a directly requested course, read `references/local-sessions.md`, then run
`local_teaching.py status`. The optional introduction need not be complete:
start the requested session with the actual native chat pair and preserve any
unfinished introduction, without in

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 6 — file references are metadata, not package contents.

View saved version →

---
name: privacy-surface-review
description: Use when adding, changing, reviewing, or releasing a Clara workflow or hosted integration to record what Codex can read, every boundary beyond Codex, and the source-backed access and retention position before packaging.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Privacy Surface Review

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

Do not initiate feedback merely because this release check was run.

This is a developer and release workflow. It is not a customer-case intake step.
A normal Clara run does not display a privacy notice or ask for privacy consent
merely because Codex reads professional material.

## Review workflow

1. Resolve the Clara root and list every sibling directory in `skills/` that has
   a `SKILL.md`. Every user-facing workflow except this review skill must have a
   matching record in `privacy/workflows/`.
2. Read the workflow's complete skill and every relevant script, reference,
   payload builder, connector, browser route, and embedded component. For
   Attribute Reporting and Brand Fit, resolve `modules/attribute-reporting` in a
   packaged plugin or the sibling repository component.
3. Record the information that may enter Codex context. Real client, participant,
   employee, source, transcript, deck, and business data may enter that context.
   Do not describe model-read material as local-only because its source file or
   final artifact remains on the user's computer.
   For ordinary Codex model processing, keep the common policy explicit: the
   user-selected ChatGPT/Codex account is the processing arrangement; Clara adds
   no separate recipient, does not automatically anonymise, and may filter or
   aggregate locally only when useful. Clara cannot inspect or enforce the plan.
4. Record every boundary beyond Codex in the workflow manifest. Link every
   Mparanza route to one record in `privacy/hosted-services/`. Public research,
   public image retrieval, external connectors, and send or publish actions stay
   in the workflow manifest.
5. For a hosted service, record only payload, access, and retention facts that
   inspected governed source supports, including the relevant Mparanza service
   and legal copy. If those sources do not establish hosted retention or
   deletion, say so. Link expiry is not proof that stored material is deleted.
6. The user's explicit choice of a hosted, connector, send, or publish route is
   the confirmation for that route. Ask separately only when the external action
   is optional and the user has not already chosen it. Do not ask twice.
7. Record only source-enforced security controls and the user's ChatGPT/Codex
   account boundary. An empty security-control array is accurate when the
   workflow has no control of its own. Do not relabel local storage, output
   review, source preservation, ordinary route choice, policy wording, or a
   procedural instruction as security. Clara cannot inspect or enforce the
   user's plan, model-training data controls, or retention/deletion controls. The
   firm or us

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 3 — file references are metadata, not package contents.

View saved version →

---
name: reporting-engine
description: Use when Clara needs budgeting/forecast reports with both variances and Sites delivery, CSV/XLSX/Parquet dataset intake, Sales/Discount/COGS identification, chart capability evidence, dataset profiling, a source-backed dataset semantic layer, mechanical compatibility checks, or reporting contract inspection before chart/report selection.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

## Budget monitoring and forecast reports

For Actual/Budget monitoring, use `../../modules/reporting-engine/scripts/budget_report.py`
from this skill. This route reuses the management-control calculation core and
shared IBCS-style reporting table, separately from Business Planning. Run the
normal dependency check below (`requirements.txt` includes openpyxl).

1. `python scripts/budget_report.py inspect --input <exports.xlsx> --output-dir <new-inspection-folder>`
2. Read the bounded inspection and author/review its recipe for the user: source
   roles, signed amounts, category/account mappings, reporting start/end, closed
   month cutoff, currency, controls, audience and optional forecast assumptions.
   Ask only unresolved business decisions; never ask the user to edit JSON.
3. `python scripts/budget_report.py run --input <exports.xlsx> --recipe <reviewed.json> --output-dir <new-report-folder>`
4. Read `model_context.json`, not raw populations by default, and prepare
   commentary from `commentary_template.json`, bound to its metric IDs and pack
   hash. Treat observations and hypotheses separately; professional review
   remains explicit. Deliver that explanation with the local report by running
   `python scripts/budget_report.py run --input <exports.xlsx> --recipe <reviewed.json> --commentary <commentary.json> --output-dir <new-explained-report-folder>`.
   This replays the original sources, rejects stale commentary and writes the
   explained dashboard, `management_control_report.md`, the numeric workbook
   and an execution receipt. Keep the earlier calculation folder intact.
   Open the native interactive dashboard locally with
   `python scripts/budget_report_preview.py --report <new-explained-report-folder>/management_control_dashboard.html`
   and open its returned loopback URL in the Codex browser. This receipt-checked,
   read-only preview keeps month and cumulative-view controls working; it does
   not publish or need a Vera client engagement. Keep the server running while
   reviewing. Use the course document reader for the workbook and Markdown
   report, not for the interactive HTML; opening HTML as a source file is not
   a rendered-dashboard check.
5. If the user requests Sites: `python scripts/budget_report.py site --input <exports.xlsx> --recipe <reviewed.json> --pack <management_control_pack.json> --commentary <commentary.json> --audience <client> --output-dir <new-site-folder>`.

Repeat `--input` for separate exports. The optional `forecast` role uses the same
reviewed columns as Budget; `forecast_basis` states its source and assumptions.
Actuals through cutoff plus remaining-month estimates form the full-period
forecast. Do not infer future values or 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: research-video
description: Turn a user-approved ordered set of research scene images into a source-faithful 16:9 narrated MP4 with restrained motion, synchronized narration in English, Italian, French, German, or Spanish, captions, a reviewable narration script, and mechanical media validation. Use for a research explainer, executive briefing video, client education video, or narrated visual short. Do not use for filming, avatar video, generative scene invention, or revising an existing video.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Research Video

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

Create one short, source-faithful research video from an ordered set of approved
scene images. The supplied images and source material remain authoritative.
Clara may write narration and recommend scene order, but must not invent a
claim, statistic, map feature, figure label, visual object, or source basis.

## Runtime and output boundary

The complete workflow uses the authenticated Mparanza Research Video voice
page to generate one audio artifact per approved scene, plus a local Clara
runtime with Python and FFmpeg to build the MP4. No user API key is required.
Mparanza holds the provider credential; the packaged renderer contains no
provider credential and makes no direct speech-provider call.

The hosted service is currently open to every authenticated Mparanza account;
there is no Research Video email allowlist. Only the exact approved narration,
language, scene identifiers, and approval/plan hashes cross the hosted boundary.
Images, research sources, source-basis notes, Vera artifacts, and local paths
stay in the local workspace. Mparanza builds the response ZIP in memory and does
not write the request or generated audio to application storage. OpenAI receives
the narration under Mparanza's provider arrangement; do not infer or promise an
OpenAI retention period from this workflow.

Keep all run inputs and outputs outside plugin source and static/public folders.
Use an output folder beside the user's project material unless the user names a
different destination. Never put an API key in chat, a scene plan, a command
argument, a log, or an artifact.

## Decision boundary

Clara owns semantic work through model-led review:

- selecting and ordering only the user-approved research scenes;
- interpreting the supplied material;
- drafting concise narration in the approved language (`en`, `it`, `fr`, `de`,
  or `es`);
- deciding what each scene contributes to the argument;
- checking that narration says no more than its recorded source basis;
- identifying qualifications, uncertainty, and claims that should be removed.

Deterministic code owns work whose correctness is mechanically verifiable:

- scene-plan schema, path, file-type, dimension, and size validation;
- SHA-256 fingerprints for the plan and every visual layer;
- approval binding to the exact narration and visual plan;
- hosted voice request and bundle-manifest shape, scene-audio conversion and
  hashes, scene timing, caption timing, motion render

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 4 — file references are metadata, not package contents.

View saved version →

---
name: transcribe
description: Capture, transcribe, import, attribute, and review advisor voice notes, consultant debriefs, meetings, calls, and existing audio recordings with Clara Hosted Voice. Use when the user asks to start Voice Capture, transcribe an audio file, import a case-notes-audio or case-notes-voice ZIP/JSON bundle, preserve a transcript in an ordinary folder with deduplication, or add a reviewed transcript to a Clara case. Do not use to create an adaptive external-participant interview link or to revise a deck from spoken feedback.
---

<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->
Onboarding is optional. Continue ordinary professional work immediately,
including direct specialist invocation, without checking or completing a local
onboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,
or unavailable voice/window controls, must never block ordinary work. Do not
automatically start, resume or repeatedly offer onboarding.
Only for a user-requested tutorial or a native teaching handoff, read
`../clara/references/local-onboarding.md`. A verified paired lesson worker
executes only its bound lesson and token; never bypass tutorial validation.
Tutorial profiles, progress, examples and feedback remain local; never send a
change request, stamp a tutorial receipt or call hosted interviews for a tutorial.
Current user requests take precedence over saved preferences.
<!-- CLARA_OPENAI_ONBOARDING_END -->

# Transcribe

After substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.

## Output Location Rule

Never write run outputs inside this Git workspace, `static/shared`,
`protected_downloads`, or another static-site folder. Preserve bundles, audio,
transcripts, review files, and `codex_run_review.md` in the user's target case,
ordinary folder, or adjacent project/output folder.

Use this skill for transcription-first evidence capture. The hosted service is
the authorized audio/transcription layer. Durable source and output files remain
local after import; Codex performs speaker review and advisory interpretation
through the user's existing ChatGPT plan. This is separate from `hosted-interview`,
which conducts an adaptive conversation with an external participant.

## Choose the Path

- **Live consultant debrief:** launch Voice Capture from an existing Clara case.
- **Existing audio:** upload the voice note, meeting, or call recording through
  the hosted service, then import the downloaded bundle.
- **Downloaded bundle into a Clara case:** import into `voice_sessions/`, finish
  speaker attribution, register the reviewed transcript, and update the case
  evidence map before downstream advisory output.
- **Downloaded bundle into an ordinary folder:** preserve the original bundle
  and readable transcript with deduplication; do not initialize a case merely
  to store the transcript.
- **Spoken feedback that should change a deck:** complete transcription and
  attribution here, then route the reviewed evidence to `deck-correction`.

In a case using advisory lineage, the reviewed transcript creates an
`interview_transcript` receipt with the transcript path, locator, and hash.
Each quote or attribution used downstream becomes a claim linked to that
receipt. The receipt can establish that the named speaker said the quoted
words; it does not by itself establish that the speaker's underlying assertion
is true. Create a separate claim and basis when Clara relies on the assertion
as a fact. Preserve the same claim and evidence IDs when the quote moves into a
workpaper, memo, decision pack, Claim Basis Map, or HTML content ledger.

Run dependency checks from the plugin directory before substantive work:

```bash
python scripts/check_dependencies.py
```

Install declared requirements only when the environment permits. Do not install
packages at runtime from within a plugin script.

## Live Capture

For an initialized Clara case:

```bash
python scripts/l

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.