gkt-node 3.3.0

package/assets/.agent/skills/analytics-tracking/SKILL.md

@@ -0,0 +1,404 @@
+---
+name: analytics-tracking
+description: >
+  Design, audit, and improve analytics tracking systems that produce reliable,
+  decision-ready data. Use when the user wants to set up, fix, or evaluate
+  analytics tracking (GA4, GTM, product analytics, events, conversions, UTMs).
+  This skill focuses on measurement strategy, signal quality, and validation—
+  not just firing events.
+---
+
+# Analytics Tracking & Measurement Strategy
+
+You are an expert in **analytics implementation and measurement design**.
+Your goal is to ensure tracking produces **trustworthy signals that directly support decisions** across marketing, product, and growth.
+
+You do **not** track everything.
+You do **not** optimize dashboards without fixing instrumentation.
+You do **not** treat GA4 numbers as truth unless validated.
+
+---
+
+## Phase 0: Measurement Readiness & Signal Quality Index (Required)
+
+Before adding or changing tracking, calculate the **Measurement Readiness & Signal Quality Index**.
+
+### Purpose
+
+This index answers:
+
+> **Can this analytics setup produce reliable, decision-grade insights?**
+
+It prevents:
+
+* event sprawl
+* vanity tracking
+* misleading conversion data
+* false confidence in broken analytics
+
+---
+
+## 🔢 Measurement Readiness & Signal Quality Index
+
+### Total Score: **0–100**
+
+This is a **diagnostic score**, not a performance KPI.
+
+---
+
+### Scoring Categories & Weights
+
+| Category                      | Weight  |
+| ----------------------------- | ------- |
+| Decision Alignment            | 25      |
+| Event Model Clarity           | 20      |
+| Data Accuracy & Integrity     | 20      |
+| Conversion Definition Quality | 15      |
+| Attribution & Context         | 10      |
+| Governance & Maintenance      | 10      |
+| **Total**                     | **100** |
+
+---
+
+### Category Definitions
+
+#### 1. Decision Alignment (0–25)
+
+* Clear business questions defined
+* Each tracked event maps to a decision
+* No events tracked “just in case”
+
+---
+
+#### 2. Event Model Clarity (0–20)
+
+* Events represent **meaningful actions**
+* Naming conventions are consistent
+* Properties carry context, not noise
+
+---
+
+#### 3. Data Accuracy & Integrity (0–20)
+
+* Events fire reliably
+* No duplication or inflation
+* Values are correct and complete
+* Cross-browser and mobile validated
+
+---
+
+#### 4. Conversion Definition Quality (0–15)
+
+* Conversions represent real success
+* Conversion counting is intentional
+* Funnel stages are distinguishable
+
+---
+
+#### 5. Attribution & Context (0–10)
+
+* UTMs are consistent and complete
+* Traffic source context is preserved
+* Cross-domain / cross-device handled appropriately
+
+---
+
+#### 6. Governance & Maintenance (0–10)
+
+* Tracking is documented
+* Ownership is clear
+* Changes are versioned and monitored
+
+---
+
+### Readiness Bands (Required)
+
+| Score  | Verdict               | Interpretation                    |
+| ------ | --------------------- | --------------------------------- |
+| 85–100 | **Measurement-Ready** | Safe to optimize and experiment   |
+| 70–84  | **Usable with Gaps**  | Fix issues before major decisions |
+| 55–69  | **Unreliable**        | Data cannot be trusted yet        |
+| <55    | **Broken**            | Do not act on this data           |
+
+If verdict is **Broken**, stop and recommend remediation first.
+
+---
+
+## Phase 1: Context & Decision Definition
+
+(Proceed only after scoring)
+
+### 1. Business Context
+
+* What decisions will this data inform?
+* Who uses the data (marketing, product, leadership)?
+* What actions will be taken based on insights?
+
+---
+
+### 2. Current State
+
+* Tools in use (GA4, GTM, Mixpanel, Amplitude, etc.)
+* Existing events and conversions
+* Known issues or distrust in data
+
+---
+
+### 3. Technical & Compliance Context
+
+* Tech stack and rendering model
+* Who implements and maintains tracking
+* Privacy, consent, and regulatory constraints
+
+---
+
+## Core Principles (Non-Negotiable)
+
+### 1. Track for Decisions, Not Curiosity
+
+If no decision depends on it, **don’t track it**.
+
+---
+
+### 2. Start with Questions, Work Backwards
+
+Define:
+
+* What you need to know
+* What action you’ll take
+* What signal proves it
+
+Then design events.
+
+---
+
+### 3. Events Represent Meaningful State Changes
+
+Avoid:
+
+* cosmetic clicks
+* redundant events
+* UI noise
+
+Prefer:
+
+* intent
+* completion
+* commitment
+
+---
+
+### 4. Data Quality Beats Volume
+
+Fewer accurate events > many unreliable ones.
+
+---
+
+## Event Model Design
+
+### Event Taxonomy
+
+**Navigation / Exposure**
+
+* page_view (enhanced)
+* content_viewed
+* pricing_viewed
+
+**Intent Signals**
+
+* cta_clicked
+* form_started
+* demo_requested
+
+**Completion Signals**
+
+* signup_completed
+* purchase_completed
+* subscription_changed
+
+**System / State Changes**
+
+* onboarding_completed
+* feature_activated
+* error_occurred
+
+---
+
+### Event Naming Conventions
+
+**Recommended pattern:**
+
+```
+object_action[_context]
+```
+
+Examples:
+
+* signup_completed
+* pricing_viewed
+* cta_hero_clicked
+* onboarding_step_completed
+
+Rules:
+
+* lowercase
+* underscores
+* no spaces
+* no ambiguity
+
+---
+
+### Event Properties (Context, Not Noise)
+
+Include:
+
+* where (page, section)
+* who (user_type, plan)
+* how (method, variant)
+
+Avoid:
+
+* PII
+* free-text fields
+* duplicated auto-properties
+
+---
+
+## Conversion Strategy
+
+### What Qualifies as a Conversion
+
+A conversion must represent:
+
+* real value
+* completed intent
+* irreversible progress
+
+Examples:
+
+* signup_completed
+* purchase_completed
+* demo_booked
+
+Not conversions:
+
+* page views
+* button clicks
+* form starts
+
+---
+
+### Conversion Counting Rules
+
+* Once per session vs every occurrence
+* Explicitly documented
+* Consistent across tools
+
+---
+
+## GA4 & GTM (Implementation Guidance)
+
+*(Tool-specific, but optional)*
+
+* Prefer GA4 recommended events
+* Use GTM for orchestration, not logic
+* Push clean dataLayer events
+* Avoid multiple containers
+* Version every publish
+
+---
+
+## UTM & Attribution Discipline
+
+### UTM Rules
+
+* lowercase only
+* consistent separators
+* documented centrally
+* never overwritten client-side
+
+UTMs exist to **explain performance**, not inflate numbers.
+
+---
+
+## Validation & Debugging
+
+### Required Validation
+
+* Real-time verification
+* Duplicate detection
+* Cross-browser testing
+* Mobile testing
+* Consent-state testing
+
+### Common Failure Modes
+
+* double firing
+* missing properties
+* broken attribution
+* PII leakage
+* inflated conversions
+
+---
+
+## Privacy & Compliance
+
+* Consent before tracking where required
+* Data minimization
+* User deletion support
+* Retention policies reviewed
+
+Analytics that violate trust undermine optimization.
+
+---
+
+## Output Format (Required)
+
+### Measurement Strategy Summary
+
+* Measurement Readiness Index score + verdict
+* Key risks and gaps
+* Recommended remediation order
+
+---
+
+### Tracking Plan
+
+| Event | Description | Properties | Trigger | Decision Supported |
+| ----- | ----------- | ---------- | ------- | ------------------ |
+
+---
+
+### Conversions
+
+| Conversion | Event | Counting | Used By |
+| ---------- | ----- | -------- | ------- |
+
+---
+
+### Implementation Notes
+
+* Tool-specific setup
+* Ownership
+* Validation steps
+
+---
+
+## Questions to Ask (If Needed)
+
+1. What decisions depend on this data?
+2. Which metrics are currently trusted or distrusted?
+3. Who owns analytics long term?
+4. What compliance constraints apply?
+5. What tools are already in place?
+
+---
+
+## Related Skills
+
+* **page-cro** – Uses this data for optimization
+* **ab-test-setup** – Requires clean conversions
+* **seo-audit** – Organic performance analysis
+* **programmatic-seo** – Scale requires reliable signals
+
+---

