-
Notifications
You must be signed in to change notification settings - Fork 44
Patterns Analysis ‐ August 2026 ‐ Development
| # | Pattern | Passes | Fails | Note |
|---|---|---|---|---|
| 1 | avoid-tracking-unnecessary-data | 7 | 1,5,9,10 | Revision |
| 2 | cache-static-data | 8 | 5,8,10 | Minor revision |
| 3 | compress-stored-data | 9 | 5,10 | Near-ready |
| 4 | compress-transmitted-data | 7 | 5,8,10,11 | Consolidate |
| 5 | optimize-data-storage-ai-training | 10 | 2 | Near-ready |
| 6 | reduce-transmitted-data | 7 | 5,8,10,11 | Consolidate |
| 7 | evaluate-whether-to-use-TLS-termination | 7 | 5,7,8,10 | Revision |
| 8 | defer-offscreen-images | 7 | 1,5,9,10 | Revision |
| 9 | deprecate-gifs | 6 | 1,5,8,9,10 | Revision |
| 10 | properly-sized-images | 6 | 1,5,8,9,10 | Revision |
| 11 | remove-unused-css | 7 | 5,8,10,11 | Revision |
| 12 | serve-images-in-modern-formats | 7 | 5,8,9,10 | Revision |
| 13 | use-compiled-languages | 9 | 5,10 | Near-ready |
| 14 | minimizing-deployed-environments | 8 | 5,8,10 | Minor revision |
| 15 | optimize-agent-orchestration-reduce-model-calls | 10 | 6 | Near-ready (+ fix markdown bug) |
| 16 | pre-trained-transfer-learning | 11 | none | Publication ready |
| 17 | right-sized-energy-efficient-ai-models | 9 | 6,11 | Near-ready / consolidation |
| 18 | select-efficient-ml-frameworks-inference-runtimes | 9 | 2,6 | Near-ready |
| 19 | use-async-instead-of-sync | 7 | 4,5,9,10 | Revision |
| 20 | avoid-chaining-critical-requests | 8 | 5,8,10 | Minor revision |
| 21 | avoid-excessive-dom-size | 7 | 2,5,9,10 | Revision |
| 22 | enable-text-compression | 6 | 5,8,9,10,11 | Consolidate |
| 23 | keep-request-counts-low | 5 | 1,5,7,8,10,11 | Revision |
| 24 | minify-web-assets | 4 | 1,5,7,8,9,10,11 | Substantial revision |
| 25 | minimize-main-thread-work | 8 | 5,9,10 | Minor revision |
| 26 | use-server-side-rendering | 8 | 5,8,10 | Minor revision |
1. Two confirmed duplication clusters, both spanning subfolders:
-
Transmitted-data reduction (3-way):
compress-transmitted-data.mdandreduce-transmitted-data.md(near-identical Description text, same author/date) plusenable-text-compression.md(web-performance) as the HTTP-specific instance of the same compression idea. Recommend consolidating into one "Reduce transmitted data" pattern covering compression and payload-trimming as named techniques, with HTTP-specific compression as a considerations note rather than a separate title. -
AI/ML model efficiency (cross-category):
right-sized-energy-efficient-ai-models.md(this category, modern, thorough) substantially supersedes Architecture'senergy-efficent-models.md(2022, thin, cites now-dated specific models). This closes the loop on a question raised in the earlier Architecture review.
2. The "many narrow patterns instead of fewer, broader ones" problem is concentrated in media-and-code-efficiency and web-performance. Both folders read like a performance-audit checklist translated 1:1 into patterns (four separate image patterns; seven separate single-technique web-perf patterns, several with literal "None" or blank Assumptions/Considerations sections). Worth a team conversation about consolidating into 2-3 broader patterns per theme (e.g., "Optimize image delivery" covering lazy-loading/sizing/format/GIF-replacement; "Reduce page weight" covering minification/unused-CSS-removal/request-count; "Optimize the critical rendering path" covering chaining/DOM-size/main-thread-work) rather than doing narrow revision on each of the ~10 thinnest patterns individually.
3. Missing Cost Impact remains the single most common failure — 22 of 26 patterns lack it, consistent with the pattern seen in Requirements and Architecture (older, pre-2024 submissions systematically missing this section). Two omissions stand out as unusually consequential given the specific pattern's subject matter: use-compiled-languages.md (never mentions the real cost of rewriting an application in a different language) and use-server-side-rendering.md (never quantifies the server-compute-cost side of the very client-to-server compute shift the pattern proposes).
4. Two confirmed "Patterns, not Practices" violations via framework/product-naming (distinct from the vague-language violations seen elsewhere): avoid-excessive-dom-size.md names Angular's component dev kit and the react-window library directly in its Solution, and select-efficient-ml-frameworks-inference-runtimes.md names six specific commercial products densely enough to read as a buyer's guide.
5. Minor mechanical issues worth fixing regardless of principle scoring: use-async-instead-of-sync.md's title breaks the sentence-casing rule ("Use Asynchronous..."), and optimize-agent-orchestration-reduce-model-calls.md has a literal duplicated ## Considerations markdown header.
6. Best patterns in the category: pre-trained-transfer-learning (11/11 — the best pattern found across all four categories reviewed so far), optimize-data-storage-ai-training (10/11), and optimize-agent-orchestration-reduce-model-calls (10/11) — all from the same modern AI-focused submission batch that also produced the standout patterns in the Architecture review.
cache-static-data — title is literally the skill's own good-example title. Excellent, honest Considerations (correctly warns that using external cache infrastructure instead of local in-memory cache "may not reduce [SCI] considerably" — a genuinely sophisticated self-critique). Fails: no Cost Impact (5,10); Assumptions is a narrative hypothetical, not a stated testable condition (8).
compress-stored-data — one of the best legacy patterns reviewed: Assumptions honestly notes you sometimes have no choice about compression ("if you have a limited amount of storage space, you will be forced to use a high compression even when a high CPU is required"), and Considerations names the exact right trade-off (CPU/RAM cost of compress/decompress vs. storage savings). Only fails on missing Cost Impact (5,10).
compress-transmitted-data and reduce-transmitted-data — Evidence of duplication: both by the same author (greenhsu123), same date (2022-11-10), with near-verbatim identical Description text differing only in British/American spelling ("minimise"/"minimize"). They cover genuinely different mechanisms (compress the payload vs. trim unnecessary fields/properties from it), but the copy-paste-identical framing strongly suggests these were meant as two techniques within one broader "reduce transmitted data volume" pattern rather than separate titles. Both also fail 5, 8 (narrative, non-testable Assumptions), 10 for the same reasons as their siblings. enable-text-compression (web-performance) is a third, HTTP-specific instance of the same compression idea — see cross-cutting note.
optimize-data-storage-ai-training — strong, modern, complete pattern (full Cost Impact, honest vector-DB-licensing trade-off). Only fails Principle 2: it names specific commercial products (Milvus, Pinecone, Parquet, ORC, FAISS) densely enough, including in the Cost Impact's licensing line, that it edges from "pattern" toward "buyer's guide."
avoid-tracking-unnecessary-data — thin (Solution is one sentence that just restates the title); Considerations doesn't name the real trade-off this pattern actually has — reduced tracking often means reduced ad revenue/personalization capability for the product, which goes completely unacknowledged (9, 10). No Cost Impact (5).
This subfolder is where the "narrow micro-pattern instead of fewer/broader" problem (Principle 1) shows up most: defer-offscreen-images, deprecate-gifs, and properly-sized-images are each a single short technique with an empty or near-empty Assumptions/Considerations section, arguably three facets of one broader "Optimize image delivery" pattern (see cross-cutting note).
- defer-offscreen-images: Considerations explicitly "None" — doesn't mention the real, well-known complication that lazy-loading without reserved image dimensions causes layout shift (CLS).
- deprecate-gifs: Assumption ("the web browser must support the new format") is nearly universal/untestable given near-total modern browser support — doesn't name a real gating condition.
-
properly-sized-images: Assumptions explicitly "None," despite SCI Impact itself honestly flagging a real counter-effect (
Mincreases from storing multiple cached image sizes) that never gets carried into a proper trade-off discussion. - serve-images-in-modern-formats: sole Consideration is a cross-reference to minification, not a real complication (doesn't mention needing a fallback path for the small remaining legacy-browser share).
-
remove-unused-css: genuinely good idea in Considerations (crafting specialized CSS per high-traffic landing page), but Assumptions is explicitly "None" despite an obvious real one being available ("you have tooling to reliably detect dynamically-added CSS classes as 'used'"). Also overlaps thematically with
minify-web-assets(web-performance) — both shrink CSS/JS payload, filed in different subfolders. - use-compiled-languages — the strongest pattern in this subfolder: Assumptions honestly names a real counter-example (compiled languages aren't usable in web browsers) and recommends benchmarking first; Considerations names GraalVM as a genuine middle path. Its one real gap is significant, though: no Cost Impact, and this pattern's real-world cost (rewriting/porting an application to a different language) is arguably the single largest implementation cost of any pattern reviewed in this whole exercise, yet it goes completely unmentioned.
pre-trained-transfer-learning — passes all 11 principles. Considerations honestly flags that "fine-tuning large foundation models can still require substantial compute resources comparable to training from scratch" — exactly the kind of non-obvious, real complication the framework wants, and one that directly tempers the pattern's own headline claim. This is the strongest pattern found across every category assessed so far in this whole review (Requirements, Architecture, Design, Development). Publication ready.
right-sized-energy-efficient-ai-models — excellent content (its Assumption — "Smaller or optimized models can meet the functional requirements" — is literally the skill's own quoted good example of a testable assumption). Fails Principle 6 (9 Solution bullets + 6 Considerations, several redundant) and Principle 11: this pattern substantially duplicates/supersedes Architecture's energy-efficent-models.md (2022, thin, names now-dated specific models like GPT-Neo/GPT-J with "Assumptions: None"). This resolves an open question flagged in the earlier Architecture review — recommend retiring or merging that older pattern into this one.
select-efficient-ml-frameworks-inference-runtimes — thorough and honest (Considerations names hardware-specific runtime lock-in, e.g. TensorRT/Apple Metal, as a real risk). Fails Principle 2 — the highest density of named commercial products/frameworks of any pattern reviewed (ONNX Runtime, TensorRT, OpenVINO, PyTorch, TensorFlow all named directly in Solution/Considerations) — and Principle 6 (8 Solution bullets, several overlapping).
optimize-agent-orchestration-reduce-model-calls — excellent, thorough, honest (explicitly warns "avoid over-optimizing at the expense of output quality"). Fails only Principle 6 (10 Solution bullets is well past "three strong points"). Separately, worth flagging as a fix-it item regardless of principle scoring: the file has a literal duplicated ## Considerations header (lines 67 and 69) — a markdown authoring bug that should be cleaned up before publication.
minimizing-deployed-environments — genuinely good Considerations (names the real bottleneck risk of losing a dedicated QA/perf-testing environment). Fails: no Cost Impact (5,10); Assumptions is a narrative hypothetical, not a testable statement (8).
use-async-instead-of-sync — fails Principle 4 on a mechanical, checkable basis: the title "Use Asynchronous network calls instead of synchronous" breaks the explicit sentence-casing formatting rule (should read "Use asynchronous network calls..."). Also fails 9/10 — Considerations doesn't mention the real, well-known cost of async code (harder debugging, race conditions, callback/promise complexity), and there's no Cost Impact.
evaluate-whether-to-use-TLS-termination — same author (yelghali) as evaluate-using-a-service-mesh.md (Architecture), and it repeats the exact same vague-assumption pattern: "The application does not have compliance requirements for using end-to-end TLS" — the literal bad example the skill itself warns against. It also never names the real security-risk trade-off (unencrypted internal traffic between gateway and workload is a genuine attack-surface increase) anywhere, despite that being arguably the pattern's most important cost.
This folder is where the "many narrow micro-patterns" problem is most acute — nearly every pattern here maps 1:1 to a single Lighthouse/web.dev audit item (the References sections literally link to web.dev/offscreen-images, web.dev/unused-css-rules, web.dev/dom-size, web.dev/mainthread-work-breakdown, web.dev/resource-summary, etc.), suggesting the folder was seeded from a performance-audit checklist rather than authored as broader, coherent patterns.
- avoid-chaining-critical-requests — reasonably solid; single Consideration usefully scopes the pattern ("some chains may be necessary... focus is avoidance, not elimination"). Fails 5, 8, 10 (no Cost Impact; generic, near-universal Assumption).
- avoid-excessive-dom-size — clear Principle 2 violation: Solution names specific frameworks and a specific library by name — "Angular: Use virtual scrolling with the component dev kit" / "React: Use 'windowing' libraries like react-window" — this is framework-specific implementation detail, exactly what the skill's Patterns-not-Practices rule prohibits. Considerations section is also present but entirely empty.
-
enable-text-compression — Considerations section present but completely empty; Assumption ("use of web servers that allow compression formats") is nearly tautological, missing the one fact that actually matters here (already-compressed formats like JPEG/MP4 gain nothing from additional text compression). Confirmed duplication with
compress-transmitted-data.md(data-handling) — this is the HTTP-specific instance of that same broader compression pattern. - keep-request-counts-low — Assumptions section header present but completely blank (more extreme than "None" — no content at all). Doesn't mention that HTTP/2+ multiplexing substantially changes the cost-benefit of request-count bundling, a significant and dating omission.
- minify-web-assets — the thinnest pattern in this whole category: "Assumptions: None," "Considerations: None," no Cost Impact. Weakest pattern in Development.
- minimize-main-thread-work — actually one of the better web-perf patterns: gives a genuinely specific, actionable threshold ("computations that run longer than a few 100 ms"), unusually concrete compared to most patterns in this review. Fails only on missing Cost Impact and a thin Considerations (doesn't mention Web Worker message-passing/serialization overhead).
- use-server-side-rendering — the best-titled pattern in the folder (bakes its own scope, "for high-traffic pages," directly into the title — a good practice most other patterns in this review skip). But its Assumption ("visited in high enough volumes") never quantifies "high enough," and critically, no Cost Impact section exists despite this pattern being explicitly about shifting compute cost from many clients to concentrated servers — arguably the single most cost-relevant trade-off of any pattern in this whole review, and it's entirely unaddressed.