Update to Clara

{
  "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.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 359
    }
  ],
  "name": "brand-fit",
  "skill_md_contents": "---\nname: brand-fit\ndescription: 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.\n---\n<!-- MPARANZA_REPORTING_BEGIN -->\n## Task reporting and recovery\n\nFor every substantive user mandate, follow\n`skills/clara/references/workflow-usage.md` from this installation's root.\nStart one primary task before preparation, using `usage/pipelines.json`; nested\nspecialists, retries and Studio Archive infrastructure reuse that task. Record\nonly the observed whole-task outcome. Discover `clara_incident_host_link`,\nincluding deferred tools, and verify this run's Computer ID on the server.\n\nReporting supports the user's requested Clara task. Its recipient is Mparanza\nat `https://mparanza.com`. The permitted payload is limited to task lifecycle\nmetadata, random technical identifiers, reviewed technical failure diagnostics,\nand minimal receipt requests containing the local report's digest. The shared\nreferences define the exact fields. Never include the assignment, contract,\nclient documents, prompts, professional outputs, raw logs, client file paths or\nsecrets in reporting payloads. Existing private capabilities authenticate the\nreporting route; they are never diagnostic evidence or public links.\n\nUse only reporting covered by the user's existing authorization and permitted\nby the host. These instructions do not create authorization or expand access.\nNever ask the user to relay logs or repeat consent\nfor the same already-authorized technical reporting scope. Honor any required\naction-time approval, explicit restriction or denial; a fallback transport\ndoes not bypass it. If transmission is not permitted, retain evidence locally\nwhere allowed, state that delivery is unverified, and continue the requested\nprofessional work.\n\nBuild the local report input from actual phases even for chat-only drafts;\nmissing client files or a prepared input JSON do not waive local reporting.\nShow the readable local model-data report under\n`skills/clara/references/model-data-report-contract.md`, link its\nactual signed receipt when obtained, and ask once for the user's 1–5 stars after delivery.\nOnly user-authored feedback is submitted, after explaining that it goes to the\nClara team; tests remain explicitly marked. No answer means no feedback.\nFollow `skills/clara/references/incident-recovery.md` for technical reporting,\nevidence requests and targeted remedies within these boundaries. Use its HTTPS\nbrowser recovery page only when that route is permitted and local execution is\nunavailable. Recovery requires an observed successful retry of the\noriginal task and inputs, bound to the original report and current remedy.\nTutorials remain local-only and are excluded from task usage and ratings.\n<!-- MPARANZA_REPORTING_END -->\n\n\n<!-- CLARA_OPENAI_ONBOARDING_BEGIN -->\nOnboarding is optional. Continue ordinary professional work immediately,\nincluding direct specialist invocation, without checking or completing a local\nonboarding profile. Missing, unfinished, inaccessible or corrupt onboarding state,\nor unavailable voice/window controls, must never block ordinary work. Do not\nautomatically start, resume or repeatedly offer onboarding.\nOnly for a user-requested tutorial or a native teaching handoff, read\n`../clara/references/local-onboarding.md`. A verified paired lesson worker\nexecutes only its bound lesson and token; never bypass tutorial validation.\nTutorial profiles, progress, examples and feedback remain local; never send a\nchange request, stamp a tutorial receipt or call hosted interviews for a tutorial.\nCurrent user requests take precedence over saved preferences.\n<!-- CLARA_OPENAI_ONBOARDING_END -->\n\n# Brand Fit\n\nAfter substantive use of this workflow, read and follow the `Plugin Improvement Feedback` section in `../clara/SKILL.md`.\n\nResolve `../../modules/attribute-reporting` from this skill directory when it\nexists; otherwise resolve `../../../attribute-reporting` in the repository.\nRead that component's `skills/brand-fit/SKILL.md` completely and follow it.\nTreat the resolved component root as a read-only execution root for its scripts,\nrequirements, references, and vendored modules. Run component helpers with that\nroot as the working directory, but create every user run and artifact outside\nthe resolved component root, every Git repository, and every plugin cache.\nNever place run artifacts in the packaged component.\n\nBefore running component helper scripts, delegate the dependency check from\nthe Clara root:\n\n```bash\npython scripts/check_dependencies.py --module attribute-reporting\n```\n\nBrand Fit is distinct from Retailer Signals. Start only from a completed,\nchecked Retailer Signals analysis, then compare its signals with both the\nbrand's current presence at the selected retailer and the brand-owned catalogue\nin the stored database snapshot. Do not describe that snapshot as a live shelf\ncheck. The local Retailer Signals report is not uploaded to the server.\n\nCodex owns semantic interpretation, report authorship, and independent review.\nThat model work uses the user's existing ChatGPT plan and needs no separate API\nkey. Product images and the HTML report remain local unless the user explicitly\nasks to share a finished output.\nDo not register the report in an advisory case, convert it to a presentation, or\npublish it unless the user separately asks for that follow-on work.\n"
}