[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JWMZ96P7S79B6ECG2CJQSH":3,"skill-same:01M6JWMZ96P7S79B6ECG2CJQSH":84},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":62,"updatedAt":63,"install":64,"resources":77},"01M6JWMZ96P7S79B6ECG2CJQSH","scaling-load-assumptions",null,"Verify and design for load scaling — data volume, transaction volume, request rate, and user count. Use when sizing infrastructure, choosing data structures, designing pagination and lazy-loading patterns, evaluating dependencies' rate limits, or load-testing before launch. Most scaling failures are load failures: a system that handled X requests\u002Fsecond can't handle 10X. The skill is anticipating the load the system will see and designing or testing for it deliberately.","hashgraph-online\u002Fawesome-codex-plugins","hashgraph-online","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F160371962?v=4","01M6CNB6NRJVNNGN14TR01Q6D3","HOL (Hashgraph Online)","01M6JT1HSKKG9V68KQAQGBA7XP",1559,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Fscaling-load-assumptions\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000008","测试与质量","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"scaling load assumptions","load","scaling","data structures","when","limits","count","request","rate","lazy","lazy-loading","for","can","loading","testing","volume","transaction","patterns","use","10x","system","load-testing","data","infrastructure","design","2026-11-10 10:12:30",false,"---\nname: scaling-load-assumptions\ndescription: 'Verify and design for load scaling — data volume, transaction volume, request rate, and user count. Use when sizing infrastructure, choosing data structures, designing pagination and lazy-loading patterns, evaluating dependencies'' rate limits, or load-testing before launch. Most scaling failures are load failures: a system that handled X requests\u002Fsecond can''t handle 10X. The skill is anticipating the load the system will see and designing or testing for it deliberately.'\n---\n\n# Scaling — load assumptions\n\nThe first kind of scaling fallacy: assumptions about how the system will perform under load — data volume, request rate, user count, transaction volume. A system that handles current load gracefully may fail catastrophically at 10x or 100x load. Often the failure isn't a steady degradation but a sharp cliff: things work fine until the moment they don't.\n\nThe work of treating load assumptions is partly architectural (designing systems that scale) and partly verification (testing at production-like scale before launch).\n\n## Common load-scaling failures\n\n**Linear search on a growing dataset.** A simple \"search through all records\" works for small datasets and times out for large ones. Eventually requires indexing or dedicated search infrastructure.\n\n**N+1 query patterns.** A code pattern that issues one database query per item in a list. Fine for 10 items; catastrophic for 10,000.\n\n**Unbounded results.** \"Return all matching records\" fine for small queries; explodes when \"all matching\" is millions of rows.\n\n**Synchronous external API calls in a critical path.** Each call adds latency; under load, latency compounds and the system slows.\n\n**Naive caching.** Caching every request individually fills memory; cache eviction becomes the new bottleneck.\n\n**No backpressure.** A system that accepts requests faster than it can process them accumulates a backlog that grows without bound.\n\n**Single points of failure under load.** A single database that handles all writes; a single cache server that holds all sessions. Works under low load; catastrophically fails when load exceeds the single instance's capacity.\n\n**Inadequate rate limiting on dependencies.** A third-party API has a 1000 req\u002Fsec limit; the system makes 10,000 req\u002Fsec and gets throttled or blocked.\n\n## Patterns for load resilience\n\n**Pagination.** Don't return all results at once. Return a page of results with a cursor or offset for the next page. Forces the user (or client) to consume in chunks.\n\n**Lazy loading \u002F virtualization.** Load only what's currently visible. As the user scrolls, load more.\n\n**Indexing.** Database indexes make queries fast even at large data volumes. Search infrastructure (Elasticsearch, Algolia) for full-text queries.\n\n**Caching.** Store frequently-requested data in fast memory; serve from cache rather than recomputing or refetching.\n\n**Asynchronous processing.** Move expensive work to background queues. Respond quickly; process slowly.\n\n**Sharding \u002F partitioning.** Split data across multiple databases or storage units. Each shard handles a fraction of the load.\n\n**Read replicas.** Multiple read-only copies of the database; reads distributed across replicas; writes go to a single master.\n\n**Rate limiting.** Cap the request rate per user or per source. Prevents single users from consuming disproportionate resources.\n\n**Circuit breakers.** Detect when a dependency is failing or slow; stop calling it temporarily; resume when it recovers.\n\n**Graceful degradation.** When some services are slow, return partial results or cached results rather than failing entirely.\n\n**Auto-scaling.** Add capacity dynamically as load increases; remove when load decreases.\n\n**Load testing.** Simulate production-scale load in a non-production environment. Identify bottlenecks before they hit users.\n\n## Worked examples\n\n### A list view that breaks at scale\n\nA team builds a feature showing all activity in a user's account. With 100 events per account, the page loads in 200ms. With 100,000 events, the page takes 30 seconds and crashes the browser.\n\nThe fix: pagination (load 50 events per page) + virtualization (only render visible rows in the DOM) + filtering (let users narrow to specific event types). The system now scales to millions of events without breaking.\n\n### An N+1 query pattern\n\nAn ORM auto-generates queries that fetch one user's data per row. For a list of 1000 users, it makes 1001 database queries (1 for the list, then 1 per user for related data). Page load takes 8 seconds.\n\nThe fix: eager loading (fetch related data in a single query) + caching (store frequently-accessed user data). Page load drops to 200ms. Same result; very different performance.\n\n### A cache that becomes the bottleneck\n\nA team adds Redis caching to speed up database queries. Initially great. As traffic grows, the Redis instance starts to hit CPU and memory limits; queries are now slow because Redis is the bottleneck.\n\nThe fix: Redis cluster (multiple instances handling different keys), local in-process caching for the hottest data, and cache eviction policies. The cache is no longer a single bottleneck.\n\n### A third-party API rate limit\n\nA product depends on a payment-processing API with a 100 req\u002Fsec limit. During a holiday sale, peak traffic produces 1000 req\u002Fsec. The API throttles; transactions fail; users see errors.\n\nThe fix: queue payment requests locally; process them at the rate the API allows; show users an \"in progress\" state for delayed transactions. + Negotiate a higher rate limit with the provider. + Add a backup payment provider for failover.\n\n### A search query that times out\n\nA simple full-text search across user-generated content works fine at 100K records. As the corpus grows to 100M records, queries take 30 seconds.\n\nThe fix: dedicated search infrastructure (Elasticsearch) with proper indexing. Queries become sub-second even at billion-record scale.\n\n## Load testing patterns\n\n**Synthetic load testing.** Tools like JMeter, Gatling, or k6 simulate users making requests. Run at multiples of expected production load.\n\n**Production traffic mirroring.** Mirror real production traffic to a test environment. Tests with real-world request distributions.\n\n**Chaos engineering.** Deliberately fail components to verify the system handles failure gracefully. Netflix's Chaos Monkey is the canonical example.\n\n**Canary deployments.** Roll out new code to a small fraction of users first; verify it doesn't degrade under their load before rolling out broadly.\n\n**Stress testing to find the breaking point.** Increase load until the system fails. Document the breaking point; design to be safely below it.\n\n## Designing for load from the start\n\nWhen designing a new system or feature, ask:\n\n**What's the expected load in 6 months and 2 years?** Project upward; design with margin.\n\n**Which operations are likely to scale poorly?** Linear scans, all-results queries, N+1 patterns.\n\n**What's our story for handling 10x current load?** Adding capacity, sharding, caching, async processing.\n\n**What dependencies have load limits?** Identify and design around them.\n\n**How will we know when we're approaching limits?** Monitoring and alerts on the right metrics.\n\n## Anti-patterns\n\n**Premature optimization.** Adding complexity (caching, sharding) before measurements show it's needed. Better to start simple and add complexity when bottlenecks emerge — but design with the architectural choices that allow adding complexity later.\n\n**No load testing.** Shipping to production without verifying that the system handles realistic load. Hoping it'll be fine.\n\n**Underestimating peak traffic.** Designing for average load and being shocked when peak is 10x average. Most systems have peak\u002Faverage ratios of 3–10x; design accordingly.\n\n**Single instances of critical components.** A single database, a single cache server, a single application instance. Single points of failure under load.\n\n**Ignoring third-party limits.** Building features that depend on third-party APIs without checking their rate limits or planning for throttling.\n\n**Auto-scaling without budgets.** Auto-scaling is great until your bill becomes catastrophic. Set caps and alerts.\n\n## Heuristic checklist\n\nWhen designing for load, ask: **What's the projected load in the foreseeable future?** Design with margin. **Which operations scale linearly vs. non-linearly with input size?** Identify and improve the non-linear ones. **Have we load-tested at production-target scale?** If not, the load assumption is unverified. **What single points of failure exist?** Eliminate or accept the risk explicitly. **Do we have monitoring to detect approaching limits?** Surprises are costly.\n\n## Related sub-skills\n\n- `scaling-fallacy` — parent principle on the dangers of scale assumptions.\n- `scaling-interaction-assumptions` — sibling skill on user-base scaling.\n- `weakest-link` — load reveals weak links that were tolerable at small scale.\n- `factor-of-safety` — design with margin for the load you might see, not just the load you have.\n- `errors` — error handling becomes critical when load creates failure conditions.\n\n## See also\n\n- `references\u002Fload-test-patterns.md` — practical patterns for load testing and capacity planning.\n","# Scaling — load assumptions\n\nThe first kind of scaling fallacy: assumptions about how the system will perform under load — data volume, request rate, user count, transaction volume. A system that handles current load gracefully may fail catastrophically at 10x or 100x load. Often the failure isn't a steady degradation but a sharp cliff: things work fine until the moment they don't.\n\nThe work of treating load assumptions is partly architectural (designing systems that scale) and partly verification (testing at production-like scale before launch).\n\n## Common load-scaling failures\n\n**Linear search on a growing dataset.** A simple \"search through all records\" works for small datasets and times out for large ones. Eventually requires indexing or dedicated search infrastructure.\n\n**N+1 query patterns.** A code pattern that issues one database query per item in a list. Fine for 10 items; catastrophic for 10,000.\n\n**Unbounded results.** \"Return all matching records\" fine for small queries; explodes when \"all matching\" is millions of rows.\n\n**Synchronous external API calls in a critical path.** Each call adds latency; under load, latency compounds and the system slows.\n\n**Naive caching.** Caching every request individually fills memory; cache eviction becomes the new bottleneck.\n\n**No backpressure.** A system that accepts requests faster than it can process them accumulates a backlog that grows without bound.\n\n**Single points of failure under load.** A single database that handles all writes; a single cache server that holds all sessions. Works under low load; catastrophically fails when load exceeds the single instance's capacity.\n\n**Inadequate rate limiting on dependencies.** A third-party API has a 1000 req\u002Fsec limit; the system makes 10,000 req\u002Fsec and gets throttled or blocked.\n\n## Patterns for load resilience\n\n**Pagination.** Don't return all results at once. Return a page of results with a cursor or offset for the next page. Forces the user (or client) to consume in chunks.\n\n**Lazy loading \u002F virtualization.** Load only what's currently visible. As the user scrolls, load more.\n\n**Indexing.** Database indexes make queries fast even at large data volumes. Search infrastructure (Elasticsearch, Algolia) for full-text queries.\n\n**Caching.** Store frequently-requested data in fast memory; serve from cache rather than recomputing or refetching.\n\n**Asynchronous processing.** Move expensive work to background queues. Respond quickly; process slowly.\n\n**Sharding \u002F partitioning.** Split data across multiple databases or storage units. Each shard handles a fraction of the load.\n\n**Read replicas.** Multiple read-only copies of the database; reads distributed across replicas; writes go to a single master.\n\n**Rate limiting.** Cap the request rate per user or per source. Prevents single users from consuming disproportionate resources.\n\n**Circuit breakers.** Detect when a dependency is failing or slow; stop calling it temporarily; resume when it recovers.\n\n**Graceful degradation.** When some services are slow, return partial results or cached results rather than failing entirely.\n\n**Auto-scaling.** Add capacity dynamically as load increases; remove when load decreases.\n\n**Load testing.** Simulate production-scale load in a non-production environment. Identify bottlenecks before they hit users.\n\n## Worked examples\n\n### A list view that breaks at scale\n\nA team builds a feature showing all activity in a user's account. With 100 events per account, the page loads in 200ms. With 100,000 events, the page takes 30 seconds and crashes the browser.\n\nThe fix: pagination (load 50 events per page) + virtualization (only render visible rows in the DOM) + filtering (let users narrow to specific event types). The system now scales to millions of events without breaking.\n\n### An N+1 query pattern\n\nAn ORM auto-generates queries that fetch one user's data per row. For a list of 1000 users, it makes 1001 database queries (1 for the list, then 1 per user for related data). Page load takes 8 seconds.\n\nThe fix: eager loading (fetch related data in a single query) + caching (store frequently-accessed user data). Page load drops to 200ms. Same result; very different performance.\n\n### A cache that becomes the bottleneck\n\nA team adds Redis caching to speed up database queries. Initially great. As traffic grows, the Redis instance starts to hit CPU and memory limits; queries are now slow because Redis is the bottleneck.\n\nThe fix: Redis cluster (multiple instances handling different keys), local in-process caching for the hottest data, and cache eviction policies. The cache is no longer a single bottleneck.\n\n### A third-party API rate limit\n\nA product depends on a payment-processing API with a 100 req\u002Fsec limit. During a holiday sale, peak traffic produces 1000 req\u002Fsec. The API throttles; transactions fail; users see errors.\n\nThe fix: queue payment requests locally; process them at the rate the API allows; show users an \"in progress\" state for delayed transactions. + Negotiate a higher rate limit with the provider. + Add a backup payment provider for failover.\n\n### A search query that times out\n\nA simple full-text search across user-generated content works fine at 100K records. As the corpus grows to 100M records, queries take 30 seconds.\n\nThe fix: dedicated search infrastructure (Elasticsearch) with proper indexing. Queries become sub-second even at billion-record scale.\n\n## Load testing patterns\n\n**Synthetic load testing.** Tools like JMeter, Gatling, or k6 simulate users making requests. Run at multiples of expected production load.\n\n**Production traffic mirroring.** Mirror real production traffic to a test environment. Tests with real-world request distributions.\n\n**Chaos engineering.** Deliberately fail components to verify the system handles failure gracefully. Netflix's Chaos Monkey is the canonical example.\n\n**Canary deployments.** Roll out new code to a small fraction of users first; verify it doesn't degrade under their load before rolling out broadly.\n\n**Stress testing to find the breaking point.** Increase load until the system fails. Document the breaking point; design to be safely below it.\n\n## Designing for load from the start\n\nWhen designing a new system or feature, ask:\n\n**What's the expected load in 6 months and 2 years?** Project upward; design with margin.\n\n**Which operations are likely to scale poorly?** Linear scans, all-results queries, N+1 patterns.\n\n**What's our story for handling 10x current load?** Adding capacity, sharding, caching, async processing.\n\n**What dependencies have load limits?** Identify and design around them.\n\n**How will we know when we're approaching limits?** Monitoring and alerts on the right metrics.\n\n## Anti-patterns\n\n**Premature optimization.** Adding complexity (caching, sharding) before measurements show it's needed. Better to start simple and add complexity when bottlenecks emerge — but design with the architectural choices that allow adding complexity later.\n\n**No load testing.** Shipping to production without verifying that the system handles realistic load. Hoping it'll be fine.\n\n**Underestimating peak traffic.** Designing for average load and being shocked when peak is 10x average. Most systems have peak\u002Faverage ratios of 3–10x; design accordingly.\n\n**Single instances of critical components.** A single database, a single cache server, a single application instance. Single points of failure under load.\n\n**Ignoring third-party limits.** Building features that depend on third-party APIs without checking their rate limits or planning for throttling.\n\n**Auto-scaling without budgets.** Auto-scaling is great until your bill becomes catastrophic. Set caps and alerts.\n\n## Heuristic checklist\n\nWhen designing for load, ask: **What's the projected load in the foreseeable future?** Design with margin. **Which operations scale linearly vs. non-linearly with input size?** Identify and improve the non-linear ones. **Have we load-tested at production-target scale?** If not, the load assumption is unverified. **What single points of failure exist?** Eliminate or accept the risk explicitly. **Do we have monitoring to detect approaching limits?** Surprises are costly.\n\n## Related sub-skills\n\n- `scaling-fallacy` — parent principle on the dangers of scale assumptions.\n- `scaling-interaction-assumptions` — sibling skill on user-base scaling.\n- `weakest-link` — load reveals weak links that were tolerable at small scale.\n- `factor-of-safety` — design with margin for the load you might see, not just the load you have.\n- `errors` — error handling becomes critical when load creates failure conditions.\n\n## See also\n\n- `references\u002Fload-test-patterns.md` — practical patterns for load testing and capacity planning.\n",{"name":5,"description":7},"main","b0f0a87593c578a7898eccaf1b363f7f87c1f99b","plugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Fscaling-load-assumptions",474,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins","https:\u002F\u002Fhol.org\u002Fplugins\u002Fbest-codex-plugins","https:\u002F\u002Fgithub.com\u002Fhashgraph-online","https:\u002F\u002Fhol.org","Open-source standards and developer tools for interoperable AI agents: discovery, identity, communication, payments, privacy and security.","2026-11-11 14:40:14",{"source":8,"skillName":5,"commands":65,"prompt":75,"zipAvailable":76},[66,69,72],{"tool":67,"command":68},"npx","npx skills add hashgraph-online\u002Fawesome-codex-plugins --skill scaling-load-assumptions",{"tool":70,"command":71},"bunx","bunx skills add hashgraph-online\u002Fawesome-codex-plugins --skill scaling-load-assumptions",{"tool":73,"command":74},"pnpm","pnpm dlx skills add hashgraph-online\u002Fawesome-codex-plugins --skill scaling-load-assumptions","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Fscaling-load-assumptions\u002FSKILL.md",true,[78],{"path":79,"resourceType":80,"resourceTypeDesc":81,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fload-test-patterns.md","REFERENCE","参考文档",5631,"https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002FHDeibler\u002Funiversal-design-principles\u002Fplugins\u002Fprocess-and-robustness-principles\u002Fskills\u002Fscaling-load-assumptions\u002Freferences\u002Fload-test-patterns.md",[85,93,100,107,132,157],{"skillNo":86,"name":87,"nameZh":6,"description":88,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":92},"01M746ZWACVKMZ1BJXJZHYJSSX","migrate-to-e2e","Moves an existing Playwright, Cypress, Selenium, Appium, Detox, Maestro, or TesterArmy suite to e2e one slice at a time, with the old suite running beside the new one until each ported test is proven. Keeps a MIGRATION.md progress file so any later session resumes where the last stopped. Optionally plants a defect to show both suites catch it. Use for \u002Fmigrate-to-e2e, \"migrate our tests to e2e\", \"port these Maestro flows\", \"move our TesterArmy tests\", or when a project has an e2e config and an older suite still running.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fmigrate-to-e2e\u002FSKILL.md",[],[],"2026-11-11 15:11:14",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":92},"01M746ZPTAX1Q0FBKAB1CYND7E","e2e","Writes, runs, and debugs end-to-end tests for web and mobile apps with e2e, the agentic test runner, which mixes agent.act goals with exact locator assertions on a Playwright browser or an iOS or Android device. Also drives a project's running app live over the e2e MCP server to look at a screen, check a UI change, take a screenshot or record a video, and try a locator; and runs bug bashes, parallel e2e explore runs with each bug proven by a repro test. Use when a project depends on e2e or has an e2e.config.ts, when asked for end-to-end, browser, mobile, or agentic UI tests, to check a change in the running app, to QA or bug bash an app or branch, or when an e2e run fails.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fe2e\u002FSKILL.md",[],[],{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":92},"01M746ZJN784HVHMDP9MQGCSGG","create-verification-skill","Generate a project-local verify-\u003Capp> skill on top of e2e, so any coding agent can launch the app, check it is worth driving, exercise a feature the way a user does, keep evidence, and bug bash it. Writes the skill, a feature map with one explore charter per feature, and proves it once. Use for \u002Fcreate-verification-skill, \"make a verification skill for this repo\", or when a project has no scripted way to prove UI behavior.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftester-army\u002Fe2e\u002Fskills\u002Fcreate-verification-skill\u002FSKILL.md",[],[],{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":49},"01M716A6ETNB9B1SQ3GXZC75VR","deja-search","deja-vu memory — search the user's past AI coding sessions with the deja CLI. Holds what they already settled and never wrote into the repo (naming rules, banned or already-tried tools, required checks before merge, preferred values, who owns what). Use before your first edit in a task, before you call a change done or ready to merge, before you recommend a tool, library, design or reviewer, before re-debugging an error that may already be solved, when they say 'didn't we fix this before', 'what did we decide about X' or 'I already have that', and before telling them something on this machine does not exist.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-search\u002FSKILL.md",[],[114,115,116,117,118,119,120,121,122,48,123,28,124,125,126,127,128,129,130,131],"search","deja search","never","error","ready","memory","re","decide","fix","debugging","you","done","reviewer","io","change","cli","merge","past",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":138,"publishedAt":49},"01M716A3J2W5SENSE9VGMXB375","deja-reflect","End-of-session reflection and memory curation with deja-vu. Review what was decided, what commands broke and what repaired them, and record durable project rules or decisions with deja remember so the next session starts with them.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Fvshulcz\u002Fdeja-vu\u002Fskills\u002Fdeja-reflect\u002FSKILL.md",[],[139,140,141,127,142,143,144,145,146,147,148,149,150,151,119,152,153,154,155,156],"deja reflect","reflect","review","with","record","github","next","https","node","Rules","decisions","brew","remember","project rules","project","session","end","reflection",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":172,"publishedAt":49},"01M715T3RR4BAYSR57HPPTJ0PF","revid","Make, edit, export and post AI videos with Revid (revid.ai) through the Revid MCP server. Use whenever the user wants a short-form or long-form video made (from an idea, a script, a URL, an article, a PDF, a tweet, a product page, their own clips, or a song), wants to find what is going viral on TikTok, YouTube, Instagram or X before making something, wants to edit or re-export an existing Revid project, generate a standalone AI image or clip, make a series episode, or publish and schedule a finished video to connected social accounts. Covers setup (hosted MCP with OAuth, or an API key), the 36 tools, credits, polling and the rules for publishing. Routes to the more specific revid-* skills when one fits.","https:\u002F\u002Fgithub.com\u002Fhashgraph-online\u002Fawesome-codex-plugins\u002Fblob\u002Fmain\u002Fplugins\u002Ftmakersas\u002Frevid-skills\u002Fskills\u002Frevid\u002FSKILL.md",[163,166,169],{"categoryNo":164,"categoryName":165,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",{"categoryNo":167,"categoryName":168,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":170,"categoryName":171,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",[159,173,174,175,176,177,178,153,179,120,180,181,182,183,28,184,185,186,187,188],"URL","Video","short-form","standalone","PDF","viral","tiktok","short","social","MCP","song","image","mcp server","schedule","api","publish"]