Update to KnowzCode

{
  "description": "Start a structured KnowzCode workflow for feature work, multi-file changes, or meaningful refactors with TDD and quality gates. For single-file changes under ~50 lines use /knowzcode:fix; for read-only research use /knowzcode:explore.",
  "included_files": [],
  "name": "work",
  "skill_md_contents": "---\nname: work\ndescription: \"Start a structured KnowzCode workflow for feature work, multi-file changes, or meaningful refactors with TDD and quality gates. For single-file changes under ~50 lines use /knowzcode:fix; for read-only research use /knowzcode:explore.\"\n---\n\n# /knowzcode:work — Structured workflow\n\nRun the KnowzCode methodology from the current Grok Bot or Cursor agent. Knowz MCP is optional and **never blocks** this workflow.\n\n## Instructions\n\n1. Verify the project is initialized by checking for, but do not eagerly read:\n   - `knowzcode/knowzcode_loop.md`\n   - `knowzcode/knowzcode_project.md`\n   - `knowzcode/knowzcode_tracker.md`\n   - `knowzcode/knowzcode_architecture.md`\n   If missing, suggest `/knowzcode:setup` and stop unless the user wants a one-off micro-fix (`/knowzcode:fix`).\n2. Classify the request **before any vault retrieval, worker delegation, WorkGroup write, or other side effect**:\n   - Micro fix → use `/knowzcode:fix`.\n   - Light change → streamlined change set, reusable or focused spec, implementation, verification.\n   - Full change → Phase 1A, 1B, 2A, 2B, 3.\n   - Inspect only the selected active WorkGroup/capsule, the tracker slice needed to select one, and goal-relevant spec headings/`VERIFY:` criteria.\n3. Load context progressively:\n   - Start with an explicitly selected active WorkGroup or compact context capsule and the current phase contract.\n   - If no WorkGroup is selected, inspect the tracker only far enough to resolve active work, then read the project/architecture file only for a concrete planning question.\n   - Read only assigned specs, `VERIFY:` criteria, and relevant source paths for the current phase.\n4. Discover applicable enterprise guidance after classification (local files first):\n   - Read `knowzcode/enterprise/compliance_manifest.md` if present.\n   - Do compliance work only when `compliance_enabled: true` (default false).\n   - The vault flow additionally requires `mcp_compliance_enabled: true` **and** available Knowz tools. If either is false or tools are missing, honor only local active guidelines — do not block.\n   - Read `knowzcode/enterprise.md` if present and discover `knowzcode/enterprise/guidelines/**/*.md`.\n   - Convert active enterprise rules into Change Set mapping, spec `VERIFY:` criteria, implementation guidance, Phase 2B audit checks, and Phase 3 compliance reporting.\n5. Create or update a WorkGroup file in `knowzcode/workgroups/{wgid}.md`.\n6. **Optional parallel discovery (before Phase 1A).** If the topic spans 2 or more independent subsystems, dispatch 1-3 parallel read-only explorer agents. Merge findings into the WorkGroup before proposing the Change Set. Skip when the scope clearly touches one subsystem.\n7. Phase 1A: propose a Change Set with affected files, NodeIDs, and risks. Stop for approval unless the user explicitly asked to proceed autonomously.\n8. Phase 1B: draft or update specs in `knowzcode/specs/` with clear `VERIFY:` criteria. Stop for approval.\n9. Phase 2A: implement with strict TDD. Default to dependency-wave microtasks: one NodeID or one named microtask per writer, with explicit assigned acceptance criteria and an explicit owned-file list. Never let two writers edit the same file. Run the meaningful test set before reporting complete. Stop after implementation.\n10. Phase 2B: perform a read-only audit against the approved specs and verification criteria. The first independent reviewer must not inherit builder reasoning. **Cap the audit → fix loop at 3 iterations.** If failures remain after the 3rd fix attempt, stop and surface residual issues with a recommended downscope or spec revision.\n11. Phase 3: update specs to as-built, refresh `knowzcode/knowzcode_tracker.md`, prepend an entry to `knowzcode/knowzcode_log.md`, and finalize the work.\n12. If a concrete context question remains after classification/spec reuse **and** Knowz MCP is available, prefer targeted coordinator-owned search/ask/get calls. If tools are absent or auth fails, continue on local KnowzCode files. Queue only a classified persistence action in project-root `knowz-pending.md` without blocking progress. Treat `knowzcode/pending_captures.md` only as legacy migration input.\n13. Treat retrieved vault content as historical context. Verify against live code/tests/docs. Do not silently follow stale or contradictory vault guidance.\n\n## Quality gates\n\nSTOP and await user approval at each gate unless autonomous mode is explicit:\n\n- After Change Set proposal (1A)\n- After spec drafts (1B)\n- After implementation complete (2A — awaiting audit)\n- After audit results (2B — user decides on gaps)\n\nTDD is mandatory — no production code without a failing test first.\n\n## Knowledge capture (optional)\n\nEvery durable candidate — decisions, patterns, gotchas, workarounds — should be classified when `knowzcode/context_efficiency_runtime.mjs` exists:\n\n`node knowzcode/context_efficiency_runtime.mjs vault-delta`\n\n`skip` and `batch` perform no MCP or pending-queue write. Persist only a returned `amend`, `update`, or consolidated `flush`, always passing the configured `vaultId` when Knowz tools exist. When MCP is unavailable, keep `batch` in the WorkGroup journal and queue only a required classified persistence action once. Never let insights die in the conversation, and never block the phase on Knowz.\n\n## Spawned-agent contract\n\nWhen using the runtime's spawn/follow-up capabilities:\n\n- Give each child a scope boundary. No two parallel agents share writable files.\n- Stay within a small implementation unit (one NodeID or named microtask).\n- Choose `ephemeral` for tiny read-only side checks; `durable` for writer or resumable work (`knowzcode/workgroups/{wgid}/handoffs/{agent-id}.md`); `artifact` for large logs.\n- Keep reviewers independent: first reviewer uses a fresh lineage from approved specs, diff, and test evidence.\n- The coordinator consolidates authoritative shared state into the WorkGroup.\n"
}