본문으로 건너뛰기
cccskills
무료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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

연동 도구AWS
설치 방법 보기

포함된 파일(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(원문)

설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.

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.

리뷰

아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.

댓글

로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.

아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.

보내면 바로 공개됩니다. 이메일 주소나 전화번호 같은 개인 정보는 쓰지 마세요. URL은 2개까지입니다.

0 / 1,000자

이 양식은 reCAPTCHA로 보호되며 Google 개인정보처리방침 및 서비스 약관이 적용됩니다.

같은 저장소의 스킬

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

justsml/ExploitHunter.app142026년 10월 17일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

justsml/ExploitHunter.app142026년 10월 17일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

justsml/ExploitHunter.app142026년 10월 17일 업데이트

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

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

justsml/ExploitHunter.app142026년 10월 17일 업데이트

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

justsml/ExploitHunter.app142026년 10월 17일 업데이트

diagnose

무료

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.

한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.

justsml/ExploitHunter.app142026년 10월 17일 업데이트

justsml의 스킬 모두 보기

이 스킬의 문제 신고