Add optional CTO workflows in SkipHow 4.5.0

AGENTS.md

@@ -4,15 +4,15 @@ These are contributor rules for developing SkipHow. They do not describe how Ski
 
 ## Product direction
 
-Treat [the owner-outcome contract](docs/outcome-contract.md) as the canonical product objective. The README explains that contract to users. The current implementation is one plain-language owner skill backed by a governing kernel and optional modules. Preserve autonomous technical judgment, effort proportional to the request, and the least total cost that reliably delivers the required outcomes. Native host bindings or a thin adapter may change this implementation where evidence justifies them.
+Treat [the owner-outcome contract](docs/outcome-contract.md) as the canonical product objective. The README explains that contract to users. The current implementation has one accountable CTO kernel, optional workflow skills, and shared internal references. Workflows define the owner's chosen work pattern without transferring technical supervision to the owner. Preserve autonomous technical judgment, effort proportional to the request, and the least total cost that reliably delivers the required outcomes. Native host bindings or a thin adapter may change this implementation where evidence justifies them.
 
 Keep universal runtime policy in the kernel as outcomes, authority boundaries, and non-negotiable invariants. Everything else is optional guidance, consulted when the work makes it worth its cost. A module exists only where it covers one distinct failure domain, gives a reason to consult it recognizable without opening it, holds no critical invariant absent from the kernel, duplicates no rule another module owns, and repays the permanent discovery and maintenance cost of a separate file. Those criteria are drawn from the 1.8.0 field audit, which measured references loading three times against roughly twelve applicable triggers while the rules in the unopened files governed nothing. Modules are not routes, commands, roles, stages, or an owner-operated chain. Leave sequencing, tools, decomposition, and implementation to the agent unless evidence shows that judgment is unreliable. Audit briefs, checklists, past transcripts, and one-off preferences are evidence for the question they examine; they are not standing product requirements.
 
 ## Changing the runtime contract
 
-Change the shipped instructions to fix an observed defect or protect a high-risk boundary, not to describe an ideal execution in full. One run can prove that wording is missing, ambiguous, or contradictory. It cannot prove that agents generally need a new procedure.
+Change the shipped instructions to fix an observed defect, protect a high-risk boundary, or implement an explicitly requested product capability. An owner-selected workflow may prescribe its defining behavior without making that process universal. One run can prove that wording is missing, ambiguous, or contradictory. It cannot prove that agents generally need a new procedure.
 
-Evaluate additions, removals, and retained complexity against the same outcome contract and total cost. For a material removal, identify the useful behavior, its surviving execution path, and the acceptance check. Missing behavioral evidence is uncertainty, not evidence that a required responsibility is unnecessary. Remove duplicates and contradictions without a paid experiment when inspection settles the result. Add a mandatory step, role, gate, dependency, or persistent state only when evidence shows that capable agents cannot reliably infer the needed behavior and the benefit justifies its ongoing cost. Review each change for lost responsibility, autonomy, extra turns, maintenance cost, and provider assumptions.
+Evaluate additions, removals, and retained complexity against the same outcome contract and total cost. For a material removal, identify the useful behavior, its surviving execution path, and the acceptance check. Missing behavioral evidence is uncertainty, not evidence that a required responsibility is unnecessary. Remove duplicates and contradictions without a paid experiment when inspection settles the result. Outside an explicitly requested optional workflow contract, add a mandatory step, role, gate, dependency, or persistent state only when evidence shows that capable agents cannot reliably infer the needed behavior and the benefit justifies its ongoing cost. Review each change for lost responsibility, autonomy, extra turns, maintenance cost, and provider assumptions.
 
 ## Reviewing a change to the instructions
 
@@ -42,7 +42,7 @@ The shipped text and every delegate brief follow one prompt standard. State the
 
 ## Checks
 
