Platform & Infrastructure

Scope

Covers

• Platform engineering / “paved roads”: shared capabilities that multiple product teams reuse

• Infrastructure quality attributes: reliability, performance, privacy/safety, operability, cost

• Scalability planning: capacity limits, leading indicators, “doomsday clock” triggers, sequencing

• Instrumentation strategy: server-side event tracking, data quality, observability gaps

• Discoverability architecture for web platforms (optional): sitemap + internal linking

When to use

• “Create a platform infrastructure plan to increase feature velocity without repeating work.”

• “Turn reliability/performance/privacy goals into concrete SLOs and an execution roadmap.”

• “We’re approaching scaling limits—define triggers and the next infra projects.”

• “Our analytics is messy—design a server-side tracking plan and event contract.”

• “For a large web property, define sitemap + internal-linking requirements for crawlability.”

When NOT to use

• You are handling an active incident or outage (use incident response/runbooks first).

• You only need a single localized perf fix or refactor (just do the work).

• You need product strategy/positioning for a platform-as-product (use platform-strategy ).

• You need a full feature spec or UX flows (use writing-specs-designs / writing-prds ).

• SEO/content strategy is the primary workstream (use content-marketing ).

Inputs

Minimum required

• System boundary (services/apps) + primary users/customers

• Current pains (pick 1–3): reliability, performance, cost, privacy/security/compliance, developer velocity, data quality/analytics, SEO/discoverability

• Current architecture constraints (data stores, runtime, deployment model, key dependencies)

• Scale + trajectory (rough): current usage + expected growth + known upcoming spikes

• Constraints: deadlines, staffing/capacity, risk tolerance, compliance/privacy requirements

Missing-info strategy

• Ask up to 5 questions from references/INTAKE.md (3–5 at a time).

• If details remain missing, proceed with explicit assumptions and provide 2–3 options.

• If asked to change production systems or run commands, require explicit confirmation and include rollback guidance.

Outputs (deliverables)

Produce a Platform & Infrastructure Improvement Pack in Markdown (in-chat; or as files if requested), in this order:

• Context snapshot (scope, constraints, assumptions, stakeholders, success definition)

• Shared capabilities inventory + platformization plan (what to standardize, why, and how)

• Quality attributes spec (reliability/perf/privacy/safety targets; proposed SLOs/SLIs)

• Scaling “doomsday clock” + capacity plan (limits, triggers, lead time, projects)

• Instrumentation plan (observability gaps + server-side analytics event contract)

• Discoverability plan (optional) for web platforms (sitemap + internal linking requirements)

• Execution roadmap (sequencing, milestones, owners, dependencies, comms)

• Risks / Open questions / Next steps (always included)

Templates: references/TEMPLATES.md

Workflow (8 steps)

1. Intake + define “what decision will this enable?”

• Inputs: Context; references/INTAKE.md.

• Actions: Confirm scope boundaries, top pains, and time horizon. Write a 1–2 sentence decision statement (e.g., “We will standardize X and commit to SLO Y by date Z.”).

• Outputs: Context snapshot (draft).

• Checks: A stakeholder can answer: “What will we do differently after reading this?”

2. Find repeatable product capabilities worth platformizing

• Inputs: Recent roadmap/initiatives; architecture overview; pain points.

• Actions: Inventory repeated “feature components” (e.g., export, filtering, permissions, audit logs, notifications). Identify 3–7 candidates for shared infrastructure. Define what becomes the platform contract vs what remains product-specific.

• Outputs: Shared capabilities inventory + platformization plan (draft).

• Checks: Each candidate has: (a) at least 2 consumers, (b) a clear API/contract idea, (c) a migration/rollout approach.

3. Define quality attributes and targets (make “invisible work” explicit)

• Inputs: Reliability/perf/privacy needs; customer expectations; compliance constraints.

• Actions: Write the quality attributes spec. Propose SLOs/SLIs for reliability and performance; document privacy/safety requirements (data residency, encryption, access controls, retention).

• Outputs: Quality attributes spec (draft).

• Checks: Targets are measurable and owned (even if initial numbers are estimates + confidence).

4. Build the scaling “doomsday clock”

• Inputs: Current bottlenecks/limits; growth expectations; lead times for major changes.

• Actions: Identify top 3–10 capacity limits (DB size/IOPS, queue depth, cache hit rate, deploy throughput, rate limits). Define thresholds that trigger scaling projects early enough (lead time-aware).

• Outputs: Doomsday clock table + capacity plan (draft).

• Checks: Each limit has a metric, an alert threshold, a lead time estimate, and a named mitigation project.

5. Decide instrumentation: observability + server-side analytics

• Inputs: Current logging/metrics/tracing; current analytics tracking approach.

• Actions: Specify observability gaps (must-have dashboards/alerts) and define an event contract for server-side analytics (names, properties, identity strategy, delivery guarantees, QA checks).

• Outputs: Instrumentation plan (draft).

• Checks: Event definitions are consistent across clients; key events are captured server-side; data-quality checks exist.

6. (Optional) Discoverability architecture for web platforms

• Inputs: If applicable: site/app information architecture; SEO importance; crawl constraints.

• Actions: Define sitemap requirements (categorization, pagination, freshness) and internal-linking rules (“related content”, indexability controls, canonicalization).

• Outputs: Discoverability plan (draft) or “Not applicable” decision.

• Checks: A crawler can reach all indexable pages via links/sitemaps; “noindex”/canonicals are intentional.

7. Turn decisions into a sequenced execution roadmap

• Inputs: Draft deliverables; constraints; dependencies; capacity.

• Actions: Prioritize initiatives using impact × risk × effort × lead time. Create milestones, owners, and rollout plans (including deprecation/decommission for old paths).

• Outputs: Execution roadmap (draft).

• Checks: Roadmap has a first executable milestone, explicit dependencies, and measurable acceptance criteria.

8. Quality gate + finalize

• Inputs: Full draft pack.

• Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Tighten unclear contracts, add missing measures, and always include Risks / Open questions / Next steps.

• Outputs: Final Platform & Infrastructure Improvement Pack.

• Checks: A team can execute without extra meetings; unknowns are explicit and owned.

Quality gate (required)

• Use references/CHECKLISTS.md and references/RUBRIC.md.

• Always include: Risks, Open questions, Next steps.

Examples

Example 1 (shared capabilities): “Use platform-infrastructure for a B2B analytics app where every team keeps rebuilding export, filtering, and permissions. Output a platformization plan + roadmap + SLO targets.”

Example 2 (scaling readiness): “We expect 5× traffic in 6 months. Define a doomsday clock for Postgres limits, propose scaling projects, and set reliability/performance SLOs. Also standardize server-side analytics.”

Boundary example: “We’re mid-incident and pages are down—tell us what to do right now.”

Response: out of scope; recommend incident response first, then use this skill post-incident to create the scaling plan and reliability roadmap.