mindforge-cc 10.0.3 → 11.0.0

package/.mindforge/skills/analytics-instrumentation/SKILL.md

@@ -0,0 +1,172 @@
+---
+name: analytics-instrumentation
+version: 1.0.0
+min_mindforge_version: 10.0.4
+status: stable
+triggers: analytics instrumentation, event taxonomy, tracking plan, data layer architecture, privacy-aware analytics, funnel measurement, event naming convention, analytics schema, user journey tracking, conversion tracking, analytics governance, event validation
+---
+
+# Skill — Analytics Instrumentation (Privacy-Aware Event Architecture)
+
+## When this skill activates
+When designing event tracking systems, building data layers, creating tracking plans,
+instrumenting user journeys, or establishing analytics governance. Use for any task
+that involves measuring user behavior in a structured, privacy-respecting way.
+
+Core principle: **Track intent, not surveillance** — measure what users DO to improve
+what you BUILD, never to manipulate or over-collect.
+
+## Mandatory actions when this skill is active
+
+### Event Taxonomy Design
+
+1. **Naming convention (object_action format):**
+   ```
+   Format: [object]_[action]
+   Examples:
+   - button_clicked
+   - form_submitted
+   - page_viewed
+   - cart_item_added
+   - search_performed
+   - error_encountered
+   ```
+
+   Rules:
+   - Always past tense for the action (clicked, not click)
+   - Lowercase with underscores (snake_case)
+   - Object first, action second (noun_verb)
+   - Maximum 3 words total (object can be compound: cart_item_added)
+   - Never include PII in event names
+   - Never include dynamic values in event names (no "product_12345_viewed")
+
+2. **Event property schema:**
+   ```json
+   {
+     "event": "button_clicked",
+     "properties": {
+       "button_id": "string (required) — unique identifier",
+       "button_text": "string (required) — visible label",
+       "page_path": "string (required) — current URL path",
+       "section": "string (optional) — page section containing button",
+       "variant": "string (optional) — A/B test variant if applicable"
+     },
+     "context": {
+       "timestamp": "ISO-8601 (auto)",
+       "session_id": "string (auto)",
+       "device_type": "string (auto)",
+       "viewport_width": "number (auto)"
+     }
+   }
+   ```
+
+   Rules:
+   - Separate event-specific properties from auto-collected context
+   - Mark each property as required or optional
+   - Include data type and brief description
+   - Never include PII in properties without explicit consent flag
+
+### Tracking Plan
+
+3. **Tracking plan structure (source of truth):**
+   ```
+   | Event Name       | Trigger                    | Properties         | Owner    | Status       |
+   |------------------|----------------------------|--------------------|----------|--------------|
+   | page_viewed      | Page load complete         | page_path, title   | @fe-team | Implemented  |
+   | button_clicked   | Any tracked button click   | button_id, text    | @fe-team | In Review    |
+   | form_submitted   | Form submission success    | form_id, fields    | @fe-team | Planned      |
+   ```
+
+   Rules:
+   - Every event MUST have an owner (team or individual)
+   - Status lifecycle: Planned → In Review → Implemented → Validated → Deprecated
+   - Review tracking plan quarterly: deprecate unused events
+   - New events require tracking plan entry BEFORE implementation
+
+### Data Layer Architecture
+
+4. **Data layer implementation:**
+   ```javascript
+   // Structured data layer (consumed by analytics tools)
+   window.dataLayer = window.dataLayer || [];
+
+   // Push events with standard structure
+   window.dataLayer.push({
+     event: 'button_clicked',
+     properties: {
+       button_id: 'cta-signup-hero',
+       button_text: 'Start Free Trial',
+       page_path: '/pricing'
+     }
+   });
+   ```
+
+   Rules:
+   - Data layer is the SINGLE source of truth (analytics tools consume it, don't instrument directly)
+   - Never push to data layer before consent is granted
+   - Validate data layer pushes against schema in CI
+   - Data layer must be populated server-side for critical events (don't rely solely on client JS)
+
+### Privacy-Aware Analytics
+
+5. **Privacy requirements (non-negotiable):**
+   - Obtain consent BEFORE any tracking fires (banner/modal with granular choices)
+   - Honor Do Not Track (DNT) header — respect user preference
+   - Anonymize by default: no full IP, no fingerprinting, no cross-site tracking
+   - Data retention: define maximum retention per event type (default 13 months for GDPR)
+   - Right to deletion: ensure analytics pipeline can purge by user ID
+   - Consent categories: necessary (no consent needed) | analytics (consent required) | marketing (separate consent)
+
+6. **Consent implementation:**
+   ```javascript
+   // Only track if user has consented to analytics category
+   if (consentManager.hasConsent('analytics')) {
+     dataLayer.push({ event: 'page_viewed', properties: {...} });
+   }
+   ```
+
+### Funnel Measurement
+
+7. **Funnel definition:**
+   ```
+   Funnel: [name]
+   Steps:
+   1. page_viewed (page_path = '/pricing')     → Entry
+   2. button_clicked (button_id = 'select-plan') → Intent
+   3. form_submitted (form_id = 'payment')     → Commitment
+   4. purchase_completed                        → Conversion
+
+   Metrics per step:
+   - Volume (count)
+   - Conversion rate (step N / step N-1)
+   - Drop-off rate (1 - conversion rate)
+   - Time between steps (median, p95)
+   ```
+
+   Rules:
+   - Define funnels for every critical user journey
+   - Segment funnels by: device, acquisition source, user cohort, experiment variant
+   - Alert on significant drop-off changes (>10% deviation from baseline)
+   - Funnel steps must use the same event taxonomy
+
+### Analytics Governance
+
+8. **Governance processes:**
+   - **Schema validation in CI**: every new event must match the tracking plan schema
+   - **Unused event cleanup**: quarterly audit, deprecate events with <100 fires/month
+   - **Naming review**: new events require team lead approval (prevents drift)
+   - **Data quality monitoring**: alert on sudden volume spikes/drops (instrumentation bugs)
+   - **Documentation**: tracking plan is the living doc, not code comments
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Did I follow the object_action naming convention?
+- [ ] Is every event documented in the tracking plan with owner and status?
+- [ ] Does the data layer implementation gate on user consent?
+- [ ] Are PII fields excluded from event properties (or flagged for special handling)?
+- [ ] Did I define funnels for critical user journeys with per-step metrics?
+- [ ] Is there a governance process for event lifecycle management?
+- [ ] Can the schema be validated in CI (preventing undocumented events)?
+- [ ] Is data retention defined and compliant with privacy regulations?

package/.mindforge/skills/api-gateway-patterns/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: api-gateway-patterns
+version: 1.0.0
+min_mindforge_version: 0.1.0
+status: stable
+compose: api-design
+triggers: api gateway, gateway rate limiting, request routing, auth offloading, response transformation, backend for frontend, gateway circuit breaker, request aggregation, api composition, gateway caching, gateway throttling, gateway authentication
+---
+
+# Skill — API Gateway Patterns
+
+## When this skill activates
+Any task involving API gateway configuration, gateway rate limiting, request
+routing, authentication offloading, BFF patterns, or gateway-level caching.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Identify which cross-cutting concerns belong at the gateway vs service level.
+2. Define rate limiting strategy (algorithm, limits, granularity).
+3. Determine if BFF pattern is needed (multiple client types).
+
+### During implementation
+- Keep gateway logic stateless (no session state in gateway).
+- Implement circuit breakers per downstream service.
+- Add request correlation IDs at the gateway for distributed tracing.
+
+### After implementation
+- Load test rate limiting configuration.
+- Verify circuit breaker thresholds with failure injection.
+- Document gateway routing rules in ARCHITECTURE.md.
+
+## Rate Limiting Algorithms
+
+### Token Bucket
+- Bucket holds N tokens, refills at constant rate.
+- Each request consumes one token.
+- Allows bursts up to bucket capacity.
+- Best for: APIs that need burst tolerance.
+
+### Sliding Window
+- Count requests in rolling time window.
+- Smoother than fixed window (no boundary burst issue).
+- Best for: strict per-second/minute rate enforcement.
+
+### Fixed Window
+- Count requests per calendar interval (e.g., per minute).
+- Simple to implement, but allows 2x burst at window boundary.
+- Best for: simple use cases where boundary bursts are acceptable.
+
+### Rate Limit Granularity
+- **Per-user**: fairest, prevents one user from affecting others.
+- **Per-IP**: catches unauthenticated abuse, but shared IPs cause issues.
+- **Per-endpoint**: different limits for reads vs writes.
+- **Per-plan**: higher limits for premium tier customers.
+
+### Response Headers
+```
+X-RateLimit-Limit: 1000
+X-RateLimit-Remaining: 847
+X-RateLimit-Reset: 1623456789
+Retry-After: 30
+```
+
+## Authentication Offloading
+
+### Pattern
+1. Client sends request with auth token to gateway.
+2. Gateway validates JWT signature and expiration.
+3. Gateway extracts claims (user_id, roles, permissions).
+4. Gateway passes claims as trusted headers to downstream services.
+5. Downstream services trust headers (internal network only).
+
+### Benefits
+- Auth logic in one place, not duplicated across services.
+- Downstream services are simpler (no JWT library needed).
+- Token refresh/rotation handled centrally.
+
+### Security Considerations
+- Strip incoming trust headers from external requests (prevent spoofing).
+- Internal services MUST reject requests without gateway headers.
+- Gateway must validate token on every request (no caching of auth decisions).
+
+## Backend for Frontend (BFF)
+
+### Pattern
+- One gateway per client type: web, mobile, third-party.
+- Each BFF tailored to client needs (field selection, aggregation).
+- Mobile BFF: fewer fields, compressed responses, batch endpoints.
+- Web BFF: full responses, pagination, real-time subscriptions.
+- Third-party BFF: stable API, versioned, rate-limited.
+
+### When to Use BFF
+- Different clients need different data shapes.
+- Mobile clients need response optimization (bandwidth).
+- Third-party API needs different auth and rate limiting.
+
+## Request Aggregation
+
+### Pattern
+- Client sends one request to gateway.
+- Gateway fans out to multiple backend services.
+- Gateway combines responses into single response.
+- Returns aggregated result to client.
+
+### Best Practices
+- Set timeout per downstream call (don't wait forever).
+- Return partial results if some backends fail (degrade gracefully).
+- Cache individual backend responses independently.
+- Use async/parallel calls to backends (not sequential).
+
+## Circuit Breaking (Per-Route)
+
+### States
+- **Closed**: requests flow normally, failures counted.
+- **Open**: requests immediately fail (503), no backend calls.
+- **Half-Open**: allow one probe request to test recovery.
+
+### Configuration Per Downstream
+```yaml
+payment-service:
+  failure_threshold: 5       # failures before opening
+  timeout: 10s               # time in open state before half-open
+  success_threshold: 3       # successes in half-open to close
+
+inventory-service:
+  failure_threshold: 10
+  timeout: 30s
+  success_threshold: 5
+```
+
+### Fallback Strategies
+- Return cached response (stale but functional).
+- Return default/empty response with degraded flag.
+- Route to alternative backend (failover service).
+
+## Gateway Caching
+
+### What to Cache
+- GET responses with stable data (product catalog, configuration).
+- Use ETag/Last-Modified for conditional requests.
+- Cache per-user or per-role (never cache authenticated data globally).
+
+### What NOT to Cache
+- POST/PUT/DELETE responses.
+- Responses with `Cache-Control: no-store`.
+- Responses containing PII without per-user isolation.
+
+### Cache Invalidation at Gateway
+- TTL-based (simple, eventual consistency).
+- Purge API (explicit invalidation from backend on mutation).
+- Surrogate keys (tag responses, purge by tag).
+
+## Response Transformation
+
+### Appropriate at Gateway
+- Field filtering (client requests specific fields).
+- Pagination wrapping (add metadata to list responses).
+- Format conversion (JSON to XML for legacy clients).
+- Header manipulation (add CORS, security headers).
+
+### NOT Appropriate at Gateway
+- Business logic transformation.
+- Data enrichment from other services.
+- Complex aggregation with business rules.
+
+## Self-check before task completion
+
+Before marking a task done when this skill was active:
+
+- [ ] Did I read the full SKILL.md before starting? (Not just the triggers)
+- [ ] Is gateway logic stateless?
+- [ ] Are rate limits per-user (not just per-IP)?
+- [ ] Are circuit breakers configured per downstream service?
+- [ ] Is auth offloading stripping external trust headers?
+- [ ] Is business logic kept out of the gateway?
+- [ ] Are request correlation IDs generated at the gateway?

package/.mindforge/skills/api-marketplace/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: api-marketplace
+version: 1.0.0
+min_mindforge_version: 10.7.0
+status: stable
+triggers: API marketplace internal, API discovery platform, API versioning governance, API deprecation workflow, API developer onboarding, API portal, API catalog, API consumer management, API usage tracking, API lifecycle governance, internal API standard, API documentation portal
+compose: api-versioning
+---
+
+# Skill — API Marketplace
+
+## When this skill activates
+
+This skill activates when the user is designing or implementing an internal API marketplace. This includes API discovery platforms, versioning governance, deprecation workflows, developer onboarding for API consumers, API portals, API catalogs, consumer management, usage tracking, API lifecycle governance, internal API standards, and documentation portals.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+
+1. Inventory all internal APIs (REST, GraphQL, gRPC, event streams) and assess current discoverability and documentation quality.
+2. Define API lifecycle stages (proposal, alpha, beta, stable, deprecated, retired) and governance requirements for each stage.
+3. Identify API consumer personas (internal developers, data teams, mobile engineers) and their discovery and onboarding needs.
+4. Establish API standards (authentication, versioning, error handling, pagination, rate limiting) that all APIs must follow.
+5. Assess current API sprawl: duplicate APIs, shadow APIs (not documented), orphaned APIs (no owner).
+
+### During implementation
+
+- **API Discovery:** Central catalog searchable by domain, team, capability, or keyword. Each API should have: name, description, owner, SLA, OpenAPI spec, example requests, status (alpha/beta/stable/deprecated). Discovery should return results in under 500ms.
+- **API Portal:** Single entry point for all internal APIs. Include: catalog, interactive docs (Swagger UI, GraphQL Playground), try-it-now sandbox, code examples in 3+ languages, changelog per API. Portal must be indexed by internal search.
+- **Versioning Governance:** Enforce consistent versioning strategy (see `api-versioning` skill). APIs must publish a deprecation policy (minimum 6-month notice for stable APIs). Breaking changes require new major version.
+- **Deprecation Workflow:** Automated workflow: API owner announces deprecation → sunset headers added → usage monitoring dashboard → consumer outreach (email + Slack) → grace period (6 months) → removal. Track deprecation status in catalog.
+- **Developer Onboarding:** New API consumers should go from discovery to first successful API call in under 15 minutes. Include: API key provisioning (self-service), quick-start guide, sandbox environment, example code, troubleshooting tips.
+- **Consumer Management:** Track which teams consume which APIs. Use API keys or OAuth clients for attribution. Consumer dashboard shows: usage metrics, quota limits, deprecation notices, breaking change alerts.
+- **Usage Tracking:** Collect per-consumer metrics: request count, error rate, latency, quota consumption. Expose to API owners via dashboard. Alert when consumers exceed 80% of quota or hit high error rates.
+- **API Lifecycle Governance:** Alpha APIs can break without notice. Beta APIs require 1-month deprecation notice. Stable APIs require 6-month notice. Retired APIs return 410 Gone. Enforce via automated policy checks.
+- **Internal API Standards:** All APIs must: use standard authentication (OAuth2 or API keys), include OpenAPI spec, provide health check endpoint, emit structured logs, track RED metrics. Standards enforced via linting (Spectral) and API gateway policies.
+
+### After implementation
+
+- Verify the API catalog includes 100% of production-facing internal APIs with ownership and OpenAPI specs.
+- Confirm API portal enables discovery-to-first-call in under 15 minutes via user testing.
+- Validate deprecation workflows include automated sunset headers and consumer outreach.
+- Ensure usage tracking is per-consumer with dashboards for API owners.
+- Check that API standards are enforced via automated linting and gateway policies.
+
+## Self-check before task completion
+
+- [ ] API catalog is searchable and includes 100% of internal APIs with ownership and specs.
+- [ ] API portal enables discovery-to-first-call in under 15 minutes.
+- [ ] Versioning governance enforces consistent strategy across all APIs.
+- [ ] Deprecation workflow includes sunset headers, monitoring, and 6-month grace period.
+- [ ] Developer onboarding is self-service with API key provisioning and sandbox access.
+- [ ] Consumer management tracks per-team usage with quota limits and alerts.
+- [ ] Usage tracking provides per-consumer metrics to API owners via dashboard.
+- [ ] API lifecycle governance enforces deprecation policies automatically.
+- [ ] Internal API standards are enforced via linting and API gateway policies.

package/.mindforge/skills/api-versioning/SKILL.md

@@ -0,0 +1,100 @@
+---
+name: api-versioning
+version: 1.0.0
+min_mindforge_version: 10.0.7
+status: stable
+triggers: api version strategy, api deprecation lifecycle, breaking change detection, consumer contract strategy, sunset header strategy, version negotiation, api migration guide, backward compatibility strategy, api evolution pattern, api lifecycle management, api sunset policy, deprecation timeline
+---
+
+# API Versioning
+
+## When this skill activates
+
+This skill activates when the user is designing, implementing, or managing API
+versioning strategies. This includes choosing versioning schemes (URL, header, query),
+managing deprecation lifecycles, detecting breaking changes, implementing consumer-driven
+contracts, designing sunset policies, creating migration guides for consumers, and
+planning backward-compatible API evolution.
+
+## Mandatory actions
+
+### Before
+
+1. Identify the API type (REST, GraphQL, gRPC, event-driven) and existing versioning approach.
+2. Determine the consumer landscape (internal teams, external partners, public developers).
+3. Assess the current API lifecycle stage (greenfield, stable, legacy with many consumers).
+4. Review existing breaking change history and consumer migration friction.
+5. Check for contractual SLA obligations around API stability and deprecation timelines.
+
+### During
+
+**Versioning Strategies:**
+- **URL Path (`/v1/`, `/v2/`):** Most explicit, easiest for consumers to understand. Best for public APIs. Downside: duplicates route definitions.
+- **Header (`Accept: application/vnd.api+json;version=2`):** Cleaner URLs, version in content negotiation. Best for APIs with many versions. Downside: harder to test in browser.
+- **Query Parameter (`?version=2`):** Easy to implement, visible in URLs. Best for internal APIs. Downside: pollutes query string, caching complexity.
+- **No versioning (additive-only):** Evolve by only adding, never removing. Best for GraphQL. Downside: field bloat over time.
+- Choose ONE strategy per API surface. Do not mix approaches.
+
+**Breaking vs Non-Breaking Changes:**
+- **Breaking (requires new version):** Field removal, type change, adding required field, changing response structure, removing endpoint, changing authentication, altering error codes.
+- **Non-breaking (safe to deploy):** Adding optional field, adding new endpoint, adding optional query parameter, adding new enum value (if consumer ignores unknown), relaxing validation.
+- When in doubt, treat it as breaking. Consumer assumptions are hard to predict.
+
+**Deprecation Lifecycle:**
+- **Phase 1 — Announce:** Document deprecation in changelog, API docs, and developer portal. Set `Sunset` header (RFC 8594) with target date.
+- **Phase 2 — Sunset Header:** Return `Sunset: <date>` and `Deprecation: true` headers on every response from deprecated endpoints.
+- **Phase 3 — Migration Period:** Minimum 6 months for external APIs, 3 months for internal. Provide migration guide with code examples.
+- **Phase 4 — Usage Monitoring:** Track deprecated endpoint usage. Reach out to remaining consumers directly.
+- **Phase 5 — Removal:** Return 410 Gone with a body pointing to the new version. Remove after usage drops to zero (or contractual deadline).
+
+**Consumer-Driven Contracts:**
+- Consumers declare what fields/endpoints they actually use (contract).
+- Provider runs consumer contracts as part of CI (Pact, Spring Cloud Contract).
+- Breaking changes are detected automatically when a provider change violates a consumer contract.
+- Reduces false positives: only truly consumed features are protected.
+- Each consumer maintains their own contract; provider tests against all.
+
+**Sunset Header (RFC 8594):**
+- Format: `Sunset: Sat, 01 Jan 2028 00:00:00 GMT`
+- Accompanies `Deprecation: true` header.
+- Signals to automated tooling when an endpoint will be removed.
+- Include `Link` header pointing to migration documentation.
+- Example: `Link: <https://api.example.com/docs/migrate-v1-v2>; rel="sunset"`
+
+**Migration Guides:**
+- One guide per breaking change (not per version — granularity matters).
+- Include: what changed, why, before/after code examples, timeline.
+- Provide automated migration tooling where possible (codemods, SDK upgrades).
+- Offer a compatibility shim or adapter layer for complex migrations.
+- Test migration guide accuracy with a sample consumer before publishing.
+
+**Version Negotiation:**
+- Default to latest stable version if no version specified (for new consumers).
+- Return `API-Version` response header confirming which version served the request.
+- Support version discovery endpoint (`GET /versions` or API docs endpoint).
+- For header-based versioning, return 406 Not Acceptable if version is unsupported.
+
+**Backward Compatibility Strategies:**
+- Tolerant reader: consumers ignore unknown fields (Postel's law).
+- Additive evolution: only add, never remove or rename.
+- Envelope pattern: wrap responses so structure can evolve independently.
+- Feature flags: toggle new behavior per consumer via API keys or headers.
+
+### After
+
+1. Verify the chosen versioning strategy is consistently applied across all endpoints.
+2. Confirm deprecated endpoints include `Sunset` and `Deprecation` headers.
+3. Validate migration guides include before/after code examples.
+4. Check that consumer-driven contracts run in CI and detect breaking changes.
+5. Ensure monitoring tracks deprecated endpoint usage for removal decisions.
+
+## Self-check before task completion
+
+- [ ] A single versioning strategy is chosen and applied consistently.
+- [ ] Breaking vs non-breaking changes are clearly categorized.
+- [ ] Deprecation lifecycle includes announcement, sunset headers, migration period, and removal.
+- [ ] Migration period meets minimum duration (6 months external, 3 months internal).
+- [ ] Consumer-driven contracts detect breaking changes automatically in CI.
+- [ ] Sunset headers conform to RFC 8594 with linked documentation.
+- [ ] Migration guides provide per-change code examples.
+- [ ] Deprecated endpoint usage is monitored to inform removal timing.

package/.mindforge/skills/app-store-deployment/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: app-store-deployment
+version: 1.0.0
+min_mindforge_version: 10.4.0
+status: stable
+triggers: app store deployment, release management mobile, staged rollout mobile, app store compliance, app review guideline, mobile A/B testing, app store optimization deployment, mobile release pipeline, code push update, hot patch mobile, mobile feature flags, app store submission
+---
+
+# Skill — App Store Deployment & Release Management
+
+## When this skill activates
+This skill activates when managing mobile app releases, including app store submissions, staged rollouts, A/B testing, release automation, code push updates, or ensuring compliance with platform guidelines.
+
+## Mandatory actions when this skill is active
+
+### Before writing any code
+1. Review App Store Review Guidelines (iOS) and Google Play policies (Android) to ensure compliance
+2. Establish release checklist: version bumps, changelog, screenshots, metadata, certificates, entitlements
+3. Plan rollout strategy: percentage-based staged rollout, internal testing groups, beta testing timelines
+4. Configure feature flags or code push mechanism for post-release updates without app store review
+
+### During implementation
+- Implement proper build versioning (semantic versioning, build numbers, consistent across platforms)
+- Use Fastlane or similar automation for code signing, building, uploading, and screenshot generation
+- Configure app store metadata, descriptions, keywords, categories, and age ratings correctly
+- Set up staged rollout configuration (Google Play: percentage rollout, iOS: phased release)
+- Implement A/B testing framework with proper analytics events and experiment tracking
+- Use code push (CodePush, Expo Updates) for JavaScript-only changes that don't require app store review
+- Prepare app store assets: screenshots (all required device sizes), app previews, promotional text
+
+### After implementation
+- Submit to internal testing tracks first (TestFlight, Google Play Internal Testing) before production
+- Monitor crash rates and user feedback during staged rollout, pause if issues detected
+- Track rollout metrics: adoption rate, crash-free sessions, key performance indicators
+- Respond to app review feedback promptly with clarifications or necessary changes
+- Validate that all app store links, privacy policy URLs, and support contacts are functional
+
+## Self-check before task completion
+- [ ] App complies with platform guidelines (no private API usage, proper permission descriptions, content policies)
+- [ ] Release pipeline is automated with minimal manual steps (Fastlane, GitHub Actions, Bitrise, CircleCI)
+- [ ] Staged rollout is configured to gradually release to users with ability to halt if issues arise
+- [ ] Feature flags are in place for high-risk features to enable quick rollback without new submission
+- [ ] App store metadata is complete, optimized, and localized for target markets
+- [ ] Monitoring and alerting are configured to detect issues during rollout (crash rates, performance regressions)

package/.mindforge/skills/architecture-tradeoff-analysis/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: architecture-tradeoff-analysis
+version: 1.0.0
+min_mindforge_version: 10.1.0
+status: stable
+triggers: architecture tradeoff, ATAM, quality attribute scenario, sensitivity point, tradeoff point, risk theme, architecture evaluation, quality attribute tradeoff, architecture decision quality, non-functional tradeoff, architecture risk, scenario-based evaluation
+---
+
+# Architecture Tradeoff Analysis Method (ATAM)
+
+## When this skill activates
+
+This skill activates when the team needs to evaluate architectural decisions against
+competing quality attributes, identify sensitivity and tradeoff points, or assess
+architectural risk. It implements the ATAM methodology for systematic architecture
+evaluation using scenario-based analysis.
+
+## Mandatory actions when this skill is active
+
+### Before
+
+1. **Present the architecture** — Document the current or proposed architecture with
+   sufficient detail: components, connectors, deployment topology, key design decisions,
+   and the rationale behind major choices.
+2. **Identify stakeholders** — List all parties with quality attribute concerns
+   (developers, ops, security, product, business).
+3. **Elicit quality attributes** — Gather the quality attributes that matter most for
+   this system from stakeholder interviews.
+
+### During
+
+4. **Define quality attributes under evaluation:**
+   - **Performance** — Latency, throughput, resource utilization targets.
+   - **Availability** — Uptime requirements, failover behavior, recovery time.
+   - **Security** — Authentication, authorization, data protection, audit requirements.
+   - **Modifiability** — Cost of change, deployment independence, backward compatibility.
+   - **Testability** — Isolation capability, observability, deterministic behavior.
+   - **Usability** — Learnability, efficiency, error recovery for operators and users.
+   - **Scalability** — Growth handling, elasticity, degradation under load.
+
+5. **Generate quality attribute scenarios** (for each relevant attribute):
+   - **Source** — Who or what causes the stimulus?
+   - **Stimulus** — What event or condition triggers the scenario?
+   - **Artifact** — What part of the system is affected?
+   - **Environment** — Under what conditions (normal, peak, degraded)?
+   - **Response** — What should the system do?
+   - **Response measure** — How do we know the response was acceptable?
+
+6. **Analyze via architectural approaches:**
+   - Map each scenario to the architectural decisions that address it.
+   - Identify which architectural patterns, tactics, or styles are employed.
+   - Assess whether the approach adequately satisfies the scenario's response measure.
+
+7. **Identify sensitivity points:**
+   - A sensitivity point is an architectural decision that critically affects ONE
+     quality attribute.
+   - Document: "If we change X, quality attribute Y is significantly affected."
+   - These are single-attribute risks.
+
+8. **Identify tradeoff points:**
+   - A tradeoff point is an architectural decision that affects MULTIPLE quality
+     attributes in opposing directions.
+   - Document: "Decision X improves attribute Y but degrades attribute Z."
+   - These are the hardest decisions and require explicit stakeholder prioritization.
+
+9. **Generate risk themes:**
+   - Cluster related sensitivity and tradeoff points into themes.
+   - Name each theme descriptively (e.g., "Performance vs. Security tension in
+     the authentication layer").
+   - Prioritize risk themes by business impact and likelihood.
+
+10. **Propose mitigations:**
+    - For each high-priority risk theme, propose architectural alternatives or
+      complementary tactics.
+    - Assess whether mitigations introduce new tradeoffs.
+
+### After
+
+11. **Document findings** — Produce an ATAM report with: architecture overview, quality
+    attribute tree, scenario table, sensitivity points, tradeoff points, risk themes,
+    and recommended actions.
+12. **Prioritize with stakeholders** — Present tradeoff points to stakeholders for
+    explicit priority decisions. Record their choices.
+13. **Feed into ADRs** — Convert key decisions into Architecture Decision Records with
+    tradeoff rationale preserved.
+
+## Self-check before task completion
+
+- [ ] Architecture presented with sufficient detail for analysis
+- [ ] Quality attributes identified and prioritized by stakeholders
+- [ ] At least 3 quality attribute scenarios generated per relevant attribute
+- [ ] Sensitivity points identified and documented
+- [ ] Tradeoff points identified with opposing quality attributes named
+- [ ] Risk themes generated from clustered findings
+- [ ] Stakeholder priorities recorded for tradeoff resolution
+- [ ] Mitigations proposed for high-priority risk themes
+- [ ] ATAM findings documented in a shareable format