Skip to content
cccskills
FreePublished on GitHub

manage-remote-resources

Own the lifecycle of short-lived paid CPU/GPU hosts and attached resources, from bounded provisioning through verified permanent deletion. Use when renting, extending, retiring, or recovering billable remote resources; campaign scheduling belongs to run-ephemeral-hosts.

The English summary is being prepared. Showing the original description.

Works withAWS
See how to install

Files included (8)

  • SKILL.md7.4 KB
  • agents/openai.yaml233 B
  • references/aws-operations.md12.9 KB
  • references/cpu-provider-cost-snapshot.md12.5 KB
  • references/credential-custody.md4.2 KB
  • references/gpu-provider-cost-snapshot.md13.2 KB
  • references/service-selection-and-security.md6.3 KB
  • references/vast-host-capability-admission.md10.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Manage remote resources

This skill owns billable resources, not the workload queue. Use run-ephemeral-hosts for a campaign and run-remote-builds for source/build synchronization. An existing user-lent host remains outside paid-resource deletion authority.

Before host selection or credential exposure, read remote host secrets and assurance. Apply its standing maintainer approvals and direct-copy decisions without asking again. Keep SSH private identities and lifecycle execution on the coordinator; ledger each destination. Read custody mechanics when transferring credentials or closing their records. The canonical contract owns additional approval gates and accepted disposal risk.

For campaign spending, apply standing configuration and prompt overrides. Otherwise use the user's existing explicit budget/deadline. Credential permission does not authorize spending or targets.

Plan and establish ownership

Read service selection and security admission when choosing a CPU/GPU host service or reviewing a new host configuration. For AWS, follow the AWS operating runbook for identity, service choice, launch checks and complete retirement. These references supply operating procedures, not a new spending grant or an implemented AWS watchdog.

  1. Define the bounded workload, completion signal, provider/account, region, CPU/RAM/GPU/disk needs, maximum total cost and hard deadline with cleanup reserve. Include bootstrap, canaries, idle time, storage, IPs, endpoints and egress. Apply validation overhead before repeated readiness checks.
  2. When comparing providers, read the dated CPU or GPU snapshot relevant to the workload. These are historical shortlists; verify current official billing, stock, account identity, balance/quota, create/inspect/permanent-delete operations and host assurance before provisioning. Insufficient API-visible balance closes creation until it changes. On Vast, prefer a qualifying North American offer unless capacity, total cost or reliability favors another locality; explicit residency/latency requirements are hard filters.
  3. Inventory pre-existing resources and choose a unique run ID and labels. Open a protected local ownership manifest and custody ledger before creation. Record exact resource IDs/types, account, creation times, authorization source, budget, deadline, and cleanup state. Register attached or indirectly created billable resources too; prefer adequately sized ephemeral storage and explicitly track persistent volumes.
  4. Arm independent cleanup before creation. A shell trap or cleanup process inside the rented host is insufficient. Provider-native permanent-delete expiry is preferred where available. Otherwise use an independently supervised coordinator watchdog; additional provider expiry covers coordinator/network loss where supported.

For Docker/browser workloads on Vast, read host capability admission before selecting an offer. For GPU inference configuration, read inference readiness; inference details are not resource lifecycle rules.

Register and verify cleanup supervision

Read shared resource watchdog before registering, changing, migrating or recovering cleanup. Use its executable schema and one supervised service with an owner-partitioned store. Dry-run the canonical command before arming; verify the exact supervisor/PID and fresh matching heartbeat before paid admission, after restarts and at checkpoints. Preserve spend and idle history across replacement, retirement and authorization extensions.

The current adapter deletes Vast instances only. Other providers and separately billed resource types need their own verified lifecycle mechanism. An instance-only inventory cannot prove account-wide cleanup or complete billing coverage. Unregistered resources remain observations unless an explicit reclamation policy applies.

Provision one resource at a time and capture its stable ID immediately. Reconcile ambiguous create responses using run labels, creation time and pre-existing inventory before retrying. Verify each new resource has effective cleanup coverage before starting its workload. Serialize manifest writes with one writer or lock/CAS; extensions must remain within aggregate authorization and preserve accrued spend. Partition multi-provider budgets without multiplying the ceiling.

Run within the ownership contract

Supervise bounded jobs with explicit completion/failure state and preserve outputs off-host incrementally. Use the verified Vast public IP and mapped SSH port by default; a proxy route is a bounded preflight fallback. Record and prove long-lived routes before work, and close affected admissions on disconnect.

Observe jobs, queued work, provider-wait slots and progress alongside hardware metrics. Known-finished or idle hosts retire promptly; the watchdog's sampled idle policy is a zombie backstop, not permission to retain them. Bounded repairs stay inside the deadline and budget. Apply the canonical watchdog's drain/inspection and admission rules before reclaiming resources; missing telemetry remains unknown.

Before refreshing or deleting a worker, preserve source/configuration fixes through synchronization, within the cleanup deadline.

Retire and reconcile

Stop admissions, preserve partial/final evidence, stop credential holders and perform the canonical custody procedure before permanent deletion. Keep proof and accepted-risk dispositions distinct. Remove only exact owned resources, including attached storage and recreate-capable jobs/autoscalers. Stopping or losing SSH is not deletion.

For fleet retirement, verify exact-ID absence, persist deletion receipts atomically and retain retired-host accrual without disturbing live peers. Reconcile compute, storage, endpoints, IPs, snapshots and reservations against pre-existing inventory. Keep cleanup supervision active until every owned billable resource is verified absent; remove only the completed campaign registration while shared supervision continues for others.

An unresolved deletion is an active cost incident: retry official deletion and independent provider paths with bounded backoff, preserve supervision, report exact IDs/state/burn and the manual remedy promptly, and do not create replacement resources while owned deletion remains unverified.

Finish with resource IDs/types, authorization and deadline, workload artifacts, exact deletion evidence and inventory scope, measured/estimated/unknown spend, ledger dispositions and remaining incidents. Never report provider disposal assumptions as verified credential erasure.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Plan and use user-consented local camera and microphone observations for an explicitly authorized physical target. Use when a capture can establish a bounded physical-state observation such as whether a test fixture changed state, an instrument reading changed, or equipment noise changed relatively.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Plan vulnerability research using conventional bug-hunting and pentest stage names, specialty playbooks, and a research-hypothesis-experiment loop. Use when designing a bug bounty workflow, selecting tools and strategies, building a decision tree, or turning a target/scope into a staged hunting plan.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Passive code-review lane for authorized repositories, local checkouts, uploaded source archives, and diffs. Use when the security research agent needs deterministic candidate discovery before expensive AI investigation, scoped PR-style review, append-only evidence records, or independent revalidation of code findings.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Run independent, task-matched expert attempts, select a base, and synthesize the strongest result.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Select established CTF and security-research tools for authorized artifact triage, web inspection, reversing, crypto, forensics, networking, and exploit validation. Use when a user provides a CTF-style tool catalog, asks which tools to use, or needs safe usage instructions for common offensive/security tools.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

Disciplined diagnosis loop for hard bugs and performance regressions. Reproduce → minimise → hypothesise → instrument → fix → regression-test. Use when user says "diagnose this" / "debug this", reports a bug, says something is broken/throwing/failing, or describes a performance regression.

The English summary is being prepared. Showing the original description.

justsml/ExploitHunter.app14Updated Oct 17, 2026

See all skills by justsml

Report a problem with this skill