wip help

wip help

Prints the same text as --help, or asks a local AI server how to do something in plain language.

wip help
wip help --ai [--url URL] [--no-cache] [QUESTION...]

Plain usage

wip help alone prints exactly what wip --help prints. It's generated from the same command tree at run time rather than a copy kept in sync by hand, so the two can never drift apart:

$ wip help
Description:
  A developer-friendly CLI wrapper for Microsoft WSLC.

Usage:
  wip [command] [options]

Options:
  --config <config>        Path to wip.yml
  --env-file <env-file>    Path to a dotenv file (default: .env next to wip.yml)
  --debug                  Print progress and timing for each step
  --debug-log <debug-log>  Where --debug snapshots go: a file path, or "-" for inline
  -q, --quiet              Hold back a shelled-out command's own output and print it only if that command fails (--debug's own lines are unaffected)
  -?, -h, --help           Show help and usage information
  --version                Show version information

Commands:
  version                 Show wip and WSLC versions
  init                    Create a starter wip.yml (detects an existing compose file)
  doctor                  Diagnose the development environment
  help <question>         Show usage help (add --ai to ask a local AI server instead)
  manual                  Download the wip wiki so `wip help --ai` can answer offline
  config                  Print the effective configuration
  build <extra>           Build the configured image
  up                      Start the configured container and its dependencies, creating them if necessary
  sync                    Mirror the source tree into the sync volume
  ps                      Show the current state of the configured container or stack
  status                  Alias for `wip ps`
  stop                    Stop the configured container and its dependencies without removing them
  down                    Stop and remove the configured container and its dependencies
  restart                 Restart the configured container or stack (stop, then start — no rebuild)
  exec <command>          Execute a command in the running container
  run <command>           Run a command in a new container
  shell                   Open a shell in the configured container
  logs <services>         Follow logs from the configured container or compose services
  dispatch <name> <args>  Run a command defined in wip.yml

wip help takes no command name of its own — unlike git help <command>, it only ever shows the top-level listing above. A single subcommand's own flags still come from that subcommand directly:

wip up --help
wip sync --help

Flags

--ai [--url URL] [--no-cache] [QUESTION...]

Skips printing --help and instead sends your question, together with the wip help text above as grounding context, to a local AI server — the same Ollama / LM Studio / any-OpenAI-compatible-server setup that wip init --ai uses, through the same LocalAiProvider. Everything on AI-Assisted Initialization about configuring WIP_AI_BASE_URL / WIP_AI_MODEL, model auto-discovery, and troubleshooting applies here unchanged — this page only covers what's specific to help.

--url URL overrides WIP_AI_BASE_URL for that one run, exactly like wip doctor --url and wip init --ai --url:

wip help --ai --url http://localhost:1234/v1 how do I keep syncing files while I work

The question can be given inline as trailing words — no quoting needed:

$ wip help --ai how do I restart a dependency automatically when it crashes
wip: asking llama3.1 at http://localhost:11434/v1
Set `restart: unless-stopped` (or `always`) on that dependency in wip.yml, then run
`wip up --watch`. wip polls every --interval seconds (default 5) and restarts any
dependency that has exited and whose restart: policy allows it. See "Auto Restarting
Containers" and "Restart Policies" on the wiki for the full behavior.

Omit the question and wip prompts for one interactively instead — the same blank-line-terminated convention as wip init --ai, since a question can span more than one line too:

$ wip help --ai
Ask wip how to do something, then press Enter twice (once after your question,
once more on a blank line) to finish:
What's the difference between wip stop and wip down?

wip: asking llama3.1 at http://localhost:11434/v1
`wip stop` stops the configured container and its dependencies but leaves them in place, so
`wip up` afterward just starts them again. `wip down` stops them and removes them, so the next
`wip up` recreates them from scratch. Prefer `stop` when you just want to pause; `down` when you
want a clean slate or are done with the project for now.

The answer is generated text, not a lookup. It's grounded in the reference above and instructed to say so rather than guess when something isn't covered, but a small local model can still misread its own reference material — verify anything it tells you to run, the same caution AI-Assisted Initialization gives for a generated wip.yml.

--no-cache

Skips the downloaded manual cache (see wip manual) and fetches the wiki page(s) relevant to this one question live instead, even if wip manual has already been run:

wip help --ai --no-cache how do I disable the build cache

Use it when the wiki has changed since your last wip manual run and you want this answer grounded in the current pages rather than a possibly-stale local copy. Without a downloaded cache at all, --no-cache makes no difference — wip help --ai already fetches live in that case.

--url without --ai

$ wip help --url http://localhost:1234/v1
wip: --url requires --ai

--no-cache without --ai

$ wip help --no-cache
wip: --no-cache requires --ai

A question without --ai

$ wip help how do I sync files
wip: a question requires --ai

All three fail before touching the network or reading wip.yml — same as wip init --template x --ai rejecting the combination up front.

What gets sent

Every prompt includes the wip --help text (command names, one-line descriptions, global options) as before, plus — when available — an excerpt of the wiki manual relevant to your question:

• A downloaded cache (wip manual was run) is searched first: the question's keywords are matched against every cached page, and the top few pages are included, trimmed to a size budget so a small local model's context window isn't overrun. wip: manual: cached is logged.
• No cache, but the network is reachable: the same keyword matching runs against the wiki's page index first, and only the page(s) that look relevant are fetched live — not the whole wiki. wip: manual: live is logged.
• Neither (offline, and nothing downloaded): the question is answered from the --help text alone, same as before wip manual existed. wip: manual: unavailable is logged.

No project files, no wip.yml, no environment variables are ever sent — a smaller, static payload compared to what wip init --ai sends. There's also nothing to confirm or save afterward; wip help --ai only ever prints an answer.

Related

• wip manual — downloads the wiki so this command's answers can be grounded in it
• wip doctor — --url, and the local AI availability check both commands share
• wip init — --ai, the other command that talks to a local AI server
• AI-Assisted Initialization — server setup, model auto-discovery, troubleshooting (/v1, ambiguous models, timeouts) — all of it applies to wip help --ai too
• CLI Command Reference