skill-library-mcp 1.0.0

package/skills/page-cro/SKILL.md

@@ -0,0 +1,343 @@
+---
+name: page-cro
+description: >
+  Analyze and optimize individual pages for conversion performance.
+  Use when the user wants to improve conversion rates, diagnose why a page
+  is underperforming, or increase the effectiveness of marketing pages
+  (homepage, landing pages, pricing, feature pages, or blog posts).
+  This skill focuses on diagnosis, prioritization, and testable recommendations—
+  not blind optimization.
+---
+# Page Conversion Rate Optimization (CRO)
+You are an expert in **page-level conversion optimization**.
+Your goal is to **diagnose why a page is or is not converting**, assess readiness for optimization, and provide **prioritized, evidence-based recommendations**.
+You do **not** guarantee conversion lifts.
+You do **not** recommend changes without explaining *why they matter*.
+---
+## Phase 0: Page Conversion Readiness & Impact Index (Required)
+
+Before giving CRO advice, calculate the **Page Conversion Readiness & Impact Index**.
+
+### Purpose
+
+This index answers:
+
+> **Is this page structurally capable of converting, and where are the biggest constraints?**
+
+It prevents:
+
+* cosmetic CRO
+* premature A/B testing
+* optimizing the wrong thing
+
+---
+
+## 🔢 Page Conversion Readiness & Impact Index
+
+### Total Score: **0–100**
+
+This is a **diagnostic score**, not a success metric.
+
+---
+
+### Scoring Categories & Weights
+
+| Category                    | Weight  |
+| --------------------------- | ------- |
+| Value Proposition Clarity   | 25      |
+| Conversion Goal Focus       | 20      |
+| Traffic–Message Match       | 15      |
+| Trust & Credibility Signals | 15      |
+| Friction & UX Barriers      | 15      |
+| Objection Handling          | 10      |
+| **Total**                   | **100** |
+
+---
+
+### Category Definitions
+
+#### 1. Value Proposition Clarity (0–25)
+
+* Visitor understands what this is and why it matters in ≤5 seconds
+* Primary benefit is specific and differentiated
+* Language reflects user intent, not internal jargon
+
+---
+
+#### 2. Conversion Goal Focus (0–20)
+
+* One clear primary conversion action
+* CTA hierarchy is intentional
+* Commitment level matches page stage
+
+---
+
+#### 3. Traffic–Message Match (0–15)
+
+* Page aligns with visitor intent (organic, paid, email, referral)
+* Headline and hero match upstream messaging
+* No bait-and-switch dynamics
+
+---
+
+#### 4. Trust & Credibility Signals (0–15)
+
+* Social proof exists and is relevant
+* Claims are substantiated
+* Risk is reduced at decision points
+
+---
+
+#### 5. Friction & UX Barriers (0–15)
+
+* Page loads quickly and works on mobile
+* No unnecessary form fields or steps
+* Navigation and next steps are clear
+
+---
+
+#### 6. Objection Handling (0–10)
+
+* Likely objections are anticipated
+* Page addresses “Will this work for me?”
+* Uncertainty is reduced, not ignored
+
+---
+
+### Conversion Readiness Bands (Required)
+
+| Score  | Verdict                  | Interpretation                                 |
+| ------ | ------------------------ | ---------------------------------------------- |
+| 85–100 | **High Readiness**       | Page is structurally sound; test optimizations |
+| 70–84  | **Moderate Readiness**   | Fix key issues before testing                  |
+| 55–69  | **Low Readiness**        | Foundational problems limit conversions        |
+| <55    | **Not Conversion-Ready** | CRO will not work yet                          |
+
+If score < 70, **testing is not recommended**.
+
+---
+
+## Phase 1: Context & Goal Alignment
+
+(Proceed only after scoring)
+
+### 1. Page Type
+
+* Homepage
+* Campaign landing page
+* Pricing page
+* Feature/product page
+* Content page with CTA
+* Other
+
+### 2. Primary Conversion Goal
+
+* Exactly **one** primary goal
+* Secondary goals explicitly demoted
+
+### 3. Traffic Context (If Known)
+
+* Organic (what intent?)
+* Paid (what promise?)
+* Email / referral / direct
+
+---
+
+## Phase 2: CRO Diagnostic Framework
+
+Analyze in **impact order**, not arbitrarily.
+
+---
+
+### 1. Value Proposition & Headline Clarity
+
+**Questions to answer:**
+
+* What problem does this solve?
+* For whom?
+* Why this over alternatives?
+* What outcome is promised?
+
+**Failure modes:**
+
+* Vague positioning
+* Feature lists without benefit framing
+* Cleverness over clarity
+
+---
+
+### 2. CTA Strategy & Hierarchy
+
+**Primary CTA**
+
+* Visible above the fold
+* Action + value oriented
+* Appropriate commitment level
+
+**Hierarchy**
+
+* One primary action
+* Secondary actions clearly de-emphasized
+* Repeated at decision points
+
+---
+
+### 3. Visual Hierarchy & Scannability
+
+**Check for:**
+
+* Clear reading path
+* Emphasis on key claims
+* Adequate whitespace
+* Supportive (not decorative) visuals
+
+---
+
+### 4. Trust & Social Proof
+
+**Evaluate:**
+
+* Relevance of proof to audience
+* Specificity (numbers > adjectives)
+* Placement near CTAs
+
+---
+
+### 5. Objection Handling
+
+**Common objections by page type:**
+
+* Price/value
+* Fit for use case
+* Time to value
+* Implementation complexity
+* Risk of failure
+
+**Resolution mechanisms:**
+
+* FAQs
+* Guarantees
+* Comparisons
+* Process transparency
+
+---
+
+### 6. Friction & UX Barriers
+
+**Look for:**
+
+* Excessive form fields
+* Slow load times
+* Mobile issues
+* Confusing flows
+* Unclear next steps
+
+---
+
+## Phase 3: Recommendations & Prioritization
+
+All recommendations must map to:
+
+* a **scoring category**
+* a **conversion constraint**
+* a **measurable hypothesis**
+
+---
+
+## Output Format (Required)
+
+### Conversion Readiness Summary
+
+* Overall Score: XX / 100
+* Verdict: High / Moderate / Low / Not Ready
+* Key limiting factors
+
+---
+
+### Quick Wins (Low Effort, High Confidence)
+
+Changes that:
+
+* Require minimal effort
+* Address obvious constraints
+* Do not require testing to validate
+
+---
+
+### High-Impact Improvements
+
+Structural or messaging changes that:
+
+* Address primary conversion blockers
+* Require design or copy effort
+* Should be validated via testing
+
+---
+
+### Testable Hypotheses
+
+Each test must include:
+
+* Hypothesis
+* What changes
+* Expected behavioral impact
+* Primary success metric
+
+---
+
+### Copy Alternatives (If Relevant)
+
+Provide 2–3 alternatives for:
+
+* Headlines
+* Subheadlines
+* CTAs
+
+Each with rationale tied to user intent.
+
+---
+
+## Page-Type Specific Guidance
+
+*(Condensed but preserved; unchanged logic, cleaner framing)*
+
+* Homepage: positioning + audience routing
+* Landing pages: message match + single CTA
+* Pricing pages: clarity + risk reduction
+* Feature pages: benefit framing + proof
+* Blog pages: contextual CTAs
+
+---
+
+## Experiment Guardrails
+
+Do **not** recommend A/B testing when:
+
+* Traffic is too low
+* Page score < 70
+* Value proposition is unclear
+* Conversion goal is ambiguous
+
+Fix fundamentals first.
+
+---
+
+## Questions to Ask (If Needed)
+
+1. Current conversion rate and baseline?
+2. Traffic sources and intent?
+3. What happens after this page?
+4. Existing data (heatmaps, recordings)?
+5. Past experiments?
+
+---
+
+## Related Skills
+
+* **signup-flow-cro** – If drop-off occurs after the page
+* **form-cro** – If the form is the bottleneck
+* **popup-cro** – If overlays are considered
+* **copywriting** – If messaging needs a full rewrite
+* **ab-test-setup** – For test execution and instrumentation
+
+```

package/skills/pagerduty-automation/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: pagerduty-automation
+description: "Automate PagerDuty tasks via Rube MCP (Composio): manage incidents, services, schedules, escalation policies, and on-call rotations. Always search tools first for current schemas."
+requires:
+  mcp: [rube]
+---
+
+# PagerDuty Automation via Rube MCP
+
+Automate PagerDuty incident management and operations through Composio's PagerDuty toolkit via Rube MCP.
+
+## Prerequisites
+
+- Rube MCP must be connected (RUBE_SEARCH_TOOLS available)
+- Active PagerDuty connection via `RUBE_MANAGE_CONNECTIONS` with toolkit `pagerduty`
+- Always call `RUBE_SEARCH_TOOLS` first to get current tool schemas
+
+## Setup
+
+**Get Rube MCP**: Add `https://rube.app/mcp` as an MCP server in your client configuration. No API keys needed — just add the endpoint and it works.
+
+
+1. Verify Rube MCP is available by confirming `RUBE_SEARCH_TOOLS` responds
+2. Call `RUBE_MANAGE_CONNECTIONS` with toolkit `pagerduty`
+3. If connection is not ACTIVE, follow the returned auth link to complete PagerDuty authentication
+4. Confirm connection status shows ACTIVE before running any workflows
+
+## Core Workflows
+
+### 1. Manage Incidents
+
+**When to use**: User wants to create, update, acknowledge, or resolve incidents
+
+**Tool sequence**:
+1. `PAGERDUTY_FETCH_INCIDENT_LIST` - List incidents with filters [Required]
+2. `PAGERDUTY_RETRIEVE_INCIDENT_BY_INCIDENT_ID` - Get specific incident details [Optional]
+3. `PAGERDUTY_CREATE_INCIDENT_RECORD` - Create a new incident [Optional]
+4. `PAGERDUTY_UPDATE_INCIDENT_BY_ID` - Update incident status or assignment [Optional]
+5. `PAGERDUTY_POST_INCIDENT_NOTE_USING_ID` - Add a note to an incident [Optional]
+6. `PAGERDUTY_SNOOZE_INCIDENT_BY_DURATION` - Snooze an incident for a period [Optional]
+
+**Key parameters**:
+- `statuses[]`: Filter by status ('triggered', 'acknowledged', 'resolved')
+- `service_ids[]`: Filter by service IDs
+- `urgencies[]`: Filter by urgency ('high', 'low')
+- `title`: Incident title (for creation)
+- `service`: Service object with `id` and `type` (for creation)
+- `status`: New status for update operations
+
+**Pitfalls**:
+- Incident creation requires a `service` object with both `id` and `type: 'service_reference'`
+- Status transitions follow: triggered -> acknowledged -> resolved
+- Cannot transition from resolved back to triggered directly
+- `PAGERDUTY_UPDATE_INCIDENT_BY_ID` requires the incident ID as a path parameter
+- Snooze duration is in seconds; the incident re-triggers after the snooze period
+
+### 2. Inspect Incident Alerts and Analytics
+
+**When to use**: User wants to review alerts within an incident or analyze incident metrics
+
+**Tool sequence**:
+1. `PAGERDUTY_GET_ALERTS_BY_INCIDENT_ID` - List alerts for an incident [Required]
+2. `PAGERDUTY_GET_INCIDENT_ALERT_DETAILS` - Get details of a specific alert [Optional]
+3. `PAGERDUTY_FETCH_INCIDENT_ANALYTICS_BY_ID` - Get incident analytics/metrics [Optional]
+
+**Key parameters**:
+- `incident_id`: The incident ID
+- `alert_id`: Specific alert ID within the incident
+- `statuses[]`: Filter alerts by status
+
+**Pitfalls**:
+- An incident can have multiple alerts; each alert has its own status
+- Alert IDs are scoped to the incident
+- Analytics data includes response times, engagement metrics, and resolution times
+
+### 3. Manage Services
+
+**When to use**: User wants to create, update, or list services
+
+**Tool sequence**:
+1. `PAGERDUTY_RETRIEVE_LIST_OF_SERVICES` - List all services [Required]
+2. `PAGERDUTY_RETRIEVE_SERVICE_BY_ID` - Get service details [Optional]
+3. `PAGERDUTY_CREATE_NEW_SERVICE` - Create a new technical service [Optional]
+4. `PAGERDUTY_UPDATE_SERVICE_BY_ID` - Update service configuration [Optional]
+5. `PAGERDUTY_CREATE_INTEGRATION_FOR_SERVICE` - Add an integration to a service [Optional]
+6. `PAGERDUTY_CREATE_BUSINESS_SERVICE` - Create a business service [Optional]
+7. `PAGERDUTY_UPDATE_BUSINESS_SERVICE_BY_ID` - Update a business service [Optional]
+
+**Key parameters**:
+- `name`: Service name
+- `escalation_policy`: Escalation policy object with `id` and `type`
+- `alert_creation`: Alert creation mode ('create_alerts_and_incidents' or 'create_incidents')
+- `status`: Service status ('active', 'warning', 'critical', 'maintenance', 'disabled')
+
+**Pitfalls**:
+- Creating a service requires an existing escalation policy
+- Business services are different from technical services; they represent business-level groupings
+- Service integrations define how alerts are created (email, API, events)
+- Disabling a service stops all incident creation for that service
+
+### 4. Manage Schedules and On-Call
+
+**When to use**: User wants to view or manage on-call schedules and rotations
+
+**Tool sequence**:
+1. `PAGERDUTY_GET_SCHEDULES` - List all schedules [Required]
+2. `PAGERDUTY_RETRIEVE_SCHEDULE_BY_ID` - Get specific schedule details [Optional]
+3. `PAGERDUTY_CREATE_NEW_SCHEDULE_LAYER` - Create a new schedule [Optional]
+4. `PAGERDUTY_UPDATE_SCHEDULE_BY_ID` - Update an existing schedule [Optional]
+5. `PAGERDUTY_RETRIEVE_ONCALL_LIST` - View who is currently on-call [Optional]
+6. `PAGERDUTY_CREATE_SCHEDULE_OVERRIDES_CONFIGURATION` - Create temporary overrides [Optional]
+7. `PAGERDUTY_DELETE_SCHEDULE_OVERRIDE_BY_ID` - Remove an override [Optional]
+8. `PAGERDUTY_RETRIEVE_USERS_BY_SCHEDULE_ID` - List users in a schedule [Optional]
+9. `PAGERDUTY_PREVIEW_SCHEDULE_OBJECT` - Preview schedule changes before saving [Optional]
+
+**Key parameters**:
+- `schedule_id`: Schedule identifier
+- `time_zone`: Schedule timezone (e.g., 'America/New_York')
+- `schedule_layers`: Array of rotation layer configurations
+- `since`/`until`: Date range for on-call queries (ISO 8601)
+- `override`: Override object with user, start, and end times
+
+**Pitfalls**:
+- Schedule layers define rotation order; multiple layers can overlap
+- Overrides are temporary and take precedence over the normal schedule
+- `since` and `until` are required for on-call queries to scope the time range
+- Time zones must be valid IANA timezone strings
+- Preview before saving complex schedule changes to verify correctness
+
+### 5. Manage Escalation Policies
+
+**When to use**: User wants to create or modify escalation policies
+
+**Tool sequence**:
+1. `PAGERDUTY_FETCH_ESCALATION_POLICES_LIST` - List all escalation policies [Required]
+2. `PAGERDUTY_GET_ESCALATION_POLICY_BY_ID` - Get policy details [Optional]
+3. `PAGERDUTY_CREATE_ESCALATION_POLICY` - Create a new policy [Optional]
+4. `PAGERDUTY_UPDATE_ESCALATION_POLICY_BY_ID` - Update an existing policy [Optional]
+5. `PAGERDUTY_AUDIT_ESCALATION_POLICY_RECORDS` - View audit trail for a policy [Optional]
+
+**Key parameters**:
+- `name`: Policy name
+- `escalation_rules`: Array of escalation rule objects
+- `num_loops`: Number of times to loop through rules before stopping (0 = no loop)
+- `escalation_delay_in_minutes`: Delay between escalation levels
+
+**Pitfalls**:
+- Each escalation rule requires at least one target (user, schedule, or team)
+- `escalation_delay_in_minutes` defines how long before escalating to the next level
+- Setting `num_loops` to 0 means the policy runs once and stops
+- Deleting a policy fails if services still reference it
+
+### 6. Manage Teams
+
+**When to use**: User wants to create or manage PagerDuty teams
+
+**Tool sequence**:
+1. `PAGERDUTY_CREATE_NEW_TEAM_WITH_DETAILS` - Create a new team [Required]
+
+**Key parameters**:
+- `name`: Team name
+- `description`: Team description
+
+**Pitfalls**:
+- Team names must be unique within the account
+- Teams are used to scope services, escalation policies, and schedules
+
+## Common Patterns
+
+### ID Resolution
+
+**Service name -> Service ID**:
+```
+1. Call PAGERDUTY_RETRIEVE_LIST_OF_SERVICES
+2. Find service by name in response
+3. Extract id field
+```
+
+**Schedule name -> Schedule ID**:
+```
+1. Call PAGERDUTY_GET_SCHEDULES
+2. Find schedule by name in response
+3. Extract id field
+```
+
+### Incident Lifecycle
+
+```
+1. Incident triggered (via API, integration, or manual creation)
+2. On-call user notified per escalation policy
+3. User acknowledges -> status: 'acknowledged'
+4. User resolves -> status: 'resolved'
+```
+
+### Pagination
+
+- PagerDuty uses offset-based pagination
+- Check response for `more` boolean field
+- Use `offset` and `limit` parameters
+- Continue until `more` is false
+
+## Known Pitfalls
+
+**ID Formats**:
+- All PagerDuty IDs are alphanumeric strings (e.g., 'P1234AB')
+- Service references require `type: 'service_reference'`
+- User references require `type: 'user_reference'`
+
+**Status Transitions**:
+- Incidents: triggered -> acknowledged -> resolved (forward only)
+- Services: active, warning, critical, maintenance, disabled
+
+**Rate Limits**:
+- PagerDuty API enforces rate limits per account
+- Implement exponential backoff on 429 responses
+- Bulk operations should be spaced out
+
+**Response Parsing**:
+- Response data may be nested under `data` or `data.data`
+- Parse defensively with fallback patterns
+- Pagination uses `offset`/`limit`/`more` pattern
+
+## Quick Reference
+
+| Task | Tool Slug | Key Params |
+|------|-----------|------------|
+| List incidents | PAGERDUTY_FETCH_INCIDENT_LIST | statuses[], service_ids[] |
+| Get incident | PAGERDUTY_RETRIEVE_INCIDENT_BY_INCIDENT_ID | incident_id |
+| Create incident | PAGERDUTY_CREATE_INCIDENT_RECORD | title, service |
+| Update incident | PAGERDUTY_UPDATE_INCIDENT_BY_ID | incident_id, status |
+| Add incident note | PAGERDUTY_POST_INCIDENT_NOTE_USING_ID | incident_id, content |
+| Snooze incident | PAGERDUTY_SNOOZE_INCIDENT_BY_DURATION | incident_id, duration |
+| Get incident alerts | PAGERDUTY_GET_ALERTS_BY_INCIDENT_ID | incident_id |
+| Incident analytics | PAGERDUTY_FETCH_INCIDENT_ANALYTICS_BY_ID | incident_id |
+| List services | PAGERDUTY_RETRIEVE_LIST_OF_SERVICES | (none) |
+| Get service | PAGERDUTY_RETRIEVE_SERVICE_BY_ID | service_id |
+| Create service | PAGERDUTY_CREATE_NEW_SERVICE | name, escalation_policy |
+| Update service | PAGERDUTY_UPDATE_SERVICE_BY_ID | service_id |
+| List schedules | PAGERDUTY_GET_SCHEDULES | (none) |
+| Get schedule | PAGERDUTY_RETRIEVE_SCHEDULE_BY_ID | schedule_id |
+| Get on-call | PAGERDUTY_RETRIEVE_ONCALL_LIST | since, until |
+| Create schedule override | PAGERDUTY_CREATE_SCHEDULE_OVERRIDES_CONFIGURATION | schedule_id |
+| List escalation policies | PAGERDUTY_FETCH_ESCALATION_POLICES_LIST | (none) |
+| Create escalation policy | PAGERDUTY_CREATE_ESCALATION_POLICY | name, escalation_rules |
+| Create team | PAGERDUTY_CREATE_NEW_TEAM_WITH_DETAILS | name, description |