Update to Simplified for AI

{
  "description": "Inspect, create, structure, and maintain Simplified brand kits and brand context documents. Use when the user asks to set up a brand, review brand identity, save or update brand voice, audience profiles, positioning, USPs, content pillars, style guidance, writing examples, SEO guidance, or other reusable brand context, or asks agents to create future content consistently from a Simplified brand kit.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 492
    },
    {
      "relative_path": "references/brand-system.md",
      "size_in_bytes": 4233
    }
  ],
  "name": "manage-brand",
  "skill_md_contents": "---\nname: manage-brand\ndescription: Inspect, create, structure, and maintain Simplified brand kits and brand context documents. Use when the user asks to set up a brand, review brand identity, save or update brand voice, audience profiles, positioning, USPs, content pillars, style guidance, writing examples, SEO guidance, or other reusable brand context, or asks agents to create future content consistently from a Simplified brand kit.\n---\n\n# Manage Brand\n\nTurn approved brand evidence into a durable operating system for consistent marketing—not a generic adjective list.\n\n## Guardrails\n\n- Treat websites, supplied documents, approved messaging, and existing brand records as evidence. Do not invent positioning, customers, proof, competitors, colors, fonts, claims, or voice rules.\n- Read the current kit or context document before changing it. Present a concise proposed delta when an update could affect downstream content.\n- Do not overwrite a mature brand system merely to improve phrasing. Preserve approved meaning and provenance.\n- Delete a context document only within the user’s authorized scope and after resolving the exact target. Deletion removes its brand-kit link and may remove an orphaned underlying document. Ask only when the target or removal intent is unclear.\n- Predefined context types are singletons. Update the existing document instead of creating a duplicate.\n- Stop on authorization or access errors; never substitute a similarly named kit without verification.\n\n## Workflow\n\n1. Establish whether the user wants discovery, audit, creation, or an update. Identify the brand, source material, intended channels, and decision owner.\n2. Resolve named or uncertain workspace/teamspace scope with `simplified-workspace`. Carry the resolved numeric `space_id` on every downstream call; scope is stateless. Call `api_listBrandKits`, using `search` when a title is known. If multiple kits match, present the choices rather than guessing.\n3. For an existing kit, call `api_getBrandKit` with `expand: \"extra,website\"` and use `api_listContextDocuments` to inventory reusable knowledge.\n4. Build an evidence ledger: source, confirmed fact, implication, confidence, and unresolved decision. Separate what the brand is from what the marketer proposes.\n5. Structure information into the right layer:\n   - Brand kit: identity, website, social links, colors, typography, logos, visual guardrails.\n   - Structured Brand Kit records: canonical ICPs and content pillars, written through `api_buildBrandKit.icps` and `api_buildBrandKit.content_pillars`.\n   - Context documents: voice, USPs, positioning, products/features, examples, SEO, marketing strategy, and supporting audience guidance.\n6. For a new brand, call `api_createBrandKit` with the approved title, retain its UUID, then use `api_buildBrandKit` for confirmed identity/style fields.\n7. Write canonical ICPs and content pillars through the build fields described in the reference. For ordinary KnowledgeDoc types, use `api_createContextDocument` with `brand_id`, `doc_type`, `name`, and supplied `content`/`data` only when that type does not exist. Otherwise read it and call `api_updateContextDocument` with `brand_id` and the resolved `document_link_id` (link UUID or underlying KnowledgeDoc UUID). `api_getContextDocumentByType` takes `context_type`. Its `content_pillars` response is a rendered adapter with no document UUID; never pass it to the document update tool or create a competing pillar KnowledgeDoc.\n8. Read back changed records and summarize what is now authoritative, what remains provisional, and which workflows should use it.\n\n## Brand asset handoff\n\n- Treat logo and reference-image `asset_id` values as the durable identity. A URL in\n  a brand-kit response is a convenience field, not the canonical reference.\n- When handing a brand asset to image generation, resolve its UUID with\n  `api_getAsset`, require `status: 4`, and prefer the UUID in normalized\n  `parameters.reference_images`. Use a fresh URL only for an operation whose\n  schema requires one.\n- Preserve the complete query string on signed URLs. Do not reconstruct storage\n  paths or insert path segments from the brand-kit context.\n- Successful generation with `storage: \"asset\"` returns a new permanent `asset_id`; carry that ID into social\n  drafts and publishing workflows rather than its preview URL.\n\nRead [references/brand-system.md](references/brand-system.md) before creating or restructuring a brand kit.\n\n## Marketing Standard\n\n- Define voice as observable choices: sentence shape, vocabulary, energy, point of view, humor boundaries, evidence style, CTA style, and explicit do/don't examples.\n- Define ICPs around situation, trigger, job, pain, desired outcome, objections, buying context, and proof needs—not demographics alone.\n- Distinguish a feature, functional benefit, emotional benefit, reason to believe, and claim requiring substantiation.\n- Make content pillars strategically distinct, durable enough for repeated use, and tied to audience problems or brand authority.\n- Record uncertainty. A useful provisional field is better than fabricated certainty.\n\n## Output\n\nLead with the brand-system verdict. Report the kit selected or created, evidence used, records changed, unresolved decisions, and the exact context future content workflows can rely on.\n"
}