forgecraft-mcp 0.2.0 → 0.3.0

package/templates/data-lineage/instructions.yaml

@@ -0,0 +1,28 @@
+tag: DATA-LINEAGE
+section: instructions
+blocks:
+  - id: field-coverage
+    tier: recommended
+    title: "100% Field Coverage Enforcement"
+    content: |
+      ## 100% Field Coverage Enforcement
+
+      - Every data field must have a documented origin (source system, table, column) and destination (target system, table, column).
+      - Maintain a field-level lineage registry: no field enters production without a lineage entry. Enforce this in CI.
+      - Track field transformations explicitly: document every rename, type cast, aggregation, join, and filter applied to each field.
+      - Implement automated coverage checks: compare the lineage registry against actual schema definitions. Flag any untracked fields as errors.
+      - Version lineage metadata alongside code: lineage definitions live in the repository, not in external wikis or spreadsheets.
+      - Generate lineage reports per pipeline run: which fields were read, transformed, and written, with row counts and data quality metrics.
+
+  - id: lineage-tracking-decorators
+    tier: recommended
+    title: "Lineage Tracking Decorators & Annotations"
+    content: |
+      ## Lineage Tracking Decorators & Annotations
+
+      - Use decorators or annotations on transformation functions to declare input fields, output fields, and transformation type.
+      - Standardize lineage metadata format: source, transformation, destination, timestamp, pipeline_id, run_id.
+      - Emit lineage events at runtime: every transformation step publishes a lineage event to a centralized lineage store.
+      - Support both code-level lineage (decorators on functions) and config-level lineage (YAML/JSON transformation specs).
+      - Integrate lineage with data quality: when a quality check fails, trace back through lineage to identify the source of bad data.
+      - Visualize lineage graphs: generate dependency diagrams showing field-level flow from source to consumption.

package/templates/data-lineage/mcp-servers.yaml

@@ -0,0 +1,22 @@
+tag: DATA-LINEAGE
+section: mcp-servers
+servers:
+  - name: postgres
+    description: "PostgreSQL database inspection — query lineage metadata and schema definitions"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-postgres"]
+    tags: [DATA-LINEAGE, DATA-PIPELINE]
+    category: database
+    tier: recommended
+    env:
+      POSTGRES_CONNECTION_STRING: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"
+
+  - name: filesystem
+    description: "Filesystem access for lineage definition files and pipeline configurations"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-filesystem"]
+    tags: [DATA-LINEAGE, UNIVERSAL]
+    category: filesystem
+    tier: optional
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem"

package/templates/data-pipeline/mcp-servers.yaml

@@ -0,0 +1,13 @@
+tag: DATA-PIPELINE
+section: mcp-servers
+servers:
+  - name: postgres
+    description: "PostgreSQL database inspection, queries, and schema management"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-postgres"]
+    tags: [DATA-PIPELINE, API]
+    category: database
+    tier: recommended
+    env:
+      POSTGRES_CONNECTION_STRING: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"

package/templates/data-pipeline/skills.yaml

@@ -0,0 +1,56 @@
+tag: DATA-PIPELINE
+section: skills
+skills:
+  - id: pipeline-validate-schema
+    name: Validate Pipeline Schema
+    filename: pipeline-validate-schema.md
+    description: "Validate data pipeline schemas and detect drift"
+    tier: core
+    content: |
+      Validate data pipeline schemas for consistency and detect drift.
+
+      Steps:
+      1. **Find schema definitions**: Search for schema files, model definitions, or DDL:
+         - SQL migration files
+         - ORM models (SQLAlchemy, Prisma, TypeORM, etc.)
+         - Avro/Protobuf/JSON Schema definitions
+         - DataFrame column definitions
+      2. **Check for drift**: Compare schemas across pipeline stages:
+         - Source schema vs. ingestion schema
+         - Ingestion schema vs. transformation output
+         - Transformation output vs. serving layer
+      3. **Validate contracts**:
+         - All nullable fields explicitly marked
+         - Default values defined for new columns
+         - Breaking changes (column removal, type change) flagged
+         - Backward/forward compatibility for event schemas
+      4. **Report**:
+         - Schema location and version
+         - Drift detected between stages
+         - Breaking changes that need migration
+
+      If $ARGUMENTS specifies a pipeline or table name, focus on that. Otherwise, scan all schemas.
+
+  - id: pipeline-trace-lineage
+    name: Trace Data Lineage
+    filename: pipeline-trace-lineage.md
+    description: "Trace data lineage from source to destination"
+    tier: recommended
+    content: |
+      Trace the data lineage for the field or table specified in $ARGUMENTS.
+
+      Steps:
+      1. Start from the target field/table
+      2. Trace backward through transformations:
+         - Which upstream tables/sources feed into it?
+         - What transformations are applied (joins, filters, aggregations)?
+         - What business logic modifies the values?
+      3. Trace forward to consumers:
+         - Which downstream tables/reports/APIs consume it?
+         - What would break if the source schema changed?
+      4. Document the lineage:
+         - Source → Transform → Target chain
+         - Data freshness (batch frequency, streaming lag)
+         - Owner/team for each stage
+
+      Output a text-based lineage diagram showing the data flow.

