[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7E8HV3EC9ZDVM4RTW0MFZGS":3,"skill-same:01M7E8HV3EC9ZDVM4RTW0MFZGS":48},{"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":28,"commitSha":29,"skillDirectory":30,"forksCount":14,"repositoryHtmlUrl":31,"repositoryHomepageUrl":31,"ownerHtmlUrl":32,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":33,"install":34,"resources":47},"01M7E8HV3EC9ZDVM4RTW0MFZGS","patterns",null,"Reference document for monopoly patterns.","Mr-Nobody-Anonymous\u002FAll-skills","Mr-Nobody-Anonymous","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F184253119?v=4","01M7AEXFJHKTYQW5R0ZCQQTWFV","anonymous","01M7C00M3GQR4QKP9GZA42GFAK",0,"MIT","https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous\u002FAll-skills\u002Fblob\u002Fmain\u002Fawesome_skills\u002Farchitecture\u002Fmonopoly\u002Fpatterns\u002FSKILL.md",[],[],"2026-11-15 14:19:17",false,"---\nname: patterns\ndescription: Reference document for monopoly patterns.\nsource: community\ndate_added: \"2026-09-04\"\nrisk: safe\nreports-to: monopoly\n---\n\n# MONOPOLY — Design Patterns Deep Dive\n\n## When to Use\n- Use this skill when the task matches this description: Reference document for monopoly patterns.\n\n## Table of Contents\n1. CQRS\n2. Event Sourcing\n3. Saga Pattern\n4. Circuit Breaker\n5. Bulkhead\n6. Strangler Fig\n7. Sidecar \u002F Service Mesh\n8. Outbox Pattern\n9. Consistent Hashing\n10. Backpressure\n11. Leader Election\n12. Two-Phase Commit\n\n---\n\n## 1. CQRS (Command Query Responsibility Segregation)\n\n**What it is:** Separate the read model (Query) from the write model (Command) into distinct services, databases, or code paths.\n\n**When to use:**\n- Read load is 10×+ write load (most web apps)\n- Read queries are complex aggregations over write data\n- Need to optimize read and write paths independently\n- Domain model is complex (DDD contexts)\n\n**Implementation:**\n```\nWrite Path:  Client → Command API → Write DB (normalized, PostgreSQL)\nRead Path:   Client → Query API  → Read DB (denormalized, Redis \u002F Elasticsearch)\nSync:        Write DB → CDC (Debezium) → Message Queue → Read DB updater\n```\n\n**Trade-offs:**\n- ✅ Independent scaling of read and write\n- ✅ Optimized schemas for each operation type\n- ❌ Eventual consistency between write and read models\n- ❌ Increased complexity; two models to maintain\n\n**Real-world users:** Amazon (order service), LinkedIn (feed)\n\n---\n\n## 2. Event Sourcing\n\n**What it is:** Store state as a sequence of immutable events rather than current state. Rebuild current state by replaying events.\n\n**When to use:**\n- Full audit trail is a regulatory requirement (fintech, healthcare)\n- Need to replay history for debugging or analytics\n- Complex domain with many state transitions\n- Need to derive multiple read projections from same data\n\n**Implementation:**\n```\nEvent Store: append-only log (Kafka, EventStoreDB)\nSnapshots:   periodic snapshots to speed up state rebuild\nProjections: consumers build read models from events\n```\n\n**Trade-offs:**\n- ✅ Complete audit history; perfect for compliance\n- ✅ Replay and time-travel debugging\n- ❌ Querying current state requires projection maintenance\n- ❌ Event schema evolution is hard\n- ❌ High storage overhead over time\n\n---\n\n## 3. Saga Pattern\n\n**What it is:** Manage distributed transactions across microservices via a sequence of local transactions, each publishing an event. If a step fails, compensating transactions undo previous steps.\n\n**Two variants:**\n- **Choreography:** Services react to events autonomously (decentralized)\n- **Orchestration:** A central Saga Orchestrator coordinates steps (centralized)\n\n**When to use:**\n- Multi-service workflows where ACID across services is impossible\n- Long-running business transactions (order → payment → inventory → shipping)\n- Need rollback across service boundaries\n\n**Choreography Example:**\n```\nOrderService creates order →\n  [event: OrderCreated] →\n    PaymentService charges card →\n      [event: PaymentProcessed] →\n        InventoryService reserves stock →\n          [event: StockReserved] →\n            ShippingService books courier\n```\n\n**Compensating Transactions (on failure):**\n```\nShippingService fails →\n  [event: ShippingFailed] →\n    InventoryService releases stock →\n      PaymentService refunds card →\n        OrderService marks order failed\n```\n\n**Trade-offs:**\n- ✅ No distributed locking; high availability\n- ✅ Scales well across services\n- ❌ Hard to debug; distributed trace required\n- ❌ Compensating transactions are complex to implement correctly\n\n---\n\n## 4. Circuit Breaker\n\n**What it is:** A proxy that monitors calls to a service. If failure rate exceeds threshold, the circuit \"opens\" and calls fail fast instead of waiting for timeout.\n\n**States:**\n```\nCLOSED  → calls pass through; monitor failure rate\nOPEN    → calls fail immediately; no calls to downstream\nHALF-OPEN → let a probe call through; if success, close; if fail, stay open\n```\n\n**When to use:**\n- Calling any external service (payment gateway, SMS, email)\n- Microservices calling each other\n- Preventing timeout cascade when downstream is slow\n\n**Implementation tools:** Hystrix (deprecated), Resilience4j, Polly (.NET), Envoy proxy\n\n**Thresholds (starting point):**\n- Open after 50% failure rate over 10 requests\n- Stay open for 30 seconds\n- Half-open: allow 1 probe request\n\n**Trade-offs:**\n- ✅ Prevents cascade failures\n- ✅ Gives downstream time to recover\n- ❌ Adds latency overhead for monitoring\n- ❌ Requires fallback behavior when circuit is open\n\n---\n\n## 5. Bulkhead\n\n**What it is:** Isolate components so a failure in one doesn't consume resources of others. Named after the watertight compartments in ship hulls.\n\n**Types:**\n- **Thread Pool Bulkhead:** Separate thread pools per service call\n- **Semaphore Bulkhead:** Limit concurrent calls per service\n- **Process Bulkhead:** Separate processes\u002Fcontainers per service type\n\n**When to use:**\n- Multiple tenants sharing infrastructure (SaaS)\n- One slow service consuming all connection pool slots\n- Protecting critical services from being starved by non-critical ones\n\n**Example:**\n```\nWithout bulkhead:\n  [Recommendation Service hangs] → fills shared thread pool → [Payment Service starves]\n\nWith bulkhead:\n  [Recommendation Service hangs] → fills its own thread pool (10 threads) → [Payment Service unaffected, has its own 50 threads]\n```\n\n---\n\n## 6. Strangler Fig Pattern\n\n**What it is:** Incrementally replace a legacy monolith by routing new functionality to new microservices, while keeping the monolith alive for unchanged features.\n\n**Migration steps:**\n```\nPhase 1: Deploy proxy in front of monolith (no user impact)\nPhase 2: Route one feature to new microservice\nPhase 3: Verify; deprecate that feature in monolith\nPhase 4: Repeat for each feature\nPhase 5: Monolith is empty; decommission\n```\n\n**When to use:**\n- Migrating legacy monolith to microservices\n- Can't do a big-bang rewrite (too risky)\n- Need to ship new features during migration\n\n**Trade-offs:**\n- ✅ Zero downtime migration\n- ✅ Incremental risk\n- ❌ Dual maintenance burden during migration (monolith + new services)\n- ❌ Proxy adds latency; must be managed carefully\n\n---\n\n## 7. Outbox Pattern\n\n**What it is:** Solve the dual-write problem (write to DB AND publish to queue atomically) by writing the event to an \"outbox\" table in the same DB transaction, then having a separate process relay it to the queue.\n\n**Problem it solves:**\n```\n❌ WRONG (dual-write race):\n  BEGIN;\n  UPDATE orders SET status='paid';\n  COMMIT;\n  \u002F\u002F Crash here → event never published, DB and queue are inconsistent\n  publish(PaymentProcessed);\n```\n\n```\n✅ CORRECT (outbox):\n  BEGIN;\n  UPDATE orders SET status='paid';\n  INSERT INTO outbox (event_type, payload) VALUES ('PaymentProcessed', {...});\n  COMMIT;\n  \u002F\u002F Relay process reads outbox and publishes to Kafka\n  \u002F\u002F At-least-once delivery guaranteed; make consumers idempotent\n```\n\n**Relay options:** Debezium (CDC), polling relay, transaction log tailing\n\n---\n\n## 8. Consistent Hashing\n\n**What it is:** A hashing scheme where adding or removing nodes requires only K\u002FN keys to be remapped (K = keys, N = nodes), instead of remapping all keys.\n\n**When to use:**\n- Distributing cache keys across Redis cluster nodes\n- Routing requests to servers in a distributed system\n- Partitioning data across database nodes\n\n**Virtual nodes:** Assign multiple positions per physical node on the hash ring to ensure even distribution even with few nodes.\n\n---\n\n## 9. Backpressure\n\n**What it is:** A mechanism for consumers to signal producers to slow down when they can't keep up, preventing memory exhaustion and cascade failures.\n\n**Strategies:**\n- **Drop:** Discard overflow messages (acceptable for metrics, logs)\n- **Buffer:** Queue up to a limit, then block or drop\n- **Block:** Producer waits until consumer catches up (simplest, may cause timeout)\n- **Rate Limit:** Throttle producers at ingestion point\n\n**When to use:**\n- Message queue consumers are slower than producers\n- Real-time data pipeline ingestion spikes\n- API rate limiting for upstream clients\n\n---\n\n## 10. Leader Election\n\n**What it is:** In a distributed system, elect a single node to perform a privileged task (e.g., writing to DB, sending scheduled jobs, coordinating work).\n\n**Algorithms:**\n- **Raft:** Used by etcd, CockroachDB, Consul. Practical and well-understood.\n- **ZooKeeper (ZAB):** Used by Kafka, HBase. Mature but operationally heavy.\n- **Bully Algorithm:** Simple; highest ID wins. Not fault-tolerant.\n\n**When to use:**\n- Scheduled jobs that should only run once (cron replacement)\n- Primary\u002Freplica database failover coordination\n- Distributed lock management\n\n**Tools:** etcd, ZooKeeper, Consul, Redis (Redlock — use with caution)\n\n---\n\n## 11. Two-Phase Commit (2PC)\n\n**What it is:** A distributed algorithm that ensures all participants in a transaction either all commit or all abort.\n\n**Phases:**\n```\nPhase 1 (Prepare): Coordinator asks all participants \"can you commit?\"\n  All say YES → proceed to Phase 2\n  Any says NO → abort\n\nPhase 2 (Commit): Coordinator tells all participants to commit\n```\n\n**When to use (sparingly):**\n- Strong consistency is an absolute requirement across services\n- Data loss is catastrophic (financial settlements)\n\n**Why to avoid:**\n- Coordinator is a SPOF\n- Blocks on participant failure\n- Very low throughput under contention\n- Prefer Saga Pattern in most microservice architectures\n\n---\n\n## 12. Read-Through \u002F Write-Through \u002F Write-Behind Cache\n\n**Read-Through:**\n```\nClient → Cache (miss) → Cache fetches from DB → Returns to client\n```\nCache is always populated on miss. Simple for clients. Risk: cold start.\n\n**Write-Through:**\n```\nClient → Cache → Cache writes to DB synchronously → Confirms\n```\nStrong consistency. Higher write latency. Good for read-heavy with consistency need.\n\n**Write-Behind (Write-Back):**\n```\nClient → Cache → Confirms immediately → Async flush to DB\n```\nVery low write latency. Risk of data loss if cache fails before flush. Good for high-throughput counters, analytics.\n\n**Cache-Aside (Lazy Loading):**\n```\nClient → Cache (miss) → Client fetches from DB → Client writes to Cache\n```\nMost common. Application owns cache logic. Risk: thundering herd on cold start.\n\n\n## Limitations\n- This is a reference document and may not cover all edge cases. Always verify architectures before production.\n","# MONOPOLY — Design Patterns Deep Dive\n\n## When to Use\n- Use this skill when the task matches this description: Reference document for monopoly patterns.\n\n## Table of Contents\n1. CQRS\n2. Event Sourcing\n3. Saga Pattern\n4. Circuit Breaker\n5. Bulkhead\n6. Strangler Fig\n7. Sidecar \u002F Service Mesh\n8. Outbox Pattern\n9. Consistent Hashing\n10. Backpressure\n11. Leader Election\n12. Two-Phase Commit\n\n---\n\n## 1. CQRS (Command Query Responsibility Segregation)\n\n**What it is:** Separate the read model (Query) from the write model (Command) into distinct services, databases, or code paths.\n\n**When to use:**\n- Read load is 10×+ write load (most web apps)\n- Read queries are complex aggregations over write data\n- Need to optimize read and write paths independently\n- Domain model is complex (DDD contexts)\n\n**Implementation:**\n```\nWrite Path:  Client → Command API → Write DB (normalized, PostgreSQL)\nRead Path:   Client → Query API  → Read DB (denormalized, Redis \u002F Elasticsearch)\nSync:        Write DB → CDC (Debezium) → Message Queue → Read DB updater\n```\n\n**Trade-offs:**\n- ✅ Independent scaling of read and write\n- ✅ Optimized schemas for each operation type\n- ❌ Eventual consistency between write and read models\n- ❌ Increased complexity; two models to maintain\n\n**Real-world users:** Amazon (order service), LinkedIn (feed)\n\n---\n\n## 2. Event Sourcing\n\n**What it is:** Store state as a sequence of immutable events rather than current state. Rebuild current state by replaying events.\n\n**When to use:**\n- Full audit trail is a regulatory requirement (fintech, healthcare)\n- Need to replay history for debugging or analytics\n- Complex domain with many state transitions\n- Need to derive multiple read projections from same data\n\n**Implementation:**\n```\nEvent Store: append-only log (Kafka, EventStoreDB)\nSnapshots:   periodic snapshots to speed up state rebuild\nProjections: consumers build read models from events\n```\n\n**Trade-offs:**\n- ✅ Complete audit history; perfect for compliance\n- ✅ Replay and time-travel debugging\n- ❌ Querying current state requires projection maintenance\n- ❌ Event schema evolution is hard\n- ❌ High storage overhead over time\n\n---\n\n## 3. Saga Pattern\n\n**What it is:** Manage distributed transactions across microservices via a sequence of local transactions, each publishing an event. If a step fails, compensating transactions undo previous steps.\n\n**Two variants:**\n- **Choreography:** Services react to events autonomously (decentralized)\n- **Orchestration:** A central Saga Orchestrator coordinates steps (centralized)\n\n**When to use:**\n- Multi-service workflows where ACID across services is impossible\n- Long-running business transactions (order → payment → inventory → shipping)\n- Need rollback across service boundaries\n\n**Choreography Example:**\n```\nOrderService creates order →\n  [event: OrderCreated] →\n    PaymentService charges card →\n      [event: PaymentProcessed] →\n        InventoryService reserves stock →\n          [event: StockReserved] →\n            ShippingService books courier\n```\n\n**Compensating Transactions (on failure):**\n```\nShippingService fails →\n  [event: ShippingFailed] →\n    InventoryService releases stock →\n      PaymentService refunds card →\n        OrderService marks order failed\n```\n\n**Trade-offs:**\n- ✅ No distributed locking; high availability\n- ✅ Scales well across services\n- ❌ Hard to debug; distributed trace required\n- ❌ Compensating transactions are complex to implement correctly\n\n---\n\n## 4. Circuit Breaker\n\n**What it is:** A proxy that monitors calls to a service. If failure rate exceeds threshold, the circuit \"opens\" and calls fail fast instead of waiting for timeout.\n\n**States:**\n```\nCLOSED  → calls pass through; monitor failure rate\nOPEN    → calls fail immediately; no calls to downstream\nHALF-OPEN → let a probe call through; if success, close; if fail, stay open\n```\n\n**When to use:**\n- Calling any external service (payment gateway, SMS, email)\n- Microservices calling each other\n- Preventing timeout cascade when downstream is slow\n\n**Implementation tools:** Hystrix (deprecated), Resilience4j, Polly (.NET), Envoy proxy\n\n**Thresholds (starting point):**\n- Open after 50% failure rate over 10 requests\n- Stay open for 30 seconds\n- Half-open: allow 1 probe request\n\n**Trade-offs:**\n- ✅ Prevents cascade failures\n- ✅ Gives downstream time to recover\n- ❌ Adds latency overhead for monitoring\n- ❌ Requires fallback behavior when circuit is open\n\n---\n\n## 5. Bulkhead\n\n**What it is:** Isolate components so a failure in one doesn't consume resources of others. Named after the watertight compartments in ship hulls.\n\n**Types:**\n- **Thread Pool Bulkhead:** Separate thread pools per service call\n- **Semaphore Bulkhead:** Limit concurrent calls per service\n- **Process Bulkhead:** Separate processes\u002Fcontainers per service type\n\n**When to use:**\n- Multiple tenants sharing infrastructure (SaaS)\n- One slow service consuming all connection pool slots\n- Protecting critical services from being starved by non-critical ones\n\n**Example:**\n```\nWithout bulkhead:\n  [Recommendation Service hangs] → fills shared thread pool → [Payment Service starves]\n\nWith bulkhead:\n  [Recommendation Service hangs] → fills its own thread pool (10 threads) → [Payment Service unaffected, has its own 50 threads]\n```\n\n---\n\n## 6. Strangler Fig Pattern\n\n**What it is:** Incrementally replace a legacy monolith by routing new functionality to new microservices, while keeping the monolith alive for unchanged features.\n\n**Migration steps:**\n```\nPhase 1: Deploy proxy in front of monolith (no user impact)\nPhase 2: Route one feature to new microservice\nPhase 3: Verify; deprecate that feature in monolith\nPhase 4: Repeat for each feature\nPhase 5: Monolith is empty; decommission\n```\n\n**When to use:**\n- Migrating legacy monolith to microservices\n- Can't do a big-bang rewrite (too risky)\n- Need to ship new features during migration\n\n**Trade-offs:**\n- ✅ Zero downtime migration\n- ✅ Incremental risk\n- ❌ Dual maintenance burden during migration (monolith + new services)\n- ❌ Proxy adds latency; must be managed carefully\n\n---\n\n## 7. Outbox Pattern\n\n**What it is:** Solve the dual-write problem (write to DB AND publish to queue atomically) by writing the event to an \"outbox\" table in the same DB transaction, then having a separate process relay it to the queue.\n\n**Problem it solves:**\n```\n❌ WRONG (dual-write race):\n  BEGIN;\n  UPDATE orders SET status='paid';\n  COMMIT;\n  \u002F\u002F Crash here → event never published, DB and queue are inconsistent\n  publish(PaymentProcessed);\n```\n\n```\n✅ CORRECT (outbox):\n  BEGIN;\n  UPDATE orders SET status='paid';\n  INSERT INTO outbox (event_type, payload) VALUES ('PaymentProcessed', {...});\n  COMMIT;\n  \u002F\u002F Relay process reads outbox and publishes to Kafka\n  \u002F\u002F At-least-once delivery guaranteed; make consumers idempotent\n```\n\n**Relay options:** Debezium (CDC), polling relay, transaction log tailing\n\n---\n\n## 8. Consistent Hashing\n\n**What it is:** A hashing scheme where adding or removing nodes requires only K\u002FN keys to be remapped (K = keys, N = nodes), instead of remapping all keys.\n\n**When to use:**\n- Distributing cache keys across Redis cluster nodes\n- Routing requests to servers in a distributed system\n- Partitioning data across database nodes\n\n**Virtual nodes:** Assign multiple positions per physical node on the hash ring to ensure even distribution even with few nodes.\n\n---\n\n## 9. Backpressure\n\n**What it is:** A mechanism for consumers to signal producers to slow down when they can't keep up, preventing memory exhaustion and cascade failures.\n\n**Strategies:**\n- **Drop:** Discard overflow messages (acceptable for metrics, logs)\n- **Buffer:** Queue up to a limit, then block or drop\n- **Block:** Producer waits until consumer catches up (simplest, may cause timeout)\n- **Rate Limit:** Throttle producers at ingestion point\n\n**When to use:**\n- Message queue consumers are slower than producers\n- Real-time data pipeline ingestion spikes\n- API rate limiting for upstream clients\n\n---\n\n## 10. Leader Election\n\n**What it is:** In a distributed system, elect a single node to perform a privileged task (e.g., writing to DB, sending scheduled jobs, coordinating work).\n\n**Algorithms:**\n- **Raft:** Used by etcd, CockroachDB, Consul. Practical and well-understood.\n- **ZooKeeper (ZAB):** Used by Kafka, HBase. Mature but operationally heavy.\n- **Bully Algorithm:** Simple; highest ID wins. Not fault-tolerant.\n\n**When to use:**\n- Scheduled jobs that should only run once (cron replacement)\n- Primary\u002Freplica database failover coordination\n- Distributed lock management\n\n**Tools:** etcd, ZooKeeper, Consul, Redis (Redlock — use with caution)\n\n---\n\n## 11. Two-Phase Commit (2PC)\n\n**What it is:** A distributed algorithm that ensures all participants in a transaction either all commit or all abort.\n\n**Phases:**\n```\nPhase 1 (Prepare): Coordinator asks all participants \"can you commit?\"\n  All say YES → proceed to Phase 2\n  Any says NO → abort\n\nPhase 2 (Commit): Coordinator tells all participants to commit\n```\n\n**When to use (sparingly):**\n- Strong consistency is an absolute requirement across services\n- Data loss is catastrophic (financial settlements)\n\n**Why to avoid:**\n- Coordinator is a SPOF\n- Blocks on participant failure\n- Very low throughput under contention\n- Prefer Saga Pattern in most microservice architectures\n\n---\n\n## 12. Read-Through \u002F Write-Through \u002F Write-Behind Cache\n\n**Read-Through:**\n```\nClient → Cache (miss) → Cache fetches from DB → Returns to client\n```\nCache is always populated on miss. Simple for clients. Risk: cold start.\n\n**Write-Through:**\n```\nClient → Cache → Cache writes to DB synchronously → Confirms\n```\nStrong consistency. Higher write latency. Good for read-heavy with consistency need.\n\n**Write-Behind (Write-Back):**\n```\nClient → Cache → Confirms immediately → Async flush to DB\n```\nVery low write latency. Risk of data loss if cache fails before flush. Good for high-throughput counters, analytics.\n\n**Cache-Aside (Lazy Loading):**\n```\nClient → Cache (miss) → Client fetches from DB → Client writes to Cache\n```\nMost common. Application owns cache logic. Risk: thundering herd on cold start.\n\n\n## Limitations\n- This is a reference document and may not cover all edge cases. Always verify architectures before production.\n",{"name":5,"risk":24,"source":25,"date_added":26,"reports-to":27,"description":7},"safe","community","2026-09-04","monopoly","main","2d1750717747097b602acf30bd09a7cbd4b4c6ea","awesome_skills\u002Farchitecture\u002Fmonopoly\u002Fpatterns","https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous\u002FAll-skills","https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous","2026-11-09 11:45:36",{"source":8,"skillName":5,"commands":35,"prompt":45,"zipAvailable":46},[36,39,42],{"tool":37,"command":38},"npx","npx skills add Mr-Nobody-Anonymous\u002FAll-skills --skill patterns",{"tool":40,"command":41},"bunx","bunx skills add Mr-Nobody-Anonymous\u002FAll-skills --skill patterns",{"tool":43,"command":44},"pnpm","pnpm dlx skills add Mr-Nobody-Anonymous\u002FAll-skills --skill patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous\u002FAll-skills\u002Fblob\u002Fmain\u002Fawesome_skills\u002Farchitecture\u002Fmonopoly\u002Fpatterns\u002FSKILL.md",true,[],[49,57,64,71,78,85],{"skillNo":50,"name":51,"nameZh":6,"description":52,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":53,"categories":54,"keywords":55,"publishedAt":56},"01M7EXRQF9GFM7D9BG6N5HAT34","oath","Auditing regulatory compliance (SOC2\u002FPCI-DSS\u002FHIPAA\u002FISO 27001): maps requirements, checks controls, designs audit trails, implements Policy as Code. Use when compliance auditing is needed.","https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous\u002FAll-skills\u002Fblob\u002Fmain\u002Fawesome_skills\u002Fdevsecops\u002Foath\u002FSKILL.md",[],[],"2026-11-15 14:25:24",{"skillNo":58,"name":59,"nameZh":6,"description":60,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":61,"categories":62,"keywords":63,"publishedAt":19},"01M7EXRH7TYTNZJT0BQXEWAMW7","nexus","Orchestrating multi-specialist task chains and scope-adaptive product delivery: classifies intent, selects and executes the minimum viable chain, aggregates results, and verifies acceptance criteria. For multi-domain tasks, build-first delivery, and product lifecycle execution.","https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous\u002FAll-skills\u002Fblob\u002Fmain\u002Fawesome_skills\u002Fdevsecops\u002Fnexus\u002FSKILL.md",[],[],{"skillNo":65,"name":66,"nameZh":6,"description":67,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":68,"categories":69,"keywords":70,"publishedAt":19},"01M7EXRCDPFWVEEEFR2ZQGJCYY","nest","Designing LLM-optimized folder structures: audits and restructures directories for context efficiency, progressive disclosure, and prompt cache performance. Not for general repo structure (Grove).","https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous\u002FAll-skills\u002Fblob\u002Fmain\u002Fawesome_skills\u002Fdevsecops\u002Fnest\u002FSKILL.md",[],[],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":19},"01M7EXR7JEER60TH0HD0AH4EE9","native","Implementing production iOS\u002FAndroid\u002FmacOS native features (SwiftUI, Compose) and iterating a screen against a reference design. Not for cross-platform RN\u002FFlutter (Port) or web (Artisan).","https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous\u002FAll-skills\u002Fblob\u002Fmain\u002Fawesome_skills\u002Fdevsecops\u002Fnative\u002FSKILL.md",[],[],{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":19},"01M7EXR133J7DD5961R80QTRZY","muse","Defining and managing design tokens, applying token systems to existing codebases, building design system foundations. Use for spacing, color, typography, dark mode, cross-platform output.","https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous\u002FAll-skills\u002Fblob\u002Fmain\u002Fawesome_skills\u002Fdevsecops\u002Fmuse\u002FSKILL.md",[],[],{"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":19},"01M7EXQWWX7ECQN0J50B41YN5N","morph","Converting document formats (Markdown\u002FWord\u002FExcel\u002FPDF\u002FHTML) and generating reusable conversion scripts. Use for distributable specs, accessibility-compliant PDFs, or Pandoc\u002FLibreOffice pipelines.","https:\u002F\u002Fgithub.com\u002FMr-Nobody-Anonymous\u002FAll-skills\u002Fblob\u002Fmain\u002Fawesome_skills\u002Fdevsecops\u002Fmorph\u002FSKILL.md",[],[]]