install-statusline

Install Statusline for Claude Code

This generated file is the Claude Code-facing runtime skill document. Claude Code slash commands should read this file directly; maintainers edit the source documents listed below instead.

Generated Runtime Composition

Source order:

• ../../docs/skill-core/install-statusline.md
• ../../docs/platforms/claude-code-runtime.md
• ../../docs/platforms/claude-code-install-statusline.md

The sections below are already composed for this platform. Do not ask the runtime model to load another platform's runtime document or invocation syntax.

Source: docs/skill-core/install-statusline.md

Install Statusline

Install Statusline is a user-invoked setup action. It installs a developer-focused Claude Code statusline (working directory, git branch/status, model and reasoning effort, context-window gauge, and rate-limit gauges) into the user's ~/.claude configuration so a freshly set up Claude Code environment gets the same statusline.

This skill is human-invoke-only. It is never auto-invoked by the model: its frontmatter sets disable-model-invocation: true, and it is intentionally left out of the SessionStart routing map. Only an explicit /oh-no-harness:install-statusline from the user runs it.

It is Claude Code-only: it configures Claude Code's statusLine setting and ships no Codex variant.

Software Development Stage

Install Statusline is a one-time environment-setup action, not a software development stage. It should not gather requirements, plan, edit project code, debug failures, clean code, or verify completion. It does not invoke workflow skills.

When To Use

Use only when the user explicitly asks to install or set up the Oh No Harness developer statusline, typically on a new machine or a fresh ~/.claude.

Do not use it as part of any automated workflow. There is no model-driven trigger for this skill.

What Gets Installed

• The statusline script is copied to ~/.claude/statusline-command.sh.
• The user's ~/.claude/settings.json statusLine key is set to:

{
  "type": "command",
  "command": "bash ~/.claude/statusline-command.sh",
  "refreshInterval": 3
}

All other keys in settings.json are preserved. The change takes effect within a few seconds (the statusline refreshes on refreshInterval); a new session or /clear guarantees it.

Install Procedure

The bundled installer does the deterministic file work; this skill orchestrates the safe-by-default flow and owns the conflict decision.

1. Locate the bundled installer at <plugin-root>/scripts/install-statusline (the active platform runtime overlay names the concrete plugin-root path).
2. Run it in check mode first: "<plugin-root>/scripts/install-statusline" check. It prints a STATUS: line describing the current state without changing anything:
   • STATUS: not-installed — no statusLine configured yet.
   • STATUS: installed-outdated — our statusLine is configured but the script is missing or differs from the bundled payload.
   • STATUS: installed-matching — already installed and current.
   • STATUS: conflict — a different statusLine is already configured.
3. Act on the status:
   • installed-matching: report that nothing needs to change and stop.
   • not-installed or installed-outdated: run "<plugin-root>/scripts/install-statusline" apply (no prompt needed — this is the harness's own statusline).
   • conflict: show the user the existing statusLine.command, then ASK whether to back up and replace it. Only on an explicit yes, run "<plugin-root>/scripts/install-statusline" apply --replace, which timestamp-backs-up the existing script and settings.json before replacing. On no, make no change and report that the existing statusline was kept.
4. Report exactly what changed (files written, backups created, the settings.json keys that were preserved) and that the statusline refreshes within a few seconds.

Safety Rules

• The installer requires jq. If jq is absent it refuses with a clear error, exits non-zero, and leaves settings.json byte-unchanged. Relay that to the user; do not hand-edit the JSON as a workaround.
• If settings.json is present but not valid JSON, the installer refuses and leaves the file unchanged. Relay that; do not overwrite it.
• Never replace an existing different statusLine without the user's explicit approval and a backup.
• Do not invoke workflow skills from this setup skill.

Source: docs/platforms/claude-code-runtime.md

Claude Code Runtime Rules

This compact platform section is embedded in generated Claude Code-facing skill documents.

Skill Loading

Claude Code-facing public skills live under skills-claude/. Generated skills-claude/<skill>/SKILL.md files compose the matching skill core, this compact runtime section, and any Claude Code skill-specific overlay such as docs/platforms/claude-code-<skill>.md. Slash commands must delegate to the matching generated skill document.

User Approval, Tasks, And Prompting

Use the host's structured question tool when available for approval, preference, scope, or next-step selection; otherwise ask one focused plain-text question and wait. Present options as actions the host agent will take.

When a core skill has a multi-phase approval handoff and the host exposes task tracking, create one task per phase and complete them sequentially.

Keep Claude prompts explicit and sectioned: state scope, non-goals, constraints, approval gates, expected evidence, and output format. Preserve long-running context in artifacts before compaction, task handoff, or subagent dispatch.

Role Dispatch

Dispatch only after the active skill's trigger fires, then read docs/platforms/claude-code.md ## Role Dispatch for the full host contract. Prefer oh-no-harness:<role>, request the whole independent batch before waiting, capture every final result, and clean up only after integration. An approved-plan handoff is dispatch authorization for eligible isolated roles; plugin-agent unavailability uses the documented embedded-role fallback.

Cross-Host Consult Channel

This channel is trigger-loaded, not embedded in every workflow decision. When a named THOROUGH paired-review or Fusion Rescue trigger fires, read and apply docs/platforms/claude-code.md ## Cross-Host Consult Channel before dispatch. Until then, do not preload opposite-host invocation details.

Source: docs/platforms/claude-code-install-statusline.md

Claude Code Install Statusline Rules

This platform overlay is source content for the generated Claude Code-facing install-statusline runtime document, after the shared core and docs/platforms/claude-code-runtime.md.

The statusline installs into Claude Code's user settings at ~/.claude.

When CLAUDE_PLUGIN_ROOT is set, run the bundled installer directly:

"${CLAUDE_PLUGIN_ROOT}/scripts/install-statusline" check
"${CLAUDE_PLUGIN_ROOT}/scripts/install-statusline" apply
"${CLAUDE_PLUGIN_ROOT}/scripts/install-statusline" apply --replace

If the plugin root is not exposed, locate the installed script first:

script="$(find ~/.claude/plugins -path '*/oh-no-harness/*/scripts/install-statusline' -print -quit)"
"$script" check

For the conflict case, ask the user with the host's structured question tool (AskUserQuestion) before replacing: show the existing statusLine.command, and offer "back up and replace" versus "keep existing". Only run apply --replace after an explicit choice to replace.

The statusline reads Claude Code's statusLine JSON input, including .effort.level for the model reasoning effort. The change takes effect on the next refreshInterval tick; /clear or a new session guarantees it.