package/assets/.agent/skills/api-design-principles/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: api-design-principles
+description: Master REST and GraphQL API design principles to build intuitive, scalable, and maintainable APIs that delight developers. Use when designing new APIs, reviewing API specifications, or establishing API design standards.
+---
+
+# API Design Principles
+
+Master REST and GraphQL API design principles to build intuitive, scalable, and maintainable APIs that delight developers and stand the test of time.
+
+## Use this skill when
+
+- Designing new REST or GraphQL APIs
+- Refactoring existing APIs for better usability
+- Establishing API design standards for your team
+- Reviewing API specifications before implementation
+- Migrating between API paradigms (REST to GraphQL, etc.)
+- Creating developer-friendly API documentation
+- Optimizing APIs for specific use cases (mobile, third-party integrations)
+
+## Do not use this skill when
+
+- You only need implementation guidance for a specific framework
+- You are doing infrastructure-only work without API contracts
+- You cannot change or version public interfaces
+
+## Instructions
+
+1. Define consumers, use cases, and constraints.
+2. Choose API style and model resources or types.
+3. Specify errors, versioning, pagination, and auth strategy.
+4. Validate with examples and review for consistency.
+
+Refer to `resources/implementation-playbook.md` for detailed patterns, checklists, and templates.
+
+## Resources
+
+- `resources/implementation-playbook.md` for detailed patterns, checklists, and templates.

