[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7AM8RAMR9F16KV2RKWM8AXE":3,"skill-same:01M7AM8RAMR9F16KV2RKWM8AXE":48},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":24,"commitSha":25,"skillDirectory":26,"forksCount":27,"repositoryHtmlUrl":28,"repositoryHomepageUrl":29,"ownerHtmlUrl":30,"ownerBlogUrl":31,"ownerDescription":32,"updatedAt":33,"install":34,"resources":47},"01M7AM8RAMR9F16KV2RKWM8AXE","cloud-models-providers-and-primitives",null,"Use when choosing a cloud model or provider, or reasoning about the basic building blocks: IaaS, PaaS and SaaS, the deployment models, the five NIST characteristics, the provider landscape (AWS, Azure, Google Cloud and the second tier) and how to choose between them, and the primitives — compute, storage classes, networking and VPCs, and identity and IAM. Includes the router for the whole cloud-computing reference.","the-vibey-project\u002Fvibey","the-vibey-project","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F329298758?v=4","01M7AJHGZ9722CTJ4JNQZVRH0Q","the vibey project","01M7AJHGZVMG2K7TGXQ6XFHVG3",5,"MIT","https:\u002F\u002Fgithub.com\u002Fthe-vibey-project\u002Fvibey\u002Fblob\u002Fdevelop\u002Fsrc\u002Fvibey_tools\u002Fskills\u002Fplugins\u002Fcloud-computing\u002Fskills\u002Fcloud-models-providers-and-primitives\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: cloud-models-providers-and-primitives\ndescription: \"Use when choosing a cloud model or provider, or reasoning about the basic building blocks: IaaS, PaaS and SaaS, the deployment models, the five NIST characteristics, the provider landscape (AWS, Azure, Google Cloud and the second tier) and how to choose between them, and the primitives — compute, storage classes, networking and VPCs, and identity and IAM. Includes the router for the whole cloud-computing reference.\"\n---\n\n# Cloud Computing: Models, the Provider Landscape, and the Primitives\n\n> **Part 1 of 5** of the *Cloud Computing* reference (plugin `cloud-computing`), covering §0–§3. Sibling skills: `cloud-architecture-and-resilience` (§4–§6), `cloud-cost-security-and-operations` (§7–§9), `cloud-migration-sovereignty-and-ai-workloads` (§10–§14), `cloud-reference` (§15–§20). Section numbers are shared across the set; a reference written as §N → `skill` points into that sibling skill.\n>\n> **Currency:** Verified August 2026. See §17 → `cloud-reference` for the currency snapshot and what goes stale first.\n\n> **How to read this.** Reference, not a certification guide. Three markers:\n> - **[DURABLE]** — architectural principles and trade-offs that survive provider churn.\n> - **[VERSIONED]** — market data, pricing, service names, regulation. **Verify before\n>   quoting.**\n> - **[CONTESTED]** — genuine disagreement.\n>\n> **⚠️ GOTCHA** boxes mark the mistakes that produce outages or surprise invoices.\n>\n> **Provider-neutral by default**, with AWS\u002FAzure\u002FGCP names where the concept needs an\n> anchor. Service names change; the primitives don't.\n>\n> **The three framings that organize everything below:**\n> 1. **The cloud is someone else's computer, rented, with an API and a metered bill.**\n>    Every genuine advantage (elasticity, global reach, managed services, capex→opex) and\n>    every genuine failure mode (cost surprise, lock-in, shared fate, opaque outages)\n>    follows from that one sentence.\n> 2. **⚠️ Your failure domain is always larger than your architecture diagram says.**\n>    The 2025 outages taught this expensively: multi-AZ deployments failed because of\n>    control-plane dependencies nobody had drawn (§6 → `cloud-architecture-and-resilience`). **Map what you actually depend on,\n>    not what you think you depend on.**\n> 3. **Cost is an architectural property, not an operational afterthought.** It is\n>    determined by design decisions — data placement, service selection, egress paths —\n>    and **discovered on an invoice 30 days later** (§7 → `cloud-cost-security-and-operations`). Design for it up front or pay\n>    for it forever.\n\n---\n\n## §0. Routing\n\n| Asked about... | Go to |\n|---|---|\n| Service and deployment models | §1 |\n| Which provider, and market reality | §2 |\n| Compute, storage, networking, identity | §3 |\n| Architecture and Well-Architected | §4 → `cloud-architecture-and-resilience` |\n| Containers, Kubernetes, serverless | §5 → `cloud-architecture-and-resilience` |\n| **Resilience, and the 2025 outage lessons** | **§6 → `cloud-architecture-and-resilience`** |\n| **Cost engineering and FinOps** | **§7 → `cloud-cost-security-and-operations`** |\n| Security and shared responsibility | §8 → `cloud-cost-security-and-operations` |\n| Operations and observability | §9 → `cloud-cost-security-and-operations` |\n| Migration strategy | §10 → `cloud-migration-sovereignty-and-ai-workloads` |\n| **Sovereignty, the EU Data Act, egress** | **§11 → `cloud-migration-sovereignty-and-ai-workloads`** |\n| Multi-cloud and lock-in | §12 → `cloud-migration-sovereignty-and-ai-workloads` |\n| AI workloads and their economics | §13 → `cloud-migration-sovereignty-and-ai-workloads` |\n| Sustainability | §14 → `cloud-migration-sovereignty-and-ai-workloads` |\n| \"Don't do this\" | §15 → `cloud-reference` |\n| \"Which side is right?\" | §16 → `cloud-reference` |\n| \"Is this still current?\" | §17 → `cloud-reference` |\n| Books and resources | §18 → `cloud-reference` |\n\n---\n\n## §1. Models\n\n### 1.1 Service models\n\n```\nOn-prem  →  IaaS  →  CaaS  →  PaaS  →  FaaS  →  SaaS\n◄─────────── you manage more        you manage less ───────────►\n◄─────────── more control           less operational burden ───►\n◄─────────── more lock-in risk?     ⚠️ see §12 — it's not that simple\n```\n\n**[DURABLE] The trade-off is real in both directions**, and the common mistake is\noptimizing only one end. Managed services cost more per unit and less in engineering time;\nraw IaaS is cheaper per unit and you pay for it in people. **⚠️ The comparison people skip\nis the fully-loaded one** — a managed database's premium is frequently less than one\nengineer's fraction of time keeping a self-hosted one patched, backed up, and monitored.\n\n### 1.2 Deployment models\n**Public**, **private**, **hybrid** (⚠️ **the actual state of most large enterprises**,\nwhatever the strategy deck says), **multi-cloud** (§12 → `cloud-migration-sovereignty-and-ai-workloads`), and **edge**. **Sovereign cloud**\nis now a distinct category with regulatory meaning rather than a marketing label (§11 → `cloud-migration-sovereignty-and-ai-workloads`).\n\n### 1.3 The five NIST characteristics\nOn-demand self-service, broad network access, resource pooling, rapid elasticity,\nmeasured service. **[DURABLE] Dated 2011 and still the cleanest definition** — and\n\"measured service\" is the one that quietly determines your architecture (§7 → `cloud-cost-security-and-operations`).\n\n---\n\n## §2. The Provider Landscape\n\n**[VERSIONED — and read the ⚠️ in this section before quoting any number.]**\n\n**Market structure as of Q1 2026**: the Big Three hold roughly **60–68%** of global cloud\ninfrastructure spend, with the market reaching **~$129B in Q1 2026, growing ~35% YoY** —\ndescribed as the **ninth consecutive quarter of increasing year-over-year growth**.\n\n> **⚠️ GOTCHA — the share figures genuinely conflict across sources, and you should know\n> why before citing them.** Synergy Research puts Q1 2026 at **AWS 28%, Azure 21%, Google\n> Cloud 14%**. Other widely-circulated figures give **AWS 30% \u002F Azure 24–25% \u002F GCP 13%**,\n> and others still **AWS 32% \u002F Azure 23% \u002F GCP 11%**.\n>\n> **The discrepancy is methodological, not an error.** One analysis explains it directly:\n> Azure's higher share estimates **exceed a straight revenue calculation because Synergy\n> weights IaaS-and-PaaS spend, where Azure is stronger** — and separately, **Microsoft\n> does not break out Azure revenue at all, only its growth rate**, so any \"Azure revenue\"\n> figure is derived. **Both kinds of figure are valid; they measure different scopes.**\n> **Cite the source and the scope, or don't cite the number.**\n\n**Growth is the more interesting story than share**: Azure and Google Cloud have been\ngrowing substantially faster off smaller bases, with Google Cloud posting the highest rates\nof the three. **AI is the driver** — AI-related spending was reported at **~19% of total\ncloud spend in 2026, up from ~8% in 2023.**\n\n**⚠️ The capex arms race is the structural fact underneath all of it.** 2026 guidance\nfigures in circulation: **Amazon ~$200B, Microsoft ~$190B, Alphabet ~$180–190B.** This\nfunctions as a moat — the cost of building global infrastructure excludes almost everyone\n— and it carries genuine risk: **the Big Three are betting hundreds of billions that AI\ndemand will justify the build-out, and if it disappoints the write-downs would be\nenormous.** For a buyer, large capex commitments are **both a supply signal and a\nlock-in signal.**\n\n**Choosing** — the honest criteria, roughly in order: **existing skills and contracts**\n(⚠️ **usually decisive and rarely stated**), **the specific services you need**,\n**regional and data-residency footprint** (§11 → `cloud-migration-sovereignty-and-ai-workloads`), **pricing for your actual shape of\nworkload**, **enterprise agreements and discounts**, and **regulatory posture**.\n**Beyond the Big Three**: Oracle Cloud, IBM, Alibaba, and the **\"neoclouds\"** — GPU-focused\nproviders (CoreWeave, Lambda and others) estimated collectively at a small but real share\nsegment. **Cloudflare, Fastly, Vercel, Fly.io** for edge; **DigitalOcean, Hetzner,\nScaleway** for straightforward compute at markedly lower prices.\n\n---\n\n## §3. The Primitives\n\n**[DURABLE] Every provider has these under different names. Learn the primitive, map the\nname.**\n\n**Compute**: VMs (⚠️ **still the majority of cloud spend**), containers (§5 → `cloud-architecture-and-resilience`), serverless\nfunctions, GPU\u002Faccelerator instances (§13 → `cloud-migration-sovereignty-and-ai-workloads`), bare metal. **Pricing modes matter more than\ninstance choice**: on-demand, reserved\u002Fcommitted (1–3 year, **large discounts**), savings\nplans, **spot\u002Fpreemptible** (⚠️ **60–90% cheaper and interruptible — enormously underused\nfor batch, CI, and fault-tolerant work**), dedicated hosts.\n\n**Storage**, and **⚠️ picking the wrong class is one of the most common cost errors**:\n\n| Type | Use | ⚠️ Watch |\n|---|---|---|\n| **Object** (S3, Blob, GCS) | The default for almost everything: static assets, data lakes, backups | Request costs at high volume; egress (§11 → `cloud-migration-sovereignty-and-ai-workloads`) |\n| **Block** (EBS, Managed Disks) | Filesystem for a VM | ⚠️ **Provisioned, not consumed — you pay for the size you asked for, idle or not** |\n| **File** (EFS, Azure Files) | Shared POSIX access | Expensive per GB |\n| **Archive** (Glacier, Archive tier) | Long-term retention | ⚠️ **Retrieval time and retrieval cost — and early-deletion fees** |\n\n**⚠️ Lifecycle policies are free money and routinely unconfigured.** Object storage tiering\nfrom hot → cool → archive on an age rule takes minutes to set and runs forever.\n\n**Networking**: VPC\u002FVNet, subnets, security groups\u002FNSGs, load balancers (L4 and L7),\nDNS, CDN, private endpoints, peering, transit gateway\u002Fhub-spoke, NAT gateways\n(⚠️ **a surprisingly large and invisible line item at volume**).\n\n**Identity** — **[DURABLE] the most important primitive and the most commonly\nmisconfigured** (§8 → `cloud-cost-security-and-operations`): workload identity (⚠️ **use it — long-lived access keys are the\nsingle most common cloud breach vector**), roles and policies, federation, and\n**least privilege as an actual practice rather than an aspiration**.\n\n**Managed data services**: relational, NoSQL, cache, search, queues and streams, data\nwarehouse. **⚠️ Each is a lock-in decision as well as an architecture decision** (§12 → `cloud-migration-sovereignty-and-ai-workloads`).\n","# Cloud Computing: Models, the Provider Landscape, and the Primitives\n\n> **Part 1 of 5** of the *Cloud Computing* reference (plugin `cloud-computing`), covering §0–§3. Sibling skills: `cloud-architecture-and-resilience` (§4–§6), `cloud-cost-security-and-operations` (§7–§9), `cloud-migration-sovereignty-and-ai-workloads` (§10–§14), `cloud-reference` (§15–§20). Section numbers are shared across the set; a reference written as §N → `skill` points into that sibling skill.\n>\n> **Currency:** Verified August 2026. See §17 → `cloud-reference` for the currency snapshot and what goes stale first.\n\n> **How to read this.** Reference, not a certification guide. Three markers:\n> - **[DURABLE]** — architectural principles and trade-offs that survive provider churn.\n> - **[VERSIONED]** — market data, pricing, service names, regulation. **Verify before\n>   quoting.**\n> - **[CONTESTED]** — genuine disagreement.\n>\n> **⚠️ GOTCHA** boxes mark the mistakes that produce outages or surprise invoices.\n>\n> **Provider-neutral by default**, with AWS\u002FAzure\u002FGCP names where the concept needs an\n> anchor. Service names change; the primitives don't.\n>\n> **The three framings that organize everything below:**\n> 1. **The cloud is someone else's computer, rented, with an API and a metered bill.**\n>    Every genuine advantage (elasticity, global reach, managed services, capex→opex) and\n>    every genuine failure mode (cost surprise, lock-in, shared fate, opaque outages)\n>    follows from that one sentence.\n> 2. **⚠️ Your failure domain is always larger than your architecture diagram says.**\n>    The 2025 outages taught this expensively: multi-AZ deployments failed because of\n>    control-plane dependencies nobody had drawn (§6 → `cloud-architecture-and-resilience`). **Map what you actually depend on,\n>    not what you think you depend on.**\n> 3. **Cost is an architectural property, not an operational afterthought.** It is\n>    determined by design decisions — data placement, service selection, egress paths —\n>    and **discovered on an invoice 30 days later** (§7 → `cloud-cost-security-and-operations`). Design for it up front or pay\n>    for it forever.\n\n---\n\n## §0. Routing\n\n| Asked about... | Go to |\n|---|---|\n| Service and deployment models | §1 |\n| Which provider, and market reality | §2 |\n| Compute, storage, networking, identity | §3 |\n| Architecture and Well-Architected | §4 → `cloud-architecture-and-resilience` |\n| Containers, Kubernetes, serverless | §5 → `cloud-architecture-and-resilience` |\n| **Resilience, and the 2025 outage lessons** | **§6 → `cloud-architecture-and-resilience`** |\n| **Cost engineering and FinOps** | **§7 → `cloud-cost-security-and-operations`** |\n| Security and shared responsibility | §8 → `cloud-cost-security-and-operations` |\n| Operations and observability | §9 → `cloud-cost-security-and-operations` |\n| Migration strategy | §10 → `cloud-migration-sovereignty-and-ai-workloads` |\n| **Sovereignty, the EU Data Act, egress** | **§11 → `cloud-migration-sovereignty-and-ai-workloads`** |\n| Multi-cloud and lock-in | §12 → `cloud-migration-sovereignty-and-ai-workloads` |\n| AI workloads and their economics | §13 → `cloud-migration-sovereignty-and-ai-workloads` |\n| Sustainability | §14 → `cloud-migration-sovereignty-and-ai-workloads` |\n| \"Don't do this\" | §15 → `cloud-reference` |\n| \"Which side is right?\" | §16 → `cloud-reference` |\n| \"Is this still current?\" | §17 → `cloud-reference` |\n| Books and resources | §18 → `cloud-reference` |\n\n---\n\n## §1. Models\n\n### 1.1 Service models\n\n```\nOn-prem  →  IaaS  →  CaaS  →  PaaS  →  FaaS  →  SaaS\n◄─────────── you manage more        you manage less ───────────►\n◄─────────── more control           less operational burden ───►\n◄─────────── more lock-in risk?     ⚠️ see §12 — it's not that simple\n```\n\n**[DURABLE] The trade-off is real in both directions**, and the common mistake is\noptimizing only one end. Managed services cost more per unit and less in engineering time;\nraw IaaS is cheaper per unit and you pay for it in people. **⚠️ The comparison people skip\nis the fully-loaded one** — a managed database's premium is frequently less than one\nengineer's fraction of time keeping a self-hosted one patched, backed up, and monitored.\n\n### 1.2 Deployment models\n**Public**, **private**, **hybrid** (⚠️ **the actual state of most large enterprises**,\nwhatever the strategy deck says), **multi-cloud** (§12 → `cloud-migration-sovereignty-and-ai-workloads`), and **edge**. **Sovereign cloud**\nis now a distinct category with regulatory meaning rather than a marketing label (§11 → `cloud-migration-sovereignty-and-ai-workloads`).\n\n### 1.3 The five NIST characteristics\nOn-demand self-service, broad network access, resource pooling, rapid elasticity,\nmeasured service. **[DURABLE] Dated 2011 and still the cleanest definition** — and\n\"measured service\" is the one that quietly determines your architecture (§7 → `cloud-cost-security-and-operations`).\n\n---\n\n## §2. The Provider Landscape\n\n**[VERSIONED — and read the ⚠️ in this section before quoting any number.]**\n\n**Market structure as of Q1 2026**: the Big Three hold roughly **60–68%** of global cloud\ninfrastructure spend, with the market reaching **~$129B in Q1 2026, growing ~35% YoY** —\ndescribed as the **ninth consecutive quarter of increasing year-over-year growth**.\n\n> **⚠️ GOTCHA — the share figures genuinely conflict across sources, and you should know\n> why before citing them.** Synergy Research puts Q1 2026 at **AWS 28%, Azure 21%, Google\n> Cloud 14%**. Other widely-circulated figures give **AWS 30% \u002F Azure 24–25% \u002F GCP 13%**,\n> and others still **AWS 32% \u002F Azure 23% \u002F GCP 11%**.\n>\n> **The discrepancy is methodological, not an error.** One analysis explains it directly:\n> Azure's higher share estimates **exceed a straight revenue calculation because Synergy\n> weights IaaS-and-PaaS spend, where Azure is stronger** — and separately, **Microsoft\n> does not break out Azure revenue at all, only its growth rate**, so any \"Azure revenue\"\n> figure is derived. **Both kinds of figure are valid; they measure different scopes.**\n> **Cite the source and the scope, or don't cite the number.**\n\n**Growth is the more interesting story than share**: Azure and Google Cloud have been\ngrowing substantially faster off smaller bases, with Google Cloud posting the highest rates\nof the three. **AI is the driver** — AI-related spending was reported at **~19% of total\ncloud spend in 2026, up from ~8% in 2023.**\n\n**⚠️ The capex arms race is the structural fact underneath all of it.** 2026 guidance\nfigures in circulation: **Amazon ~$200B, Microsoft ~$190B, Alphabet ~$180–190B.** This\nfunctions as a moat — the cost of building global infrastructure excludes almost everyone\n— and it carries genuine risk: **the Big Three are betting hundreds of billions that AI\ndemand will justify the build-out, and if it disappoints the write-downs would be\nenormous.** For a buyer, large capex commitments are **both a supply signal and a\nlock-in signal.**\n\n**Choosing** — the honest criteria, roughly in order: **existing skills and contracts**\n(⚠️ **usually decisive and rarely stated**), **the specific services you need**,\n**regional and data-residency footprint** (§11 → `cloud-migration-sovereignty-and-ai-workloads`), **pricing for your actual shape of\nworkload**, **enterprise agreements and discounts**, and **regulatory posture**.\n**Beyond the Big Three**: Oracle Cloud, IBM, Alibaba, and the **\"neoclouds\"** — GPU-focused\nproviders (CoreWeave, Lambda and others) estimated collectively at a small but real share\nsegment. **Cloudflare, Fastly, Vercel, Fly.io** for edge; **DigitalOcean, Hetzner,\nScaleway** for straightforward compute at markedly lower prices.\n\n---\n\n## §3. The Primitives\n\n**[DURABLE] Every provider has these under different names. Learn the primitive, map the\nname.**\n\n**Compute**: VMs (⚠️ **still the majority of cloud spend**), containers (§5 → `cloud-architecture-and-resilience`), serverless\nfunctions, GPU\u002Faccelerator instances (§13 → `cloud-migration-sovereignty-and-ai-workloads`), bare metal. **Pricing modes matter more than\ninstance choice**: on-demand, reserved\u002Fcommitted (1–3 year, **large discounts**), savings\nplans, **spot\u002Fpreemptible** (⚠️ **60–90% cheaper and interruptible — enormously underused\nfor batch, CI, and fault-tolerant work**), dedicated hosts.\n\n**Storage**, and **⚠️ picking the wrong class is one of the most common cost errors**:\n\n| Type | Use | ⚠️ Watch |\n|---|---|---|\n| **Object** (S3, Blob, GCS) | The default for almost everything: static assets, data lakes, backups | Request costs at high volume; egress (§11 → `cloud-migration-sovereignty-and-ai-workloads`) |\n| **Block** (EBS, Managed Disks) | Filesystem for a VM | ⚠️ **Provisioned, not consumed — you pay for the size you asked for, idle or not** |\n| **File** (EFS, Azure Files) | Shared POSIX access | Expensive per GB |\n| **Archive** (Glacier, Archive tier) | Long-term retention | ⚠️ **Retrieval time and retrieval cost — and early-deletion fees** |\n\n**⚠️ Lifecycle policies are free money and routinely unconfigured.** Object storage tiering\nfrom hot → cool → archive on an age rule takes minutes to set and runs forever.\n\n**Networking**: VPC\u002FVNet, subnets, security groups\u002FNSGs, load balancers (L4 and L7),\nDNS, CDN, private endpoints, peering, transit gateway\u002Fhub-spoke, NAT gateways\n(⚠️ **a surprisingly large and invisible line item at volume**).\n\n**Identity** — **[DURABLE] the most important primitive and the most commonly\nmisconfigured** (§8 → `cloud-cost-security-and-operations`): workload identity (⚠️ **use it — long-lived access keys are the\nsingle most common cloud breach vector**), roles and policies, federation, and\n**least privilege as an actual practice rather than an aspiration**.\n\n**Managed data services**: relational, NoSQL, cache, search, queues and streams, data\nwarehouse. **⚠️ Each is a lock-in decision as well as an architecture decision** (§12 → `cloud-migration-sovereignty-and-ai-workloads`).\n",{"name":5,"description":7},"develop","ae32736a1aabddabca5d2c96d665aa0ebc7d8700","src\u002Fvibey_tools\u002Fskills\u002Fplugins\u002Fcloud-computing\u002Fskills\u002Fcloud-models-providers-and-primitives",3,"https:\u002F\u002Fgithub.com\u002Fthe-vibey-project\u002Fvibey","https:\u002F\u002Fthe-vibey-project.github.io\u002Fvibey\u002F","https:\u002F\u002Fgithub.com\u002Fthe-vibey-project","https:\u002F\u002Fvibewithadam.matthewsteinberger.com","freedom for software engineers","2026-11-15 05:47:42",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add the-vibey-project\u002Fvibey --skill cloud-models-providers-and-primitives",{"tool":40,"command":41},"bunx","bunx skills add the-vibey-project\u002Fvibey --skill cloud-models-providers-and-primitives",{"tool":43,"command":44},"pnpm","pnpm dlx skills add the-vibey-project\u002Fvibey --skill cloud-models-providers-and-primitives","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fthe-vibey-project\u002Fvibey\u002Fblob\u002Fdevelop\u002Fsrc\u002Fvibey_tools\u002Fskills\u002Fplugins\u002Fcloud-computing\u002Fskills\u002Fcloud-models-providers-and-primitives\u002FSKILL.md",true,[],[49,56,63,70,77,84],{"skillNo":50,"name":51,"nameZh":6,"description":52,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":53,"categories":54,"keywords":55,"publishedAt":19},"01M7AT1FQJAE1FQYAMDTF490Y4","white-paper-writing","Use when writing white papers, technical reports, policy documents, thought leadership pieces, or any long-form authoritative document. Triggers on requests to write, structure, outline, or review white papers, technical reports, position papers, policy briefs, or evidence-driven arguments. Also use for B2B content marketing strategy, technical documentation requiring authority, academic-style reports, or any document that must educate while persuading. Use when someone asks \"how should I structure this\" for a long-form document.","https:\u002F\u002Fgithub.com\u002Fthe-vibey-project\u002Fvibey\u002Fblob\u002Fdevelop\u002Fsrc\u002Fvibey_tools\u002Fskills\u002Fplugins\u002Fwriting-craft\u002Fskills\u002Fwhite-paper-writing\u002FSKILL.md",[],[],{"skillNo":57,"name":58,"nameZh":6,"description":59,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":60,"categories":61,"keywords":62,"publishedAt":19},"01M7AT16BJRJJKK2MASXRZS76G","prose-technical-mechanics","Use when editing or writing prose at a technical\u002Fmechanical level: choosing between Anglo-Saxon and Latinate diction, placing information in topic vs stress positions, writing periodic vs cumulative sentences, handling sentence rhythm, punctuation as logic, transitions, paragraph structure, or phonesthetics. Use when someone wants to understand WHY prose works or doesn't, not just surface-level style advice. Triggers on word choice, sentence structure, emphasis, rhythm, diction, or any deep writing mechanics question.","https:\u002F\u002Fgithub.com\u002Fthe-vibey-project\u002Fvibey\u002Fblob\u002Fdevelop\u002Fsrc\u002Fvibey_tools\u002Fskills\u002Fplugins\u002Fwriting-craft\u002Fskills\u002Fprose-technical-mechanics\u002FSKILL.md",[],[],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":19},"01M7AT0W9HT0ZZ9Y287NW99MR3","prose-mechanics","Use when writing, editing, or analyzing prose style; when trying to avoid generic AI-sounding writing; when applying specific prose styles such as journalistic, academic, narrative, KJV biblical, Hemingway plain, Latinate\u002FJamesian, Orwellian, Augustan, Victorian, Early Modern (Bacon, Browne, Milton), or free indirect discourse; or when coaching someone on writing voice and mechanics. Triggers on any request to improve, analyze, or write in a specific prose style, to fix \"AI-sounding\" writing, to make prose more vivid or concrete, to vary sentence rhythm, or to understand how a particular writer achieves their effects.","https:\u002F\u002Fgithub.com\u002Fthe-vibey-project\u002Fvibey\u002Fblob\u002Fdevelop\u002Fsrc\u002Fvibey_tools\u002Fskills\u002Fplugins\u002Fwriting-craft\u002Fskills\u002Fprose-mechanics\u002FSKILL.md",[],[],{"skillNo":71,"name":72,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":19},"01M7AT0KR635JX66X2X6F3E2CP","narrative-structure","Use when structuring stories, pitches, presentations, white papers, or any persuasive narrative; analyzing the hero's journey in fiction or non-fiction; applying StoryBrand for business communication; designing narrative arcs for thought leadership; or understanding Vogler, Snyder, Propp, or Campbell frameworks. Triggers on any narrative structure, storytelling, pitch structure, StoryBrand, hero's journey, three-act structure, Freytag, Save the Cat, narrative arc, or \"how should I structure this story\u002Fpitch\u002Fpresentation\" request.","https:\u002F\u002Fgithub.com\u002Fthe-vibey-project\u002Fvibey\u002Fblob\u002Fdevelop\u002Fsrc\u002Fvibey_tools\u002Fskills\u002Fplugins\u002Fwriting-craft\u002Fskills\u002Fnarrative-structure\u002FSKILL.md",[],[],{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":19},"01M7AT0AKGW09NKKZDYBT8VRDE","legal-brief-writing","Use when writing legal briefs, motions, or any court filing; when analyzing judicial cognition and persuasion; when applying elite brief-writing techniques from Roberts, Clement, Kagan, Garner; or when structuring legal arguments for maximum persuasion. Also use for autistic\u002Fneurodivergent advocates who need to understand how their natural communication style maps to elite legal advocacy. Triggers on any legal writing, brief drafting, motion preparation, or legal argument structuring request.","https:\u002F\u002Fgithub.com\u002Fthe-vibey-project\u002Fvibey\u002Fblob\u002Fdevelop\u002Fsrc\u002Fvibey_tools\u002Fskills\u002Fplugins\u002Fwriting-craft\u002Fskills\u002Flegal-brief-writing\u002FSKILL.md",[],[],{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":19},"01M7AT00VWPS4Q8B5VEMXX9NQT","journal-publishability-criteria","Use whenever a research paper, article or preprint is being written, revised, reviewed or published, and specifically before every publication of docs\u002Fpaper.md. Covers what legitimate journals actually gate on, in order of gating — the editor's desk screen (scope, novelty, package problems), what reviewers judge (methodological soundness, claims the evidence can carry, statistical and qualitative reporting), EQUATOR reporting guidelines, the ICMJE authorship criteria, COPE's view of text recycling, the near-universal generative-AI policy (no AI author, disclosure, author responsibility), TOP 2025 transparency standards, how to verify a journal is legitimate, submitting without an institution, and a pre-submission checklist. Triggers on requests to evaluate, review, prepare or submit a paper, to judge publishability, to write a declarations or data-availability section, to disclose AI use, or to check a journal.","https:\u002F\u002Fgithub.com\u002Fthe-vibey-project\u002Fvibey\u002Fblob\u002Fdevelop\u002Fsrc\u002Fvibey_tools\u002Fskills\u002Fplugins\u002Fwriting-craft\u002Fskills\u002Fjournal-publishability-criteria\u002FSKILL.md",[],[]]