-Install the pinned dependencies with `python -m pip install -r requirements-dev.txt`; the checks install nothing and stop on an interpreter that misses a pin. Run focused tests through `python scripts/check.py --pytest <pytest-arguments>`. Before completion, run `python scripts/check.py` and `git diff --check`. `tests/conftest.py` keeps a direct `pytest tests` run from writing bytecode into `plugins/skiphow/`, whose every file the package identity hashes. For packaging changes, also run `python scripts/check_hosts.py`, which reports each host capability on its own row, and report an unavailable host as `UNVERIFIED`. `scripts/check.py` validates the single owner skill, its reachable modules and resources, the safety shape of any shipped hook, aligned versions, and portability boundaries such as personal paths and versioned model IDs. Change the check and `docs/decisions.md` together when those invariants change.
+Install the pinned dependencies with `python -m pip install -r requirements-dev.txt`; the checks install nothing and stop on an interpreter that misses a pin. Run focused tests through `python scripts/check.py --pytest <pytest-arguments>`. Before completion, run `python scripts/check.py` and `git diff --check`. `tests/conftest.py` keeps a direct `pytest tests` run from writing bytecode into `plugins/skiphow/`, whose every file the package identity hashes. For packaging changes, also run `python scripts/check_hosts.py`, which reports each host capability on its own row, and report an unavailable host as `UNVERIFIED`. `scripts/check.py` validates the required CTO skill, sibling workflow links to it, reachable modules and resources, the safety shape of any shipped hook, aligned versions, and portability boundaries such as personal paths and versioned model IDs. Change the check and `docs/decisions.md` together when those invariants change.
 
 Every deterministic assertion belongs to one class: a package or host contract, a security or release invariant, or the semantic validity of the behavioral corpus, all of which fail the run; or an editorial or layout preference, which is at most a non-blocking lint; or an assumption about the current shape, which is deleted unless it is promoted into a stated contract with a reason. Do not pin a marketing sentence, a method roster or count, a role set, a hook matcher topology, a site presentation detail, or a prose budget with no measured limit behind it.
 

CHANGELOG.md

