Skip to content
PETROVA

Install skills into a consumer repo

skills/ — Claude Code skill wrappers

Section titled “skills/ — Claude Code skill wrappers”

Two skills that surface the petrova CLI to Claude Code sessions in any governed repo:

  • 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.

Prerequisites

Section titled “Prerequisites”

A consumer repo using these skills needs:

  1. The CLI built and on PATH. Either:
    • Global install: cd petrova-hq/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-hq}/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-hq. 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

Section titled “Install into a consumer repo”

Either symlink:

Terminal window
ln -s ~/code/workspace/petrova-hq/skills/petrova-act .claude/skills/petrova-act
ln -s ~/code/workspace/petrova-hq/skills/petrova-status .claude/skills/petrova-status

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

Terminal window
mkdir -p .claude/skills
cp -R ~/code/workspace/petrova-hq/skills/petrova-act .claude/skills/
cp -R ~/code/workspace/petrova-hq/skills/petrova-status .claude/skills/

Symlink is the recommended default — updates to petrova-hq propagate without consumer-side churn.

Refusal conditions (apply to both skills)

Section titled “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

Section titled “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.