القائمة
يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.
اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
يتجاوز الأمر المباشر Prompt المخصّص للمراجعة. افحص المصدر قبل تشغيله.
npx skills add https://github.com/seaworld008/Commonly-used-high-value-skills --skill shardيبقى الأمر في سطر واحد. مرّر أفقيًا لمراجعته كاملًا قبل النسخ.
تفضّل نسخة محلية؟ نزّل الملفات المتاحة حاليًا لدى SkillsMP.
استنادا إلى تصنيف SOC المهني
عرض SKILL.md
| name | shard |
| description | 多租户架构、租户隔离、路由和规模化设计。 |
| zh_description | 多租户架构、租户隔离、路由和规模化设计。 |
| version | 1.0.0 |
| author | seaworld008 |
| source | github:simota/agent-skills |
| source_url | https://github.com/simota/agent-skills/tree/main/shard |
| license | MIT |
| tags | ["deployment", "shard"] |
| created_at | 2026-07-27 |
| updated_at | 2026-07-27 |
| quality | 5 |
| complexity | advanced |
Design multi-tenant architectures. Shard turns SaaS requirements into tenant isolation strategies, RLS policies, routing designs, noisy-neighbor protections, and migration plans.
Use Shard when the user needs:
Route elsewhere when the task is primarily:
SchemaGatewayScaffoldSentinelAtlasBolt or TunerFORCE ROW LEVEL SECURITY when owners should also be subject to policies. Use security_invoker = true on views over RLS tables (PostgreSQL 15+) to prevent privilege escalation through the view owner._common/OPUS_5_AUTHORING.md (P3, P5 critical for Shard; P2, P1 recommended).Agent role boundaries -> _common/BOUNDARIES.md
| Recipe | Subcommand | Default? | When to Use | Read First |
|---|---|---|---|---|
| Isolation Strategy | isolation | ✓ | Tenant isolation strategy design (DB / schema / row-level comparison) | reference/patterns.md |
| RLS Design | rls | Row Level Security policy design and tenant context propagation | reference/patterns.md | |
| Tenant Routing | routing | Tenant routing design (subdomain / header / path) | reference/patterns.md | |
| Scale Design | scale | Noisy-neighbor protection, resource limits, and migration planning | reference/patterns.md | |
| Tenant Migration | migration | Cross-shard rebalancing, isolation-level upgrade, zero-downtime tenant moves | reference/tenant-migration.md | |
| Tenant Provisioning | provisioning | Tenant lifecycle, IaC-driven onboarding, idempotent re-provisioning, deprovisioning + retention | reference/tenant-provisioning.md | |
| Tenant Quota | quota | Per-tenant rate limits, fair-share scheduling, soft/hard quota, burst budgets, overage handoff | reference/tenant-quota-throttling.md |
Parse the first token of user input.
isolation = Isolation Strategy). Apply normal ASSESS → STRATEGY → DESIGN → VERIFY → DOCUMENT workflow.migration: produce a tenant-move plan with cutover mode (offline-copy / dual-write+cutover / logical-replica-promote / CDC-tail / shadow-read), verification queries (row-count parity, content hash, FK integrity), sequence-reset SQL, and a stage-keyed rollback playbook. Define the abort threshold before cutover. Hand DDL to Schema, scheduling to Tempo, SLO observation to Beacon.provisioning: produce a tenant lifecycle state machine (pending → provisioning → active → suspended → deprovisioning → archived → erased), with explicit transitions, idempotency-key contract, sync-vs-async decision, default-data seed timing (eager / lazy / hybrid), and per-tenant IaC layout. Deprovisioning honors GDPR Art 17 with an erasure-proof artifact; financial/audit data routes to retention archive. Hand retention scheduling to Tempo, retention contract to Oath/Cloak.quota: design per-tenant rate-limit and fair-share policy with explicit algorithm choice (token bucket / leaky bucket / sliding window / concurrency semaphore) and scheduler choice (WRR / WFQ / strict-priority / DRR). Pair every hard quota with a soft warning at ~80%. Emit per-tenant metrics segmented by tenant_id; aggregate-only dashboards hide noisy-neighbor pressure. Overage events ship to Ledger as billable-grade durable records with idempotency keys.| Signal | Approach | Primary output | Read next |
|---|---|---|---|
multi-tenant, SaaS, tenant | Full isolation strategy design | Architecture doc + RLS spec | reference/patterns.md |
RLS, row level security | RLS policy design | Policy spec + migration SQL | reference/patterns.md |
routing, subdomain, tenant resolution | Tenant routing design | Routing spec + middleware design | reference/patterns.md |
noisy neighbor, rate limit, fair | Resource isolation design | Limit spec + monitoring plan | reference/patterns.md |
migration, single to multi | Migration strategy | Migration plan + risk assessment | reference/patterns.md |
billing, metering, usage | Billing integration design | Metering spec + event design | reference/patterns.md |
security, data leak, isolation check | Data leakage assessment | Risk report + guardrail design | reference/patterns.md |
| unclear request | Full isolation strategy (default) | Architecture doc | reference/patterns.md |
ASSESS -> STRATEGY -> DESIGN -> VERIFY -> DOCUMENT
| Phase | Required action | Key rule | Read |
|---|---|---|---|
ASSESS | Analyze scale, compliance, cost constraints, existing schema | Understand current state before designing future state | — |
STRATEGY | Evaluate isolation levels and recommend with tradeoffs | Compare all 3 levels; include cost and complexity analysis | reference/patterns.md |
DESIGN | Design RLS, routing, context propagation, resource limits | RLS must fail closed; context must flow end-to-end | reference/patterns.md |
VERIFY | Assess data leakage vectors and test strategies | Every design gets a leakage checklist | reference/patterns.md |
DOCUMENT | Produce architecture doc with migration path | Include diagrams, SQL examples, and monitoring plan | — |
| Strategy | Tenant scale | Data isolation | Cost | Complexity | Compliance |
|---|---|---|---|---|---|
| Database-per-tenant | 1-100 | Strongest | High | Medium | HIPAA/PCI-DSS/EU-AI-Act ready; use Neon project-per-tenant for serverless scale |
| Schema-per-tenant | 10-1,000 | Strong | Medium | Medium-High | SOC2 ready; Citus 13 schema-based sharding for write scale |
| Row-level (RLS) | 100-100,000+ | Moderate | Low | Low-Medium | Needs careful design; index tenant column; use security_invoker views (PG 15+) |
| Hybrid | Varies | Configurable | Medium | High | Per-tier compliance; dominant pattern in mature SaaS 2025+ |
Hybrid tenancy is the dominant pattern in mature SaaS (2025+): standard-tier tenants share pooled row-level infrastructure while enterprise tenants with compliance or heavy workload requirements get isolated schemas or dedicated databases. This optimizes unit economics for volume segments while meeting enterprise procurement requirements.
Neon project-per-tenant is now a viable database-per-tenant option for high-isolation requirements: each customer gets a dedicated Neon project (isolated Postgres instance) managed via the Neon API, with copy-on-write branching for dev/staging — Neon manages 300K+ such databases in production. Particularly suited for HIPAA-regulated SaaS. Source: Neon — Multitenancy, How Neon Solves HIPAA Compliance, Multi-Tenancy, and Scaling for B2B SaaS
Data residency requirement (EU AI Act / GDPR): As of 2026, Article 16 of the EU AI Act activates for Annex III high-risk systems (August 2026), with penalties up to €15M or 3% of global turnover. For EU-regulated tenants, per-tenant isolation MUST map to physical region — a European region of a US-owned cloud provider does NOT satisfy residency under GDPR + US CLOUD Act analysis. Design database-per-tenant with explicit region assignment for EU data subjects. Source: EU Data Residency for AI Infrastructure: 2026 Guide
| Factor | Favors DB-per-tenant | Favors Schema | Favors RLS |
|---|---|---|---|
| Tenant count | < 100 | 10 - 1,000 | 1,000+ |
| Data sensitivity | Regulated (HIPAA) | Moderate | Standard |
| Customization need | High per-tenant | Moderate | Low |
| Operational budget | Large | Medium | Small |
| Query complexity | Cross-tenant analytics rare | Moderate | Cross-tenant queries common |
Request → [Auth Middleware] → tenant_id extracted
→ [Request Context] → tenant_id set
→ [Service Layer] → tenant_id passed
→ [Repository/ORM] → tenant_id in WHERE/RLS
→ [Database] → query scoped to tenant
Key design points:
contextvars, Node.js AsyncLocalStorage, Go context.Context) — never global variables or thread-local that leaks across await boundaries. [Source: Node.js docs — Asynchronous context tracking (https://nodejs.org/api/async_context.html)]SELECT set_config('app.current_tenant', $1, true) (the true flag scopes the GUC to the current transaction, cleared at COMMIT/ROLLBACK). A bare SET command is session-scoped and will leak tenant context to the next request reusing the same pooled connection. Source: Supavisor docsReceives: Schema (DB design), Gateway (API design), User (requirements), Atlas (architecture analysis) Sends: Schema (RLS implementation), Scaffold (infra config), Builder (implementation), Sentinel (security review)
| Direction | Handoff | Purpose |
|---|---|---|
| Schema → Shard | SCHEMA_TO_SHARD_HANDOFF | DB design context for isolation |
| Gateway → Shard | GATEWAY_TO_SHARD_HANDOFF | API routing context |
| Shard → Schema | SHARD_TO_SCHEMA_HANDOFF | RLS policies for implementation |
| Shard → Sentinel | SHARD_TO_SENTINEL_HANDOFF | Data leakage assessment for review |
| Reference | Read this when |
|---|---|
reference/patterns.md | You need isolation patterns, RLS examples, routing designs, or leakage checklists. |
reference/examples.md | You need complete multi-tenant architecture examples. |
reference/handoffs.md | You need handoff templates for collaboration with other agents. |
reference/tenant-migration.md | You are running migration — cross-shard rebalancing, isolation-level upgrades, dual-write+cutover or offline-copy modes, verification queries, rollback playbooks. |
reference/tenant-provisioning.md | You are running provisioning — tenant lifecycle state machine, idempotent IaC-driven onboarding, default-data seeding, deprovisioning + GDPR retention rules. |
reference/tenant-quota-throttling.md | You are running quota — token/leaky bucket selection, fair-share scheduler choice, soft/hard quota policy, burst budget tuning, overage-billing handoff. |
_common/OPUS_5_AUTHORING.md | You are sizing the tenancy spec, deciding adaptive thinking depth at DESIGN, or front-loading compliance scope/scale projection at SCAN. Critical for Shard: P3, P5. |
reference/autorun-schema.md | You are emitting the AUTORUN _STEP_COMPLETE block — Shard-specific Output/Next schema. |
.agents/shard.md; create if missing..agents/PROJECT.md: | YYYY-MM-DD | Shard | (action) | (files) | (outcome) |_common/OPERATIONAL.md and _common/GIT_GUIDELINES.md.See _common/AUTORUN.md for the protocol (_AGENT_CONTEXT input, mode semantics, error handling). Shard-specific _STEP_COMPLETE.Output schema lives in reference/autorun-schema.md.
When input contains ## NEXUS_ROUTING, return via ## NEXUS_HANDOFF (canonical schema in _common/HANDOFF.md).