opencode-skills-collection 4.1.0 → 4.1.2

package/bundled-skills/observability-cloud-planning/SKILL.md

@@ -0,0 +1,487 @@
+---
+name: observability-cloud-planning
+description: 'Build a cloud, SLO, and incident-readiness register after intake. Use when an SME needs monitoring scope, alert ownership, cost limits, or service planning.'
+category: engineering
+risk: safe
+source: self
+source_type: self
+date_added: "2026-09-27"
+author: WHOISABHISHEKADHIKARI
+tags: [sme, observability, monitoring, slo, sli, alerting, cloud-cost, uptime, incident, reliability, csv, sql, notion]
+tools: []
+source_repo: WHOISABHISHEKADHIKARI/sme-ops-system-builder
+---
+
+# Cloud and Observability Planning
+
+**What it is:** the plan for what the business runs on, what it watches, what wakes
+someone up, and what that costs - written before any of it is bought.
+
+## Overview
+
+Works out the smallest monitoring plan that would actually catch this business's worst
+failure, then builds it only when asked. The default output is a short recommendation, not
+a service register. The register - CSV, SQL DDL, JSON Schema, Notion mapping - is produced
+on request, from one field list so the four cannot drift apart.
+
+Layer: Layer 8: Operate. Fits: Growth stage. Table code: n/a.
+
+**The rule this table exists to enforce:** an alert is a human cost, so `Alert Channel` and
+`Severity` decide whether a person is woken at 3am. Everything else in this table exists to
+make that decision possible: what the service does (`SLI Definition`), what good looks like
+(`SLO Target`), what is measured (`Dashboard URL`), what it costs (`Monthly Cost Estimate`),
+and - the field most tables leave out - what happens when the alert fires (`Runbook URL`).
+An alert with no runbook converts a technical problem into a panicked one.
+
+**The second rule:** `Phase` is the field that keeps this affordable. A ten-service stack
+with four signals each, on a plan tier, ordered by what would hurt the business most. A
+business with no developer should be running a managed platform and three alerts, not a
+stack of collectors.
+
+## When to Use This Skill
+
+- monitoring, observability, alerting, uptime, "we found out from a customer"
+- SLI, SLO, error rate, latency, p95, p99
+- "what should we watch", "how do we know the site is down"
+- incident response, on-call, runbook, postmortem
+- cloud cost, what is it costing, what should we turn off
+- "which service should we use", VPS, containers, serverless, managed hosting
+- incident readiness, status page, downtime prevention
+
+Do not use it for: application code, infrastructure as code, or a deployment pipeline
+(`devops-pipeline-designer`, `ci-cd-pipeline-builder` in the engineering pack); a security
+architecture review (`security-and-privacy`); or a real incident, which is a live
+situation, not a plan.
+
+## How It Works
+
+Follow the shared execution contract. The module-specific rules below define only domain fields, decisions, calculations, and safety constraints.
+
+### Step 1 - Identify intent
+
+Read the request and pick the intent before asking anything.
+
+- "plan" / "set up" / "we need" -> artifacts wanted; go to Step 2.
+- "the site is down" / "is it down" / "we are down" -> an incident, right now. Confirm the
+  user-facing failure first and point at the runbook; do not build anything.
+- "what does this cost" / "review" / "audit" -> a review, not a build.
+- "should we use" -> a decision question; answer with trade-offs, then offer the register.
+
+Ask only if this is the highest-value missing fact; otherwise proceed without an opener:
+
+> **Q:** What breaks for the business if the site or app is down for one hour, and who
+> would notice first - a customer, a member of staff, or an automated system?
+
+### Step 2 - Ask only what is missing
+
+Treat ambiguous replies as unanswered and ask which explicit option the user means. Record unknown values as `Unknown`; `Unknown` is not zero. A record must not be `Done` when a required check fails.
+
+Skip anything already answered. Ask the rest one at a time, and stop as soon as the
+remaining answers would not change the plan.
+
+- **Failure** - What is the business-critical thing - the website, the booking form, the
+  till, email, the file uploads? / What is the worst realistic failure - down, slow, wrong
+  data, or an email that silently stops arriving? / How long is a customer willing to wait
+  before they complain, and how long before they leave?
+- **Stack** - What is actually running today - shared hosting, a VPS, a managed platform, a
+  SaaS tool, containers? / Who set it up, and is that person still available? / Is there a
+  repository, and who can deploy?
+- **Traffic** - Roughly how many visitors, orders or jobs a day? / Any seasonal or campaign
+  peaks that change it by an order of magnitude? / Are there peak periods where being slow
+  is worse than being down?
+- **People** - Is there anyone who can be on call, and at what hours? / Does someone already
+  use a tool the business pays for? / Who is allowed to restart something at 3am?
+- **Data and money** - What must not be lost, and what is the acceptable recovery point? /
+  What is the current monthly spend, roughly, and the budget ceiling? / Does anything
+  process a payment, personal data, or health data?
+
+Never invent an answer. Traffic numbers, costs, hostnames, provider names, service
+identifiers, error rates, uptime figures and recovery times the user has not supplied are
+`Unknown`. A monitoring plan built on invented traffic or invented spend is worthless, and
+invented SLOs are worse - they create an alert nobody can satisfy.
+
+### Step 3 - Hold the internal context
+
+```yaml
+module: observability-cloud-planning
+intent: null            # set up | review | report | import
+scale: null             # Starter | Growth | Scale, only if the answer changes it
+areas:
+  "Failure": null
+  "Stack": null
+  "Traffic": null
+  "People": null
+  "Data and money": null
+requested_outputs: []
+confirmed_facts: []
+open_questions: []
+```
+
+### Step 4 - Recommend the smallest workflow
+
+Build an already requested artifact without asking again. For advice-only requests, give a short recommendation and offer the relevant artifact.
+
+**Recommended approach:** Start with the one thing whose failure stops the business earning -
+usually the checkout or the booking form - and watch exactly that from outside the
+infrastructure, so the check does not fail with the thing it is checking. Three signals and
+no more: is it reachable, is it answering within a target time, and is the thing that
+transacts money or data actually succeeding. One alert channel that reaches a human, a
+runbook for each alert, and a named owner. Everything else - traces, log aggregation, five
+custom dashboards, a status page - goes in a later phase once the first phase has proven
+someone reads it.
+
+**Why this one:** The failure mode of observability is not too little monitoring, it is too
+much of the wrong. A business that installs fifteen alerts stops reading them within a
+week and returns to finding out from customers. And external monitoring matters more than
+internal: an uptime check that runs on the same box as the site reports the site is fine
+right up to the moment it is not.
+
+**Workflow:** Worst failure named → What must be measured to catch it, from outside →
+Baseline measured, not assumed → Three signals defined with targets → Alerts with a channel
+and a runbook each → Costs estimated against a ceiling → Owner and review date set →
+Runbook rehearsed → Phase 2 only after phase 1 is being read → Quarterly review of alerts
+kept, deleted and added
+
+### Step 5 - Build only on request
+
+Once the user asks for it, derive the fields from the confirmed context and emit the
+requested artifacts. For machine-readable text, keep prose outside the data; for files,
+provide a usable link. Report material validation failures or limitations separately.
+
+**A selected Notion output is rendered by `notion-manual-import`, so route the
+Notion step there.** When the user selects Notion, hand that step to
+](https://github.com/sickn33/agentic-awesome-skills/blob/main/skills/notion-manual-import/SKILL.md): it holds the CSV, the property
+mapping, the import steps and the verification checklist, and it renders the Field
+Reference below instead of defining a table of its own. Do not restate the mapping
+here and do not improvise the import steps. Manual CSV and mapping outputs need no
+connection. For requested workspace changes, follow the shared contract: verify actual
+tool access and the target before writing. A user saying "connected" is not tool evidence.
+Never ask for a Notion password or token.
+
+```csv
+Service ID,Service Name,Purpose,Criticality,Owner,Environment,Monitored From,SLI Definition,SLO Target,Dashboard URL,Log Source,Alert Channel,Severity,Alert Threshold,Runbook URL,Escalation Path,Monthly Cost Estimate,Data Handled,Deployment Method,Dependencies,Phase,Review Date,Status,Notes
+,Example Booking Service,Takes customer bookings and confirms by email,High,Example Owner,Production,External region outside the hosting provider,Uptime of the public booking page,99.5% monthly,Not yet created,Application and web server logs,Email and SMS to on-call,Critical,3 consecutive failed checks or 5 minutes above target,Not yet created,On-call then business owner,Unknown,Payment card details,Managed platform,None,1,2026-10-27,Not started,Example row - replace every value before use.
+```
+
+```sql
+-- Engine assumption: PostgreSQL. For another engine use the engine's auto-increment
+-- equivalent and keep the rest portable.
+CREATE TABLE obs_service (
+  service_id BIGINT PRIMARY KEY,
+  service_name VARCHAR(100) NOT NULL,
+  purpose TEXT NOT NULL,
+  criticality VARCHAR(50) NOT NULL,
+  owner VARCHAR(255) NOT NULL,
+  environment VARCHAR(50) NOT NULL,
+  monitored_from VARCHAR(100) NOT NULL,
+  sli_definition TEXT NOT NULL,
+  slo_target VARCHAR(50) NOT NULL,
+  dashboard_url VARCHAR(255),
+  log_source VARCHAR(255) NOT NULL,
+  alert_channel VARCHAR(255) NOT NULL,
+  severity VARCHAR(50) NOT NULL,
+  alert_threshold VARCHAR(255) NOT NULL,
+  runbook_url VARCHAR(255),
+  escalation_path TEXT,
+  monthly_cost_estimate NUMERIC(10,2),
+  data_handled VARCHAR(255) NOT NULL,
+  deployment_method VARCHAR(100) NOT NULL,
+  dependencies TEXT,
+  phase VARCHAR(50) NOT NULL,
+  review_date DATE,
+  status VARCHAR(50) NOT NULL,
+  notes TEXT,
+  created_at TIMESTAMP DEFAULT NOW(),
+  updated_at TIMESTAMP DEFAULT NOW(),
+  CONSTRAINT obs_service_phase CHECK (phase IN ('1 - core','2 - deepen','3 - optional','Sunset')),
+  CONSTRAINT obs_service_status CHECK (status IN ('Not started','In progress','Blocked','Done','Cancelled')),
+  CONSTRAINT obs_service_severity CHECK (severity IN ('Info','Warning','Critical')),
+  CONSTRAINT obs_service_criticality CHECK (criticality IN ('Low','Medium','High','Critical')),
+  CONSTRAINT obs_service_cost_non_negative CHECK (monthly_cost_estimate IS NULL OR monthly_cost_estimate >= 0)
+);
+
+CREATE INDEX idx_obs_service_status ON obs_service (status);
+CREATE INDEX idx_obs_service_phase ON obs_service (phase);
+CREATE INDEX idx_obs_service_review ON obs_service (review_date);
+```
+
+```json
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "title": "Cloud and Observability Plan",
+  "type": "object",
+  "additionalProperties": false,
+  "properties": {
+      "Service ID": { "type": "integer" },
+      "Service Name": { "type": "string" },
+      "Purpose": { "type": "string" },
+      "Criticality": { "type": "string" },
+      "Owner": { "type": "string" },
+      "Environment": { "type": "string" },
+      "Monitored From": { "type": "string" },
+      "SLI Definition": { "type": "string" },
+      "SLO Target": { "type": "string" },
+      "Dashboard URL": { "type": "string" },
+      "Log Source": { "type": "string" },
+      "Alert Channel": { "type": "string" },
+      "Severity": { "type": "string" },
+      "Alert Threshold": { "type": "string" },
+      "Runbook URL": { "type": "string" },
+      "Escalation Path": { "type": "string" },
+      "Monthly Cost Estimate": { "type": "number" },
+      "Data Handled": { "type": "string" },
+      "Deployment Method": { "type": "string" },
+      "Dependencies": { "type": "string" },
+      "Phase": { "type": "string" },
+      "Review Date": { "type": "string", "format": "date" },
+      "Status": { "type": "string" },
+      "Notes": { "type": "string" }
+  },
+  "required": [
+      "Service Name",
+      "Purpose",
+      "Criticality",
+      "Owner",
+      "Environment",
+      "Monitored From",
+      "SLI Definition",
+      "SLO Target",
+      "Log Source",
+      "Alert Channel",
+      "Severity",
+      "Alert Threshold",
+      "Data Handled",
+      "Deployment Method",
+      "Phase",
+      "Status"
+  ]
+}
+```
+
+```markdown
+| CSV column | Notion property | Set after import |
+|---|---|---|
+| Service ID | Text (preserve source ID) | Keep imported IDs as Text; optionally add a separate Unique ID property |
+| Service Name | Title | Use as the database title |
+| Purpose | Text | Leave as Text. What the business loses if this stops. Not a technical description |
+| Criticality | Select (add options after import) | Convert to Select, add options: "Low", "Medium", "High", "Critical". Critical means the business stops earning |
+| Owner | Text | Leave as Text. A named person. A service with no owner is unmonitored in practice |
+| Environment | Select (add options after import) | Convert to Select, add options: "Production", "Staging", "Development". Monitoring a staging URL and calling it uptime is a common and expensive mistake |
+| Monitored From | Text | Leave as Text. Where the check runs. It must not run on the thing it is checking |
+| SLI Definition | Text | Leave as Text. The measurement in plain words - "public booking page answers in under 2 seconds for 95% of requests" |
+| SLO Target | Text | Leave as Text. The number and the window, e.g. "99.5% monthly". A target nobody has ever met is a target that gets deleted |
+| Dashboard URL | Text | Leave as Text. Blank until a dashboard exists, which is the correct state in phase 1 |
+| Log Source | Text | Leave as Text. Where the logs are today, including "none - not collected" |
+| Alert Channel | Text | Leave as Text. The specific route: which email, which SMS, which app. "Alerts" is not a channel |
+| Severity | Select (add options after import) | Convert to Select, add options: "Info", "Warning", "Critical". Only Critical should page a human outside working hours |
+| Alert Threshold | Text | Leave as Text. The condition that fires, written so it is unambiguous and testable |
+| Runbook URL | Text | Leave as Text. Blank is a finding, not a formatting gap. An alert with no runbook must not ship |
+| Escalation Path | Text | Leave as Text. Who is woken first, then who, then who gives up and calls the host |
+| Monthly Cost Estimate | Number | Convert to Number, two decimal places. An estimate against a ceiling, in the business's own currency |
+| Data Handled | Select (add options after import) | Convert to Select, add options: "None", "Personal data", "Payment card details", "Health data", "Credentials or secrets", "Business confidential", "Public only". Drives the log retention and access rules |
+| Deployment Method | Text | Leave as Text. How a change reaches this service, and by whom |
+| Dependencies | Text | Leave as Text. What this needs to work. "None" is a valid and worth recording answer |
+| Phase | Select (add options after import) | Convert to Select, add options: "1 - core", "2 - deepen", "3 - optional", "Sunset". The affordability control |
+| Review Date | Date | Convert to Date. When the alerts, the target and the cost are re-examined |
+| Status | Select (add options after import) | Convert to Select, add options: "Not started", "In progress", "Blocked", "Done", "Cancelled" |
+| Notes | Text | Leave as Text |
+```
+
+The rows above are documentation examples only. Emit empty templates unless the user explicitly requests examples. `Dashboard URL` and `Runbook URL` read `Not yet
+created` rather than a plausible-looking link, because a dead or wrong link in a runbook
+column is worse than an obvious gap.
+
+## Field Reference
+
+| # | Field | Type | SQL | JSON Schema | Notion | CSV example |
+|---:|---|---|---|---|---|---|
+| 1 | Service ID | `id` | `BIGINT PRIMARY KEY` | `integer` | Text or Notion auto-ID | (blank) |
+| 2 | Service Name | `text` | `VARCHAR(100)` | `string` | Text | *(blank)* |
+| 3 | Purpose | `long_text` | `TEXT` | `string` | Text | *(blank)* |
+| 4 | Criticality | `select` | `VARCHAR(50)` | `string` | Select | High |
+| 5 | Owner | `text` | `VARCHAR(255)` | `string` | Text | *(blank)* |
+| 6 | Environment | `select` | `VARCHAR(50)` | `string` | Select | Production |
+| 7 | Monitored From | `text` | `VARCHAR(100)` | `string` | Text | *(blank)* |
+| 8 | SLI Definition | `long_text` | `TEXT` | `string` | Text | *(blank)* |
+| 9 | SLO Target | `text` | `VARCHAR(50)` | `string` | Text | 99.5% monthly |
+| 10 | Dashboard URL | `text` | `VARCHAR(255)` | `string` | Text | *(blank)* |
+| 11 | Log Source | `text` | `VARCHAR(255)` | `string` | Text | *(blank)* |
+| 12 | Alert Channel | `text` | `VARCHAR(255)` | `string` | Text | *(blank)* |
+| 13 | Severity | `select` | `VARCHAR(50)` | `string` | Select | Critical |
+| 14 | Alert Threshold | `text` | `VARCHAR(255)` | `string` | Text | *(blank)* |
+| 15 | Runbook URL | `text` | `VARCHAR(255)` | `string` | Text | *(blank)* |
+| 16 | Escalation Path | `long_text` | `TEXT` | `string` | Text | *(blank)* |
+| 17 | Monthly Cost Estimate | `number` | `NUMERIC(10,2)` | `number` | Number | Unknown |
+| 18 | Data Handled | `select` | `VARCHAR(255)` | `string` | Select | Personal data |
+| 19 | Deployment Method | `text` | `VARCHAR(100)` | `string` | Text | *(blank)* |
+| 20 | Dependencies | `long_text` | `TEXT` | `string` | Text | None |
+| 21 | Phase | `select` | `VARCHAR(50)` | `string` | Select | 1 - core |
+| 22 | Review Date | `date` | `DATE` | `string, format: date` | Date | *(blank)* |
+| 23 | Status | `select` | `VARCHAR(50)` | `string` | Select | Not started |
+| 24 | Notes | `long_text` | `TEXT` | `string` | Text | *(blank)* |
+
+## Select Options
+
+**Criticality** - what the business loses. `Critical` means the business stops earning, not
+that the service is technically important. A search index that goes down is `Low`; a
+checkout that goes down is `Critical`.
+
+```
+Low | Medium | High | Critical
+```
+
+**Environment** - and the mistake this prevents: monitoring a staging URL and reporting it
+as uptime. Production is the only environment that earns an alert.
+
+```
+Production | Staging | Development
+```
+
+**Severity** - the difference between a notification and a woken person. Only `Critical`
+should reach a human outside working hours, because a `Warning` that pages at 3am trains
+the on-call to ignore the channel.
+
+```
+Info | Warning | Critical
+```
+
+**Data Handled** - this is not documentation, it is an instruction. `Payment card details`,
+`Health data` and `Credentials or secrets` change the log retention period, who may read
+the logs, and whether the logs may be shipped to a third-party service at all.
+
+```
+None | Personal data | Payment card details | Health data | Credentials or secrets | Business confidential | Public only
+```
+
+**Phase** - the field that keeps this affordable. Phase 1 is what catches the worst failure
+and is read. Nothing enters phase 2 until phase 1 is being read and acted on; a plan that
+ships all phases at once is a plan nobody maintains.
+
+```
+1 - core | 2 - deepen | 3 - optional | Sunset
+```
+
+**Status** - `Blocked` is the honest value whenever something depends on a person, a
+contract or a decision that has not happened.
+
+```
+Not started | In progress | Blocked | Done | Cancelled
+```
+
+## Relations
+
+- `Dependencies` names other rows in this table. A cycle here is a design smell, not an
+  error, and it is worth finding deliberately.
+- `Log Source` and `Data Handled` point at the data and access rules in
+  `data-privacy-controls` (`me-ops-system-builder`). Confirm the join before making it
+  live; a third-party log destination is a data transfer.
+- `Runbook URL` points at `runbook-playbook` in the engineering pack. Blank there and blank
+  here is the same finding.
+
+## Examples
+
+**Prompt**
+
+```
+We run a booking site on a VPS. Last month it was down for a whole Sunday and we only
+found out on Monday from a customer. We want to know if it goes down, and we do not know
+what we should be paying for all this.
+```
+
+**Context first** - one question per message, nothing already answered:
+
+> **Q:** What breaks for the business if the site or app is down for one hour, and who
+> would notice first - a customer, a member of staff, or an automated system?
+> **A:** The booking form. A customer, obviously.
+>
+> **Q:** What is actually running today, and who set it up?
+> **A:** A VPS with the site on it, set up by an agency we no longer deal with.
+>
+> **Q:** Roughly how many visitors or bookings a day?
+> **A:** Maybe 20 bookings. It is much busier in December.
+>
+> **Q:** Is there anyone who could be on call, and at what hours?
+> **A:** Me, evenings and weekends.
+>
+> **Q:** What is the current monthly spend, roughly, and the ceiling?
+> **A:** Forty a month for the server. I would not want to spend much more than that.
+
+**Recommended next step** - offered, not built:
+
+> One external uptime check on the booking page, run from outside your provider, plus a
+> check that a test booking actually completes. That catches the Sunday problem. Two
+> alerts, both to your phone: the page unreachable for three checks running, and a test
+> booking that fails. No dashboard, no log shipping, no tracing - the site does not earn
+> that yet. A one-page runbook for each: what to check, how to restart it, and the agency
+> number if it does not come back. December is your peak, so test it properly in November.
+> Keep it near 40 a month, or you will pay more for storage than you do for the server.
+>
+> Workflow: Worst failure named → What must be measured, from outside → Baseline measured
+> → Three signals with targets → Alerts with a channel and a runbook each → Costs
+> estimated → Owner and review date set → Runbook rehearsed → Phase 2 only if phase 1 is
+> being read
+>
+> Want the CSV, SQL DDL, JSON Schema and Notion mapping for this?
+
+## Best Practices
+
+- Build when requested; recommend and offer a build for advice-only requests.
+- One question per message. A batched intake reads as a form and gets guessed at.
+- Monitor from outside the thing you are monitoring. A check on the same host as the site
+  reports the site healthy right up to the moment it is not.
+- Monitor the transaction, not the server. A server can return 200 while the checkout throws
+  an exception on every attempt, and no amount of CPU monitoring catches that.
+- Measure the baseline before setting the target. An SLO set above what the system has ever
+  done is a target that guarantees a permanently firing alert.
+- Three signals to start. Reachability, latency, and the business transaction. Resist the
+  fourth until the first three are read.
+- Only `Critical` pages a human. Everything else is a notification for working hours, or it
+  is deleted. Alert fatigue is the normal end state of an unmaintained alerting setup.
+- No alert without a runbook. Blank `Runbook URL` is a finding that blocks going live.
+- Set the alert threshold in advance and test it. An alert that has never fired is an
+  untested assumption.
+- Track cost against a ceiling the business named. A plan with no ceiling becomes an
+  invoice nobody predicted.
+- Name an owner per service. A service with no owner is unmonitored in practice, whatever
+  the dashboards say.
+- Set a review date and honour it. Every quarter, ask of each alert: did a human act on
+  this? If not, delete it.
+- Never log secrets, tokens, full card numbers, or unnecessary personal data. `Data
+  Handled` exists to make that decision explicit before the logs are shipped anywhere.
+- If logs go to a third-party service, that is a data transfer with its own agreement.
+  Confirm it rather than assuming it is fine.
+- Keep phase 1 small enough to maintain. An unmaintained 40-service plan is worse than a
+  maintained three-service one.
+- Derive all four artifacts from the field list in this file, never by hand.
+- If the user requests an example row, keep it obviously fake so nobody imports it as a real service.
+
+## Limitations
+
+- This is a plan. It does not deploy anything, install an agent, open a dashboard, create an
+  alert or read a log.
+- It has no access to the business's infrastructure, so it cannot measure a baseline, read a
+  metric, or verify an SLO. Every value in this table comes from the user.
+- Costs are estimates by definition and depend on region, tier, retention and traffic that
+  this skill cannot see. Treat `Monthly Cost Estimate` as a planning figure, never as a
+  quote, and never as a provider price list.
+- It does not recommend a specific provider on a current price. Provider capabilities,
+  pricing and free tiers change; verify against the provider's own current documentation.
+- Log volume, cardinality and ingestion cost are the usual cause of an unexpected bill, and
+  they cannot be estimated here without real traffic.
+- It cannot tell you what is currently running, what is currently alerting, or whether the
+  current setup already covers the worst failure. That needs access.
+- Uptime, latency and error-rate targets are engineering commitments. They are not
+  business promises, and a target that is missed is a trigger for a decision, not a
+  contractual breach.
+- SLOs do not replace a backup, a restore test, or a disaster recovery plan. A monitored
+  service with no tested restore is still a lost database.
+- Compliance requirements around logging, retention and personal data are jurisdiction and
+  sector specific, and are not modelled here.
+- Security monitoring, intrusion detection and access review are out of scope; use
+  `security-and-privacy`.
+- It cannot judge whether a provider, region or architecture is right. It structures the
+  question.
+
+
+See the [Security & Safety Notes](references/security-safety-notes.md) reference for the full guidance.
+

package/bundled-skills/observability-cloud-planning/references/common-pitfalls.md

@@ -0,0 +1,39 @@
+# Common Pitfalls
+
+- **Problem:** a static mapping is described as a completed workspace build.
+  **Solution:** deliver manual mappings without a connection; claim a live change only
+  after the authorized tool operation succeeds.
+- **Problem:** asked all five questions in one message.
+  **Solution:** ask one, wait, and drop any the first answer already covered.
+- **Problem:** an uptime check running on the same server as the site.
+  **Solution:** monitor from outside, ideally from a different provider or region. A
+  self-hosted check cannot observe its own failure.
+- **Problem:** monitoring the server, not the booking.
+  **Solution:** add a synthetic check that completes a real transaction end to end. That is
+  the signal that matches the business loss.
+- **Problem:** twenty alerts, none read.
+  **Solution:** three signals, `Critical` only for waking someone, and a quarterly review
+  that deletes anything no human acted on. Alert fatigue is not a tooling problem.
+- **Problem:** an SLO of 99.99% on a business that has never measured above 98%.
+  **Solution:** measure the baseline, then set a target you can hold. A permanently firing
+  alert is a target that has already failed.
+- **Problem:** an alert with no runbook, discovered at 3am.
+  **Solution:** blank `Runbook URL` blocks going live. Write the runbook first, and rehearse
+  it while the site is up.
+- **Problem:** the whole stack arrived at once and nothing is maintained after month two.
+  **Solution:** phase it. Phase 2 only when phase 1 is being read and acted on.
+- **Problem:** logs shipped to a third party, including personal data and card fragments.
+  **Solution:** decide what may leave the business before the agent is installed, not after.
+  Scrub at source.
+- **Problem:** December arrived and the plan had never been tested under load.
+  **Solution:** test in November. A peak season is the one time a monitoring plan must
+  already be proven.
+- **Problem:** a service with no named owner.
+  **Solution:** assign one. An unowned service is unmonitored regardless of its dashboards.
+- **Problem:** all four artifacts drift apart.
+  **Solution:** derive all four from the field list in this file, never by hand.
+- **Problem:** Notion import shows every column as Text.
+  **Solution:** that is expected. Apply the property mapping table once, after import.
+
+
+See the [Related Skills](references/related-skills.md) reference for the full guidance.

package/bundled-skills/observability-cloud-planning/references/related-skills.md

@@ -0,0 +1,20 @@
+# Related Skills
+
+- @brand-growth-system-builder - routes to this skill and the other 12 brand and growth modules.
+- @business-website-setup - the site whose availability this table protects.
+- `devops-pipeline-designer` (engineering pack) - how a change reaches the service in
+  `Deployment Method`.
+- `runbook-playbook` (engineering pack) - the document every `Runbook URL` should point at.
+- `ci-cd-pipeline-builder` (engineering pack) - deployment, alerting on build failure.
+- `security-and-privacy` (engineering pack) - access control, secrets, incident response.
+- `data-privacy-controls` (`me-ops-system-builder`) - what may be logged and for how long.
+- `cloud-cost-variance-tracker` (`me-ops-system-builder`) - reconciling `Monthly Cost
+  Estimate` against the real invoice.
+- `legal-compliance-vault` (`me-ops-system-builder`) - where the data-processing agreement
+  for a third-party log destination is stored.
+- @code-of-conduct - what may be recorded about a person, and who may read it.
+- @gbp-local-seo-intent - the phone number and hours that must stay correct when the site
+  is down, since a monitoring alert and a listing are the same promise.
+
+
+See the [Reusable Prompt](references/reusable-prompt.md) reference for the full guidance.

package/bundled-skills/observability-cloud-planning/references/reusable-prompt.md

@@ -0,0 +1,12 @@
+# Reusable Prompt
+
+```
+I need a monitoring and cloud plan for a small business: what is critical, what should be
+measured, what should alert a human, and what it will cost.
+Ask me one short question at a time, and only about what I have not already told you.
+Never invent a hostname, a provider, a price, a traffic figure or an uptime target. Start
+with the one failure that would stop the business earning, and monitor it from outside the
+infrastructure. Three signals, and no alert without a runbook. Wait for me to ask before
+you build it.
+When I ask, output CSV, SQL DDL, JSON Schema and a Notion property mapping. Data only.
+```

package/bundled-skills/observability-cloud-planning/references/security-safety-notes.md

@@ -0,0 +1,30 @@
+# Security & Safety Notes
+
+- Never invent a hostname, IP address, service identifier, provider, price, traffic figure,
+  error rate, uptime percentage or recovery time. `Unknown` and blank are correct.
+- Never paste credentials, API keys, tokens, SSH keys, database connection strings, backup
+  locations or `.env` contents into this table. Not into a dashboard field, not into Notes.
+- Never paste real customer data, personal data, health data or payment data into this
+  table. `Data Handled` records the *category*, not the data.
+- Do not put secrets, tokens or personal data in log lines. That decision is made when
+  logging is configured, and this table is where the consequence is recorded - so a
+  service that would log secrets belongs in a different design.
+- Sending logs to a third-party service is a data transfer. Confirm the destination, the
+  agreement, the region and the retention before enabling it, and record the decision in
+  `Notes`.
+- `Data Handled` = `Credentials or secrets` means access to those logs is itself a
+  privileged operation. Restrict it and review who has it.
+- Never leave a monitoring endpoint unauthenticated. A public status page that leaks
+  internal hostnames or error detail is an information disclosure.
+- Alert channels contain contact details. Keep the register in an access-restricted place;
+  do not paste a real phone number or escalation tree into a shared spreadsheet while
+  prototyping.
+- If a monitoring tool is given production access, scope it to read-only and to the minimum
+  needed. An observability agent with write access to the thing it observes is a real
+  privilege.
+- Local reads, generation commands, and validation are part of a requested artifact build.
+  External writes, messages, provisioning, and publication require authorization for that
+  action and target; existing explicit authorization does not need to be repeated.
+
+
+See the [Common Pitfalls](references/common-pitfalls.md) reference for the full guidance.