Deploy / monitor / close a NAMED Senpi trading strategy. Monitoring is on demand: never an agent-turn cron to watch a strategy (a model call per firing) — the runtime supervises it at zero model cost, and there is no paper-trading mode ($10 floor = the test). Use when the user names a strategy to run — "install spider", "deploy polar", "set up kodiak", "reinstall athena", "run the spider strategy", "is my strategy live?", "what am I running", "list my strategies" (→ status.py), A STRATEGY IS A PACKAGE, NEVER A SKILL: "install/reinstall <name>" is `deploy.py create <id>` here — never `openclaw skills install`, never clawhub, and never a GitHub user or repo named after the strategy. A package missing from disk is normal (it was closed, or never fetched) and `deploy.py` fetches it by id. "are my positions protected? / do they have a stop-loss (DSL)?", "stop/close/uninstall polar" — and for teardown like "close all strategies", "return funds to main", "tear everything down" (→ close.py --all). ALWAYS tear down via close.py, never a raw strategy_close (that strands the runtime). ops deploys / closes / monitors; it does NOT author or edit strategy files — an edit ("make my live strategy more aggressive", change leverage/sizing/DSL) is authored in senpi-strategy-author, the only skill that knows the scanner / yaml / DSL schema — and "tighten the ratchet / change the tiers / the locks" on a LIVE strategy is applied here (update --apply), never parked "for the next position". A strategy is a PACKAGE (strategy.yaml + one runtime.yaml per instance + scanners/) the runtime supervises in-process — no scanner daemon. `deploy.py create <id> --budget <usd>` takes a package live end to end (it gates the package, then runs the runtime's detached deploy job; watch with `senpi deploy status`); close.py tears down (stop runtime + strategy_close → flattens positions, returns funds). Before the budget question ops runs THE WALKTHROUGH (Step 0.75): what the template does, how it is set, the two levers worth shifting — all in bullets and plain words, never a config key — and its name: every template deploys as the user's own fork, named after their Senpi username (`deploy.py create <template>` → `ignas-phalanx`, spoken as "Ignas's Phalanx"; `--name` for their own words), as-is or with levers moved. The id (spider, polar, kodiak) is the package folder. NOT for choosing WHICH strategy (senpi-strategy-discover) or authoring / editing the strategy files themselves (senpi-strategy-author).
cp -r cryptoskill/skills/exchanges/senpi-ai-senpi-strategy-ops .claude/skills/clawhub install senpi-ai-senpi-strategy-opsCapabilities below are detected automatically by an open-source scanner that reads the skill's text and scripts (see how this is computed). Not measured means the scanner couldn't make a confident call — it is NOT a green check, and you should treat it as a possible red flag until a human or a stronger scanner has measured it.
router_orchestrator Phase 1 single-mode classification — multi-mode breakdown deferred to Phase 2.
We did not find any well-known hosted services in this skill's text or scripts. This does NOT mean the skill is local-only — it might use services we don't yet recognize, or talk to them through code paths our scanner can't reach. A complete dependency list (every package, library, and binary, with integrity hashes) is on the roadmap; today we only show recognized hosts.
No one has audited this skill yet. That is different from “audited and clean” — it just means no professional reviewer (a security firm, the CryptoSkill team, or a verified independent researcher) has signed off on it. There are no audit reports to read. How reviewer levels work →
SKILL.md → SOURCE.md → TRUST.auto.yaml → Browse directory →
Auto-generated by cryptoskill/extract-capabilities/0.3.1 · hosted-service list version 2026-09-06 · how this is computed