Update to get-fable

{
  "description": "Configure and audit AI agent harness settings, permissions allowlists, environment variables, editor keybindings, and lifecycle hook integrations. Use when modifying settings.json, adjusting tool permissions, setting up environment variables, or configuring agent lifecycle hooks — even if the user does not explicitly say \"fable-config\" (e.g. \"update settings\", \"allow command permissions\", \"configure agent hooks\", \"setup environment variables\"). Do NOT use for application-level business configuration.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 367
    },
    {
      "relative_path": "evals/scenarios.json",
      "size_in_bytes": 3826
    },
    {
      "relative_path": "examples/configure-allowlist.md",
      "size_in_bytes": 266
    },
    {
      "relative_path": "references/config-precedence-permissions-and-hooks.md",
      "size_in_bytes": 2579
    },
    {
      "relative_path": "references/harness-configuration-rules.md",
      "size_in_bytes": 2308
    },
    {
      "relative_path": "skill.package.json",
      "size_in_bytes": 469
    },
    {
      "relative_path": "templates/harness-settings.template.json",
      "size_in_bytes": 460
    }
  ],
  "name": "fable-config",
  "skill_md_contents": "---\nname: fable-config\ndescription: \"Configure and audit AI agent harness settings, permissions allowlists, environment variables, editor keybindings, and lifecycle hook integrations. Use when modifying settings.json, adjusting tool permissions, setting up environment variables, or configuring agent lifecycle hooks — even if the user does not explicitly say \\\"fable-config\\\" (e.g. \\\"update settings\\\", \\\"allow command permissions\\\", \\\"configure agent hooks\\\", \\\"setup environment variables\\\"). Do NOT use for application-level business configuration.\"\nversion: 1.3.0\npack: system\ninputs:\n  - config_change\nrequires:\n  - target_harness\nproduces:\n  - settings_diff\ngates:\n  - valid_json\n  - safe_permissions\nfallback: fable-plan\nmutatesWorkspace: true\nparallelSafe: false\nneural_links:\n  precursors:\n    - fable-plan\n  continuations:\n    - fable-verify\n    - get-fable\n  lateral_peers:\n    - fable-plan\n  recovery: fable-recover\n---\n\n# Fable Config\n\nChange harness/configuration behavior with explicit precedence, least privilege, secret-safe handling, and a verified rollback path.\n\n## Mission\nConfiguration is executable behavior. A syntactically valid JSON/TOML/YAML file can still disable a guard, broaden permissions, write to the wrong scope, or be ignored because another source has higher precedence.\n\nThe Skill must prove both **configuration validity** and **effective behavior**.\n\n## Activate When\n- changing host/harness settings, permissions, hooks, keybindings, model/tool config, or environment references;\n- adding/removing lifecycle enforcement;\n- troubleshooting why a setting is not taking effect;\n- configuring safe command/tool allowlists;\n- migrating configuration formats/scopes.\n\n## Do Not Activate When\n- storing raw credentials/secrets;\n- application business logic is the real change;\n- a host capability is unknown and needs research/discovery first;\n- the requested change is to weaken a safety boundary merely to bypass an error without understanding it.\n\n## Configuration Classification\n| Change | Main risk |\n| --- | --- |\n| Permission/allowlist | excessive privilege/wildcard scope |\n| Hook registration | hook exists but is never invoked / blocks wrong phase |\n| Environment config | precedence, secret leakage, type/format |\n| Host settings | wrong user/project scope, unsupported keys |\n| Model/tool config | changed behavior/cost/access unexpectedly |\n| Keybindings/UI | collision/override |\n| Generated config | manual edit overwritten by generator |\n\n## Protocol\n### Stage 1 — Locate source and effective scope\nIdentify:\n- target host/version;\n- project vs user/global scope;\n- all configuration sources and precedence;\n- generated vs hand-maintained files;\n- existing user customizations to preserve.\n\nDo not edit the first file with the right name until you know it is effective.\n\n### Stage 2 — Define desired behavior and least privilege\nState exactly what capability should become allowed/blocked/triggered and what must remain unchanged.\n\nFor permissions, prefer narrow command/tool/path patterns. Wildcards need explicit justification and threat consideration.\n\n### Stage 3 — Protect secrets\nConfiguration may reference environment variable names or secure stores, but should not embed raw tokens/passwords/private keys unless the target's secure format explicitly requires protected encrypted storage.\n\nIf an existing secret is found in plaintext, do not echo it; route exposure handling appropriately.\n\n### Stage 4 — Make a minimal merge\nPreserve unknown/user-defined settings. Avoid replacing an entire config object/file when one scoped key can be merged.\n\nFor generated config, modify source/generator then regenerate.\n\n### Stage 5 — Validate structure and semantics\nRun available parser/schema/host diagnostics. Check:\n- syntax;\n- key types/enums;\n- duplicate/conflicting entries;\n- unsupported/deprecated keys;\n- permission pattern scope;\n- hook command/path existence.\n\n### Stage 6 — Prove effective behavior\nA valid file is not enough. Test the configured behavior safely:\n- target command is allowed while broader command remains denied;\n- hook fires at intended lifecycle point;\n- project override wins as expected;\n- setting is visible to the target host;\n- rollback restores previous behavior.\n\n### Stage 7 — Record rollback and handoff\nCapture changed source, effective scope, validation, behavioral proof, and how to revert if the host fails after restart/update.\n\n## Decision Rules\n- Preserve existing user settings not owned by the task.\n- Prefer exact allowlists over `*`, shell wildcards, root/global permissions.\n- A config key accepted by parser but ignored by host is not a successful change; verify effect.\n- Host integration levels differ; do not claim hooks/enforcement where the host only supports advisory rules.\n- Environment variable name may be stored; secret value should remain in secure environment/credential store.\n- If config precedence is uncertain, investigate before editing more files.\n- Do not disable security/approval checks simply because they are blocking an unsafe action.\n- If a malformed edit can lock out the host, keep a reversible backup/atomic write strategy.\n\n## Invariants\n- Least privilege is preserved or any broadening is explicit and justified.\n- Raw secrets are not introduced into repository/config logs.\n- Existing unrelated user configuration is preserved.\n- Edited source is the effective source-of-truth.\n- Syntax/schema and actual host behavior both verify.\n- Rollback is possible for material changes.\n\n## Failure Taxonomy\n### Precedence mismatch\nEdited file is shadowed by another scope/source. Trace effective configuration.\n\n### Schema-valid but ignored\nHost accepts file but does not support/use key. Verify host version/capability.\n\n### Permission overreach\nPattern allows more than requested. Narrow and test negative case.\n\n### Hook misregistration\nScript exists but lifecycle never invokes it. Validate registration path/event and permissions.\n\n### Secret leakage\nCredential embedded/logged. Remove safely and rotate if exposure occurred.\n\n### User-config clobber\nWhole-file rewrite loses existing settings. Restore/merge surgically.\n\n### Generated drift\nManual edit is overwritten. Change generator/source instead.\n\n## Anti-Patterns\n- `\"allow\": [\"*\"]` to stop approval prompts;\n- editing global config when project scope suffices;\n- copying API tokens into settings examples;\n- validating JSON syntax and calling the hook configured;\n- claiming full lifecycle enforcement on a host with advisory-only integration;\n- resetting the whole config file for one key;\n- disabling security controls to make a command pass;\n- manually patching generated config.\n\n## Configuration Packet\n```text\nTarget host/version/scope:\nEffective config sources + precedence:\nDesired behavior:\nSettings changed:\nPermissions before/after:\nSecret handling:\nSyntax/schema validation:\nBehavioral proof + negative case:\nPreserved user settings:\nRollback:\n```\n\n## Completion Criteria\nConfiguration completes when:\n- correct effective source/scope was changed minimally;\n- configuration parses and satisfies schema/capability constraints;\n- permissions remain least-privilege;\n- secrets/unrelated settings remain safe;\n- target behavior is empirically observed, including important negative case;\n- rollback and host limitations are explicit.\n\n## Progressive Resources\n- Deep guide: `references/config-precedence-permissions-and-hooks.md`\n- Existing rules: `references/harness-configuration-rules.md`\n- Example: `examples/configure-allowlist.md`\n"
}