SkipHow

An adaptive virtual CTO for founders and product owners using Claude Code or Codex.

Describe the product outcome in ordinary language. You keep product decisions; SkipHow owns research, architecture, planning, implementation, review, integration, and verification. Work stays proportional to the request. The host supplies the model, tools, permissions, sessions, and subagents.

SkipHow also keeps the system you own small. Everything the agent adds stays, and you pay for it in every later change. So it builds the least that delivers the result, writes a test only for a break a user or caller would notice, moves every caller in the repository instead of leaving a compatibility shim, and asks for independent review only where a mistake is expensive. It removes what no longer pays for itself. Guards for money, security, customer data, and the release path stay.

Is it for you?

Use SkipHow when you want the agent to own engineering through a verified result while you decide product behavior, scope, cost, risk, privacy, and rollout. You do not need to read code. You need to own the outcome.

If your base agent already does this reliably, another instruction layer adds little. A specification framework fits an owner who wants to approve the development method. A runtime orchestrator fits persistent teams, queues, scheduling, and budget enforcement. SkipHow is an instruction layer and provides none of those runtime services.

Install

Codex:

codex plugin marketplace add mzored/SkipHow
codex plugin add skiphow@skiphow

Claude Code:

claude plugin marketplace add https://github.com/mzored/SkipHow.git
claude plugin install skiphow@skiphow

Start a new session after installation. The owner guide covers updates and uninstall.

Activate it for ordinary language

Ask the installed skill to enable itself once:

$skiphow Enable SkipHow as my default virtual CTO on this machine.

In Claude Code, use /skiphow:skiphow instead of $skiphow. The agent resolves the trusted instruction file your host reads, previews one reversible block, and writes it after confirmation. Configured, available, and loaded are separate facts; loading is only visible in a fresh session. Installation and activation grant no actions. The activation guide explains the lifecycle and manual fallback.

Explicit invocation remains available:

$skiphow The totals overlap on small screens. Find the cause and fix it.

Recurring workflows

Ordinary project requests need no mode. Optional workflows share the same CTO kernel, authority boundaries, and internal references.

Skill	Requested result
skiphow-bug	Find and repair the general cause, then verify at the authorized destination
skiphow-plan	Prepare the whole scope, resolve product questions, review executable tasks, and return a launch; no implementation
skiphow-longrun	Deliver agreed substantial work with coordinated implementation and review scaled to consequence
skiphow-deploy-ready	Complete deferred checks, review, commits, and authorized integration
skiphow-fast-fixes	Show checked local fixes while you send feedback; delivery starts when requested
skiphow-simplify	Measure the project, remove tests, tooling, shims, and rules that do not pay, and report what it saved; only when you ask

Use $skiphow-plan in Codex or /skiphow:skiphow-plan in Claude Code, with the same naming pattern for the other workflows. The workflow guide covers examples, planning readiness, feedback, and delivery boundaries.

Authority and evidence

Answering, research, diagnosis, review, and ordinary planning are read-only. A change request permits editing and verification within its scope. Applicable authorization can cover routine shared delivery; production, public releases, credentials, access, material deletion, and wider disclosure need explicit owner authorization. The owner guide explains the boundaries.

SkipHow adds no intelligence and enforces no security boundary. Package checks prove structure and declared invariants. Identified historical runs show bounded loading, task, and delivery observations; current-package CTO behavior, reliable multi-agent execution, general activation reliability, and comparative benefit remain UNVERIFIED. See the evidence ledger and the dated host-support matrix.

Documentation

For owners:

• Owner guide: install, activation, workflows, what a request allows, reports, and common questions.
• Evidence: which claims real runs have shown and which stay UNVERIFIED.
• Security and host support: private reporting and the host capability matrix.

For contributors:

• Owner-outcome contract: what every implementation must deliver.
• Decisions: live decisions, why they stand, and what would reopen them.
• Prior art: what SkipHow took from other projects and what it refused.
• Contributing and repository instructions.
• Evaluation corpus: cases, fixtures, and retained receipts.
• Changelog: what changed in each release and why.

Earlier release narratives and documentation live in git history. Commit 2f72c7f holds the documentation before it was cut to the current state, and commit 72aef45 holds the longer ledgers through 6.3.3.