ワンクリックでManusで任意のスキルを実行

cost-management-app-operator

スター4

フォーク2

更新日2026年7月12日 23:04

Operate the Cost Management App app through its generated CLI and browser surface. Use for "Turn fleet cost findings into governed recommendations, approvals, and receipts.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

confighub

confighub/examples

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Cost Management App Operator

Use this skill when a user asks to operate this generated ConfigHub app.

Route

Run node cli.mjs preflight --json.
Run node cli.mjs map --json to show Variant scope.
Run node cli.mjs findings --json to show blockers and proof gaps.
Choose an actionable id from node cli.mjs findings --json, then run node cli.mjs preview --finding <finding-id> --json and inspect the saved diff.
Record the exact review with node cli.mjs review --record --preview <preview-id> --reason '<why>' --json; never hand-author a function, target, or argument at review time. Show the human the target, function, arguments, and reviewed diff. The record is evidence, not approval.
Ask one explicit approval question for that exact review id and scope. Only after the human approves, run node cli.mjs commit --review <review-id> --confirm-execute --json. If it blocks or returns an unverified receipt, report that state; do not retry automatically.
Close with node cli.mjs verify --json and node cli.mjs receipt --json.

Boundaries

The CLI and GUI share data/operational-workflow.json.
Deployment-local bindings live in data/live-bindings.json.
Review files are local evidence, not signed ConfigHub approvals or mutation permission.
Do not treat a missing live binding as success.
Do not claim runtime success without receipt and runtime evidence.

このリポジトリの他の Skills

同じリポジトリ

add-on-manager-operator

confighub/examples

Operate the Add-on Manager app through its generated CLI and browser surface. Use for "Install, upgrade, review, and prove platform add-ons through governed ConfigHub delivery paths.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.

2026-07-024

autoscale-audit

confighub/examples

Inventory and report Kubernetes autoscaling stored in ConfigHub across a fleet with the cub-autoscale CLI — HorizontalPodAutoscalers and KEDA ScaledObjects: each one's scale target, min/max replicas, and whether it is pinned (min == max). Use for "what autoscalers do we have?", "list our HPAs / ScaledObjects", "which workloads are autoscaled?", "per-cluster autoscaler counts", "is autoscaler X pinned?". Not for autoscaling findings/anti-patterns (use autoscale-findings), edits or HPA→KEDA conversion (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

2026-07-024

autoscale-edit

confighub/examples

Set Kubernetes autoscaling as config-as-data with the cub-autoscale CLI — edit a HorizontalPodAutoscaler's min/max replicas and cpu/memory targets, convert an HPA to a KEDA ScaledObject, apply reusable autoscaling profiles to one Unit or across a whole selector, and promote changes downstream. Use for "raise the HPA max to 20", "set cpu target to 60%", "convert this HPA to KEDA", "make every prod HPA scale out earlier", "apply the hpa-range profile", "roll the autoscaling change downstream". Dry-run by default; requires --commit --change-desc. Not for read-only checks (use autoscale-audit / autoscale-findings) or enforcement Triggers (use autoscale-guardrails).

2026-07-024

autoscale-findings

confighub/examples

Produce severity-ranked Kubernetes autoscaling findings across a ConfigHub fleet with the cub-autoscale CLI. Flags autoscalers that are pinned (min == max, can't scale), workloads with no HPA/ScaledObject, and the cross-resource case where a PodDisruptionBudget's minAvailable blocks all voluntary eviction at the autoscaler's minReplicas. Use for "what autoscaling problems do we have?", "which HPAs can't scale?", "which workloads lack an autoscaler?", "is any PDB blocking scale-down?". Not for the raw autoscaler inventory (use autoscale-audit), fixing autoscaling (use autoscale-edit), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

2026-07-024

autoscale-guardrails

confighub/examples

Install and inspect the autoscaling enforcement pack with the cub-autoscale CLI — an autoscale-policy Space with two Warn=true Triggers: a vet-cel rule that flags any HPA/ScaledObject that is pinned (min == max), and a vet-schemas rule that schema-validates every mutation (the post-convert check for convert-keda output, since keda.sh is in the schema catalog) — wired to in-scope Spaces via a shared Trigger Filter. guardrails install (dry-run by default) and status (Units with ApplyWarnings/Gates). Use for "enforce that no HPA is pinned", "make sure converted ScaledObjects pass schema validation", "which autoscalers are flagged?". Not for read-only findings (use autoscale-findings) or fixing autoscaling (use autoscale-edit).

2026-07-024

observability-audit

confighub/examples

Inventory the observability posture of Kubernetes workloads stored in ConfigHub across a fleet with the cub-observability CLI — ServiceMonitors, Services (and which expose metrics), and telemetry-sidecar presence. Use for "what ServiceMonitors / Services do we have?", "which Services expose metrics?", "which workloads have an otel sidecar?", "per-cluster observability counts". Not for ServiceMonitor coverage gaps (use observability-findings), fixes (use observability-instrument / observability-guardrails), or live cluster state (use kubectl); analysis is over ConfigHub-managed Units only.

2026-07-014

name	cost-management-app-operator
description	Operate the Cost Management App app through its generated CLI and browser surface. Use for "Turn fleet cost findings into governed recommendations, approvals, and receipts.", Variant review, proof gaps, preview, approval scope, and receipt checks. Read-only first; live mutation requires the app commit command to prove real ConfigHub bindings.
phase	verify
allowed-tools	Bash(node cli.mjs preflight --json) Bash(node cli.mjs map --json) Bash(node cli.mjs findings --json) Bash(node cli.mjs preview ) Bash(node cli.mjs review ) Bash(node cli.mjs commit *) Bash(node cli.mjs verify --json) Bash(node cli.mjs receipt --json)

Cost Management App Operator

Use this skill when a user asks to operate this generated ConfigHub app.

Route

Run node cli.mjs preflight --json.
Run node cli.mjs map --json to show Variant scope.
Run node cli.mjs findings --json to show blockers and proof gaps.
Choose an actionable id from node cli.mjs findings --json, then run node cli.mjs preview --finding <finding-id> --json and inspect the saved diff.
Record the exact review with node cli.mjs review --record --preview <preview-id> --reason '<why>' --json; never hand-author a function, target, or argument at review time. Show the human the target, function, arguments, and reviewed diff. The record is evidence, not approval.
Ask one explicit approval question for that exact review id and scope. Only after the human approves, run node cli.mjs commit --review <review-id> --confirm-execute --json. If it blocks or returns an unverified receipt, report that state; do not retry automatically.
Close with node cli.mjs verify --json and node cli.mjs receipt --json.

Boundaries

The CLI and GUI share data/operational-workflow.json.
Deployment-local bindings live in data/live-bindings.json.
Review files are local evidence, not signed ConfigHub approvals or mutation permission.
Do not treat a missing live binding as success.
Do not claim runtime success without receipt and runtime evidence.