Update to OmniSkill

{
  "description": "Architect a new agent Skill or convert an existing prompt, SOP, playbook, runbook, workflow, or repeated agent behavior into a durable Skill. Use when the main problem is deciding what the Skill should contain, how it should activate, which architecture and freedom levels fit, and how to separate instructions, references, scripts, and host adapters. Do NOT use when the user only wants to run an existing Skill or only wants behavioral evaluation of an already-frozen Skill.\n",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 268
    }
  ],
  "name": "skill-architect",
  "skill_md_contents": "---\nname: skill-architect\ndescription: >\n  Architect a new agent Skill or convert an existing prompt, SOP, playbook, runbook, workflow, or repeated agent behavior into a durable Skill. Use when the main problem is deciding what the Skill should contain, how it should activate, which architecture and freedom levels fit, and how to separate instructions, references, scripts, and host adapters. Do NOT use when the user only wants to run an existing Skill or only wants behavioral evaluation of an already-frozen Skill.\n---\n\n# Skill Architect\n\n> Turn repeated agent work into a behaviorally specified Skill before writing host syntax.\n\n## Why This Skill Is Needed & Target State\n\n**Why this skill is needed:** Developers often jump directly to writing ad-hoc prompt strings or host-specific configurations without defining a clear behavioral boundary. This results in poorly triggering skills, overlapping responsibilities, uncalibrated freedom levels, and lack of falsifiable success criteria.\n\n**Target state:** Every authored skill begins with an explicit contract defining its singular job, trigger boundaries, invariants, freedom calibrations, and evaluation criteria before any code is generated.\n\n## Required inputs\n\nExtract from the request or source material:\n\n- recurring user job\n- primary user\n- realistic trigger prompts\n- close negatives\n- desired outcome\n- current failure or inconsistency\n- consequences of mistakes\n- required tools or data\n- target hosts, if any\n\nDo not force the user to answer fields that can be inferred safely from supplied material. Mark uncertain assumptions\n\n## Step 1: Decide whether a Skill is justified\n\nA Skill is justified when at least one durable behavior is missing or unreliable:\n\n- specialized knowledge\n- stable decision policy\n- workflow order or gates\n- recurring preference\n- deterministic mechanic\n- tool-selection rule\n- cross-tool coordination pattern\n\nIf the base agent already does the job reliably and no durable behavior is added, recommend not creating a Skill\n\n## Step 2: Create the Universal Skill Contract\n\nUse `../omni-skill/references/skill-contract.md`\n\nFreeze:\n\n- one job\n- positive triggers\n- implicit triggers\n- negative triggers\n- collision set\n- behavior preconditions\n- decision points\n- evidence requirements\n- completion and stop conditions\n- mutation boundary\n- capability requirements\n- evaluation coverage\n\n## Step 3: Choose architecture\n\nUse `../skill-conductor/references/patterns.md`\n\nPick the main control pattern before drafting prose\n\nIf the Skill has several independent jobs, split it into multiple Skills and define routing rather than building a monolith\n\n## Step 4: Set freedom per behavior\n\nFor each important behavior record:\n\n`behavior | consequence | reversibility | verifiability | freedom | implementation form`\n\nUse scripts or schemas for low-freedom mechanics\nUse decision tables or constrained pseudocode for medium freedom\nUse prose guidance where judgment is the value\n\n## Step 5: Design activation\n\nBuild an activation bank before finalizing the description\n\nInclude:\n\n- 4 to 8 positive prompts\n- 2 to 4 implicit prompts\n- 4 to 8 close negative prompts\n- neighboring Skill collisions\n\nThe description should expose the job and routing boundary, not the workflow sequence\n\n## Step 6: Design the information shape\n\nKeep frequently needed operating instructions in `SKILL.md`\nMove deep domain material into `references/`\nMove fragile repeated mechanics into `scripts/`\nKeep generated-output assets in `assets/`\n\nA reader should be able to understand the Skill's control flow without loading every reference\n\n## Step 7: Author the first candidate\n\nUse imperative instructions\nExplain why a non-obvious gate exists\nPlace checks at the point of risk\nUse one term per concept\nState evidence requirements before consequential claims or mutations\nState completion conditions explicitly\n\nDo not include credentials, private absolute paths, or assumed host tool names in the portable core\n\n## Step 8: Produce the evaluation blueprint\n\nBefore calling the Skill complete, hand off:\n\n- no-Skill baseline cases\n- activation positives\n- activation negatives\n- core behavior cases\n- edge cases\n- pressure cases where relevant\n- host-portability cases where relevant\n- critical binary questions\n\nRoute these to `skill-evaluator`\n\n## Output contract\n\nReturn:\n\n1. Skill rationale\n2. Universal Skill Contract\n3. architecture decision\n4. freedom map\n5. proposed package tree\n6. first candidate Skill content or patch\n7. evaluation blueprint\n8. unresolved assumptions\n\nDo not report behavioral validity until tests actually run\n"
}