Install skills into a consumer repo

skills/ — Claude Code skill wrappers

Skills that surface the PETROVA control loop and CLI to Claude Code sessions in any governed repo. Each is a directory: SKILL.md, plus a commands/<name>.md slash-command invoker where the skill is one of the eight golden prompts.

The eight golden prompts

Derived from docs/PETROVA-GOLDEN-PROMPTS.md (G-01..G-08), one skill per prompt, one prompt per session. Each opens by fetching https://petrova.blog/llms-preamble.txt rather than carrying a pasted copy of the law.

Skill	Prompt	Terminal state
petrova-phase-open	G-01	dry-run phase-open record
petrova-verify-round	G-02	classified friction list
petrova-phase-close	G-03	dry-run close + deferred ledger
petrova-decide	G-04	dry-run decision record
petrova-onboard	G-05	admission sequence + proposed contract
petrova-drift-check	G-06	three-class findings list, read-only
petrova-recover	G-07	diagnosis + one recovery path
petrova-plan	G-08	task sequence, no code

The phase trio is deliberately not one chain — see petrova-phase-cycle, which merged them and is deprecated as of 2026-08-13.

Verb surface

• petrova-act — write verbs (open_decision, start_phase, propose_fix, …). Composes typed JSON params, validates against spec/verbs/, invokes the CLI to emit a PR. Dry-run by default; --apply requires explicit human go-ahead.
• petrova-status — read-only verbs (status, diagnose, validate). Cross-repo dashboards, single-repo diagnostics, MR/convention checks.

Other

petrova-boundary-check, petrova-mr-audit, petrova-realign — narrow audits, outside the golden-prompt set.

Prerequisites

A consumer repo using these skills needs:

1. The CLI built and on PATH. Either:
   • Global install: cd petrova-codes/cli && npm install && npm run build && npm link, then petrova is available globally.
   • Path reference: every script falls back to ${PETROVA_HOME:-~/code/workspace/petrova-codes}/cli/dist/index.js.
2. registry.yaml listing the consumer repo. The skills refuse to act on repos absent from ${PETROVA_HOME}/registry.yaml. Add the repo via PR before invoking write verbs.
3. PETROVA_WORKSPACE env var (optional). Defaults to the parent directory of petrova-codes. Each governed repo lives at $PETROVA_WORKSPACE/<slug>.
4. Auth for --apply (optional). PETROVA_GITHUB_TOKEN (PAT) OR the GitHub App env triple (PETROVA_APP_ID, PETROVA_APP_PRIVATE_KEY_PATH, PETROVA_APP_INSTALLATION_ID). Dry-run requires no auth.

Install into a consumer repo

Either symlink:

ln -s ~/code/workspace/petrova-codes/skills/petrova-act .claude/skills/petrova-act
ln -s ~/code/workspace/petrova-codes/skills/petrova-status .claude/skills/petrova-status

Or vendor (when you want the consumer’s pinned version):

mkdir -p .claude/skills
cp -R ~/code/workspace/petrova-codes/skills/petrova-act .claude/skills/
cp -R ~/code/workspace/petrova-codes/skills/petrova-status .claude/skills/

Or take the whole set, which is what a governed repo normally wants:

mkdir -p .claude/skills
for s in ~/code/workspace/petrova-codes/skills/petrova-*; do
  ln -sfn "$s" ".claude/skills/$(basename "$s")"
done

Symlink is the recommended default — updates to petrova-codes propagate without consumer-side churn. The commands/ directory travels inside each skill, so the slash commands arrive with it by either route.

Refusal conditions (apply to both skills)

• Target repo’s slug not present in registry.yaml → refuse, list known slugs, suggest opening an onboarding PR (TASKSET 8).
• Write verb invoked with --apply and PETROVA_GITHUB_TOKEN / GitHub App env vars unset → refuse, instruct to set credentials.
• Privileged paths (.github/workflows/, *.env, secrets/, deploy/credentials/) appearing in any write verb’s files → refuse unconditionally; humans edit those.
• Skill cannot determine the current repo’s slug from git remote get-url → refuse and ask for explicit --repo <slug> from the human.

What these skills do NOT do

• They don’t bypass the CLI’s schema validation — every invocation passes through validateVerbInput first. A skill cannot construct a PR with a malformed payload.
• They don’t write directly to a target repo’s filesystem. All writes emit PRs via the GitHub API.
• They don’t auto-merge. request_merge_when_green enables auto-merge labels, but branch protection / CI gates remain the human gate.