[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M79TDR0PHSAJMSEQ7XFMP6NB":3,"skill-same:01M79TDR0PHSAJMSEQ7XFMP6NB":53},{"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":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":32,"commitSha":33,"skillDirectory":34,"forksCount":14,"repositoryHtmlUrl":35,"repositoryHomepageUrl":6,"ownerHtmlUrl":36,"ownerBlogUrl":6,"ownerDescription":37,"updatedAt":38,"install":39,"resources":52},"01M79TDR0PHSAJMSEQ7XFMP6NB","mongodb-architect",null,"Architect-level MongoDB guidance — document modelling by access pattern, embed-versus-reference decisions, index and aggregation strategy, schema validation, and the unbounded-document traps that make Mongo slow or expensive. Use when designing or reviewing a MongoDB data model.","SriAkhilSJ\u002FPulseAIRepo","SriAkhilSJ","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F206201543?v=4","01M79RWFD1Q09B89SXTTKKJY6Z","Sri Akhil SJ","01M79RWFE26NPG0BZ1FRNX376H",0,"MIT","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fdatabase-engineering-architect\u002Fmongodb-architect\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: mongodb-architect\ndescription: Architect-level MongoDB guidance — document modelling by access pattern, embed-versus-reference decisions, index and aggregation strategy, schema validation, and the unbounded-document traps that make Mongo slow or expensive. Use when designing or reviewing a MongoDB data model.\nlicense: MIT\ncompatibility: MongoDB 6\u002F7+; any driver or ODM\nmetadata:\n  crusor-domain: website-architect\n  crusor-path: website-architect\u002Fdatabase-engineering-architect\u002Fmongodb-architect\n  crusor-origin: original\n  crusor-sources: \"mongodb.com\u002Fdocs\u002Fmanual; mongodb.com\u002Fdocs\u002Fmanual\u002Fdata-modeling\"\n  crusor-triggers: \"mongodb, mongo, documents, aggregation pipeline, embed, references, nosql, mongoose\"\n  crusor-verified-on: \"2026-10-30\"\n---\n\n# MongoDB Architect\n\nMongoDB is **not \"SQL without joins\"**. It is a model where the document boundary\n*is* the atomic unit — so the schema follows the query, not the entity.\n\n## When to use\n\n- Aggregates are read and written as a unit (order + lines, profile + settings).\n- Shape varies by tenant or evolves fast, with query patterns known.\n- Document-per-entity access dominates; joins are rare.\n\n## When NOT to use\n\n- Multi-entity reporting, ad-hoc joins, strong relational integrity.\n- Highly relational data or money\u002Finventory requiring cross-document\n  transactions at volume.\n\n## Decision 1 — Model by access pattern\n\n| Relationship | Choose |\n|---|---|\n| read together, bounded size | embed |\n| referenced by many, unbounded | reference |\n| many-to-many with attributes | reference + lookup collection |\n| unbounded growth (events, logs) | separate collection, time-bucketed |\n\n- Never embed an array that can grow without limit (16 MB document cap and\n  in-place update costs).\n- Duplicate data is a **decision with a sync owner**, not an accident.\n- Each collection is designed for the queries it serves; a second query shape\n  may warrant a second collection (CQRS-style).\n\n## Decision 2 — Indexes\n\n- Index for the actual query: equality fields, then sort field, then range.\n- Compound index prefix rules apply the same as relational.\n- `explain(\"executionStats\")`: watch `totalDocsExamined` vs `nReturned`.\n- TTL indexes for expiring data; partial indexes for hot subsets.\n- Text search: `$text` for simple needs, Atlas Search for real relevance.\n\n## Decision 3 — Writes and consistency\n\n- Single-document writes are atomic; multi-document transactions exist but are\n  a design smell at high volume — restructure instead.\n- Write concern: acknowledge majority for durability-critical writes.\n- Read concern: `local` for speed, `majority` for correctness-sensitive reads.\n- Optimistic concurrency with a version field for contended updates.\n\n## Decision 4 — Validation and evolution\n\n- `$jsonSchema` validation on collections where shape matters.\n- Migrations are scripts run as deploys: backfill, dual-read, switch, clean up.\n- Field renames are dual-write migrations, never in-place rewrites of a large\n  collection.\n\n## Decision 5 — Aggregation discipline\n\n- `$match` first, then `$lookup` — pipelines that start with lookups scan\n  everything.\n- `$lookup` on unindexed foreign fields is a collection scan per document.\n- `allowDiskUse` hides a design problem; keep the pipeline in memory.\n- Materialise expensive aggregates into a read collection, refreshed on write.\n\n## Failure modes at scale\n\n- Embedded arrays growing unbounded until documents hit the size cap.\n- `$lookup` joins turning a 3 ms query into 900 ms.\n- No compound index for the main list query → collection scans under load.\n- Transactions used per-request to emulate a relational schema.\n- No validation → five shapes of the same document in one collection.\n\n## Verification receipts\n\n1. Model documented: embed vs reference per relationship, with size bounds.\n2. `explain(\"executionStats\")` for the top queries, index used.\n3. Validation schema present on shape-critical collections.\n4. Unbounded-array audit: every array has a cap or an archive path.\n5. Write\u002Fread concern chosen per collection, documented.\n","# MongoDB Architect\n\nMongoDB is **not \"SQL without joins\"**. It is a model where the document boundary\n*is* the atomic unit — so the schema follows the query, not the entity.\n\n## When to use\n\n- Aggregates are read and written as a unit (order + lines, profile + settings).\n- Shape varies by tenant or evolves fast, with query patterns known.\n- Document-per-entity access dominates; joins are rare.\n\n## When NOT to use\n\n- Multi-entity reporting, ad-hoc joins, strong relational integrity.\n- Highly relational data or money\u002Finventory requiring cross-document\n  transactions at volume.\n\n## Decision 1 — Model by access pattern\n\n| Relationship | Choose |\n|---|---|\n| read together, bounded size | embed |\n| referenced by many, unbounded | reference |\n| many-to-many with attributes | reference + lookup collection |\n| unbounded growth (events, logs) | separate collection, time-bucketed |\n\n- Never embed an array that can grow without limit (16 MB document cap and\n  in-place update costs).\n- Duplicate data is a **decision with a sync owner**, not an accident.\n- Each collection is designed for the queries it serves; a second query shape\n  may warrant a second collection (CQRS-style).\n\n## Decision 2 — Indexes\n\n- Index for the actual query: equality fields, then sort field, then range.\n- Compound index prefix rules apply the same as relational.\n- `explain(\"executionStats\")`: watch `totalDocsExamined` vs `nReturned`.\n- TTL indexes for expiring data; partial indexes for hot subsets.\n- Text search: `$text` for simple needs, Atlas Search for real relevance.\n\n## Decision 3 — Writes and consistency\n\n- Single-document writes are atomic; multi-document transactions exist but are\n  a design smell at high volume — restructure instead.\n- Write concern: acknowledge majority for durability-critical writes.\n- Read concern: `local` for speed, `majority` for correctness-sensitive reads.\n- Optimistic concurrency with a version field for contended updates.\n\n## Decision 4 — Validation and evolution\n\n- `$jsonSchema` validation on collections where shape matters.\n- Migrations are scripts run as deploys: backfill, dual-read, switch, clean up.\n- Field renames are dual-write migrations, never in-place rewrites of a large\n  collection.\n\n## Decision 5 — Aggregation discipline\n\n- `$match` first, then `$lookup` — pipelines that start with lookups scan\n  everything.\n- `$lookup` on unindexed foreign fields is a collection scan per document.\n- `allowDiskUse` hides a design problem; keep the pipeline in memory.\n- Materialise expensive aggregates into a read collection, refreshed on write.\n\n## Failure modes at scale\n\n- Embedded arrays growing unbounded until documents hit the size cap.\n- `$lookup` joins turning a 3 ms query into 900 ms.\n- No compound index for the main list query → collection scans under load.\n- Transactions used per-request to emulate a relational schema.\n- No validation → five shapes of the same document in one collection.\n\n## Verification receipts\n\n1. Model documented: embed vs reference per relationship, with size bounds.\n2. `explain(\"executionStats\")` for the top queries, index used.\n3. Validation schema present on shape-critical collections.\n4. Unbounded-array audit: every array has a cap or an archive path.\n5. Write\u002Fread concern chosen per collection, documented.\n",{"name":5,"license":15,"metadata":24,"description":7,"compatibility":31},{"crusor-path":25,"crusor-domain":26,"crusor-origin":27,"crusor-sources":28,"crusor-triggers":29,"crusor-verified-on":30},"website-architect\u002Fdatabase-engineering-architect\u002Fmongodb-architect","website-architect","original","mongodb.com\u002Fdocs\u002Fmanual; mongodb.com\u002Fdocs\u002Fmanual\u002Fdata-modeling","mongodb, mongo, documents, aggregation pipeline, embed, references, nosql, mongoose","2026-10-30","MongoDB 6\u002F7+; any driver or ODM","main","8fa4e240be65b98472c9b2d3a505ade2aea1a5c6","skills\u002Fwebsite-architect\u002Fdatabase-engineering-architect\u002Fmongodb-architect","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ","Studying in CMR institute of Technology\r\n2024 - 2028","2026-11-13 21:02:23",{"source":8,"skillName":5,"commands":40,"prompt":50,"zipAvailable":51},[41,44,47],{"tool":42,"command":43},"npx","npx skills add SriAkhilSJ\u002FPulseAIRepo --skill mongodb-architect",{"tool":45,"command":46},"bunx","bunx skills add SriAkhilSJ\u002FPulseAIRepo --skill mongodb-architect",{"tool":48,"command":49},"pnpm","pnpm dlx skills add SriAkhilSJ\u002FPulseAIRepo --skill mongodb-architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fdatabase-engineering-architect\u002Fmongodb-architect\u002FSKILL.md",true,[],[54,61,68,75,82,89],{"skillNo":55,"name":56,"nameZh":6,"description":57,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":58,"categories":59,"keywords":60,"publishedAt":19},"01M79TTAJNACCNXCEN3649CMMD","interaction-patterns-architect","Architect-level interaction design in code — choosing established patterns over invented ones, feedback and latency behaviour, destructive-action safeguards, navigation and overlay conventions, and the state model behind every interactive surface. Use when a screen has to behave, not just look.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Finteraction-patterns-architect\u002FSKILL.md",[],[],{"skillNo":62,"name":63,"nameZh":6,"description":64,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":65,"categories":66,"keywords":67,"publishedAt":19},"01M79TT2ESKB1TKZBYY9KYJHV9","design-system-ops-architect","Architect-level operation of a design system in code — token pipelines and versioning, component API and variant policy, the catalogue as the contract, adoption metrics, and the governance that stops a system from forking into three. Use when a component library must survive several teams.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fdesign-system-ops-architect\u002FSKILL.md",[],[],{"skillNo":69,"name":70,"nameZh":6,"description":71,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":72,"categories":73,"keywords":74,"publishedAt":19},"01M79TSV0PWGNK3PRX9P4JDR9N","design-handoff-architect","Architect-level design handoff — what must be specified before implementation starts, tokens over raw values, responsive and content-limit contracts, state matrices, and the review loop that catches drift between design and code. Use when a design is about to become code.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fdesign-handoff-architect\u002FSKILL.md",[],[],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":19},"01M79TSJS9BFXNP696FMJ9GKDA","content-microcopy-architect","Architect-level UI content — where strings live, voice and terminology consistency, error and empty-state copy as part of the interface, translation-ready authoring, and the content model a product needs before it multiplies screens. Use when the words in the interface matter as much as the pixels.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002Fcontent-microcopy-architect\u002FSKILL.md",[],[],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":19},"01M79TSCNBST3N1M68V1KPH9HQ","ui-ux-implementation-architect","Architect-level direction for turning a design into working UI — the handoff contract, component ownership versus screen-level layout, interaction and state conventions, design QA gates, and the review habits that keep an implementation faithful without frozen pixels. Use before any specific UI implementation skill.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Fui-ux-implementation-architect\u002FSKILL.md",[],[],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":19},"01M79TS4N6A4D2QQ433VXS5D0R","test-strategy-architect","Architect-level test strategy — allocating assertions across unit, integration, contract and end-to-end layers, designing for testability through dependency boundaries, fixture and data strategy, and the flake and coverage policies that keep a suite trustworthy. Use when defining how a codebase is tested.","https:\u002F\u002Fgithub.com\u002FSriAkhilSJ\u002FPulseAIRepo\u002Fblob\u002Fmain\u002Fskills\u002Fwebsite-architect\u002Ftesting-and-deployment-architect\u002Ftest-strategy-architect\u002FSKILL.md",[],[]]