Runs the hypervisor layer beneath the servers — host capacity and consolidation ratios, VM sprawl, snapshot discipline, resilience and live migration, and licensing that counts cores rather than instances. Use this to size or expand a cluster, work out why VMs are slow when the hosts look idle, clean up sprawl, set snapshot and template policy, or decide what stays virtualized and what moves to cloud.
インストール方法を見るインストールする前に、エージェントに与えられる指示の中身を確認できます。
Virtualization is the layer most infrastructure problems actually live in, and the one most monitoring is blind to. A guest reports healthy CPU while contending for a core it never gets. The usual failure is diagnosing upward — into the application — when the constraint is a host two layers below.
Every cluster has a ratio of virtual resources to physical ones, and most organizations discover theirs rather than choosing it. Overcommitting memory and CPU is normal and correct; the question is how far, and what happens at peak rather than average.
Two numbers worth knowing at all times: what the cluster runs at now, and what it runs at when one host is gone. If losing a single host takes you past capacity, you have a cluster that survives hardware failure on paper and not in practice. Size for N-1 and keep the spare capacity visible in the budget, or the first thing cut is the headroom that makes the design work.
Memory is usually the real ceiling, not CPU. Cores oversubscribe gracefully; RAM does not.
VMs are trivially easy to create and socially difficult to delete. Nobody remembers what the box does, so it stays — consuming license, backup capacity, patching effort, and an attack surface nobody reviews.
The fix is ownership recorded at creation, not an annual cleanup. Every VM gets a named owner and a review date before it is built. Anything that cannot name an owner is a candidate for decommissioning, and the decommission path is: power off, wait a defined period, then delete. Powering off first turns an irreversible decision into a reversible one and produces the phone call that tells you what the machine did.
Templates and golden images keep the estate consistent. Builds that started from a template drift
less than builds someone assembled, and drift is what makes patching unpredictable — see
it-operations:systems-administration for the configuration baseline this feeds.
A snapshot is a change log against a disk, and it grows until it is merged. Left running, it fills the datastore and takes down every VM sharing that storage, which is a much worse incident than whatever the snapshot was protecting against.
Treat them as a short-lived tool for a specific change: take one before a risky upgrade, merge it
the same day, and alert on any snapshot older than the threshold you set. They are not a retention
mechanism and they do not survive storage failure — real recovery belongs to
it-operations:backup-and-recovery.
Moving running workloads between hosts is what makes patching the hypervisor possible without a maintenance window, and that alone justifies it. It does not protect against a host failing suddenly — that is a restart on another host, with downtime measured in boot time.
Know which of your workloads tolerate that restart and which do not. The ones that do not need clustering inside the guest, and virtualizing them does not remove that requirement.
Hypervisor and guest licensing is commonly priced per physical core or socket, which means a consolidation decision is also a licensing decision, and adding hosts can cost more in license than in hardware. Some vendors license every core in a cluster a workload could migrate to, not the one it runs on — which turns an availability setting into a bill.
Model the license cost before the hardware purchase, and check it again when the cluster grows.
it-operations:it-asset-management owns the entitlement records; this skill owns knowing which
architectural choices move them.
Not everything should be virtualized on-premises, and not everything should move. The honest test is not cost per VM — it is whether the workload's demand is steady or spiky. Steady, predictable load runs cheaper on hardware you own. Spiky or seasonal load is what cloud elasticity is actually for.
Hybrid is the normal end state, not a transitional embarrassment. What makes it painful is running two operating models with two sets of habits, so decide deliberately which one owns identity, monitoring, and backup rather than letting each side answer differently.
references/sources.md in this skill lists the outside authorities that settle the questions
here — what each one is authoritative for, and what you may do with it. Check them before
answering on anything they cover, and cite what you used. Most are free to read and not free
to reproduce; the use note on each is binding.
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
Designs and audits who can reach what — authentication, authorization models, privileged access, service credentials, and joiner-mover-leaver process. Use this to design a permissions model, run an access review, reduce standing privilege, handle offboarding, set up SSO or MFA, manage service and machine credentials, or diagnose why permissions have sprawled.
日本語の概要は準備中です。原文の説明を表示しています。
Concentrates marketing and sales effort on a named set of accounts rather than on volume — qualifying whether the model fits your economics at all, building the account list and the buying group inside each, tiering effort against account value, coordinating so the account experiences one campaign rather than several, and measuring account progression instead of leads. Use this to decide whether to run an account-based program, build one, or work out why an existing one produces activity and no pipeline.
日本語の概要は準備中です。原文の説明を表示しています。
Gets new users from signup to first real value — signup flow, onboarding, time-to-value, and the early experience that determines whether someone becomes a user or a lapsed account. Use this to design or fix signup and onboarding, diagnose why signups do not convert to active use, reduce time-to-value, or decide what a new user must accomplish first.
日本語の概要は準備中です。原文の説明を表示しています。
Designs orchestrator-and-subagent hierarchies for a repository — splitting agents by exclusive write surface, pairing every producer with an independent auditor, and enforcing the split with a script that runs in CI. Use this whenever the user wants to set up, expand, audit, or fix a multi-agent or subagent structure for a codebase; asks how to divide work between agents; wants agent charters, roles, or a surface map written; or is hitting agents that collide on the same files, review their own work, or drift from their remit. Also use when sizing a roster or deciding whether a new agent is justified.
日本語の概要は準備中です。原文の説明を表示しています。
Governs models and AI systems in production — intended use, evaluation, monitoring, human oversight, documentation, and the decision to deploy or retire. Use this before deploying a model or AI feature, when defining evaluation criteria, when a model's behavior has drifted, when assessing AI risk or regulatory exposure, or when deciding whether an AI system is fit for a consequential decision.
日本語の概要は準備中です。原文の説明を表示しています。
Produces executive-level research — market sizing, competitor mapping, trend analysis, and strategic intelligence — grounded in cited sources with the confidence in each claim made explicit. Use this to analyze a market or industry, map competitors, evaluate a market-entry or build-versus-buy decision, produce a research brief, or assemble evidence for a decision. Also use when comparing options that need a structured, evidence-based verdict rather than an opinion.
日本語の概要は準備中です。原文の説明を表示しています。