@skill-graph/cli 0.5.6

package/marketplace/skills/performance-budgets/SKILL.md

@@ -0,0 +1,185 @@
+---
+name: performance-budgets
+description: "Use when declaring, measuring, or enforcing performance thresholds as a quality contract rather than as an aspirational target. Covers the three budget axes (time, size, count), the four governing properties of a real budget (metric, threshold, percentile, consequence), the Core Web Vitals set (LCP, INP, CLS), the RAIL model, Lighthouse budgets.json, lab vs field measurement, and the discipline of treating budget breach as a build or deploy failure rather than a tracked metric. Do NOT use for the activity of profiling and optimizing a specific slow path (use performance-engineering), the choice of rendering model that bounds achievable budgets (use rendering-models), or the design of observability and telemetry signals (use observability-modeling)."
+license: MIT
+allowed-tools: Read Grep
+metadata:
+  metadata: "{\"schema_version\":6,\"version\":\"1.0.0\",\"type\":\"capability\",\"category\":\"quality\",\"domain\":\"quality/performance\",\"scope\":\"reference\",\"owner\":\"skill-graph-maintainer\",\"freshness\":\"2026-05-15\",\"drift_check\":\"{\\\\\\\"last_verified\\\\\\\":\\\\\\\"2026-05-15\\\\\\\"}\",\"eval_artifacts\":\"planned\",\"eval_state\":\"unverified\",\"routing_eval\":\"absent\",\"comprehension_state\":\"present\",\"stability\":\"experimental\",\"keywords\":\"[\\\\\\\"performance budget\\\\\\\",\\\\\\\"Core Web Vitals\\\\\\\",\\\\\\\"LCP\\\\\\\",\\\\\\\"INP\\\\\\\",\\\\\\\"CLS\\\\\\\",\\\\\\\"RAIL model\\\\\\\",\\\\\\\"Lighthouse budgets\\\\\\\",\\\\\\\"lab metrics\\\\\\\",\\\\\\\"field metrics\\\\\\\",\\\\\\\"p75 performance\\\\\\\",\\\\\\\"bundle size budget\\\\\\\",\\\\\\\"request count budget\\\\\\\",\\\\\\\"performance regression\\\\\\\",\\\\\\\"budget breach\\\\\\\"]\",\"triggers\":\"[\\\\\\\"how fast does this page need to be\\\\\\\",\\\\\\\"what's a good LCP target\\\\\\\",\\\\\\\"should this fail the build\\\\\\\",\\\\\\\"why is the Lighthouse score different from real users\\\\\\\",\\\\\\\"we need a performance budget\\\\\\\"]\",\"examples\":\"[\\\\\\\"set a Core Web Vitals budget for a marketing landing page and enforce it in CI\\\\\\\",\\\\\\\"explain why a green Lighthouse score still produced bad real-user performance\\\\\\\",\\\\\\\"decide between INP and FID as the interaction-responsiveness metric\\\\\\\",\\\\\\\"design a per-route budget table that distinguishes static pages from logged-in dashboards\\\\\\\"]\",\"anti_examples\":\"[\\\\\\\"profile a specific slow query and decide what to fix (use performance-engineering)\\\\\\\",\\\\\\\"choose between SSG and SSR for a route (use rendering-models)\\\\\\\",\\\\\\\"design telemetry spans and traces (use observability-modeling)\\\\\\\"]\",\"relations\":\"{\\\\\\\"related\\\\\\\":[\\\\\\\"performance-engineering\\\\\\\",\\\\\\\"rendering-models\\\\\\\",\\\\\\\"observability-modeling\\\\\\\",\\\\\\\"testing-strategy\\\\\\\",\\\\\\\"http-semantics\\\\\\\"],\\\\\\\"boundary\\\\\\\":[{\\\\\\\"skill\\\\\\\":\\\\\\\"performance-engineering\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"performance-engineering owns the activity of measuring, profiling, and improving performance. performance-budgets owns the threshold-and-consequence contract. The two compose: budgets define the failure conditions; engineering produces the improvements that prevent breach.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"rendering-models\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"rendering-models owns the choice of when and where the UI is produced. performance-budgets sits downstream — the chosen rendering model bounds which budgets are achievable on a given route.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"observability-modeling\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"observability-modeling owns the design of telemetry signals (spans, metrics, logs). performance-budgets consumes signals as evidence of breach but does not design the signals themselves.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"testing-strategy\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"testing-strategy owns runtime-correctness verification. performance-budgets is an analogous discipline for non-functional properties — a budget breach is the same kind of CI failure as a failing test.\\\\\\\"}],\\\\\\\"verify_with\\\\\\\":[\\\\\\\"performance-engineering\\\\\\\",\\\\\\\"observability-modeling\\\\\\\"]}\",\"mental_model\":\"|\",\"purpose\":\"|\",\"boundary\":\"|\",\"analogy\":\"A performance budget is to a web app what a calorie budget is to a diet — the calorie count of any single meal is information; the calorie budget is what you do about it when you exceed it. A diet that 'tracks' calories without consequence is description; a diet with a calorie *budget* is discipline. And a per-meal budget (per-route) catches drift earlier than a per-day total: by the time the day total breaches, the offending meal is hours behind you and harder to undo.\",\"misconception\":\"|\",\"concept\":\"{\\\\\\\"definition\\\\\\\":\\\\\\\"A performance budget is a declared, measurable threshold for a user-affecting property of a system — load time, interaction latency, layout stability, bundle size, request count — treated as a contract the system must satisfy. A budget has four parts: the metric (what is measured), the threshold (the maximum or minimum acceptable value), the percentile (whose experience the threshold describes), and the consequence (what happens when the threshold is breached). Without all four, the number is an aspiration, not a budget.\\\\\\\",\\\\\\\"mental_model\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"purpose\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"boundary\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"taxonomy\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"analogy\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"misconception\\\\\\\":\\\\\\\"|\\\\\\\"}\",\"skill_graph_source_repo\":\"https://github.com/jacob-balslev/skill-graph\",\"skill_graph_protocol\":\"Skill Metadata Protocol v5\",\"skill_graph_project\":\"Skill Graph\",\"skill_graph_canonical_skill\":\"skills/performance-budgets/SKILL.md\"}"
+  skill_graph_source_repo: "https://github.com/jacob-balslev/skill-graph"
+  skill_graph_protocol: Skill Metadata Protocol v4
+  skill_graph_project: Skill Graph
+  skill_graph_canonical_skill: skills/performance-budgets/SKILL.md
+---
+
+# Performance Budgets
+
+## Coverage
+
+The discipline of declaring measurable thresholds for performance-affecting properties and enforcing them as quality contracts. Covers the four governing properties (metric, threshold, percentile, consequence), the three budget axes (time, size, count), the three measurement modes (lab, field, synthetic), the Core Web Vitals set as the most-adopted public budget standard, the RAIL model as the interaction-class framework, Lighthouse budgets.json as a declarative enforcement mechanism, and the per-route granularity that real applications require.
+
+## Philosophy
+
+A budget is a contract written in numbers. Three things distinguish a real budget from a tracked metric:
+
+1. **It is set before the spending decisions, not after.** A budget that emerges from post-hoc retrospectives is a description; a budget that constrains the next feature is a discipline.
+2. **It binds to a consequence, not a dashboard.** A number that someone watches and worries about is a metric. A number that fails a build is a budget.
+3. **It speaks for the user.** Every other voice in the room — engineering, design, product, analytics, marketing — has its own incentives. The budget is the institutional voice of the user, present at every commit, refusing to grant exceptions silently.
+
+The hardest part of performance budgeting is not setting the number — it is committing to enforce it when enforcement is expensive. The first time the budget blocks a feature, the discipline is tested. A team that grants an exception "just this once" has reduced the budget to a metric. A team that delays the feature, cuts another feature, or extends the budget through a documented amendment has kept the contract intact.
+
+## The Four Parts of a Real Budget
+
+A complete budget statement names all four:
+
+> **LCP at p75 must be below 2.5 seconds in field measurement; breach blocks deploy.**
+
+| Part | This budget's value | Why it matters |
+|---|---|---|
+| Metric | LCP (Largest Contentful Paint) | Cited by name, not by "speed" or "load time"; LCP has a precise definition |
+| Threshold | 2.5 seconds | A number, not a band; matches the Core Web Vitals "Good" boundary |
+| Percentile | p75 | Whose experience this threshold describes — the slower three-quarters get worse |
+| Consequence | Deploy blocked | The discipline; without this, the rest is a tracked metric |
+
+A statement that says "LCP should be fast" or "we target a Lighthouse score of 90" is missing at least one of these parts. The missing parts are where the discipline leaks.
+
+## The Three Axes
+
+| Axis | Examples | Why budgeted |
+|---|---|---|
+| **Time** | LCP, INP, CLS, TTFB, FCP, TTI | Direct user-perceived latency |
+| **Size** | JS bytes, CSS bytes, image bytes, font bytes, total transfer | Bounds parse, network, and execution cost — proxies for time on slow devices |
+| **Count** | Requests, third-party scripts, fonts loaded, DOM nodes | Connection overhead, rendering cost, attack surface |
+
+Size and count budgets are upstream of time budgets: a page that ships 3MB of JS will fail INP on a mid-range Android device regardless of how clever the optimization is. Setting all three axes catches regression at the level closest to where it happened.
+
+## The Core Web Vitals Set
+
+Google's Core Web Vitals are the most widely adopted public budget standard. They are the default starting point for a project that does not yet have a budget.
+
+| Metric | Good | Needs Improvement | Poor | Definition |
+|---|---|---|---|---|
+| LCP (Largest Contentful Paint) | ≤ 2.5s | 2.5–4.0s | > 4.0s | Time from navigation start to the largest above-fold element rendering |
+| INP (Interaction to Next Paint) | ≤ 200ms | 200–500ms | > 500ms | The worst observed delay between any user interaction and the next paint, in the session |
+| CLS (Cumulative Layout Shift) | ≤ 0.1 | 0.1–0.25 | > 0.25 | Sum of unexpected layout shifts, weighted by impact area |
+
+All three are measured at p75 in field data. The bands come from Google's published correlation between metric value and user-retention proxies.
+
+INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. FID measured only the first interaction; INP measures the worst across the session. A site that passes FID may fail INP; the budget update is not cosmetic.
+
+## The RAIL Model
+
+A complementary framework that classifies interactions by their latency budget:
+
+| Class | Budget | Examples |
+|---|---|---|
+| **Response** | < 100ms from user input to acknowledgement | Button press feedback, hover, focus |
+| **Animation** | < 16ms per frame (60fps) | Scroll, transition, drag |
+| **Idle** | Idle work in chunks ≤ 50ms | Analytics flush, prefetching, deferred rendering |
+| **Load** | < 5s on a slow 3G mid-range mobile | First navigation to interactive |
+
+RAIL is older than Core Web Vitals but still load-bearing as a per-interaction-class budget. CWV is the public-facing summary; RAIL is the design-time guidance for what each interaction should cost.
+
+## Lab vs Field
+
+| Mode | Tool examples | Strengths | Limitations |
+|---|---|---|---|
+| Lab | Lighthouse, WebPageTest, sitespeed.io | Reproducible, fast, integrable in CI | Constructed environment may not reflect real users |
+| Field (RUM) | CrUX, web-vitals.js + own RUM, Sentry Performance, Datadog RUM | Authoritative; reflects real users on real devices | Slow feedback; data arrives after the regression ships |
+| Synthetic | Scheduled lab runs against production from multiple regions | Trend tracking; geographic coverage | Still lab; same constructed-environment limits |
+
+The discipline that works:
+
+- **Lab as pre-deploy gate.** Lighthouse-CI or equivalent runs on every PR; budget breach blocks the merge. Catches regressions before they ship.
+- **Field as authoritative assessment.** RUM data reports the p75 the user actually experienced. If the field metric breaches even though the lab passed, the lab is missing something — investigate and fix the gap.
+- **Synthetic for trend.** Scheduled production runs from a representative set of geographies; useful for week-over-week regression spotting and for the rare case where production diverges from staging.
+
+## Per-Route Budgets
+
+A site-wide budget either fits the strictest route or the loosest. Neither is right. A realistic budget table:
+
+| Route profile | LCP target | INP target | JS budget | Why |
+|---|---|---|---|---|
+| Marketing landing | 1.5s | 200ms | 100KB compressed | Largest revenue impact per millisecond; competition is fast |
+| Product detail | 2.0s | 200ms | 200KB | Catalog content + image-heavy; users have intent |
+| Search results | 2.5s | 200ms | 250KB | Server work per query; users tolerate slightly more for relevance |
+| Logged-in dashboard | 3.0s | 300ms | 400KB | Personalized; users have committed; richer UI |
+| Admin panel | 4.0s | 500ms | 600KB | Low-traffic; high-functionality; small known audience |
+
+The numbers above are illustrative — the actual values come from the project's content, audience, and competitive position. The shape is the load-bearing part: differentiate per route, with stricter budgets on the routes that face the cold-arriving user and looser budgets on the routes that face the committed one.
+
+## Lighthouse budgets.json
+
+A declarative enforcement file that Lighthouse and Lighthouse-CI consume:
+
+```json
+{
+  "path": "/",
+  "resourceSizes": [
+    { "resourceType": "script", "budget": 200 },
+    { "resourceType": "stylesheet", "budget": 50 },
+    { "resourceType": "image", "budget": 300 },
+    { "resourceType": "font", "budget": 100 },
+    { "resourceType": "total", "budget": 800 }
+  ],
+  "resourceCounts": [
+    { "resourceType": "third-party", "budget": 10 },
+    { "resourceType": "script", "budget": 20 }
+  ],
+  "timings": [
+    { "metric": "interactive", "budget": 3000 },
+    { "metric": "first-contentful-paint", "budget": 1500 }
+  ]
+}
+```
+
+The file is checked into the repo, applies per path, and triggers a Lighthouse-CI failure when breached. It is the cheapest place to make a budget enforceable; the consequence (CI failure) is the property that makes it a budget rather than documentation.
+
+## The Discipline of Calibration
+
+A budget set too tight blocks all work and gets disabled. A budget set too loose generates no signal. Calibration is the practice of setting budgets that are slightly stricter than current performance, ratcheting them tighter as optimization work lands.
+
+**Ratchet pattern:**
+
+1. Measure current p75 on the route.
+2. Set the budget at the current value + a small margin (5–10%).
+3. Land optimization work; budget enforces no regression.
+4. When the optimization shows in field data, tighten the budget to the new p75 + margin.
+5. Repeat.
+
+The pattern prevents the "budget is impossible from day one" failure mode and the "budget drifts forever" failure mode. Each tightening is small enough to land without negotiation; the cumulative effect over a year is substantial.
+
+## Verification
+
+After applying this skill, verify:
+- [ ] Every budget statement names all four parts (metric, threshold, percentile, consequence).
+- [ ] At least one budget on each of the three axes (time, size, count) — single-axis budgets miss whole classes of regression.
+- [ ] Field measurement (RUM, CrUX) is the authoritative source for at least the Core Web Vitals; lab measurement is the pre-deploy gate.
+- [ ] Per-route budgets exist where routes have meaningfully different content profiles (landing vs dashboard, anonymous vs logged-in).
+- [ ] The consequence is automated — a CI step, a deploy gate, a rollback trigger — not a manual review.
+- [ ] Lighthouse budgets.json (or equivalent declarative file) is checked into the repo, version-controlled, and reviewed in the same PR as performance-affecting changes.
+- [ ] INP is part of the time budget set (FID alone is insufficient for sessions with multiple interactions).
+- [ ] Third-party scripts are inside the budget, not exempted — the user experiences their cost.
+- [ ] The percentile is documented and matches industry convention (p75 for CWV) or has an explicit reason for differing.
+- [ ] A calibration plan exists — when and how the budget tightens as performance improves.
+
+## Do NOT Use When
+
+| Instead of this skill | Use | Why |
+|---|---|---|
+| Profiling a specific slow path and deciding what to fix | `performance-engineering` | performance-engineering owns the diagnostic and optimization activity; this skill owns the contract that defines failure |
+| Choosing a rendering model for a route | `rendering-models` | rendering-models bounds what budgets are achievable; this skill consumes that input |
+| Designing telemetry spans, traces, or metric pipelines | `observability-modeling` | observability-modeling designs the signals; this skill defines what level of those signals counts as a breach |
+| Writing tests for behavior correctness | `testing-strategy` | testing-strategy owns runtime correctness; budgets are an analogous discipline for non-functional properties |
+| Designing HTTP cache headers, compression, or transport | `http-semantics` | http-semantics owns the wire-level optimization; budgets are downstream of the choice |
+
+## Key Sources
+
+- Google Chrome Team. [Core Web Vitals](https://web.dev/articles/vitals). Definitions, "Good / Needs Improvement / Poor" bands, and the underlying research linking metric values to user-retention proxies. The most-adopted public budget standard.
+- Google Chrome Team. [Interaction to Next Paint (INP)](https://web.dev/articles/inp). The 2024 replacement for FID; explains why measuring all interactions in the session (not just the first) materially changes which sites pass.
+- Google Chrome Team. [The RAIL performance model](https://web.dev/articles/rail). Older but still load-bearing; classifies interactions by latency class and assigns each a budget.
+- Tim Kadlec. ["Performance Budgets"](https://timkadlec.com/2013/01/setting-a-performance-budget/). 2013. The original article naming and defining the performance-budget concept; introduces the discipline as a product practice rather than a technical metric.
+- Google Chrome Team. [Lighthouse performance budgets](https://developer.chrome.com/docs/lighthouse/performance/performance-budgets-101). The budgets.json reference and CI integration.
+- Chrome User Experience Report (CrUX). [CrUX dataset](https://developer.chrome.com/docs/crux). The public field dataset; the source of truth for cross-site Core Web Vitals data and the underlying corpus for the band definitions.
+- Addy Osmani. ["Speed at Scale: Web Performance Tips and Tricks from the Trenches"](https://addyosmani.com/blog/). Practitioner-level writing on calibrating and enforcing budgets in production teams.
+- Web Almanac (HTTP Archive). [Performance chapter](https://almanac.httparchive.org/en/2024/performance). Annual cross-site analysis; useful for competitive-derived threshold calibration.
+- Microsoft. [INP at Microsoft Store: 30% improvement case study](https://blogs.windows.com/msedgedev/2023/10/06/the-edge-team-on-improving-inp/). A worked example of an INP budget driving a measurable user-experience improvement.

package/marketplace/skills/performance-engineering/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: performance-engineering
+description: "Use when measuring, diagnosing, budgeting, or improving performance: latency, throughput, Core Web Vitals, database queries, caching, bundle size, concurrency, resource use, and regression prevention. Do NOT use for telemetry schema design alone (use `observability-modeling`), error capture setup (use `error-tracking`), or premature micro-optimization without a measured bottleneck."
+license: MIT
+compatibility: "Portable performance discipline for frontend, backend, databases, jobs, APIs, and agent tooling."
+allowed-tools: Read Grep
+metadata:
+  metadata: "{\"schema_version\":6,\"version\":\"1.0.0\",\"type\":\"capability\",\"category\":\"quality\",\"domain\":\"quality/performance\",\"scope\":\"portable\",\"owner\":\"skill-graph-maintainer\",\"freshness\":\"2026-05-11\",\"drift_check\":\"{\\\\\\\"last_verified\\\\\\\":\\\\\\\"2026-05-11\\\\\\\"}\",\"eval_artifacts\":\"present\",\"eval_state\":\"unverified\",\"routing_eval\":\"absent\",\"stability\":\"experimental\",\"keywords\":\"[\\\\\\\"performance engineering\\\\\\\",\\\\\\\"performance budget\\\\\\\",\\\\\\\"profiling\\\\\\\",\\\\\\\"latency\\\\\\\",\\\\\\\"throughput\\\\\\\",\\\\\\\"Core Web Vitals\\\\\\\",\\\\\\\"database performance\\\\\\\",\\\\\\\"caching\\\\\\\",\\\\\\\"bundle size\\\\\\\",\\\\\\\"performance regression\\\\\\\"]\",\"examples\":\"[\\\\\\\"profile this slow dashboard and decide what to optimize first\\\\\\\",\\\\\\\"set performance budgets for API latency, page load, and query time\\\\\\\",\\\\\\\"review this change for likely N+1 queries, cache mistakes, or bundle growth\\\\\\\",\\\\\\\"design a regression check so this endpoint cannot get slow again unnoticed\\\\\\\"]\",\"anti_examples\":\"[\\\\\\\"design logs, spans, metrics, and correlation IDs before implementation\\\\\\\",\\\\\\\"set up Sentry and error redaction\\\\\\\",\\\\\\\"make random micro-optimizations without measurements\\\\\\\",\\\\\\\"write general unit tests for this feature\\\\\\\"]\",\"relations\":\"{\\\\\\\"boundary\\\\\\\":[{\\\\\\\"skill\\\\\\\":\\\\\\\"observability-modeling\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"observability-modeling designs telemetry signals; performance-engineering uses measurements to improve performance\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"error-tracking\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"error-tracking captures failures; performance-engineering handles latency, throughput, and resource efficiency\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"testing-strategy\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"testing-strategy plans correctness tests; performance-engineering plans performance budgets and regressions\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"refactor\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"refactor restructures code while preserving behavior; performance-engineering changes behavior characteristics under measurement\\\\\\\"}],\\\\\\\"related\\\\\\\":[\\\\\\\"observability-modeling\\\\\\\",\\\\\\\"api-design\\\\\\\",\\\\\\\"data-modeling\\\\\\\",\\\\\\\"testing-strategy\\\\\\\"],\\\\\\\"verify_with\\\\\\\":[\\\\\\\"observability-modeling\\\\\\\",\\\\\\\"code-review\\\\\\\"]}\",\"portability\":\"{\\\\\\\"readiness\\\\\\\":\\\\\\\"scripted\\\\\\\",\\\\\\\"targets\\\\\\\":[\\\\\\\"skill-md\\\\\\\"]}\",\"lifecycle\":\"{\\\\\\\"stale_after_days\\\\\\\":180,\\\\\\\"review_cadence\\\\\\\":\\\\\\\"quarterly\\\\\\\"}\",\"skill_graph_source_repo\":\"https://github.com/jacob-balslev/skill-graph\",\"skill_graph_protocol\":\"Skill Metadata Protocol v5\",\"skill_graph_project\":\"Skill Graph\",\"skill_graph_canonical_skill\":\"skills/performance-engineering/SKILL.md\"}"
+  skill_graph_source_repo: "https://github.com/jacob-balslev/skill-graph"
+  skill_graph_protocol: Skill Metadata Protocol v4
+  skill_graph_project: Skill Graph
+  skill_graph_canonical_skill: skills/performance-engineering/SKILL.md
+---
+
+# Performance Engineering
+
+## Coverage
+
+Measure and improve performance across frontend, backend, database, jobs, APIs, and tooling. Covers bottleneck analysis, performance budgets, Core Web Vitals, query plans, N+1 detection, caching, batching, concurrency, bundle size, resource use, regression checks, and tradeoffs.
+
+## Philosophy
+
+Measure first. Performance work without measurement is guessing, and guessing usually optimizes the easiest code rather than the bottleneck. The correct target is the user-visible or business-critical bottleneck with evidence.
+
+Performance is also a contract. If speed matters, define budgets and regression checks before the system silently decays.
+
+## Method
+
+1. Define the performance goal and user/business impact.
+2. Collect baseline measurements under realistic conditions.
+3. Identify the bottleneck: network, server, database, rendering, bundle, CPU, memory, lock contention, or third party.
+4. Choose the smallest intervention likely to move the bottleneck.
+5. Verify improvement with the same measurement method.
+6. Add a budget, alert, or regression test for the fixed surface.
+7. Record tradeoffs such as freshness, complexity, cost, or cache invalidation risk.
+
+## Evals
+
+This skill ships a comprehension-eval artifact at [`examples/evals/performance-engineering.json`](https://github.com/jacob-balslev/skill-graph/blob/main/examples/evals/performance-engineering.json). The checklist below is the authoring gate for performance decisions; the eval file is the grader surface.
+
+## Verification
+
+- [ ] Baseline and post-change measurements use the same method
+- [ ] The optimized target is the measured bottleneck
+- [ ] User-visible or business impact is stated
+- [ ] Cache changes include invalidation and staleness rules
+- [ ] Database fixes include query-plan or index evidence when relevant
+- [ ] Frontend fixes include bundle or Web Vitals evidence when relevant
+- [ ] A regression guard exists for important performance surfaces
+
+## Do NOT Use When
+
+| Use instead | When |
+|---|---|
+| `observability-modeling` | You need to design telemetry schema and diagnostic signals. |
+| `error-tracking` | You need error capture, redaction, source maps, or issue triage. |
+| `testing-strategy` | You need general correctness test planning. |
+| `refactor` | You are restructuring code without a measured performance goal. |

package/marketplace/skills/performance-testing/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: performance-testing
+description: "Use when measuring a system's non-functional properties — latency, throughput, error rate, resource utilization — by running it under controlled load and verifying against explicit SLO thresholds. Covers the five primitives (load profile, workload, latency metric, throughput metric, SLO target), the load-shape taxonomy (smoke, load, stress, spike, soak, breakpoint), the latency-percentile vocabulary (p50, p95, p99, p99.9) and why average latency misleads, the tool ecosystem (k6, JMeter, Locust, Gatling, Vegeta), and the offline-vs-observability distinction. Do NOT use for the optimization activity itself (use `performance-engineering`), declaring the threshold contract (use `performance-budgets`), runtime measurement of deployed systems (use `observability` or `error-tracking`), microbenchmarks of single functions (language benchmark tools), chaos engineering (use `chaos-engineering`), or test-suite quality measurement (use `mutation-testing`)."
+license: MIT
+allowed-tools: Read Grep
+metadata:
+  metadata: "{\"schema_version\":6,\"version\":\"1.0.0\",\"type\":\"capability\",\"category\":\"quality\",\"domain\":\"quality/testing\",\"scope\":\"reference\",\"owner\":\"skill-graph-maintainer\",\"freshness\":\"2026-05-16\",\"drift_check\":\"{\\\\\\\"last_verified\\\\\\\":\\\\\\\"2026-05-16\\\\\\\"}\",\"eval_artifacts\":\"planned\",\"eval_state\":\"unverified\",\"routing_eval\":\"absent\",\"comprehension_state\":\"present\",\"stability\":\"experimental\",\"keywords\":\"[\\\\\\\"performance testing\\\\\\\",\\\\\\\"load testing\\\\\\\",\\\\\\\"stress testing\\\\\\\",\\\\\\\"soak testing\\\\\\\",\\\\\\\"spike testing\\\\\\\",\\\\\\\"breakpoint test\\\\\\\",\\\\\\\"k6\\\\\\\",\\\\\\\"JMeter\\\\\\\",\\\\\\\"Locust\\\\\\\",\\\\\\\"Gatling\\\\\\\",\\\\\\\"latency percentile\\\\\\\",\\\\\\\"p95\\\\\\\",\\\\\\\"p99\\\\\\\",\\\\\\\"SLO\\\\\\\",\\\\\\\"throughput\\\\\\\"]\",\"triggers\":\"[\\\\\\\"what should our load test do\\\\\\\",\\\\\\\"p95 vs average latency\\\\\\\",\\\\\\\"k6 vs JMeter vs Locust\\\\\\\",\\\\\\\"is the system fast enough\\\\\\\",\\\\\\\"stress test or load test\\\\\\\"]\",\"examples\":\"[\\\\\\\"design a load test for an API endpoint that verifies the p95 SLO at expected production traffic\\\\\\\",\\\\\\\"decide between load, stress, and soak tests for a new service before launch\\\\\\\",\\\\\\\"diagnose a soak test failure that only appears after 4 hours — likely a leak\\\\\\\",\\\\\\\"explain why average latency is the wrong metric for user experience\\\\\\\"]\",\"anti_examples\":\"[\\\\\\\"measure production traffic latency in real time (use observability)\\\\\\\",\\\\\\\"benchmark a single function in isolation (use language benchmark tools)\\\\\\\",\\\\\\\"inject failures into a production system (use chaos-engineering)\\\\\\\"]\",\"relations\":\"{\\\\\\\"related\\\\\\\":[\\\\\\\"testing-strategy\\\\\\\",\\\\\\\"integration-test-design\\\\\\\",\\\\\\\"e2e-test-design\\\\\\\",\\\\\\\"performance-engineering\\\\\\\",\\\\\\\"performance-budgets\\\\\\\"],\\\\\\\"boundary\\\\\\\":[{\\\\\\\"skill\\\\\\\":\\\\\\\"testing-strategy\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"testing-strategy owns the strategic question of what to test; this skill owns one tactical technique (controlled-load measurement of non-functional properties) within that strategy.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"integration-test-design\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"integration-test-design owns tests of correctness across internal seams; this skill owns tests of non-functional properties (latency, throughput) under controlled load. Both can use the same environment; they answer different questions.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"e2e-test-design\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"e2e-test-design owns user-journey correctness tests; this skill owns load-driven measurement of those same journeys. A 'performance e2e test' is the composition of both disciplines.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"performance-engineering\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"performance-engineering owns the activity of profiling and optimizing a specific slow path once it has been identified; this skill owns the discipline of exercising the system under controlled load to discover and quantify performance behavior. Performance-engineering acts on bottlenecks; performance-testing produces the measurements that locate them and verifies the optimizations afterward.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"performance-budgets\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"performance-budgets owns the declaration of the threshold-and-consequence contract (metric, threshold, percentile, consequence) as a quality property; this skill owns the test mechanism that exercises the system under load and verifies whether the declared budgets hold. The two compose: budgets declare what 'fast enough' means; performance tests verify the system meets the declaration. Without a budget, a performance test produces measurements without a verdict; without performance tests, a budget is an aspirational threshold without empirical evidence.\\\\\\\"}],\\\\\\\"verify_with\\\\\\\":[\\\\\\\"testing-strategy\\\\\\\",\\\\\\\"integration-test-design\\\\\\\",\\\\\\\"performance-budgets\\\\\\\"]}\",\"mental_model\":\"|\",\"purpose\":\"|\",\"boundary\":\"|\",\"analogy\":\"Performance testing is to a software system what a load-bearing inspection is to a bridge — you do not certify a bridge by walking across it (functional test) and concluding it works; you drive trucks of known weight across at increasing volumes, with strain gauges on every beam, and verify the deflection stays within spec under expected traffic, that the failure mode is graceful when overloaded (cracks before collapse), that nothing creeps over a long soak. A bridge whose 'average' load it can carry is 50 tonnes but whose p99 stressor reveals harmonic resonance at 80 tonnes is the bridge that fails on a windy day.\",\"misconception\":\"|\",\"concept\":\"{\\\\\\\"definition\\\\\\\":\\\\\\\"Performance testing is the discipline of measuring a system's non-functional properties — latency, throughput, resource utilization, error rate under load — by running the system under controlled load conditions and observing the resulting metrics. Where functional tests answer 'does the system produce the right output?', performance tests answer 'does the system produce the right output *quickly enough* and at *sufficient scale*, while staying within resource budgets and error tolerances?'. The unit of judgment is whether the measured metrics meet defined acceptance thresholds (typically Service-Level Objectives expressed as percentiles, e.g., 'p95 latency below 200ms at 1,000 requests per second sustained for 30 minutes'). Performance testing is *controlled* and *offline*; observability is its production-runtime counterpart that measures the live system without imposed load.\\\\\\\",\\\\\\\"mental_model\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"purpose\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"boundary\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"taxonomy\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"analogy\\\\\\\":\\\\\\\"|\\\\\\\",\\\\\\\"misconception\\\\\\\":\\\\\\\"|\\\\\\\"}\",\"skill_graph_source_repo\":\"https://github.com/jacob-balslev/skill-graph\",\"skill_graph_protocol\":\"Skill Metadata Protocol v5\",\"skill_graph_project\":\"Skill Graph\",\"skill_graph_canonical_skill\":\"skills/performance-testing/SKILL.md\",\"skill_graph_export_description\":\"shortened for Agent Skills 1024-character description limit; canonical source keeps the full routing contract\",\"skill_graph_canonical_description_length\":\"1133\"}"
+  skill_graph_source_repo: "https://github.com/jacob-balslev/skill-graph"
+  skill_graph_protocol: Skill Metadata Protocol v4
+  skill_graph_project: Skill Graph
+  skill_graph_canonical_skill: skills/performance-testing/SKILL.md
+---
+
+# Performance Testing
+
+## Coverage
+
+The discipline of measuring non-functional system properties — latency, throughput, error rate, resource utilization, saturation — by running the system under controlled load and verifying against explicit SLO thresholds. Covers the five primitives (load profile, workload, latency metric, throughput metric, SLO target), the six load-shape types (smoke, load, stress, spike, soak, breakpoint) that each test a different property, the latency-percentile discipline (p50/p95/p99/p99.9) that replaces the misleading average, the environment-fidelity requirement that makes results meaningful, the modern tool landscape (k6, JMeter, Locust, Gatling, Vegeta, Wrk), and the distinction from observability (offline controlled vs online real-traffic) and benchmarking (system vs single-function).
+
+## Philosophy
+
+Performance testing is the discipline of adding the *time and scale* dimensions to verification. Functional tests verify "the system produces the right output"; performance tests verify "the system produces the right output quickly enough and at sufficient scale, within resource budgets and error tolerances." Without performance testing, "is it fast enough" is answered by intuition or by users complaining; with performance testing, it is answered by measurement against an explicit SLO.
+
+The central insight is that performance is multi-dimensional. Latency distribution, throughput ceiling, error rate under load, resource utilization, saturation point — each is a separate property; each requires its own measurement; each can be acceptable while others fail. Reducing performance to a single number (especially average latency) is the most common discipline failure.
+
+The complementary insight is environment fidelity. A performance test in a non-production-like environment produces a measurement of that environment, not the system. Production hardware, network, data volumes, dependency versions, and configuration are the load-bearing investment for performance testing; the load tool itself is increasingly cheap.
+
+## The Six Load Shapes
+
+| Shape | Profile | Verifies | When to run |
+|---|---|---|---|
+| Smoke | Small load, short duration | Test harness works, system functions under any load | Every PR (fast) |
+| Load | Expected production load × margin, sustained | System meets SLO at design load | Every merge / nightly |
+| Stress | Load beyond expected capacity | Failure mode is graceful | Pre-launch / quarterly |
+| Spike | Sudden large increase | Elasticity, autoscaling, recovery | Pre-launch / before known traffic events |
+| Soak | Sustained moderate load for hours | No leaks, no degradation | Pre-launch / monthly |
+| Breakpoint | Gradually increasing load to failure | Quantitative capacity ceiling | Pre-launch / before capacity planning |
+
+A complete pre-launch performance test suite runs all six. An ongoing test suite usually runs smoke on every PR and load on every merge, with stress / spike / soak / breakpoint on cadence.
+
+## Latency Percentiles — The Honest Vocabulary
+
+| Metric | What it tells you | Use for |
+|---|---|---|
+| Mean (average) | Arithmetic average — easily skewed by outliers | Almost nothing; avoid as acceptance criterion |
+| p50 (median) | The typical request | Sanity check; basic system health |
+| p95 | The slow 5% — what 1 in 20 users feels | Common SLO target |
+| p99 | The slow 1% — what 1 in 100 users feels | Common SLO target for user-facing systems |
+| p99.9 | The very slow 0.1% — rare but real | SLO target for high-stakes systems |
+| Max | The single worst request | Diagnosis; avoid as SLO (one bad data point dominates) |
+
+Acceptance criteria should always be percentiles (or distributions), never averages. A system whose mean is 50ms and p99 is 5 seconds has a user-experience problem the mean hides.
+
+## SLO-Driven Performance Tests
+
+A performance test without an SLO is "we measured X" without a verdict. An SLO-driven performance test is:
+
+```
+SLO statement:
+  - p95 latency < 200ms
+  - p99 latency < 500ms
+  - error rate < 0.1%
+  - sustained throughput >= 1000 RPS
+
+Test design:
+  - Load shape: constant 1000 RPS for 30 minutes
+  - Workload: 70% reads, 25% writes, 5% complex queries
+  - Environment: production-equivalent staging
+  - Pass: all four SLO conditions met for full test duration
+  - Fail: any SLO condition violated for > 60 seconds cumulative
+```
+
+The SLO is what makes the test a verification rather than a measurement.
+
+## Tool Selection
+
+| Tool | Strengths | Best for |
+|---|---|---|
+| k6 (Grafana Labs) | Modern JS scripting; cloud-and-local; HTTP/gRPC/WebSocket | New projects; production default |
+| Apache JMeter | Broad protocol support; UI-driven; very mature | Enterprise / complex protocol mix |
+| Locust | Python scripting; distributed; behavioral modeling | Python ecosystem teams |
+| Gatling | Scala / Java; high throughput per generator | High-load single-generator scenarios |
+| Vegeta | Go; simple HTTP; CLI-driven | Simple HTTP load with CI integration |
+| Wrk / Wrk2 | C; very fast; minimal | Microbenchmarks and pure HTTP |
+
+## Verification
+
+After applying this skill, verify:
+- [ ] Performance tests have explicit SLOs as acceptance criteria. "We measured X" without a target is not a verification.
+- [ ] Acceptance criteria are stated as percentiles (p50/p95/p99/p99.9), never as averages. Tests that report only averages are misleading.
+- [ ] The test environment is production-equivalent in hardware, network, data volumes, dependency versions, and configuration. Stripped environments produce informational results, not verifications.
+- [ ] A range of load shapes is tested: smoke (PR-level), load (merge-level), stress / spike / soak / breakpoint (pre-launch and on cadence).
+- [ ] Workload composition is derived from production traffic patterns where possible. Synthetic load with the right RPS but wrong operation mix tests the wrong code paths.
+- [ ] The load tool is not the bottleneck. Distributed load generation is used where single-generator capacity might be exceeded.
+- [ ] Performance tests run continuously (not just pre-launch). Regression detection is the on-going value; one-time tests are point-in-time signals only.
+- [ ] Soak tests run for hours and exercise the leak and degradation failure modes that shorter tests miss.
+- [ ] Performance testing is paired with observability for production validation. The two compose; neither replaces the other.
+- [ ] Stress and breakpoint tests are run to characterize failure mode and capacity ceiling. A system whose failure mode is unknown cannot be operated.
+
+## Do NOT Use When
+
+| Instead of this skill | Use | Why |
+|---|---|---|
+| Profiling and optimizing a specific slow path once located | `performance-engineering` | performance-engineering is the optimization activity itself; this skill is the load-driven measurement that locates and quantifies what to optimize |
+| Declaring the threshold-and-consequence contract (metric, threshold, percentile, consequence) | `performance-budgets` | performance-budgets owns the contract; this skill verifies the contract holds under load |
+| Measuring real production traffic in real time | `observability` or `error-tracking` | observability owns runtime measurement; this skill owns offline controlled measurement |
+| Benchmarking a single function or implementation | language-level benchmark tools | benchmarks isolate; this skill measures the assembled system |
+| Injecting failures into a running system | `chaos-engineering` (when it exists) | chaos is fault injection; this skill is load measurement |
+| Testing the test suite's quality | `mutation-testing` | mutation measures test-suite effectiveness; this skill measures system performance |
+| Choosing the test-level ratio | `testing-strategy` | strategy owns ratios; this skill is one technique within them |
+| Testing internal seams between modules | `integration-test-design` | integration owns correctness across seams; this skill owns load behavior |
+| Testing user journeys end-to-end | `e2e-test-design` | e2e owns user-perceived behavior; "performance e2e" composes both |
+
+## Key Sources
+
+- Grafana Labs / k6 Team. ["k6 Documentation"](https://k6.io/docs/). Canonical reference for the modern JavaScript-scriptable load testing tool; covers the six load shapes and the SLO-as-test-target discipline.
+- Apache Software Foundation. ["Apache JMeter — User Manual"](https://jmeter.apache.org/usermanual/). Canonical reference for the most-established cross-protocol performance testing tool.
+- Locust Team. ["Locust Documentation"](https://docs.locust.io/). Reference for the Python-scriptable distributed load testing tool.
+- Gatling Team. ["Gatling Documentation"](https://gatling.io/docs/). Reference for the high-performance Scala-based load testing tool.
+- Dean, J., & Norvig, P. ["Latency Numbers Every Programmer Should Know"](https://gist.github.com/jboner/2841832). Industry-canonical reference table for the latency scales that performance testing measures against.
+- Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016). *Site Reliability Engineering*. O'Reilly. Google SRE book; chapter on SLOs as the contract performance tests verify against.
+- Brendan Gregg. ["The USE Method: A method for analyzing system performance"](https://www.brendangregg.com/usemethod.html). The Utilization-Saturation-Errors framework that underlies systematic performance analysis.
+- Tene, G. ["How NOT to Measure Latency"](https://www.youtube.com/watch?v=lJ8ydIuPFeU). The canonical talk on percentile latency, coordinated omission, and the misleading nature of average-latency reporting.
+- Smith, C. U., & Williams, L. G. (2002). *Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software*. Addison-Wesley. Foundational reference on performance engineering methodology.
+- Kounev, S., Lange, K.-D., & von Kistowski, J. (2020). *Systems Benchmarking: For Scientists and Engineers*. Springer. Modern reference on performance testing methodology and benchmark design.

package/marketplace/skills/printify/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: printify
+description: "Use when working with Printify — the print-on-demand REST API, catalog model (blueprints, print providers, variants, print areas), product creation and publish lifecycle to connected channels, order routing, shipping cost queries, and HMAC SHA-256 webhook verification. Do NOT use for non-Printify POD vendors, generic Shopify storefront work, or print-file (artwork) generation."
+license: CC-BY-4.0
+metadata:
+  metadata: "{\"schema_version\":6,\"version\":\"1.0.0\",\"type\":\"capability\",\"category\":\"engineering\",\"domain\":\"engineering/integrations\",\"scope\":\"portable\",\"owner\":\"skill-graph-maintainer\",\"freshness\":\"2026-05-12\",\"drift_check\":\"{\\\\\\\"last_verified\\\\\\\":\\\\\\\"2026-05-12\\\\\\\"}\",\"eval_artifacts\":\"planned\",\"eval_state\":\"unverified\",\"routing_eval\":\"absent\",\"stability\":\"experimental\",\"keywords\":\"[\\\\\\\"printify api\\\\\\\",\\\\\\\"print on demand\\\\\\\",\\\\\\\"printify blueprints\\\\\\\",\\\\\\\"printify print providers\\\\\\\",\\\\\\\"printify publish lifecycle\\\\\\\",\\\\\\\"printify webhooks\\\\\\\",\\\\\\\"printify variants\\\\\\\",\\\\\\\"printify shipping costs\\\\\\\",\\\\\\\"printify order routing\\\\\\\",\\\\\\\"print provider catalog\\\\\\\"]\",\"triggers\":\"[\\\\\\\"printify\\\\\\\",\\\\\\\"printify api\\\\\\\",\\\\\\\"printify webhook\\\\\\\",\\\\\\\"print on demand\\\\\\\"]\",\"examples\":\"[\\\\\\\"Create a Printify product from a blueprint + print provider + variant set and publish it to a connected Shopify store\\\\\\\",\\\\\\\"Handle a Printify order:updated webhook and reconcile fulfillment status\\\\\\\",\\\\\\\"Resolve shipping cost for a basket of Printify variants given a destination country\\\\\\\"]\",\"anti_examples\":\"[\\\\\\\"Generate the artwork PNG file that gets uploaded as a print file\\\\\\\",\\\\\\\"Implement the Shopify side of the Printify-to-Shopify sync\\\\\\\",\\\\\\\"Design a generic POD-vendor-agnostic product schema\\\\\\\"]\",\"relations\":\"{\\\\\\\"related\\\\\\\":[\\\\\\\"shopify\\\\\\\",\\\\\\\"webhook-integration\\\\\\\",\\\\\\\"api-design\\\\\\\"],\\\\\\\"boundary\\\\\\\":[{\\\\\\\"skill\\\\\\\":\\\\\\\"shopify\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"Printify publishes to Shopify (and other channels) but the Shopify-side concerns — theme display, Shopify webhooks, Admin API — belong in the shopify skill.\\\\\\\"},{\\\\\\\"skill\\\\\\\":\\\\\\\"webhook-integration\\\\\\\",\\\\\\\"reason\\\\\\\":\\\\\\\"webhook-integration covers vendor-neutral signing/retry patterns; this skill handles Printify's specific event types and signature scheme.\\\\\\\"}]}\",\"skill_graph_source_repo\":\"https://github.com/jacob-balslev/skill-graph\",\"skill_graph_protocol\":\"Skill Metadata Protocol v5\",\"skill_graph_project\":\"Skill Graph\",\"skill_graph_canonical_skill\":\"skills/printify/SKILL.md\"}"
+  skill_graph_source_repo: "https://github.com/jacob-balslev/skill-graph"
+  skill_graph_protocol: Skill Metadata Protocol v4
+  skill_graph_project: Skill Graph
+  skill_graph_canonical_skill: skills/printify/SKILL.md
+---
+
+# Printify
+
+## Coverage
+The Printify REST API exposes a catalog (blueprints — abstract product templates like "Unisex Heavy Cotton Tee"; print providers — fulfillment partners who manufacture a given blueprint; variants — concrete color/size combinations a provider offers for a blueprint), shops (connected sales channels: Shopify, Etsy, WooCommerce, eBay, TikTok, custom API), products (a blueprint + print provider + variant selection + print areas + images, owned by a Printify shop), and orders (created either by sync from a connected channel or directly via API for merchant-fulfilled flows). This skill covers the relationships between these resources and the lifecycle transitions that move a product from draft to published to live on a storefront.
+
+Authentication is a personal access token in the Authorization: Bearer header. The API is versioned via URL path (currently /v1/) and rate-limited globally with documented limits per endpoint family — product creation is more constrained than read calls. Image uploads go through a dedicated upload endpoint that accepts either a public URL or base64 contents and returns an image ID referenced by subsequent product-create payloads.
+
+The publish lifecycle is a two-step asynchronous operation. POST to /products marks a product as ready for publish in Printify; the actual push to the connected channel (e.g., creating the Shopify product) happens via /products/{id}/publish which returns immediately and resolves asynchronously. The channel push can fail independently (channel auth expired, blueprint not available in the target region) and must be observed via the publishing-succeeded / publishing-failed webhook events or by polling the product publish status. Unpublish and delete each have their own semantics — unpublish removes from the channel but keeps the product in Printify; delete removes both.
+
+Webhooks deliver order, product, and shop events. Each delivery includes an X-Pfy-Signature header computed as HMAC SHA-256 over the raw body with the webhook secret returned on subscription. Order events (order:created, order:updated, order:sent-to-production, order:shipment:created, order:shipment:delivered, order:cancelled) carry the full order payload including line items with print provider, shipping cost, and tracking. Shipping cost can also be computed pre-purchase via /shops/{shop_id}/orders/shipping.json with a destination address and line items.
+
+## Philosophy
+Printify sits between the merchant and the print provider, and its catalog reflects that — a blueprint's available variants and print areas are determined by the print provider, not by Printify. The same blueprint produced by two providers can have different color availability, different print area dimensions, and different shipping profiles. Integrations should treat blueprint + print_provider as a composite key and never assume that variants are portable across providers.
+
+The publish lifecycle is asynchronous and partially observable. Treat publish success as a separate state from product-create success, and reconcile via webhooks rather than optimistic UI. Costs (product cost, shipping cost) are determined at order-create time by Printify and can differ from any pre-quoted estimate; the order webhook payload is the source of truth for actual cost.
+
+## Verification
+- Webhook signature verification computes HMAC SHA-256 over the raw body bytes with the per-subscription secret and uses constant-time comparison against the X-Pfy-Signature header.
+- Product creation supplies a valid (blueprint_id, print_provider_id) pair from the print provider's variant list — invalid pairs return 400 with the unsupported variant ID, not a generic error.
+- Publish status is reconciled via the publishing-succeeded webhook before the product is marked live in the integrating system; status defaults to pending and stays there if the webhook is missed.
+- Image uploads complete and return an image ID before the product-create call references it; race conditions return 404 on the image reference.
+- Shipping cost queried via /shipping.json uses the same address fields the order will eventually carry; mismatched country/region codes silently route to default shipping profiles.
+- Order webhooks are idempotent at the consumer — the same event ID can be delivered more than once on retry.
+
+## Do NOT Use When
+- The print-on-demand vendor is Printful, Gelato, CustomCat, or any non-Printify provider. Each has a different catalog model, signing scheme, and publish lifecycle.
+- The task is generating the print artwork itself (PNG/SVG creation, DPI handling, color-profile conversion). That is a graphics-generation task, not a Printify task.
+- You are working on the Shopify-side of a Printify→Shopify sync (theme display, Shopify product overrides). Use the shopify skill.
+- The work is vendor-agnostic webhook plumbing (retry, dead-letter, signing-key rotation across many providers). Use webhook-integration.
+- You are designing the merchant's internal order schema. Use event-contract-design.

package/marketplace/skills/prioritization/SKILL.md

@@ -0,0 +1,118 @@
+---
+name: prioritization
+description: "This skill provides prioritization frameworks for AI engineering: RICE-A (adding AI Ambiguity to RICE) for product features, ICE for research experiments, and MoSCoW for MVP/Release scoping. Use when ranking the backlog, deciding which model research path to follow, or defining the scope of a new feature. Do NOT use for one-off task sequencing (use task skill) or personal time management."
+license: MIT
+compatibility: "Markdown, Git, agent-skill runtimes"
+allowed-tools: Read Grep Bash
+metadata:
+  metadata: "{\"schema_version\":6,\"version\":\"1.0.0\",\"type\":\"capability\",\"category\":\"quality\",\"domain\":\"quality/doctrine\",\"scope\":\"reference\",\"owner\":\"skill-graph-maintainer\",\"freshness\":\"2026-03-27\",\"drift_check\":\"{\\\\\\\"last_verified\\\\\\\":\\\\\\\"2026-03-27\\\\\\\"}\",\"eval_artifacts\":\"planned\",\"eval_state\":\"unverified\",\"routing_eval\":\"absent\",\"stability\":\"experimental\",\"keywords\":\"[\\\\\\\"prioritization\\\\\\\",\\\\\\\"RICE\\\\\\\",\\\\\\\"ICE\\\\\\\",\\\\\\\"MoSCoW\\\\\\\",\\\\\\\"RICE-A\\\\\\\",\\\\\\\"AI ambiguity\\\\\\\",\\\\\\\"feature ranking\\\\\\\",\\\\\\\"research prioritization\\\\\\\",\\\\\\\"backlog management\\\\\\\",\\\\\\\"MVP scope\\\\\\\"]\",\"triggers\":\"[\\\\\\\"prioritization-skill\\\\\\\",\\\\\\\"roadmap-skill\\\\\\\",\\\\\\\"priority-planning-mode\\\\\\\"]\",\"relations\":\"{\\\\\\\"related\\\\\\\":[\\\\\\\"constraint-awareness\\\\\\\"]}\",\"portability\":\"{\\\\\\\"readiness\\\\\\\":\\\\\\\"scripted\\\\\\\",\\\\\\\"targets\\\\\\\":[\\\\\\\"skill-md\\\\\\\"]}\",\"lifecycle\":\"{\\\\\\\"stale_after_days\\\\\\\":90,\\\\\\\"review_cadence\\\\\\\":\\\\\\\"quarterly\\\\\\\"}\",\"skill_graph_source_repo\":\"https://github.com/jacob-balslev/skill-graph\",\"skill_graph_protocol\":\"Skill Metadata Protocol v5\",\"skill_graph_project\":\"Skill Graph\",\"skill_graph_canonical_skill\":\"skills/prioritization/SKILL.md\"}"
+  skill_graph_source_repo: "https://github.com/jacob-balslev/skill-graph"
+  skill_graph_protocol: Skill Metadata Protocol v4
+  skill_graph_project: Skill Graph
+  skill_graph_canonical_skill: skills/prioritization/SKILL.md
+---
+# Prioritization
+
+## Domain Context
+
+**What is this skill?** This skill provides prioritization frameworks for AI engineering: RICE-A (adding AI Ambiguity to RICE) for product features, ICE for research experiments, and MoSCoW for MVP/Release scoping. Use when ranking the backlog, deciding which model research path to follow, or defining the scope of a new feature. Do NOT use for one-off task sequencing (use task skill) or personal time management.
+
+## Workflow
+
+Use the ordered phases, checklists, and guardrails in the sections below as the canonical workflow for this skill. When multiple subsections describe steps, follow them in the order presented.
+
+## Coverage
+
+Three prioritization frameworks (RICE-A, ICE, MoSCoW), the Human vs AI Matrix for task delegation, accuracy threshold setting to prevent scope creep, and framework selection rules for matching the right framework to the current development phase.
+
+## Philosophy
+
+Without explicit prioritization frameworks, agents default to working on whatever seems most interesting or most recently mentioned. In AI-assisted development, this is especially dangerous because research tasks have unbounded ambiguity. The RICE-A extension adds an Ambiguity denominator that forces experimental work through a research phase before it competes with proven features for engineering time. This skill prevents the two most common prioritization failures: shipping low-confidence features ahead of proven ones, and chasing diminishing accuracy returns instead of delivering core value.
+
+> Prioritization is the science of ranking work by expected impact vs. effort. In AI development, traditional prioritization fails because it ignores research uncertainty. Good prioritization accounts for model ambiguity while maximizing the delivery of core product value.
+
+## 1. RICE-A Framework — Product Feature Prioritization
+
+Use for ranking user-facing features when you have a baseline model.
+
+$$Score = \frac{Reach \times Impact \times Confidence}{Effort \times (\frac{Ambiguity}{2})}$$
+
+### RICE-A Definitions
+
+| Factor | Definition | Scale |
+|--------|------------|-------|
+| **Reach** | Users/quarter affected | Absolute number |
+| **Impact** | Contribution to core value proposition | 3 (Massive) to 0.25 (Minimal) |
+| **Confidence** | Data quality & baseline model presence | 100% (Proven) to 50% (Guess) |
+| **Effort** | Person-weeks (Inference + Data effort) | Number |
+| **Ambiguity** | "Unknown unknowns" of model performance | 1 (Deterministic) to 5 (Highly Experimental) |
+
+**Rule**: A high Ambiguity (A) score acts as a denominator that lowers the priority of experimental features until they move through the ICE research phase.
+
+## 2. ICE Framework — Research Prioritization
+
+Use for ranking 10+ experiments when you are in the "Discovery" phase.
+
+$$Score = Impact \times Confidence \times Ease$$
+
+| Factor | Scale (1-10) | Definition |
+|--------|--------------|------------|
+| **Impact** | 1-10 | How much does this improve the baseline metric? |
+| **Confidence** | 1-10 | How sure are we that this experiment will succeed? |
+| **Ease** | 1-10 | How fast can we run this experiment (ignoring long-term COGS)? |
+
+**Rule**: ICE is for "fail-fast" research. Prioritize the highest score to find the working model architecture before applying RICE-A for product integration.
+
+## 3. MoSCoW Method — MVP/Release Scoping
+
+Use for defining the "Musts" of a specific delivery milestone.
+
+| Category | Definition | AI Example |
+|----------|------------|------------|
+| **Must-Have** | Non-negotiable core functionality | "Model must correctly calculate profit_cents" |
+| **Should-Have** | High priority but not critical for launch | "Latency should be < 2s for 95% of queries" |
+| **Could-Have** | Desirable enhancements ("Nice-to-have") | "Multi-modal image support for product matching" |
+| **Won't-Have** | Out of scope for this milestone | " chasing the final 0.1% of accuracy" |
+
+**Rule**: Protect the team from "Accuracy Creep". Define the "Must-Have" accuracy threshold before starting implementation.
+
+## 4. The Human vs. AI Matrix (The Gold Quadrant)
+
+Prioritize work based on who is best suited for the task.
+
+```text
+       High |  (1) AI ASSISTED       |  (2) THE GOLD QUADRANT 
+Human       |  (Research, Strategy)  |  (Bulk Gen, Triage, Tests)
+Effort      |------------------------|--------------------------
+            |  (3) IGNORE            |  (4) HUMAN ONLY
+       Low  |  (Trivial Tasks)       |  (Creative, High-Stakes)
+            ----------------------------------------------------
+                   High              Low
+                       AI Effort
+```
+
+- **The Gold Quadrant**: High Human Effort / Low AI Effort. These tasks have the highest ROI for AI agents (e.g., generating 50 tests, triaging 1000 logs).
+
+## Verification
+
+```text
+PRIORITIZATION CHECK
+====================
+[ ] Framework matches the phase (ICE for Research, RICE-A for Product)
+[ ] Ambiguity (A) score assigned for experimental features
+[ ] Confidence score grounded in data quality (not just vibes)
+[ ] MoSCoW defined for the current milestone
+[ ] Accuracy threshold set (prevents Accuracy Creep)
+[ ] Task sits in the "Gold Quadrant" for AI agents
+```
+
+## Do NOT Use When
+
+| Instead of this skill | Use | Why |
+|---|---|---|
+| Sequencing tasks within a single sprint or session | `task` | Task skill owns execution ordering; prioritization owns which work to pick |
+| Estimating effort for individual tasks | `effort` | Effort calibration is a separate concern from priority ranking |
+| Competitive positioning or market strategy | `competitive-positioning` | Business strategy informs priority inputs but is not the framework itself |
+| Defining product requirements or specifications | `spec-driven-development` | Prioritization ranks work; SDD defines what the work contains |
+
+> **Source**: `REPORTS/Report_UI-UX-Thesis-Audit_Gemini-3-Flash_13-03-2026-05-15.md`