@@ -2,6 +2,28 @@
 
 All notable changes to SkipHow 2.x and later appear in this file. Earlier release notes remain available on [GitHub Releases](https://github.com/mzored/SkipHow/releases).
 
+## 4.5.0 (2026-09-08)
+
+Five optional workflows now share the existing SkipHow CTO kernel. Ordinary project requests still work without a workflow name.
+
+### Added
+
+- `skiphow-bug` repairs the cause of a defect and verifies the original failure and affected general cases.
+- `skiphow-plan` prepares a researched specification, independently reviewed slices, authorized planning records, and an execution prompt, then stops before implementation. Explicit invocation requests durable planning; automatic selection for a read-only question grants no writes.
+- `skiphow-longrun` delivers accepted tracked work through bounded implementation and independent review loops. Without verified writer isolation, the CTO writes and delegates investigate and review.
+- `skiphow-deploy-ready` completes deferred checks, review, commits, and authorized integration. Production still requires an applicable explicit grant, including effects triggered by CI.
+- `skiphow-fast-fixes` shows a reviewed local preview and stops for feedback. The next turn checkpoints the previous shown iteration before further edits. Acceptance stays inside the iteration session; delivery starts on request. Deferred suites cannot run indirectly through commit hooks or be bypassed to commit.
+
+### Compatibility and verification
+
+This is a minor release of optional capabilities. The public CTO name, existing activation mechanism, authority boundaries, and shared references remain available. Each workflow requires the kernel in context through a relative link; package checks verify that declaration, not model compliance.
+
+The validator accepts sibling workflows while requiring the CTO entry and valid relative kernel links. The behavioral corpus covers invocation, planning authority, repair scope, longrun review and recovery, preview checkpoints, production boundaries, and resume preservation. Workflow selection, kernel loading, and behavior remain `UNVERIFIED`; no paid behavioral runs were made for this release. See [the evidence ledger](docs/evidence.md#optional-workflow-contract) and the per-capability release validation matrix.
+
+Independent review found no qualifying contract defects. The full gate caught two remaining tests that still required exactly one skill; those now require the CTO and validate sibling kernel links. Targeted independent review confirmed that the correction preserves package boundaries.
+
+Local validation passed all 381 tests and both host schema validators. Claude Code 2.1.263 installed the exact 22-file candidate and uninstalled it from an isolated configuration directory. Codex clean installation remains `UNVERIFIED` because managed source policy refused the local marketplace. The [host ledger](evals/host-smoke.json) retains the Claude receipts; activation, continuity, and model behavior remain `UNVERIFIED` on 4.5.0.
+
 ## 4.4.0 (2026-09-06)
 
 The kernel gains one request shape it had no name for: an iteration, a change to something the owner will look at before deciding what comes next. Its completion is the shown result, not the integrated one. Installing or upgrading SkipHow still grants no authority.

CONTRIBUTING.md

@@ -1,6 +1,6 @@
 # Contributing
 
-SkipHow ships one canonical plugin for Codex and Claude Code: one autonomous owner skill with a dynamic library of focused Markdown methods. Keep changes small enough to review and large enough to solve one complete problem.
+SkipHow ships one canonical plugin for Codex and Claude Code: one accountable CTO kernel, optional workflow skills, and shared Markdown references. Keep changes small enough to review and large enough to solve one complete problem.
 
 Read the [Code of Conduct](CODE_OF_CONDUCT.md) and use the [private security process](SECURITY.md) for vulnerabilities.
 
@@ -27,12 +27,13 @@ The behavioral eval corpus in [`evals/`](evals/README.md) holds the cases for th
 ## Change the canonical package
 
 - Keep universal authority, autonomy, preservation, and completion invariants in the owner kernel at `plugins/skiphow/skills/skiphow/SKILL.md`.
+- Put an optional workflow in a sibling skill only when it defines a distinct requested work pattern and stopping condition. Require the CTO kernel in context through a relative link before consequential work. Reuse its references rather than duplicating policy. A declared dependency proves no model loading.
 - Put reusable task discipline in a focused Markdown reference under the owner skill. Keep authority, autonomy, preservation, and completion in the root; a method can help with technique, but a missed method must not change the grant or definition of done.
 - Use linked resources for detail that can materially help only some tasks. Keep every Markdown file under the owner skill's `references/` library recursively reachable from `SKILL.md`.
 - Keep Codex and Claude manifests pointed at the same `skills/` directory.
 - Bump `VERSION` whenever `plugins/skiphow/` changes. Claude Code uses the manifest version as its update key.
 - Update `docs/decisions.md` when evidence changes architecture, the product contract, or security policy. Update `docs/evidence.md` when supported claims or known limits change. Link to durable source material instead of adding one file per run or release.
-- `scripts/check.py` validates one top-level owner skill, recursive reachability of every Markdown file under its `references/` library, the safety shape of the session hook where one ships (echo-only command, bounded timeout, no continuation store selected on resume), aligned versions, and the personal-path and provider-model-ID boundaries it scans. Do not reintroduce fixed method counts, role sets, model tiers, prose spellings, marketing sentences, matcher topology, site presentation details, or word budgets; those are class 4 under the validation policy in `AGENTS.md` and are at most a non-blocking lint. Record package-invariant changes and their evidence in `docs/decisions.md`, then update the check in the same change.
+- `scripts/check.py` validates the required CTO entry, sibling workflow links to it, recursive reachability of Markdown references, the safety shape of any shipped hook, aligned versions, and the personal-path and provider-model-ID boundaries it scans. Do not reintroduce fixed method counts, role sets, model tiers, prose spellings, marketing sentences, matcher topology, site presentation details, or word budgets; those are class 4 under the validation policy in `AGENTS.md` and are at most a non-blocking lint. Record package-invariant changes and their evidence in `docs/decisions.md`, then update the check in the same change.
 - Preserve upstream license, copyright, path, and inspected revision whenever a method copies or adapts source text. Record borrowed ideas and rejected alternatives in [the design](docs/design.md) and [decision history](docs/decisions.md).
 - Write direct English prose. Use active voice, sentence-case headings, straight quotes, and concrete claims. Open each method with a scope line repeating the trigger `SKILL.md` carries for it, give any file over roughly four hundred words subheadings, keep one idea to a sentence, and use a list only where the content is already a set. No em dashes; prefer two sentences to a semicolon.