cc-os/plugins/os-status/skills/fix/SKILL.md

description
Bring the current project up to the current cc-os approach by remediating whatever /os-status checks flag — idempotent, doubles as the update path. Invoked by /os-status:fix.

fix

Unified project setup/update. Runs the same check registry the SessionStart hook runs, then drives each failing check's remediation. Per ADR-026: fix orchestrates existing per-plugin skills — it never reimplements them. Idempotent by construction: re-running fix on an already-configured project is the update path, not a separate command.

Scope: fix never stages or commits. It edits files and reports what changed — staging and committing is always the user's call, even for mechanical remediations like a .gitignore addition or a config stamp.

Flow

1. Get machine-readable results. From the project root, run:

   python3 ${CLAUDE_PLUGIN_ROOT}/hooks/checks.py --json
   

   This prints a JSON array of {name, status, message, remediation} for every check applicable to the current project (project-scoped checks are skipped outside a git project, same rule the SessionStart hook uses).

2. All ok (and only note/ok)? Report "this project is up to date" and go straight to steps 3b–4 (gitignore + version stamp) — nothing else to remediate.

3a. Ensure .cc-os/ is gitignored. Check the project's .gitignore for a .cc-os/ entry; add one if missing. Per ADR-027, this single entry covers every cc-os plugin's per-project state (os-status's .cc-os/config + .cc-os/status/, os-backlog's tracker key, etc.) — there is no separate .os-adr/ entry to add anymore. This step runs every fix invocation, not just when a check flags it.

3b. Otherwise, walk the non-ok entries in this order (mechanical → decision- bearing, so autonomous fixes land before anything needing a human gate):

a. adr-system-present → invoke /os-adr:init (or /os-adr:migrate if the project already has decision-log-like content the message/context suggests — use judgment, this is mechanical either way).

b. vault-hub-note-present → either invoke /os-vault:write to create a hub note (tags type/hub + project/<name>), or if the user says a hub note already exists under a different name, set hub = <slug> in .cc-os/config via the config-write helper (see step 4).

c. project-graph-present → invoke /os-vault:onboard-project.

d. tracker-configured → invoke /os-backlog:route directly and let it run its own inspect → propose → confirm flow. Per ADR-0042, one tracker holds both task state and durable specs — there is no second surface to weigh, so don't pre-ask the user "forgejo or github or repo?" either; the route skill owns that decision conversation and its gates. A planka: value found in an existing .cc-os/config is rejected fail-soft (one line citing ADR-0042) by both config-write and this check — the fix is the same /os-backlog:route call. If /os-backlog:route is not installed, tell the user and skip — do not fabricate a .cc-os/config tracker value yourself.

e. subagent-model-env-override → human gate, and typically out of scope for a project-level fix. This is an environment/settings.json condition, not a per-project one. Report it and ask the user to remove the env var themselves; do not edit ~/.claude/settings.json from this skill.

f. config-version-current → resolved automatically by step 4 below; no separate action.

Re-run the JSON check after each remediation that plausibly changed check-registry state (creating a hub note, running /os-adr:init, setting a config key), so later steps see fresh results (e.g. don't act on a stale vault-hub-note-present warning after already creating the note). Remediations that don't affect check-registry state — step 3a's gitignore edit is the example — don't require a re-run.

Snoozed warns self-clear: whenever a check now evaluates to ok/note (whether because this skill just fixed it or it was already fine), the next SessionStart or fix run clears its stale snooze-<check> file automatically (state.py's clear_snooze) — nothing to do here beyond re-running the JSON check per the rule above.

4. Stamp the config version. Once the mechanical/human-gated fixes above are done (or were already ok), write the current version into .cc-os/config, preserving every other key. Use the helper:

   import sys
   sys.path.insert(0, "${CLAUDE_PLUGIN_ROOT}/hooks")
   from state import write_config_value, find_project_root
   from checks import CURRENT_CONFIG_VERSION
   from pathlib import Path
   
   root = find_project_root(Path.cwd())
   write_config_value(root, "version", str(CURRENT_CONFIG_VERSION))
   

   (Equivalently, run it as a one-off python3 -c "..." from the project root.) This is what makes config-version-current pass on the next run and what makes re-running fix on a fully-configured project a fast, silent no-op.

5. Report a short summary: which checks were already ok, which were fixed and how, which were skipped pending a human decision, and confirm the config version was stamped.

Notes

• Never edit .cc-os/config by hand-writing the whole file — always go through write_config_value (or the equivalent read-modify-write) so unrelated keys (hub, tracker, vault_path, ...) are preserved.
• Decision-bearing steps (tracker destination, anything destructive) keep their human gate even when this skill is otherwise running autonomously. Mechanical steps (running /os-adr:init, /os-vault:onboard-project, stamping the version) proceed without asking.
• This skill does not touch subagent-model-env-override state — that's a machine environment condition, not a per-project one, and editing global settings.json is out of scope.