package/templates/fintech/mcp-servers.yaml

@@ -0,0 +1,13 @@
+tag: FINTECH
+section: mcp-servers
+servers:
+  - name: stripe
+    description: "Stripe API integration — payments, subscriptions, invoices, and customer management"
+    command: npx
+    args: ["-y", "@stripe/mcp-server"]
+    tags: [FINTECH]
+    category: general
+    tier: recommended
+    env:
+      STRIPE_SECRET_KEY: ""
+    url: "https://github.com/stripe/agent-toolkit"

package/templates/fintech/skills.yaml

@@ -0,0 +1,35 @@
+tag: FINTECH
+section: skills
+skills:
+  - id: fintech-money-audit
+    name: Money Calculation Audit
+    filename: fintech-money-audit.md
+    description: "Audit codebase for monetary calculation safety"
+    tier: core
+    content: |
+      Audit the codebase for monetary calculation risks.
+
+      Scan for:
+      1. **Floating-point arithmetic on money**:
+         - Any use of `float`, `double`, or JavaScript `number` for currency amounts
+         - Arithmetic operations (+, -, *, /) on money values without decimal/integer cents
+         - Rounding errors in tax, discount, or fee calculations
+      2. **Currency handling**:
+         - Money values stored without currency code
+         - Mixed-currency arithmetic without explicit conversion
+         - Missing exchange rate snapshots for audit trail
+      3. **Rounding**:
+         - Inconsistent rounding modes (banker's rounding vs. standard)
+         - Rounding applied at intermediate steps instead of final result
+         - Missing rounding specification in calculations
+      4. **Overflow / precision**:
+         - Integer cents stored in types too small for large amounts
+         - Multiplication (e.g., interest) without precision guards
+         - Division without remainder handling
+
+      For each finding, report:
+      - **File**: path
+      - **Line**: number
+      - **Risk**: CRITICAL | HIGH | MEDIUM
+      - **Issue**: what could go wrong
+      - **Fix**: recommended change (e.g., use Decimal library, store as integer cents)

package/templates/game/mcp-servers.yaml

@@ -0,0 +1,11 @@
+tag: GAME
+section: mcp-servers
+servers:
+  - name: unity-mcp
+    description: "Unity Editor integration — scene management, asset control, code generation"
+    command: npx
+    args: ["-y", "@anthropic/unity-mcp"]
+    tags: [GAME]
+    category: game-engine
+    tier: recommended
+    url: "https://github.com/CoplayDev/unity-mcp"

package/templates/healthcare/mcp-servers.yaml

@@ -0,0 +1,13 @@
+tag: HEALTHCARE
+section: mcp-servers
+servers:
+  - name: postgres
+    description: "PostgreSQL database inspection, queries, and schema management — common backend for EHR/clinical data"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-postgres"]
+    tags: [DATA-PIPELINE, API, HEALTHCARE]
+    category: database
+    tier: recommended
+    env:
+      POSTGRES_CONNECTION_STRING: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"

package/templates/healthcare/skills.yaml

@@ -0,0 +1,35 @@
+tag: HEALTHCARE
+section: skills
+skills:
+  - id: healthcare-phi-audit
+    name: PHI Audit
+    filename: healthcare-phi-audit.md
+    description: "Scan codebase for PHI exposure risks"
+    tier: core
+    content: |
+      Audit the codebase for Protected Health Information (PHI) exposure risks.
+
+      Scan for:
+      1. **Logging**: Search for log statements that might include PHI fields:
+         - Patient name, DOB, SSN, MRN, address, phone, email
+         - Diagnosis codes, treatment plans, lab results
+         - Any field from a patient/member/encounter model
+      2. **Error messages**: Check that error responses don't leak PHI in:
+         - API error bodies
+         - Exception messages
+         - Stack traces exposed to clients
+      3. **Storage**: Verify PHI at rest is protected:
+         - Database fields containing PHI are identified and encrypted
+         - File uploads with PHI use encrypted storage
+         - Temporary files are cleaned up
+      4. **Transmission**: Verify PHI in transit:
+         - All endpoints serving PHI require HTTPS
+         - No PHI in URL query parameters (use POST body)
+         - No PHI in client-side analytics or tracking
+
+      Report each finding with:
+      - **File**: path
+      - **Line**: number
+      - **Risk**: HIGH | MEDIUM | LOW
+      - **PHI type**: what data is exposed
+      - **Fix**: recommended remediation

package/templates/hipaa/instructions.yaml

@@ -0,0 +1,41 @@
+tag: HIPAA
+section: instructions
+blocks:
+  - id: pii-masking
+    tier: recommended
+    title: "PII Masking & Data Protection"
+    content: |
+      ## PII Masking & Data Protection
+
+      - Identify all Personally Identifiable Information (PII) fields at design time using the 18 HIPAA identifiers as a baseline.
+      - Implement masking templates for every PII field: full mask for display, partial mask for verification, tokenized for logging.
+      - Apply dynamic masking based on user role — clinicians see full data, billing sees partial, analytics sees only de-identified data.
+      - Never store raw PII in caches, message queues, or temporary files. Use tokenized references that resolve through a secure lookup service.
+      - Validate masking coverage with automated tests: no PII field should reach a log sink, error report, or analytics pipeline unmasked.
+      - Maintain a PII field registry as a living document — every new field must be classified before it enters the data model.
+
+  - id: encryption-checks
+    tier: recommended
+    title: "Encryption Verification & Key Management"
+    content: |
+      ## Encryption Verification & Key Management
+
+      - Enforce AES-256 encryption at rest for all data stores containing PII. Verify encryption status in CI with infrastructure-as-code checks.
+      - Require TLS 1.2+ for all data in transit. Reject connections using older protocols at the load balancer level.
+      - Use envelope encryption with a managed KMS (AWS KMS, Azure Key Vault, GCP KMS). Never store encryption keys alongside encrypted data.
+      - Rotate encryption keys on a defined schedule (90 days minimum). Automate rotation and re-encryption of affected data.
+      - Include encryption verification in deployment checklists: database encryption enabled, TLS certificates valid, KMS policies correct.
+      - Test encryption boundaries: verify that data crossing service boundaries remains encrypted and that decryption only occurs in authorized services.
+
+  - id: audit-logging-hipaa
+    tier: recommended
+    title: "HIPAA Audit Logging"
+    content: |
+      ## HIPAA Audit Logging
+
+      - Log every access to PII: who, when, what data, from where, and the business justification.
+      - Store audit logs in an append-only, tamper-evident store separate from application databases.
+      - Retain audit logs for a minimum of 6 years per HIPAA requirements.
+      - Generate automated audit reports: access frequency per user, unusual patterns, after-hours access.
+      - Implement real-time alerting for anomalous access: bulk record access, out-of-role access, VIP record access.
+      - Include a unique correlation ID in every request touching PII for end-to-end traceability across services.

package/templates/hipaa/mcp-servers.yaml

@@ -0,0 +1,13 @@
+tag: HIPAA
+section: mcp-servers
+servers:
+  - name: postgres
+    description: "PostgreSQL database inspection and schema management — common backend for PHI/PII storage"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-postgres"]
+    tags: [HIPAA, HEALTHCARE, API]
+    category: database
+    tier: recommended
+    env:
+      POSTGRES_CONNECTION_STRING: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"

package/templates/hipaa/skills.yaml

@@ -0,0 +1,39 @@
+tag: HIPAA
+section: skills
+skills:
+  - id: hipaa-compliance-check
+    name: HIPAA Compliance Check
+    filename: hipaa-compliance-check.md
+    description: "Verify HIPAA technical safeguard compliance"
+    tier: core
+    content: |
+      Check the project for HIPAA technical safeguard compliance.
+
+      Verify each requirement:
+
+      **Access Controls (§164.312(a))**:
+      - [ ] Unique user identification — every user has a unique ID
+      - [ ] Emergency access procedure — documented break-glass process
+      - [ ] Automatic logoff — session timeout configured
+      - [ ] Encryption/decryption — PHI encrypted at rest
+
+      **Audit Controls (§164.312(b))**:
+      - [ ] Audit logging enabled for all PHI access
+      - [ ] Logs include: who, what, when, where (IP)
+      - [ ] Logs are tamper-evident (append-only, signed, or immutable storage)
+      - [ ] Log retention meets minimum period (6 years)
+
+      **Integrity Controls (§164.312(c))**:
+      - [ ] Data validation on PHI fields
+      - [ ] Checksums or signatures for data integrity verification
+
+      **Transmission Security (§164.312(e))**:
+      - [ ] TLS 1.2+ enforced for all PHI transmission
+      - [ ] No PHI in URL parameters
+      - [ ] Encryption for PHI in message queues or event streams
+
+      For each gap, report:
+      - **Requirement**: HIPAA section reference
+      - **Status**: COMPLIANT | GAP | PARTIAL
+      - **Finding**: what's missing
+      - **Remediation**: specific implementation steps

package/templates/infra/mcp-servers.yaml

@@ -0,0 +1,20 @@
+tag: INFRA
+section: mcp-servers
+servers:
+  - name: docker
+    description: "Docker container and image management via MCP"
+    command: npx
+    args: ["-y", "mcp-server-docker"]
+    tags: [INFRA]
+    category: deployment
+    tier: recommended
+    url: "https://github.com/ckreiling/mcp-server-docker"
+
+  - name: kubernetes
+    description: "Kubernetes cluster management — pods, deployments, services"
+    command: npx
+    args: ["-y", "mcp-server-kubernetes"]
+    tags: [INFRA]
+    category: deployment
+    tier: optional
+    url: "https://github.com/strowk/mcp-k8s-go"

package/templates/library/mcp-servers.yaml

@@ -0,0 +1,20 @@
+tag: LIBRARY
+section: mcp-servers
+servers:
+  - name: filesystem
+    description: "Secure file operations — read, write, search, and directory management with configurable access controls"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-filesystem", "/"]
+    tags: [CLI, LIBRARY]
+    category: general
+    tier: recommended
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem"
+
+  - name: npm-search
+    description: "Search npm registry for packages, check versions, and inspect dependencies"
+    command: npx
+    args: ["-y", "mcp-server-npm-search"]
+    tags: [LIBRARY]
+    category: documentation
+    tier: optional
+    url: "https://github.com/nicholasgriffintn/npm-search-mcp-server"

package/templates/medallion-architecture/instructions.yaml

@@ -0,0 +1,41 @@
+tag: MEDALLION-ARCHITECTURE
+section: instructions
+blocks:
+  - id: bronze-layer
+    tier: recommended
+    title: "Bronze Layer — Immutable Raw Ingestion"
+    content: |
+      ## Bronze Layer — Immutable Raw Ingestion
+
+      - Bronze is the landing zone. Data arrives exactly as received from source systems — no transformations, no filtering, no deduplication.
+      - Store Bronze data in append-only, immutable formats (Parquet, Delta Lake, Iceberg). Never overwrite or delete Bronze records.
+      - Include ingestion metadata on every record: source_system, ingested_at, batch_id, file_origin, raw_checksum.
+      - Partition Bronze tables by ingestion date for efficient reprocessing. Never partition by business keys at this layer.
+      - Implement schema-on-read: Bronze accepts any schema from source. Schema validation happens at the Silver promotion step.
+      - Retain Bronze data indefinitely (or per legal retention policy). Bronze is the recovery point for all downstream reprocessing.
+
+  - id: silver-layer
+    tier: recommended
+    title: "Silver Layer — Validated & Conformed"
+    content: |
+      ## Silver Layer — Validated & Conformed
+
+      - Silver applies data quality rules: type validation, null checks, range constraints, referential integrity, deduplication.
+      - Every record in Silver must pass defined quality gates. Records failing validation are routed to a quarantine table, not dropped.
+      - Conform naming conventions: standardize column names, date formats, currency codes, and enum values across all Silver tables.
+      - Track record lineage: every Silver record links back to its Bronze source via source_record_id and bronze_batch_id.
+      - Apply slowly changing dimension (SCD) Type 2 for reference data: maintain history with effective_from and effective_to timestamps.
+      - Silver tables define explicit schemas enforced on write. Schema changes require a migration plan and backward compatibility check.
+
+  - id: gold-layer
+    tier: recommended
+    title: "Gold Layer — Aggregated & Business-Ready"
+    content: |
+      ## Gold Layer — Aggregated & Business-Ready
+
+      - Gold tables are purpose-built for specific business use cases: dashboards, ML features, API responses, reports.
+      - Apply business logic at the Gold layer: aggregations, joins, calculated fields, business rules, KPI definitions.
+      - Optimize Gold tables for read performance: pre-aggregate, denormalize, partition by access patterns.
+      - Document every Gold table with its business purpose, refresh cadence, source Silver tables, and SLA.
+      - Version Gold table definitions: changes to aggregation logic or business rules are tracked, reviewed, and deployed like code.
+      - Implement data contracts for Gold consumers: define expected schema, update frequency, and quality guarantees.

package/templates/medallion-architecture/mcp-servers.yaml

@@ -0,0 +1,22 @@
+tag: MEDALLION-ARCHITECTURE
+section: mcp-servers
+servers:
+  - name: postgres
+    description: "PostgreSQL for medallion layer metadata, quality gate results, and lineage tracking"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-postgres"]
+    tags: [MEDALLION-ARCHITECTURE, DATA-PIPELINE]
+    category: database
+    tier: recommended
+    env:
+      POSTGRES_CONNECTION_STRING: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"
+
+  - name: filesystem
+    description: "Filesystem access for Bronze/Silver/Gold layer data files and pipeline configs"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-filesystem"]
+    tags: [MEDALLION-ARCHITECTURE, DATA-PIPELINE]
+    category: filesystem
+    tier: optional
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem"

package/templates/ml/mcp-servers.yaml

@@ -0,0 +1,11 @@
+tag: ML
+section: mcp-servers
+servers:
+  - name: jupyter
+    description: "Jupyter notebook management — create, execute, and inspect cells"
+    command: npx
+    args: ["-y", "mcp-server-jupyter"]
+    tags: [ML, DATA-PIPELINE]
+    category: ai-ml
+    tier: recommended
+    url: "https://github.com/datalayer/jupyter-mcp-server"

package/templates/mobile/mcp-servers.yaml

@@ -0,0 +1,11 @@
+tag: MOBILE
+section: mcp-servers
+servers:
+  - name: android-emulator
+    description: "Android emulator control — screenshots, tap, swipe, and app lifecycle"
+    command: npx
+    args: ["-y", "mcp-server-android"]
+    tags: [MOBILE]
+    category: devtools
+    tier: recommended
+    url: "https://github.com/nicholasgriffintn/android-mcp-server"

package/templates/observability-xray/instructions.yaml

@@ -0,0 +1,40 @@
+tag: OBSERVABILITY-XRAY
+section: instructions
+blocks:
+  - id: xray-lambda-instrumentation
+    tier: recommended
+    title: "Auto-Add X-Ray Instrumentation to Lambdas"
+    content: |
+      ## Auto-Add X-Ray Instrumentation to Lambdas
+
+      - Enable X-Ray active tracing on every Lambda function by default. Set `tracing: Active` in SAM/CloudFormation or `tracing_config { mode = "Active" }` in Terraform.
+      - Wrap the AWS SDK client with the X-Ray SDK to automatically trace all downstream AWS service calls (DynamoDB, S3, SQS, SNS).
+      - Add X-Ray middleware or decorators to every Lambda handler. No handler should execute without producing a trace segment.
+      - Include custom subsegments for business-critical operations: database queries, external API calls, heavy computations.
+      - Propagate trace headers across service boundaries: ensure `X-Amzn-Trace-Id` is forwarded in HTTP headers and SQS message attributes.
+      - Set sampling rules appropriate to traffic volume: 100% for low-traffic, reservoir-based for high-traffic. Document sampling decisions.
+
+  - id: xray-annotations-metadata
+    tier: recommended
+    title: "X-Ray Annotations & Metadata Standards"
+    content: |
+      ## X-Ray Annotations & Metadata Standards
+
+      - Add annotations for every trace: `service`, `environment`, `version`, `userId` (hashed), `correlationId`. Annotations are indexed and searchable.
+      - Use metadata for non-indexed debug data: request/response sizes, feature flags, cache hit/miss ratios.
+      - Define a standard annotation taxonomy across all services. No ad-hoc annotation keys — use a shared enum or constant file.
+      - Create X-Ray groups for critical paths: user-facing APIs, payment flows, data pipelines. Monitor group error rates and latency.
+      - Set up X-Ray insights for automated anomaly detection on critical service groups.
+      - Include X-Ray trace IDs in error responses and log entries for cross-referencing between traces and logs.
+
+  - id: xray-alerting
+    tier: optional
+    title: "X-Ray-Based Alerting & SLOs"
+    content: |
+      ## X-Ray-Based Alerting & SLOs
+
+      - Define SLOs per service using X-Ray latency and error rate data: p50, p95, p99 latency targets and error budget thresholds.
+      - Create CloudWatch alarms from X-Ray service maps: alert on elevated fault rates, latency spikes, or throttling.
+      - Monitor cold start impact via X-Ray initialization subsegments. Alert if cold start percentage exceeds threshold.
+      - Build dashboards combining X-Ray service map data with CloudWatch metrics for a unified observability view.
+      - Review X-Ray traces weekly for optimization opportunities: unnecessary downstream calls, serial-when-could-be-parallel patterns.

package/templates/observability-xray/mcp-servers.yaml

@@ -0,0 +1,15 @@
+tag: OBSERVABILITY-XRAY
+section: mcp-servers
+servers:
+  - name: aws-cloudwatch
+    description: "AWS CloudWatch logs and metrics — query X-Ray traces, view Lambda logs, monitor alarms"
+    command: npx
+    args: ["-y", "mcp-server-cloudwatch"]
+    tags: [OBSERVABILITY-XRAY, INFRA]
+    category: monitoring
+    tier: recommended
+    env:
+      AWS_REGION: ""
+      AWS_ACCESS_KEY_ID: ""
+      AWS_SECRET_ACCESS_KEY: ""
+    url: "https://github.com/modelcontextprotocol/servers"

package/templates/realtime/mcp-servers.yaml

@@ -0,0 +1,13 @@
+tag: REALTIME
+section: mcp-servers
+servers:
+  - name: redis
+    description: "Redis key-value store management — pub/sub, streams, caching, and session management"
+    command: npx
+    args: ["-y", "mcp-server-redis"]
+    tags: [REALTIME]
+    category: database
+    tier: recommended
+    env:
+      REDIS_URL: "redis://localhost:6379"
+    url: "https://github.com/nicholasgriffintn/redis-mcp-server"

package/templates/soc2/instructions.yaml

@@ -0,0 +1,41 @@
+tag: SOC2
+section: instructions
+blocks:
+  - id: access-control-validation
+    tier: recommended
+    title: "Access Control Validation"
+    content: |
+      ## Access Control Validation
+
+      - Implement role-based access control (RBAC) with the principle of least privilege. No user or service account gets more access than required.
+      - Define access control matrices mapping roles to resources and operations. Review and update quarterly.
+      - Enforce multi-factor authentication (MFA) for all administrative and privileged access.
+      - Automate access reviews: flag dormant accounts (no login in 90 days), over-provisioned roles, and orphaned service accounts.
+      - Log all access control changes (role assignments, permission grants, policy updates) with who-changed-what-when detail.
+      - Test access controls with negative tests: verify that unauthorized roles are denied, not just that authorized roles succeed.
+
+  - id: change-management
+    tier: recommended
+    title: "Change Management & Audit Trail"
+    content: |
+      ## Change Management & Audit Trail
+
+      - Every production change requires a documented change request with description, risk assessment, rollback plan, and approval.
+      - Enforce separation of duties: the person who writes code cannot be the sole approver for deployment.
+      - Maintain an immutable audit trail of all changes: code commits, config changes, infrastructure modifications, access grants.
+      - Implement automated change detection: alert on unexpected file changes, config drift, or unauthorized deployments.
+      - Conduct post-incident reviews for all unplanned changes. Document root cause, timeline, and preventive measures.
+      - Tag all deployments with version, timestamp, deployer, and change request ID for full traceability.
+
+  - id: incident-response
+    tier: recommended
+    title: "Incident Response Procedures"
+    content: |
+      ## Incident Response Procedures
+
+      - Define and document an incident response plan with clear roles: incident commander, communications lead, technical lead.
+      - Classify incidents by severity (P1-P4) with defined response times, escalation paths, and communication templates.
+      - Implement automated incident detection: anomaly alerts, threshold breaches, security event correlation.
+      - Conduct tabletop exercises quarterly to test incident response procedures with realistic scenarios.
+      - Maintain a post-mortem culture: blameless retrospectives within 48 hours, action items tracked to completion.
+      - Ensure incident logs are retained for SOC2 audit periods (minimum 12 months) with tamper-evident storage.

package/templates/soc2/mcp-servers.yaml

@@ -0,0 +1,24 @@
+tag: SOC2
+section: mcp-servers
+servers:
+  - name: github
+    description: "GitHub repository management — PR reviews, access controls, audit trails for change management"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-github"]
+    tags: [SOC2, UNIVERSAL]
+    category: version-control
+    tier: recommended
+    env:
+      GITHUB_PERSONAL_ACCESS_TOKEN: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/github"
+
+  - name: sentry
+    description: "Sentry error and incident tracking — incident response monitoring and alerting"
+    command: npx
+    args: ["-y", "mcp-server-sentry"]
+    tags: [SOC2, API]
+    category: monitoring
+    tier: optional
+    env:
+      SENTRY_AUTH_TOKEN: ""
+    url: "https://github.com/modelcontextprotocol/servers"

package/templates/social/mcp-servers.yaml

@@ -0,0 +1,24 @@
+tag: SOCIAL
+section: mcp-servers
+servers:
+  - name: postgres
+    description: "PostgreSQL database inspection, queries, and schema management — common backend for social platforms"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-postgres"]
+    tags: [DATA-PIPELINE, API, SOCIAL]
+    category: database
+    tier: recommended
+    env:
+      POSTGRES_CONNECTION_STRING: ""
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/postgres"
+
+  - name: redis
+    description: "Redis key-value store management — caching, sessions, feeds, and real-time features"
+    command: npx
+    args: ["-y", "mcp-server-redis"]
+    tags: [REALTIME, SOCIAL]
+    category: database
+    tier: optional
+    env:
+      REDIS_URL: "redis://localhost:6379"
+    url: "https://github.com/nicholasgriffintn/redis-mcp-server"

package/templates/state-machine/mcp-servers.yaml

@@ -0,0 +1,11 @@
+tag: STATE-MACHINE
+section: mcp-servers
+servers:
+  - name: sequential-thinking
+    description: "Dynamic, reflective problem-solving through thought sequences — ideal for modeling state transitions"
+    command: npx
+    args: ["-y", "@modelcontextprotocol/server-sequential-thinking"]
+    tags: [UNIVERSAL, STATE-MACHINE]
+    category: general
+    tier: optional
+    url: "https://github.com/modelcontextprotocol/servers/tree/main/src/sequentialthinking"