Update to Skillquiver

{
  "description": "Creates implementation plans with interfaces, tests, and open decisions. Use when a multi-step change needs planning.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 221
    },
    {
      "relative_path": "references/full-plan.md",
      "size_in_bytes": 4571
    }
  ],
  "name": "writing-plans",
  "skill_md_contents": "---\nname: writing-plans\ndescription: Creates implementation plans with interfaces, tests, and open decisions. Use when a multi-step change needs planning.\n---\n\n# Writing Plans\n\nCreate a plan that another engineer can implement without inventing product\ndecisions. Announce: \"I'm using the writing-plans skill to create the\nimplementation plan.\"\n\n## Choose one route\n\nUse **Bounded inline planning** when the user explicitly requests planning\nonly, requests read-only work, or says not to write code, and the prompt already\nsupplies the behavior, constraints, and required interfaces.\n\nUse **Full repository planning** when the user requests a saved plan artifact,\nasks for alignment with an existing codebase, names existing paths that affect\nthe design, or leaves architecture dependent on repository evidence.\n\nBounded inline planning takes precedence whenever its conditions match. A\nnamed interface without a repository path is part of the supplied contract,\nnot a request for repository alignment. Do not switch routes merely because\nthe future implementation will integrate with existing code.\n\nCreating a plan file is a workspace change. Return the plan inline unless the\nuser requests an artifact or the active workflow already authorizes one.\n\n## Rules for every plan\n\n- List externally observable decisions the requirements do not settle, such as\n  exit status, output channel, overwrite policy, and partial-success semantics.\n  Never silently choose them. Ask only when an answer changes plan structure.\n- Do not add validation, normalization, or required-field rules for data the\n  prompt only names. Preserve it as supplied and list any policy as unresolved.\n- Never specify a behavior as required and then list that same behavior as\n  unresolved. Describe the decision seam instead until the product choice exists.\n- Label engineering recommendations as recommendations, not requirements.\n- Define file responsibilities and interfaces. Mark unverified paths as\n  proposed.\n- Make each task an independently testable deliverable with focused tests.\n- Include concrete behavior, edge cases, commands, and expected outcomes. Do\n  not use `TBD`, `TODO`, \"handle errors\", or other placeholders.\n- Split independent subsystems into separate plans when each can deliver useful\n  software alone.\n\n## Bounded inline planning\n\n1. Treat facts supplied in the prompt as the planning contract. Do not inspect the\n   workspace unless the user requests repository alignment.\n2. Return at most four implementation tasks. Each task names proposed files,\n   consumed and produced interfaces, behavior, edge cases, and focused tests.\n3. Omit code samples, commit steps, plan files, todo tools, and execution-choice\n   menus unless the user asks for them.\n4. Cover parsing, validation, success and failure flow, integration boundaries,\n   and tests where applicable.\n5. End with unresolved externally observable decisions only, then deliver the\n   plan immediately.\n\n## Full repository planning\n\nRead [references/full-plan.md](references/full-plan.md) completely before\ninspecting the repository or drafting the plan. Follow that reference in\naddition to the rules above. An explicit user output path overrides its default\nartifact location.\n\n## Self-review\n\nBefore responding, check specification coverage, placeholder absence, and\ninterface-name consistency. Fix gaps inline once; do not start a separate todo\nor review workflow.\n\nCompletion requires a plan with complete behavior, interfaces, boundaries,\nedge cases, and tests, plus an explicit list of unresolved product decisions.\n"
}