package/assets/.agent/skills/api-design-principles/assets/api-design-checklist.md

@@ -0,0 +1,155 @@
+# API Design Checklist
+
+## Pre-Implementation Review
+
+### Resource Design
+
+- [ ] Resources are nouns, not verbs
+- [ ] Plural names for collections
+- [ ] Consistent naming across all endpoints
+- [ ] Clear resource hierarchy (avoid deep nesting >2 levels)
+- [ ] All CRUD operations properly mapped to HTTP methods
+
+### HTTP Methods
+
+- [ ] GET for retrieval (safe, idempotent)
+- [ ] POST for creation
+- [ ] PUT for full replacement (idempotent)
+- [ ] PATCH for partial updates
+- [ ] DELETE for removal (idempotent)
+
+### Status Codes
+
+- [ ] 200 OK for successful GET/PATCH/PUT
+- [ ] 201 Created for POST
+- [ ] 204 No Content for DELETE
+- [ ] 400 Bad Request for malformed requests
+- [ ] 401 Unauthorized for missing auth
+- [ ] 403 Forbidden for insufficient permissions
+- [ ] 404 Not Found for missing resources
+- [ ] 422 Unprocessable Entity for validation errors
+- [ ] 429 Too Many Requests for rate limiting
+- [ ] 500 Internal Server Error for server issues
+
+### Pagination
+
+- [ ] All collection endpoints paginated
+- [ ] Default page size defined (e.g., 20)
+- [ ] Maximum page size enforced (e.g., 100)
+- [ ] Pagination metadata included (total, pages, etc.)
+- [ ] Cursor-based or offset-based pattern chosen
+
+### Filtering & Sorting
+
+- [ ] Query parameters for filtering
+- [ ] Sort parameter supported
+- [ ] Search parameter for full-text search
+- [ ] Field selection supported (sparse fieldsets)
+
+### Versioning
+
+- [ ] Versioning strategy defined (URL/header/query)
+- [ ] Version included in all endpoints
+- [ ] Deprecation policy documented
+
+### Error Handling
+
+- [ ] Consistent error response format
+- [ ] Detailed error messages
+- [ ] Field-level validation errors
+- [ ] Error codes for client handling
+- [ ] Timestamps in error responses
+
+### Authentication & Authorization
+
+- [ ] Authentication method defined (Bearer token, API key)
+- [ ] Authorization checks on all endpoints
+- [ ] 401 vs 403 used correctly
+- [ ] Token expiration handled
+
+### Rate Limiting
+
+- [ ] Rate limits defined per endpoint/user
+- [ ] Rate limit headers included
+- [ ] 429 status code for exceeded limits
+- [ ] Retry-After header provided
+
+### Documentation
+
+- [ ] OpenAPI/Swagger spec generated
+- [ ] All endpoints documented
+- [ ] Request/response examples provided
+- [ ] Error responses documented
+- [ ] Authentication flow documented
+
+### Testing
+
+- [ ] Unit tests for business logic
+- [ ] Integration tests for endpoints
+- [ ] Error scenarios tested
+- [ ] Edge cases covered
+- [ ] Performance tests for heavy endpoints
+
+### Security
+
+- [ ] Input validation on all fields
+- [ ] SQL injection prevention
+- [ ] XSS prevention
+- [ ] CORS configured correctly
+- [ ] HTTPS enforced
+- [ ] Sensitive data not in URLs
+- [ ] No secrets in responses
+
+### Performance
+
+- [ ] Database queries optimized
+- [ ] N+1 queries prevented
+- [ ] Caching strategy defined
+- [ ] Cache headers set appropriately
+- [ ] Large responses paginated
+
+### Monitoring
+
+- [ ] Logging implemented
+- [ ] Error tracking configured
+- [ ] Performance metrics collected
+- [ ] Health check endpoint available
+- [ ] Alerts configured for errors
+
+## GraphQL-Specific Checks
+
+### Schema Design
+
+- [ ] Schema-first approach used
+- [ ] Types properly defined
+- [ ] Non-null vs nullable decided
+- [ ] Interfaces/unions used appropriately
+- [ ] Custom scalars defined
+
+### Queries
+
+- [ ] Query depth limiting
+- [ ] Query complexity analysis
+- [ ] DataLoaders prevent N+1
+- [ ] Pagination pattern chosen (Relay/offset)
+
+### Mutations
+
+- [ ] Input types defined
+- [ ] Payload types with errors
+- [ ] Optimistic response support
+- [ ] Idempotency considered
+
+### Performance
+
+- [ ] DataLoader for all relationships
+- [ ] Query batching enabled
+- [ ] Persisted queries considered
+- [ ] Response caching implemented
+
+### Documentation
+
+- [ ] All fields documented
+- [ ] Deprecations marked
+- [ ] Examples provided
+- [ ] Schema introspection enabled