Object storage visualization pattern
Skill kjuhwa/skills-hub/skills/design/object-storage-visualization-pattern
Self-correcting knowledge corpus for Claude Code — 9 stable shape clusters, bias-correction pipeline baked into contribution flow. 47 papers, 45 techniques, 1.1k skills.
npx -y skills add kjuhwa/skills-hub --skill object-storage-visualization-patternAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Canvas/SVG patterns for visualizing object storage buckets, objects, and replication topologies
SKILL.md
2.1 KB, 357 tokens by cl100k_base, as published. Nobody here has run it
object-storage-visualization-pattern
Object storage visualizations must represent three distinct abstraction layers simultaneously: the flat bucket namespace (no true hierarchy), synthetic prefix-based "folders" derived from key delimiters (e.g., photos/2026/), and the underlying storage class tier (Standard, IA, Glacier, Deep Archive). Use a treemap or icicle chart for prefix exploration where rectangle area encodes cumulative object size and color encodes storage class — this maps naturally to how S3/GCS/Azure Blob actually organize data. Avoid tree-view UIs that imply real directories; instead render prefixes as breadcrumb pills with object-count badges so users retain the mental model that "folders" are a client-side illusion built from key prefixes.
For replication and cost views, use a node-link diagram where nodes are regional buckets (labeled with region code + storage class) and edges are replication rules annotated with RPO, filter prefix, and cross-region egress cost per GB. Animate object flow along edges using particle streams whose density reflects PUT rate, and color-code by replication status (PENDING / REPLICA / FAILED) — this is the only way users can spot stuck replication queues at a glance. For cost simulators, stack bars by cost component (storage, Class-A requests, Class-B requests, egress, early-deletion fees) because users consistently underestimate request and egress costs relative to raw storage.
Always expose the key schema explicitly in the UI (e.g., {tenant}/{yyyy}/{mm}/{dd}/{uuid}.parquet) because lifecycle rules, replication filters, and cost attribution all hinge on prefix patterns. Provide a "key pattern editor" with live preview showing which objects match — this is the single most valuable interaction across all three apps.