feat: add 20 new skills across 6 professions (skills 34-53) + open source contributing guide
This commit is contained in:
mohitagw15856
Vendored
BIN
Binary file not shown.
@@ -0,0 +1,175 @@
|
||||
---
|
||||
name: accessibility-audit
|
||||
description: "Generate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes."
|
||||
---
|
||||
|
||||
# Accessibility Audit Skill
|
||||
|
||||
This skill produces a structured accessibility audit based on WCAG 2.2 guidelines. It covers visual, motor, cognitive, and screen reader accessibility — with prioritised remediation for each issue found.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **What is being audited** (screen, component, full product, design spec)
|
||||
- **Description or image** of the UI
|
||||
- **Target WCAG level** (A / AA / AAA — default to AA, which is the legal standard in most jurisdictions)
|
||||
- **Known assistive technology users?** (Yes/No — if yes, which: screen reader / switch access / voice control / magnification)
|
||||
- **Platform** (Web / iOS / Android / Desktop app)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Accessibility Audit: [Component or Screen Name]
|
||||
**Target standard:** WCAG 2.2 Level [AA]
|
||||
**Platform:** [Platform]
|
||||
**Date:** [Date]
|
||||
|
||||
---
|
||||
|
||||
## Audit Summary
|
||||
|
||||
| Category | Issues Found | Critical | Moderate | Minor |
|
||||
|---|---|---|---|---|
|
||||
| Perceivable | | | | |
|
||||
| Operable | | | | |
|
||||
| Understandable | | | | |
|
||||
| Robust | | | | |
|
||||
| **Total** | | | | |
|
||||
|
||||
**Overall compliance status:** ✅ Compliant / 🟡 Minor issues / 🔴 Fails AA standard
|
||||
|
||||
---
|
||||
|
||||
## Perceivable
|
||||
|
||||
### 1.1 Text Alternatives
|
||||
- [ ] All images have descriptive alt text (not filename or "image")
|
||||
- [ ] Decorative images have `alt=""` to be skipped by screen readers
|
||||
- [ ] Icons without visible labels have accessible names
|
||||
- [ ] Complex images (charts, diagrams) have extended descriptions
|
||||
|
||||
**Issues found:** [List specific issues or "None"]
|
||||
|
||||
### 1.3 Adaptable
|
||||
- [ ] Content structure uses semantic HTML (headings, lists, landmarks) — not just visual formatting
|
||||
- [ ] Reading order in DOM matches visual order
|
||||
- [ ] Form inputs have associated labels (not placeholder text as label)
|
||||
- [ ] Data tables have proper headers and scope
|
||||
|
||||
**Issues found:**
|
||||
|
||||
### 1.4 Distinguishable
|
||||
- [ ] Text contrast ratio ≥ 4.5:1 (normal text) or ≥ 3:1 (large text 18px+)
|
||||
- [ ] UI component contrast ratio ≥ 3:1 against background
|
||||
- [ ] Information is not conveyed by colour alone
|
||||
- [ ] Text can be resized to 200% without loss of content
|
||||
- [ ] No content that auto-plays audio
|
||||
|
||||
**Issues found:**
|
||||
|
||||
---
|
||||
|
||||
## Operable
|
||||
|
||||
### 2.1 Keyboard Accessible
|
||||
- [ ] All interactive elements are reachable by keyboard (Tab key)
|
||||
- [ ] No keyboard traps
|
||||
- [ ] Custom components have keyboard interactions (arrow keys for menus, Escape to close modals)
|
||||
- [ ] Skip navigation link available for pages with repeated navigation
|
||||
|
||||
**Issues found:**
|
||||
|
||||
### 2.4 Navigable
|
||||
- [ ] Focus is visible at all times (not removed with `outline: none` without replacement)
|
||||
- [ ] Focus order is logical and predictable
|
||||
- [ ] Page/screen has a descriptive title
|
||||
- [ ] Link text is descriptive (not "click here" or "read more")
|
||||
- [ ] Headings are hierarchical (H1 → H2 → H3, no skips)
|
||||
|
||||
**Issues found:**
|
||||
|
||||
### 2.5 Input Modalities
|
||||
- [ ] Touch targets are at least 44x44px
|
||||
- [ ] No functionality requires complex gestures (pinch, multi-touch) without a simple alternative
|
||||
- [ ] Motion or dragging interactions have button alternatives
|
||||
|
||||
**Issues found:**
|
||||
|
||||
---
|
||||
|
||||
## Understandable
|
||||
|
||||
### 3.1 Readable
|
||||
- [ ] Language of the page is set (`lang` attribute)
|
||||
- [ ] Unusual words, abbreviations, or jargon are explained
|
||||
|
||||
### 3.2 Predictable
|
||||
- [ ] Navigation is consistent across screens
|
||||
- [ ] Components behave consistently (same button does the same thing)
|
||||
- [ ] No unexpected context changes on focus or input
|
||||
|
||||
### 3.3 Input Assistance
|
||||
- [ ] Error messages identify the field and describe the error in plain language (not just "Invalid input")
|
||||
- [ ] Required fields are labelled (not just with colour or asterisk alone)
|
||||
- [ ] Forms provide suggestions for correcting errors where possible
|
||||
|
||||
**Issues found:**
|
||||
|
||||
---
|
||||
|
||||
## Robust
|
||||
|
||||
### 4.1 Compatible
|
||||
- [ ] HTML is valid and well-structured
|
||||
- [ ] ARIA roles and attributes are used correctly (not to fix broken semantics)
|
||||
- [ ] Status messages (success, error, loading) are announced to screen readers without focus change
|
||||
|
||||
**Issues found:**
|
||||
|
||||
---
|
||||
|
||||
## Prioritised Remediation List
|
||||
|
||||
| Priority | Issue | WCAG Criterion | Fix | Effort |
|
||||
|---|---|---|---|---|
|
||||
| 🔴 Critical | [Issue] | [e.g. 1.4.3 Contrast] | [Specific fix] | [Low/Med/High] |
|
||||
| 🟡 Moderate | [Issue] | | | |
|
||||
| 🟢 Minor | [Issue] | | | |
|
||||
|
||||
**Priority definitions:**
|
||||
- 🔴 Critical: Blocks access for users with disabilities. Legal risk. Fix before launch.
|
||||
- 🟡 Moderate: Significant friction. Fix in next sprint.
|
||||
- 🟢 Minor: Best practice. Address in roadmap.
|
||||
|
||||
---
|
||||
|
||||
## Quick Wins (Fix in < 1 hour)
|
||||
|
||||
[List any issues that are trivially fixable — e.g. adding alt text, fixing contrast with a colour swap, adding a `lang` attribute. These are easy to ship immediately.]
|
||||
|
||||
---
|
||||
|
||||
## Testing Recommendations
|
||||
|
||||
- **Manual keyboard test:** Tab through the entire flow. Can you complete every task without a mouse?
|
||||
- **Screen reader test:** VoiceOver (Mac/iOS), NVDA or JAWS (Windows). Is every piece of content and every action accessible?
|
||||
- **Colour contrast check:** Use Stark (Figma plugin) or WebAIM Contrast Checker
|
||||
- **Automated scan:** Axe DevTools or Lighthouse accessibility audit (catches ~30% of issues automatically)
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Issues are mapped to specific WCAG criteria
|
||||
- [ ] Every critical issue has a specific fix recommendation
|
||||
- [ ] Quick wins are separated from larger fixes
|
||||
- [ ] Effort estimates are included for prioritisation
|
||||
- [ ] Testing recommendations are included
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Audit this design for accessibility"
|
||||
- "Check WCAG compliance for [screen/component]"
|
||||
- "Give me an a11y audit of [UI description]"
|
||||
- "What accessibility issues does this design have?"
|
||||
@@ -0,0 +1,146 @@
|
||||
---
|
||||
name: api-docs-writer
|
||||
description: "Write clear, developer-facing API documentation. Use when asked to document an API endpoint, write API reference docs, create a developer guide, or turn a raw spec/Postman collection into documentation. Produces endpoint documentation with descriptions, parameters, request/response examples, and error codes."
|
||||
---
|
||||
|
||||
# API Docs Writer Skill
|
||||
|
||||
This skill transforms raw API specs, endpoint descriptions, or Postman collections into clean, developer-facing documentation following OpenAPI-adjacent conventions. Output is ready for a developer portal, README, or Notion/Confluence page.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **API or endpoint details** (raw spec, Postman export, or verbal description)
|
||||
- **Auth method** (API key / Bearer token / OAuth 2.0 / None)
|
||||
- **Base URL**
|
||||
- **Audience** (internal developers / external partners / public)
|
||||
- **Output format** (Markdown / OpenAPI YAML / Plain prose)
|
||||
|
||||
## Output Structure
|
||||
|
||||
For each endpoint, produce the following:
|
||||
|
||||
---
|
||||
|
||||
## `[METHOD] /path/to/endpoint`
|
||||
|
||||
**Summary:** [One line — what this endpoint does]
|
||||
|
||||
**Description:** [2–4 sentences. When to use this endpoint. What it returns. Any important behaviour to know (pagination, rate limits, async processing, etc.)]
|
||||
|
||||
**Authentication:** [Required / Optional — method]
|
||||
|
||||
---
|
||||
|
||||
### Request
|
||||
|
||||
**Headers:**
|
||||
|
||||
| Header | Required | Description |
|
||||
|---|---|---|
|
||||
| `Authorization` | Yes | `Bearer <token>` |
|
||||
| `Content-Type` | Yes | `application/json` |
|
||||
|
||||
**Path Parameters:**
|
||||
|
||||
| Parameter | Type | Required | Description |
|
||||
|---|---|---|---|
|
||||
| `id` | string | Yes | Unique identifier for the resource |
|
||||
|
||||
**Query Parameters:**
|
||||
|
||||
| Parameter | Type | Required | Default | Description |
|
||||
|---|---|---|---|---|
|
||||
| `limit` | integer | No | 20 | Max results per page (1–100) |
|
||||
| `cursor` | string | No | — | Pagination cursor from previous response |
|
||||
|
||||
**Request Body:**
|
||||
|
||||
```json
|
||||
{
|
||||
"field_name": "value",
|
||||
"another_field": 42
|
||||
}
|
||||
```
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
|---|---|---|---|
|
||||
| `field_name` | string | Yes | [Plain description of what this field does] |
|
||||
| `another_field` | integer | No | [Description. Include valid range or enum values if applicable] |
|
||||
|
||||
---
|
||||
|
||||
### Response
|
||||
|
||||
**Success Response: `200 OK`**
|
||||
|
||||
```json
|
||||
{
|
||||
"id": "abc123",
|
||||
"status": "active",
|
||||
"created_at": "2025-04-01T10:00:00Z"
|
||||
}
|
||||
```
|
||||
|
||||
| Field | Type | Description |
|
||||
|---|---|---|
|
||||
| `id` | string | Unique identifier for the created/retrieved resource |
|
||||
| `status` | string | Current status. Enum: `active`, `inactive`, `pending` |
|
||||
| `created_at` | ISO 8601 string | Timestamp of creation in UTC |
|
||||
|
||||
---
|
||||
|
||||
### Error Codes
|
||||
|
||||
| Status Code | Error Code | Description | How to Resolve |
|
||||
|---|---|---|---|
|
||||
| `400` | `INVALID_REQUEST` | Request body is malformed or missing required fields | Check request body against schema above |
|
||||
| `401` | `UNAUTHORIZED` | Missing or invalid authentication token | Verify your API key or refresh your token |
|
||||
| `404` | `NOT_FOUND` | The requested resource does not exist | Check the ID in the path parameter |
|
||||
| `429` | `RATE_LIMITED` | Too many requests | Back off and retry after `Retry-After` header value |
|
||||
| `500` | `INTERNAL_ERROR` | Unexpected server error | Retry with exponential backoff; contact support if persists |
|
||||
|
||||
---
|
||||
|
||||
### Code Examples
|
||||
|
||||
Produce examples in at least 2 languages relevant to the audience (default: cURL + Python):
|
||||
|
||||
**cURL:**
|
||||
```bash
|
||||
curl -X POST https://api.example.com/v1/endpoint \
|
||||
-H "Authorization: Bearer YOUR_TOKEN" \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"field_name": "value"}'
|
||||
```
|
||||
|
||||
**Python:**
|
||||
```python
|
||||
import requests
|
||||
|
||||
response = requests.post(
|
||||
"https://api.example.com/v1/endpoint",
|
||||
headers={"Authorization": "Bearer YOUR_TOKEN"},
|
||||
json={"field_name": "value"}
|
||||
)
|
||||
data = response.json()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every parameter is documented (type, required/optional, description)
|
||||
- [ ] Response fields are fully documented with types
|
||||
- [ ] All relevant error codes are listed with resolution guidance
|
||||
- [ ] Code examples are copy-paste runnable (no pseudocode)
|
||||
- [ ] Auth method is clearly stated at the top
|
||||
- [ ] Enum values are listed where applicable
|
||||
- [ ] Pagination documented if the endpoint is a list endpoint
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Document this API endpoint: [paste spec or description]"
|
||||
- "Turn this Postman collection into developer docs"
|
||||
- "Write API reference docs for [endpoint]"
|
||||
- "Write a developer guide for our [product] API"
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
name: architecture-decision-record
|
||||
description: "Create an Architecture Decision Record (ADR) for any technical decision. Use when asked to document a technical decision, write an ADR, record an architecture choice, or capture why a technology or approach was selected. Produces a structured ADR with context, decision, consequences, and tradeoffs."
|
||||
---
|
||||
|
||||
# Architecture Decision Record (ADR) Skill
|
||||
|
||||
This skill produces a complete Architecture Decision Record (ADR) following the Nygard format — the most widely adopted standard. ADRs document the reasoning behind significant technical decisions so future team members understand not just *what* was decided, but *why*.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Decision title** (brief, e.g. "Use PostgreSQL as primary datastore")
|
||||
- **Context** (what situation led to this decision needing to be made?)
|
||||
- **Options considered** (at least 2; if only 1 is given, prompt for alternatives that were considered or ruled out)
|
||||
- **Decision made** (which option was chosen)
|
||||
- **Reason for choice**
|
||||
- **Status** (Proposed / Accepted / Deprecated / Superseded)
|
||||
- **Author and date**
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# ADR-[NNN]: [Decision Title]
|
||||
|
||||
**Date:** [YYYY-MM-DD]
|
||||
**Status:** [Proposed / Accepted / Deprecated / Superseded by ADR-NNN]
|
||||
**Author(s):** [Name(s)]
|
||||
**Deciders:** [Who had final say — individual or team]
|
||||
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
[3–6 sentences. Describe the situation, constraints, and forces at play that made this decision necessary. Include: the problem being solved, relevant system state, team constraints, timeline pressures, or non-negotiable requirements. Write as if explaining to someone joining the team 18 months from now who has no prior context.]
|
||||
|
||||
**Key constraints:**
|
||||
- [Constraint 1: e.g. "Must be deployable on-premise for enterprise customers"]
|
||||
- [Constraint 2: e.g. "Team has no prior Go experience"]
|
||||
- [Add as many as are relevant]
|
||||
|
||||
---
|
||||
|
||||
## Options Considered
|
||||
|
||||
For each option, produce:
|
||||
|
||||
### Option [N]: [Name]
|
||||
|
||||
**Description:** [What this option is — 1–3 sentences]
|
||||
|
||||
**Pros:**
|
||||
- [Pro 1]
|
||||
- [Pro 2]
|
||||
|
||||
**Cons:**
|
||||
- [Con 1]
|
||||
- [Con 2]
|
||||
|
||||
**Why this was ruled out (if not chosen):** [Honest reason]
|
||||
|
||||
---
|
||||
|
||||
## Decision
|
||||
|
||||
**We will [chosen option].**
|
||||
|
||||
[2–4 sentences explaining the decision in plain language. This should be readable in isolation — someone should understand the decision from this paragraph alone without reading the full document.]
|
||||
|
||||
---
|
||||
|
||||
## Consequences
|
||||
|
||||
### Positive Consequences
|
||||
- [What this decision enables or improves]
|
||||
- [What risk it mitigates]
|
||||
|
||||
### Negative Consequences / Accepted Tradeoffs
|
||||
- [What we're giving up or taking on as a result of this decision]
|
||||
- [Technical debt or limitations introduced]
|
||||
- [What must now be true for this decision to remain valid]
|
||||
|
||||
### Risks
|
||||
- [What could cause this decision to be wrong in hindsight]
|
||||
- [What would trigger us to revisit this decision]
|
||||
|
||||
---
|
||||
|
||||
## Implementation Notes
|
||||
|
||||
[Optional but valuable: any specific patterns, gotchas, or guidance for the team implementing based on this decision. Link to relevant tickets, RFCs, or design docs if applicable.]
|
||||
|
||||
---
|
||||
|
||||
## Review Date
|
||||
|
||||
[Optional: "This decision should be reviewed if [condition] — e.g. team grows beyond 20 engineers, or traffic exceeds 10M requests/day."]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Context explains the *why* — not just the *what*
|
||||
- [ ] At least 2 options are documented (including the rejected ones)
|
||||
- [ ] Rejected options include honest reasons for rejection
|
||||
- [ ] Consequences include *negative* consequences — no decision is consequence-free
|
||||
- [ ] Decision is stated in plain language in the Decision section
|
||||
- [ ] Risks section identifies what would invalidate this decision
|
||||
- [ ] Written for someone with no prior context on this decision
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write an ADR for using [technology]"
|
||||
- "Document our decision to [architectural choice]"
|
||||
- "Create an architecture decision record for [topic]"
|
||||
- "Help me write up why we chose [option] over [alternative]"
|
||||
@@ -0,0 +1,157 @@
|
||||
---
|
||||
name: board-deck-narrative
|
||||
description: "Build the storyline and slide structure for a board presentation. Use when asked to create a board deck, board presentation narrative, board meeting slides, or quarterly board update. Produces a complete slide-by-slide structure with narrative beats, talking points, and slide content guidance."
|
||||
---
|
||||
|
||||
# Board Deck Narrative Skill
|
||||
|
||||
This skill builds the complete narrative and slide structure for a board presentation — from opening framing to closing asks. It produces slide-by-slide content guidance, not just a list of topics.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Company stage and context** (Seed / Series A / Growth — and where you are in the year)
|
||||
- **Board meeting type** (Regular quarterly / Annual / Special / Fundraise-related)
|
||||
- **Key themes for this meeting** (e.g. strong growth quarter / pivoting strategy / hiring challenge / fundraise update)
|
||||
- **Key metrics to feature**
|
||||
- **Decisions needed from the board** (if any)
|
||||
- **Time available** (e.g. 60 min / 90 min)
|
||||
- **Audience** (investors only / investors + independent directors / mixed)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Board Deck Narrative: [Company] — [Quarter/Period]
|
||||
|
||||
**Meeting type:** [Regular quarterly / Special]
|
||||
**Time:** [X minutes]
|
||||
**Narrative theme:** [The one-sentence story of this quarter — e.g. "We hit our revenue target, but activation is the problem we need to solve together."]
|
||||
|
||||
---
|
||||
|
||||
## Opening Frame (Slide 1–2)
|
||||
|
||||
**Slide 1: Title**
|
||||
- Company name, quarter, date
|
||||
- One-sentence framing of the meeting's narrative arc
|
||||
|
||||
**Slide 2: Agenda**
|
||||
- List of sections + time allocation
|
||||
- Flag which sections need board input vs. are informational
|
||||
|
||||
*Presenter note: Board members are busy. Tell them in the first 2 minutes what you need from them today. It changes how they listen.*
|
||||
|
||||
---
|
||||
|
||||
## Business Performance (Slides 3–6, ~15 min)
|
||||
|
||||
**Slide 3: Scorecard / KPI Dashboard**
|
||||
- Content: Key metrics vs. targets for the quarter. No more than 6 metrics.
|
||||
- Format: Traffic-light table (Green / Amber / Red against plan)
|
||||
- Narrative: [1–2 sentences — the headline story of the quarter in numbers]
|
||||
- *Don't hide reds. Boards lose trust when they discover hidden problems later.*
|
||||
|
||||
**Slide 4: Revenue / Growth Deep Dive**
|
||||
- Content: Revenue breakdown by segment, cohort retention, growth drivers
|
||||
- Key message: [What the data shows about the health of growth]
|
||||
- Call out: [Any trend that needs board context or discussion]
|
||||
|
||||
**Slide 5: Unit Economics**
|
||||
- Content: CAC, LTV, payback period, gross margin — vs. last quarter and vs. plan
|
||||
- Flag: Any metric moving in the wrong direction and what's causing it
|
||||
|
||||
**Slide 6: Operational Highlights**
|
||||
- Content: 3–5 bullet points of the most significant things that happened this quarter
|
||||
- Format: Each bullet = outcome, not activity. ("Signed 3 enterprise contracts worth £400K ARR" not "Continued enterprise sales motion")
|
||||
|
||||
---
|
||||
|
||||
## Strategic Update (Slides 7–9, ~15 min)
|
||||
|
||||
**Slide 7: Strategy Snapshot**
|
||||
- Content: Where you said you'd be vs. where you are against the annual plan
|
||||
- Narrative: [Honest assessment — what's on track, what's shifted and why]
|
||||
|
||||
**Slide 8: Key Strategic Decision or Update**
|
||||
- Content: The one strategic topic that most needs board input this meeting
|
||||
- Format: Context → Options considered → Recommendation → Question for board
|
||||
- *This is the highest-value 10 minutes of the meeting. Frame it as a real question.*
|
||||
|
||||
**Slide 9: Product & Roadmap (if relevant)**
|
||||
- Content: Top 3 product bets this quarter — what shipped, what's coming, why these bets
|
||||
- Tailored for: What the board needs to understand to support strategic decisions, not a sprint review
|
||||
|
||||
---
|
||||
|
||||
## People & Organisation (Slide 10, ~5 min)
|
||||
|
||||
**Slide 10: Team Update**
|
||||
- Content: Headcount (start vs. end of quarter), key hires made, open roles, any org changes
|
||||
- Flag: Any people risks or leadership gaps the board should know about
|
||||
- *Don't skip this slide. Board members often have network value here.*
|
||||
|
||||
---
|
||||
|
||||
## Financial Update (Slides 11–12, ~10 min)
|
||||
|
||||
**Slide 11: P&L Summary**
|
||||
- Content: Revenue, gross margin, opex by category, EBITDA/net burn — actual vs. budget
|
||||
- Include: Year-to-date vs. annual plan
|
||||
|
||||
**Slide 12: Cash & Runway**
|
||||
- Content: Cash on hand, monthly burn rate, runway at current burn
|
||||
- Include: Scenario if burn increases (e.g. key hire made), scenario if growth accelerates
|
||||
- Flag immediately: If runway is < 18 months — this needs board awareness and planning
|
||||
|
||||
---
|
||||
|
||||
## Closing & Asks (Slides 13–14, ~10 min)
|
||||
|
||||
**Slide 13: Priorities for Next Quarter**
|
||||
- Content: Top 3–5 priorities and what success looks like for each
|
||||
- Format: Priority | What we're doing | How we'll know it worked
|
||||
- *Keeps board accountability consistent across meetings*
|
||||
|
||||
**Slide 14: Board Asks**
|
||||
- Content: Specific things you need from board members before next meeting
|
||||
- Format: Each ask = specific, named if possible ("Looking for an intro to [Company] — [Board member X], do you have a connection?")
|
||||
- *A board meeting without specific asks is a missed opportunity*
|
||||
|
||||
---
|
||||
|
||||
## Appendix (Optional)
|
||||
|
||||
- Detailed cohort analysis
|
||||
- Competitive landscape update
|
||||
- Full P&L
|
||||
- Team org chart
|
||||
- Any supporting data referenced in the main deck
|
||||
|
||||
*Appendix slides are available but not presented. Board members who want detail can ask.*
|
||||
|
||||
---
|
||||
|
||||
## Narrative Principles
|
||||
|
||||
- **Lead with honesty.** If it was a hard quarter, say so in the first slide. Don't bury bad news after the wins.
|
||||
- **One slide = one idea.** If a slide has two messages, split it.
|
||||
- **Fewer slides, more depth.** A 14-slide deck presented well beats a 35-slide deck rushed through.
|
||||
- **Every slide has a "so what."** A slide that just shows data without a takeaway wastes board time.
|
||||
- **Leave time for discussion.** Board value is in the conversation, not the presentation. Aim to spend 40% of the meeting presenting and 60% in discussion.
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Opening frame states the meeting's narrative theme
|
||||
- [ ] Scorecard slide uses traffic-light format (not just green metrics)
|
||||
- [ ] Strategic decision slide frames a real question for the board
|
||||
- [ ] Financial slide includes runway explicitly
|
||||
- [ ] Board asks are specific and actionable
|
||||
- [ ] Deck is ≤ 15 slides (excluding appendix)
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a board deck structure for our Q[N] board meeting"
|
||||
- "Help me create the narrative for our board presentation"
|
||||
- "Write the slide structure for our annual board review"
|
||||
- "Design a board deck for [specific context — e.g. fundraise update]"
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: code-review-checklist
|
||||
description: "Generate a tailored code review checklist for any PR, language, or risk level. Use when asked to create a code review checklist, review guidelines, PR standards, or quality gates for a codebase. Produces a structured, prioritised checklist adapted to the specific language, PR type, and risk level."
|
||||
---
|
||||
|
||||
# Code Review Checklist Skill
|
||||
|
||||
This skill generates a structured, prioritised code review checklist tailored to a specific PR, language, and risk level. It helps reviewers be thorough without being bureaucratic.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Programming language(s)** (e.g. Python, TypeScript, Go, Java)
|
||||
- **PR type** (new feature / bug fix / refactor / performance improvement / security patch / infrastructure change)
|
||||
- **Risk level** (Low: internal tooling, Low traffic / Medium: user-facing feature / High: payment, auth, data pipeline, public API)
|
||||
- **Team context** (optional: team size, seniority mix, any known recurring issues)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Checklist Header
|
||||
|
||||
**PR:** [Title if provided]
|
||||
**Language:** [Language]
|
||||
**Type:** [PR Type]
|
||||
**Risk Level:** [Low / Medium / High]
|
||||
**Estimated review depth:** [Quick scan ~15 min / Standard ~30 min / Deep review ~60 min+]
|
||||
|
||||
---
|
||||
|
||||
### 2. The Checklist
|
||||
|
||||
Organise into sections. Mark each item with a priority indicator:
|
||||
- 🔴 **MUST** — Blocking. PR should not merge without this.
|
||||
- 🟡 **SHOULD** — Important. Address before merge unless there's a good reason not to.
|
||||
- 🟢 **CONSIDER** — Nice to have. Worth a comment but not blocking.
|
||||
|
||||
#### Section A: Correctness
|
||||
- 🔴 Does the code do what the ticket/requirement describes?
|
||||
- 🔴 Are edge cases handled? (nulls, empty arrays, zero values, max values)
|
||||
- 🔴 Are error states handled and surfaced appropriately?
|
||||
- 🟡 Does the happy path have adequate test coverage?
|
||||
- 🟡 Are failure paths tested?
|
||||
|
||||
#### Section B: Security (scale with risk level — expand for High risk PRs)
|
||||
- 🔴 [High risk only] Is user input sanitised before use in queries or commands?
|
||||
- 🔴 [High risk only] Are auth/permission checks in place?
|
||||
- 🟡 Are secrets/credentials committed anywhere? (check .env handling)
|
||||
- 🟡 Are third-party dependencies known-safe versions?
|
||||
|
||||
#### Section C: Performance
|
||||
- 🟡 Are there N+1 query patterns in database calls?
|
||||
- 🟡 Is there unnecessary work inside loops?
|
||||
- 🟢 Are database queries indexed appropriately?
|
||||
- 🟢 Is caching considered where appropriate?
|
||||
|
||||
#### Section D: Readability & Maintainability
|
||||
- 🟡 Are function and variable names clear without needing a comment to explain them?
|
||||
- 🟡 Are complex logic blocks explained with inline comments?
|
||||
- 🟢 Is the code consistent with existing patterns in the codebase?
|
||||
- 🟢 Are there any magic numbers that should be named constants?
|
||||
|
||||
#### Section E: Language-Specific Checks
|
||||
[Populate this section based on the specified language. Examples below:]
|
||||
|
||||
**Python:**
|
||||
- 🟡 Are type hints used on function signatures?
|
||||
- 🟡 Are exceptions caught specifically (not bare `except:`)?
|
||||
- 🟢 Does it follow PEP 8 (or the team's linter config)?
|
||||
|
||||
**TypeScript/JavaScript:**
|
||||
- 🔴 Are there any `any` types that should be properly typed?
|
||||
- 🟡 Are async/await patterns used consistently (no mixed Promise.then chains)?
|
||||
- 🟢 Are there unnecessary re-renders in React components?
|
||||
|
||||
**Go:**
|
||||
- 🔴 Are errors checked (not ignored with `_`)?
|
||||
- 🟡 Are goroutines properly managed to prevent leaks?
|
||||
- 🟢 Are exported functions documented?
|
||||
|
||||
#### Section F: PR Hygiene
|
||||
- 🟡 Is the PR a reasonable size? (>500 lines diff suggests it should be split)
|
||||
- 🟡 Does the PR description explain *why*, not just *what*?
|
||||
- 🟢 Are there linked tickets or context in the PR description?
|
||||
- 🟢 Are migration scripts or deployment notes included if needed?
|
||||
|
||||
---
|
||||
|
||||
### 3. Risk-Specific Additions
|
||||
|
||||
For **High risk** PRs, always add:
|
||||
- 🔴 Has this been tested in a staging environment?
|
||||
- 🔴 Is there a rollback plan?
|
||||
- 🔴 Has a second reviewer been assigned?
|
||||
|
||||
For **Infrastructure / DB changes**, always add:
|
||||
- 🔴 Are migrations backward-compatible?
|
||||
- 🔴 Has the migration been tested against production data volume?
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Checklist is tailored to the specified language (not generic)
|
||||
- [ ] Risk level is reflected in the MUST vs SHOULD balance
|
||||
- [ ] Language-specific section covers the most common issues for that language
|
||||
- [ ] PR hygiene section is always present
|
||||
- [ ] High-risk additions are included when risk level = High
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Generate a code review checklist for a Python bug fix PR"
|
||||
- "Give me a review checklist for a high-risk TypeScript auth change"
|
||||
- "What should I check in this Go PR?"
|
||||
- "Create PR review standards for our team"
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
name: competitor-teardown
|
||||
description: "Produce a structured competitive analysis for any product or market. Use when asked for a competitor analysis, competitive teardown, market comparison, SWOT, or positioning map. Generates a structured teardown with positioning map, feature comparison, messaging gaps, and strategic recommendations."
|
||||
---
|
||||
|
||||
# Competitor Teardown Skill
|
||||
|
||||
This skill produces a complete competitive analysis document — structured for use in strategy decks, investor materials, sales enablement, or product planning sessions.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Your product** (name + one-line description)
|
||||
- **Competitors to analyse** (list 2–5 names; if not provided, ask)
|
||||
- **Analysis depth** (quick overview / detailed teardown)
|
||||
- **Primary use case for this analysis** (e.g. sales enablement, investor deck, internal strategy, product planning)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Competitive Landscape Overview
|
||||
|
||||
One paragraph summarising the market dynamic: who the key players are, how the market is segmented, and where the white space sits. Keep this under 150 words — it's the exec summary.
|
||||
|
||||
### 2. Positioning Map
|
||||
|
||||
Describe a 2x2 positioning map in text form (since you can't render images):
|
||||
|
||||
- Define the two axes relevant to this market (e.g. "Ease of Use vs. Depth of Features" or "Price vs. Enterprise Readiness")
|
||||
- Place each competitor in one quadrant with a one-sentence rationale
|
||||
- Place the user's product and highlight the strategic implication
|
||||
|
||||
### 3. Feature Comparison Table
|
||||
|
||||
| Feature / Capability | [Your Product] | [Competitor A] | [Competitor B] | [Competitor C] |
|
||||
|---|---|---|---|---|
|
||||
| [Feature] | ✅ / ❌ / 🟡 Partial | | | |
|
||||
|
||||
Use ✅ (has it), ❌ (doesn't have it), 🟡 (partial/limited). Add a "Strategic Notes" column for features where the difference is a significant selling point or risk.
|
||||
|
||||
Include 10–15 rows. If user hasn't provided feature details, note which cells need to be verified.
|
||||
|
||||
### 4. Messaging Analysis
|
||||
|
||||
For each competitor, analyse their public-facing messaging (website headline, tagline, primary value prop):
|
||||
|
||||
**[Competitor Name]**
|
||||
- **Their primary claim:** [what they say they do]
|
||||
- **Target audience signal:** [who they seem to be targeting based on language/imagery]
|
||||
- **Emotional hook:** [fear / aspiration / authority / speed / simplicity]
|
||||
- **Gap or weakness in their messaging:** [what they don't address that your product could own]
|
||||
|
||||
### 5. SWOT Summary
|
||||
|
||||
Produce a clean SWOT for the user's product in the context of this competitive landscape:
|
||||
|
||||
- **Strengths:** [2–3 genuine differentiators]
|
||||
- **Weaknesses:** [2–3 honest gaps or vulnerabilities]
|
||||
- **Opportunities:** [2–3 market gaps or competitor weaknesses to exploit]
|
||||
- **Threats:** [2–3 competitor moves or market shifts to watch]
|
||||
|
||||
### 6. Strategic Recommendations
|
||||
|
||||
3–5 actionable recommendations based on the analysis. Frame each as: **"Given [observation], [your product] should [action] to [outcome]."**
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Axes on positioning map are meaningful and specific to this market
|
||||
- [ ] Feature table includes strategic notes on key differentiators
|
||||
- [ ] Messaging analysis covers all named competitors
|
||||
- [ ] SWOT is honest — Weaknesses and Threats should not be softened
|
||||
- [ ] Recommendations are specific and actionable, not generic strategy advice
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Do a competitor analysis of [Product] vs [Competitor A] and [Competitor B]"
|
||||
- "Tear down [Competitor]'s positioning"
|
||||
- "Give me a competitive landscape for [market]"
|
||||
- "Build a SWOT for our product against [competitor]"
|
||||
@@ -0,0 +1,58 @@
|
||||
---
|
||||
name: content-calendar
|
||||
description: "Generate a structured content calendar for any brand, product, or creator. Use when asked for a content plan, editorial calendar, social media schedule, or weekly/monthly content strategy. Produces a calendar with topics, formats, channels, and copy hooks."
|
||||
---
|
||||
|
||||
# Content Calendar Skill
|
||||
|
||||
This skill generates a structured content calendar from brand inputs. It produces ready-to-use calendar entries with topics, formats, channels, and opening hooks — usable for social media, blogs, newsletters, or multi-channel campaigns.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Brand or product name**
|
||||
- **Target audience** (who are you trying to reach?)
|
||||
- **Primary content goal** (awareness / lead gen / retention / thought leadership)
|
||||
- **Channels** (e.g. LinkedIn, Instagram, newsletter, blog, X/Twitter)
|
||||
- **Cadence** (daily / 3x per week / weekly / monthly)
|
||||
- **Timeframe** (e.g. 4 weeks, Q2)
|
||||
- **Brand pillars or themes** (optional — if not provided, derive 3 from the product description)
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Content Pillars (if not provided)
|
||||
|
||||
Derive 3–4 content pillars from the brand/product description. Each pillar = a recurring theme that anchors multiple posts. Label each one clearly (e.g. "Pillar 1: Industry Education", "Pillar 2: Product Stories").
|
||||
|
||||
### 2. Calendar Table
|
||||
|
||||
Produce a weekly table for each week requested. Format:
|
||||
|
||||
| Date | Pillar | Topic | Format | Channel | Opening Hook |
|
||||
|---|---|---|---|---|---|
|
||||
| Mon 7 Apr | Education | [Topic title] | Carousel / Article / Short video / Thread | LinkedIn | [First sentence or headline of the post] |
|
||||
|
||||
Rules:
|
||||
- Rotate through all pillars across the week — don't stack the same pillar on consecutive days
|
||||
- Match format to channel norms (e.g. carousels for Instagram, long-form for LinkedIn, threads for X)
|
||||
- Opening hooks must be specific and scroll-stopping — no generic openers like "Did you know..."
|
||||
- Flag 1–2 posts per week as "High Priority" — these are the cornerstone pieces worth boosting or repurposing
|
||||
|
||||
### 3. Repurposing Map
|
||||
|
||||
For each "High Priority" post, add one repurposing suggestion — e.g. "Turn this LinkedIn article into a newsletter section" or "Clip this video for an Instagram Reel."
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every week has balanced pillar distribution
|
||||
- [ ] No two consecutive posts have the same format on the same channel
|
||||
- [ ] Opening hooks are specific (no generic openers)
|
||||
- [ ] Formats match platform norms
|
||||
- [ ] Repurposing map covers all High Priority posts
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build me a 4-week content calendar for [brand]"
|
||||
- "Create a social media plan for [product launch]"
|
||||
- "Give me a monthly editorial calendar for my newsletter"
|
||||
- "Plan my LinkedIn content for the next month"
|
||||
@@ -0,0 +1,122 @@
|
||||
---
|
||||
name: dashboard-brief
|
||||
description: "Convert a business question into a complete dashboard specification. Use when asked to design a dashboard, create a dashboard spec or brief, plan a BI report, or define what charts and metrics a dashboard should include. Produces a structured spec with metrics, dimensions, chart types, filters, and layout guidance."
|
||||
---
|
||||
|
||||
# Dashboard Brief Skill
|
||||
|
||||
This skill converts a business question or monitoring need into a complete, implementation-ready dashboard specification. The output gives a data engineer or BI developer everything they need to build without a follow-up meeting.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **The business question this dashboard should answer** (e.g. "How is our activation funnel performing this week?")
|
||||
- **Primary audience** (exec / product team / operations / customer success / engineering)
|
||||
- **Refresh cadence** (real-time / hourly / daily / weekly)
|
||||
- **Data sources available** (e.g. Postgres, BigQuery, Mixpanel, Salesforce, Jira)
|
||||
- **BI tool being used** (Looker / Metabase / Tableau / Power BI / Grafana / Custom / Unknown)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Dashboard Brief: [Dashboard Name]
|
||||
|
||||
**Business Question:** [The question this dashboard answers — verbatim from inputs or refined]
|
||||
**Audience:** [Who uses this]
|
||||
**Refresh Rate:** [Real-time / Hourly / Daily / Weekly]
|
||||
**Data Sources:** [List]
|
||||
**BI Tool:** [Tool or Unknown]
|
||||
|
||||
---
|
||||
|
||||
## Section 1: Key Metrics (KPI Cards)
|
||||
|
||||
List the headline numbers that should appear at the top of the dashboard as KPI cards.
|
||||
|
||||
| Metric | Definition | Data Source | Comparison |
|
||||
|---|---|---|---|
|
||||
| [Metric name] | [How it's calculated] | [Table/source] | [vs. last week / vs. target / MoM] |
|
||||
|
||||
Aim for 3–6 KPI cards. More than 6 is noise.
|
||||
|
||||
---
|
||||
|
||||
## Section 2: Charts & Visualisations
|
||||
|
||||
For each chart, specify:
|
||||
|
||||
### Chart [N]: [Chart Title]
|
||||
|
||||
- **Chart type:** [Line / Bar / Stacked bar / Pie / Funnel / Heatmap / Table / Scatter]
|
||||
- **Why this chart type:** [One sentence — why this type suits this data]
|
||||
- **X-axis / Rows:** [Dimension — e.g. Date, User segment, Product]
|
||||
- **Y-axis / Values:** [Metric — e.g. Count of active users, Revenue]
|
||||
- **Breakdown/colour:** [Optional secondary dimension — e.g. by Plan tier, by Channel]
|
||||
- **Data source:** [Table or source]
|
||||
- **Filters:** [Any default filters applied — e.g. "Exclude internal test accounts"]
|
||||
- **Key insight to surface:** [What pattern or signal this chart should help the viewer spot]
|
||||
|
||||
---
|
||||
|
||||
## Section 3: Filters & Controls
|
||||
|
||||
Global filters available to dashboard viewers:
|
||||
|
||||
| Filter | Type | Default | Options |
|
||||
|---|---|---|---|
|
||||
| Date range | Date picker | Last 30 days | Custom |
|
||||
| [Segment filter] | Dropdown | All | [List relevant values] |
|
||||
| [Other filter] | Multi-select | All | [List relevant values] |
|
||||
|
||||
---
|
||||
|
||||
## Section 4: Layout Recommendation
|
||||
|
||||
Describe the dashboard layout in plain terms:
|
||||
|
||||
```
|
||||
[ROW 1 — KPI Cards]: [Metric 1] | [Metric 2] | [Metric 3] | [Metric 4]
|
||||
[ROW 2 — Primary chart, full width]: [Chart name]
|
||||
[ROW 3 — Two charts side by side]: [Chart A] | [Chart B]
|
||||
[ROW 4 — Supporting table, full width]: [Table name]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Section 5: Data Requirements
|
||||
|
||||
List any data transformations, joins, or derived fields needed:
|
||||
|
||||
| Derived Field | Logic | Source Tables |
|
||||
|---|---|---|
|
||||
| [Field name] | [How it's calculated] | [Tables involved] |
|
||||
|
||||
Flag any fields that may not exist in current data infrastructure.
|
||||
|
||||
---
|
||||
|
||||
## Section 6: Access & Ownership
|
||||
|
||||
- **Dashboard owner:** [Leave for user to fill]
|
||||
- **Who can edit:** [Leave for user to fill]
|
||||
- **Who can view:** [Leave for user to fill]
|
||||
- **Review cadence:** [When should this dashboard be reviewed for relevance?]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every chart has a stated "key insight to surface" — not just "show the data"
|
||||
- [ ] KPI cards are 3–6 (not more)
|
||||
- [ ] Chart types are justified
|
||||
- [ ] Layout follows visual hierarchy (summary → detail)
|
||||
- [ ] Data requirements section flags any missing fields
|
||||
- [ ] Filters are practical and don't require IT to configure
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Design a dashboard to track [business process]"
|
||||
- "Give me a spec for a [team] performance dashboard"
|
||||
- "What should go on a [topic] dashboard?"
|
||||
- "Write a dashboard brief for our [metric] monitoring"
|
||||
@@ -0,0 +1,130 @@
|
||||
---
|
||||
name: design-critique
|
||||
description: "Give structured, constructive feedback on any design. Use when asked to critique a design, review a UI, give feedback on a Figma file or wireframe, assess a user flow, or evaluate a design against UX principles. Applies Jobs-to-be-Done, Gestalt principles, and usability heuristics to give actionable feedback."
|
||||
---
|
||||
|
||||
# Design Critique Skill
|
||||
|
||||
This skill provides structured, actionable design feedback using established UX frameworks. It balances positive observations with clear, prioritised improvement suggestions.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **What is being reviewed** (screen, flow, component, full product)
|
||||
- **Design description or attached image** (describe it if no image — the skill will still work)
|
||||
- **User goal** (what is the user trying to accomplish with this design?)
|
||||
- **Context** (web / mobile / desktop app / physical product)
|
||||
- **Stage** (early wireframe / mid-fidelity / high-fidelity / live product)
|
||||
- **Primary concern** (optional — e.g. "I'm worried the onboarding is too long" or "I think the CTA is unclear")
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Design Critique: [Design Name or Screen]
|
||||
|
||||
**User goal:** [What the user needs to accomplish]
|
||||
**Context:** [Platform / Stage]
|
||||
**Critique focus:** [Primary concern if stated, otherwise "full review"]
|
||||
|
||||
---
|
||||
|
||||
## 1. What's Working
|
||||
|
||||
[3–5 specific, honest observations about what the design does well. Don't manufacture praise — only include genuine strengths. Be specific: "The visual hierarchy clearly guides the eye from headline → supporting detail → CTA" is useful. "Looks clean" is not.]
|
||||
|
||||
---
|
||||
|
||||
## 2. Priority Issues
|
||||
|
||||
Rank issues by impact on the user goal. Use:
|
||||
- 🔴 **High** — Blocks or significantly degrades the user's ability to complete their goal
|
||||
- 🟡 **Medium** — Causes friction or confusion but doesn't block completion
|
||||
- 🟢 **Low** — Polish or preference — nice to fix but not critical
|
||||
|
||||
For each issue:
|
||||
|
||||
### [Priority] Issue [N]: [Short name]
|
||||
|
||||
**What's happening:**
|
||||
[Describe the specific design problem — be precise about which element, screen, or interaction]
|
||||
|
||||
**Why it matters:**
|
||||
[Connect to the user goal or a specific principle — don't just say "it's confusing." Say why it creates confusion and what the consequence is for the user.]
|
||||
|
||||
**Framework reference:**
|
||||
[Name the principle being violated — e.g. Nielsen's Heuristic #6 (Recognition over Recall), Gestalt proximity, JTBD clarity, Fitts's Law, etc.]
|
||||
|
||||
**Recommendation:**
|
||||
[Specific, actionable suggestion. Not "make the button bigger" but "Increase the primary CTA to at least 44x44px to meet touch target guidelines; consider moving it below the form rather than inline with the input fields to reduce accidental taps."]
|
||||
|
||||
---
|
||||
|
||||
## 3. Heuristic Assessment
|
||||
|
||||
Quick assessment against Nielsen's 10 Usability Heuristics — score each as ✅ Pass / 🟡 Partial / ❌ Fail:
|
||||
|
||||
| Heuristic | Status | Note |
|
||||
|---|---|---|
|
||||
| 1. Visibility of system status | | |
|
||||
| 2. Match between system and real world | | |
|
||||
| 3. User control and freedom | | |
|
||||
| 4. Consistency and standards | | |
|
||||
| 5. Error prevention | | |
|
||||
| 6. Recognition rather than recall | | |
|
||||
| 7. Flexibility and efficiency of use | | |
|
||||
| 8. Aesthetic and minimalist design | | |
|
||||
| 9. Help users recognise, diagnose, and recover from errors | | |
|
||||
| 10. Help and documentation | | |
|
||||
|
||||
Only include heuristics relevant to what's visible in the design — don't penalise for things not in scope.
|
||||
|
||||
---
|
||||
|
||||
## 4. Gestalt Principles Check
|
||||
|
||||
[Comment on any Gestalt principles that are either well-applied or violated:]
|
||||
|
||||
- **Proximity:** [Are related elements grouped clearly?]
|
||||
- **Similarity:** [Do similar elements look similar?]
|
||||
- **Continuity:** [Does the eye flow naturally through the design?]
|
||||
- **Figure/Ground:** [Is the primary content clearly distinguished from background?]
|
||||
- **Closure:** [Are any implied shapes or containers confusing?]
|
||||
|
||||
---
|
||||
|
||||
## 5. JTBD Alignment
|
||||
|
||||
[Assess how well the design serves the stated job-to-be-done:]
|
||||
|
||||
- **Does the design make the user's primary job obvious?** [Yes / Partially / No — explain]
|
||||
- **Are there any elements that distract from the primary job?** [List any competing CTAs, distractions, or unclear hierarchy]
|
||||
- **What emotional job does this design serve?** [Speed / Confidence / Control / Delight / Other] — and does the visual design match that emotional goal?
|
||||
|
||||
---
|
||||
|
||||
## 6. Top 3 Recommended Next Steps
|
||||
|
||||
Prioritised list of the 3 most impactful changes. Each should be actionable in the next design iteration:
|
||||
|
||||
1. [Most impactful change — specific]
|
||||
2. [Second priority]
|
||||
3. [Third priority]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] "What's working" includes only genuine, specific observations
|
||||
- [ ] Every issue has a framework reference (not just subjective opinion)
|
||||
- [ ] Recommendations are specific and actionable
|
||||
- [ ] Priority levels (High/Medium/Low) reflect actual impact on user goal
|
||||
- [ ] Heuristic assessment only covers visible elements
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Critique this design: [description or image]"
|
||||
- "Give me feedback on this UI/UX"
|
||||
- "Review this Figma screen for usability issues"
|
||||
- "What's wrong with this user flow?"
|
||||
- "Do a heuristic evaluation of [screen/product]"
|
||||
@@ -0,0 +1,78 @@
|
||||
---
|
||||
name: email-campaign
|
||||
description: "Write and sequence multi-email nurture or launch campaigns. Use when asked for an email sequence, drip campaign, onboarding emails, product launch emails, or nurture flow. Produces subject lines, preview text, full email body, and send-timing recommendations for each email in the sequence."
|
||||
---
|
||||
|
||||
# Email Campaign Skill
|
||||
|
||||
This skill writes complete, sequenced email campaigns — from welcome flows to product launches to re-engagement sequences. Each email is written with subject line, preview text, full body copy, and CTA.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Campaign goal** (onboard new users / launch a product / nurture leads / re-engage churned users / announce a feature)
|
||||
- **Audience** (who receives this? job title, lifecycle stage, what they know already)
|
||||
- **Product or offer** being promoted or introduced
|
||||
- **Number of emails in sequence** (if unsure, recommend based on goal)
|
||||
- **Tone** (professional / conversational / bold / educational)
|
||||
- **Sender name** (person or brand?)
|
||||
|
||||
## Sequence Recommendations by Goal
|
||||
|
||||
If the user hasn't specified number of emails, use these defaults:
|
||||
- **Onboarding:** 4 emails over 7 days (Day 0, Day 1, Day 3, Day 7)
|
||||
- **Product launch:** 3 emails (Teaser → Launch Day → Follow-up/Last chance)
|
||||
- **Lead nurture:** 5 emails over 2 weeks
|
||||
- **Re-engagement:** 3 emails (Gentle nudge → Value reminder → Final offer)
|
||||
- **Feature announcement:** 2 emails (Announcement → How-to/deep dive)
|
||||
|
||||
## Output Structure Per Email
|
||||
|
||||
For every email in the sequence, produce:
|
||||
|
||||
---
|
||||
|
||||
**Email [N] of [Total] — [Descriptive label e.g. "Welcome / Day 0"]**
|
||||
**Send timing:** [When relative to trigger event or previous email]
|
||||
|
||||
**Subject line:** [Primary option]
|
||||
**Subject line (A/B variant):** [Alternative to test]
|
||||
**Preview text:** [40–90 characters — adds context to the subject, doesn't repeat it]
|
||||
|
||||
**Body:**
|
||||
|
||||
[Full email copy — formatted with clear opening line, 2–3 body paragraphs, one primary CTA]
|
||||
|
||||
**CTA button text:** [3–6 words]
|
||||
**CTA destination:** [What page/action this should link to]
|
||||
|
||||
**Strategic note:** [Why this email does what it does — the psychological or strategic intent. 1–2 sentences.]
|
||||
|
||||
---
|
||||
|
||||
## Writing Rules
|
||||
|
||||
- Opening line must earn attention — no "Hi, welcome to [product]" openers
|
||||
- Each email has ONE primary CTA — never two competing asks
|
||||
- Keep paragraphs to 2–3 sentences maximum for mobile readability
|
||||
- Use "you" more than "we" — centre the reader, not the brand
|
||||
- Subject lines under 50 characters perform best on mobile — flag if going over
|
||||
- Preview text should add information the subject doesn't — never just repeat it
|
||||
- Every email should stand alone — assume some subscribers miss earlier emails
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Each email has a single clear CTA
|
||||
- [ ] Subject lines are under 50 characters (or flagged)
|
||||
- [ ] Preview text doesn't repeat the subject line
|
||||
- [ ] Opening line is specific and attention-earning
|
||||
- [ ] Sequence has logical narrative arc (doesn't feel like disconnected blasts)
|
||||
- [ ] Tone is consistent across all emails
|
||||
- [ ] Strategic notes explain the intent of each email
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a 3-email launch sequence for [product]"
|
||||
- "Build an onboarding email flow for [SaaS tool]"
|
||||
- "Create a drip campaign to nurture leads for [offer]"
|
||||
- "Write a re-engagement campaign for churned users"
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
name: hiring-rubric
|
||||
description: "Generate a structured interview scorecard and interview guide for any role. Use when asked to create a hiring rubric, interview scorecard, structured interview guide, or assessment criteria for a job. Produces a scorecard with competencies, behavioural questions, and scoring guidance."
|
||||
---
|
||||
|
||||
# Hiring Rubric Skill
|
||||
|
||||
This skill generates a complete structured interview scorecard and guide for any role. It reduces hiring bias, enables consistent evaluation across interviewers, and produces better hiring decisions.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Role title and level** (e.g. Senior Product Manager, Junior Data Analyst)
|
||||
- **Team or function** (e.g. Growth, Platform, Customer Success)
|
||||
- **Top 3–5 things this person needs to do well** (the actual job requirements, not just the JD)
|
||||
- **Interview format** (number of rounds, length of each)
|
||||
- **Any known gaps or risks to probe for** (optional)
|
||||
- **Company values or competencies** (optional — if provided, include as a competency section)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Interview Scorecard: [Role Title]
|
||||
**Level:** [Junior / Mid / Senior / Staff / Manager]
|
||||
**Team:** [Team name]
|
||||
**Created:** [Date]
|
||||
|
||||
---
|
||||
|
||||
## Scorecard Overview
|
||||
|
||||
Each competency is scored 1–4:
|
||||
- **4 — Strong Yes:** Clear evidence of exceptional ability. Hire signal.
|
||||
- **3 — Yes:** Solid evidence. Meets the bar for this role.
|
||||
- **2 — Lean No:** Some evidence but gaps that matter for this role.
|
||||
- **1 — No:** Little to no evidence. Clear miss.
|
||||
|
||||
**Hiring recommendation:**
|
||||
- 3+ competencies at 4, rest at 3 = Strong hire
|
||||
- Majority at 3, no 1s = Hire
|
||||
- Any 1s or majority 2s = No hire (unless specific mitigating factors)
|
||||
|
||||
---
|
||||
|
||||
## Competencies & Scoring
|
||||
|
||||
For each competency (generate 4–6 based on the role):
|
||||
|
||||
### Competency [N]: [Name — e.g. "Problem Structuring" / "Stakeholder Influence" / "Technical Depth"]
|
||||
|
||||
**Why this matters for this role:** [One sentence — connects to actual job requirements]
|
||||
|
||||
**What 4 looks like (Strong Yes):**
|
||||
[Specific, observable behaviours. "Proactively decomposed an ambiguous problem into a structured approach without prompting. Could articulate tradeoffs clearly and made assumptions explicit."]
|
||||
|
||||
**What 2 looks like (Lean No):**
|
||||
[Specific, observable behaviours at the lower end. "Could answer direct questions but struggled when the interviewer removed scaffolding. Required significant prompting to reach a structured answer."]
|
||||
|
||||
**Interview Questions (2–3 per competency):**
|
||||
|
||||
1. *[Behavioural STAR question — e.g. "Tell me about a time you had to make a decision with incomplete data."]*
|
||||
- **Good answer signals:** [What a strong answer includes]
|
||||
- **Weak answer signals:** [What a weak or scripted answer looks like]
|
||||
- **Follow-up probe:** [One follow-up to push deeper]
|
||||
|
||||
2. *[Situational or hypothetical question for this role]*
|
||||
- **Good answer signals:**
|
||||
- **Follow-up probe:**
|
||||
|
||||
---
|
||||
|
||||
## Role-Specific Technical Assessment (if applicable)
|
||||
|
||||
[If the role requires a technical screen, describe:]
|
||||
- **Format:** [Take-home / Live coding / Case study / Portfolio review]
|
||||
- **Duration:** [Time]
|
||||
- **What you're assessing:** [Specific skills]
|
||||
- **Scoring guidance:** [What distinguishes a 4 from a 2 on the technical component]
|
||||
|
||||
---
|
||||
|
||||
## Culture & Values Assessment
|
||||
|
||||
[2–3 values-based questions aligned to company values if provided, or general culture fit questions:]
|
||||
|
||||
1. *[Question]*
|
||||
- **What you're listening for:**
|
||||
|
||||
---
|
||||
|
||||
## Red Flags to Watch For
|
||||
|
||||
[5–7 specific red flags relevant to this role and level:]
|
||||
- [e.g. "Speaks only about individual work — no mention of collaboration or team impact"]
|
||||
- [e.g. "Can't give a specific example — pivots to hypotheticals when asked for real situations"]
|
||||
- [e.g. "For senior roles: no evidence of influencing without authority"]
|
||||
|
||||
---
|
||||
|
||||
## Interview Panel Guide
|
||||
|
||||
Suggest how to divide competencies across interview rounds to avoid repetition:
|
||||
|
||||
| Round | Interviewer | Competencies to Assess |
|
||||
|---|---|---|
|
||||
| 1 — Recruiter Screen | Recruiter | Motivation, career narrative, basics |
|
||||
| 2 — Hiring Manager | [Role] | [Assign 2 competencies] |
|
||||
| 3 — Peer Interview | [Role] | [Assign 2 competencies] |
|
||||
| 4 — Stakeholder | [Role] | [Assign 1–2 competencies + culture] |
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Scoring descriptions are observable (behaviours, not adjectives)
|
||||
- [ ] 4 vs 2 distinction is clear and specific
|
||||
- [ ] Questions have follow-up probes
|
||||
- [ ] Red flags are specific to this role and level
|
||||
- [ ] Panel guide avoids competency overlap between rounds
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Create a hiring rubric for a [role]"
|
||||
- "Build an interview scorecard for [job title]"
|
||||
- "Give me structured interview questions for a [level] [role]"
|
||||
- "We're hiring a [role] — help me build an assessment framework"
|
||||
@@ -0,0 +1,144 @@
|
||||
---
|
||||
name: incident-postmortem
|
||||
description: "Write a structured incident postmortem or post-incident review. Use when asked to write a postmortem, incident report, P1/P2 review, outage report, or RCA (root cause analysis). Generates a blameless postmortem with timeline, root cause, contributing factors, impact summary, and action items."
|
||||
---
|
||||
|
||||
# Incident Postmortem Skill
|
||||
|
||||
This skill produces a complete, blameless incident postmortem document following industry-standard format. Output is ready to share with engineering teams, leadership, and affected stakeholders.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Incident title / ID**
|
||||
- **Severity** (P1 / P2 / P3 or SEV1 / SEV2 / SEV3)
|
||||
- **Date and duration** of the incident
|
||||
- **What happened** (rough notes are fine — the skill will structure them)
|
||||
- **Services or systems affected**
|
||||
- **Customer impact** (how many users, what was degraded)
|
||||
- **How it was detected**
|
||||
- **How it was resolved**
|
||||
- **Initial thoughts on root cause**
|
||||
- **Action items already identified** (optional)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Incident Postmortem: [Incident Title]
|
||||
|
||||
**Incident ID:** [ID]
|
||||
**Severity:** [P1/P2/P3]
|
||||
**Date:** [Date]
|
||||
**Duration:** [Start time → Resolution time — total duration]
|
||||
**Status:** [Resolved / Monitoring / Ongoing]
|
||||
**Author:** [Leave blank for user to fill]
|
||||
**Last updated:** [Date]
|
||||
|
||||
---
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[3–5 sentences. Describe what happened, who was affected, and what was done to resolve it. Written for a non-technical stakeholder. No jargon. No blame.]
|
||||
|
||||
---
|
||||
|
||||
## Impact
|
||||
|
||||
| Dimension | Details |
|
||||
|---|---|
|
||||
| **Users affected** | [Number or percentage] |
|
||||
| **Services degraded** | [List affected services] |
|
||||
| **Business impact** | [Revenue, SLA breach, support tickets, etc. if known] |
|
||||
| **Duration** | [Total time from first detection to full resolution] |
|
||||
|
||||
---
|
||||
|
||||
## Timeline
|
||||
|
||||
List events in chronological order. Each entry: `[HH:MM UTC] — [What happened. Who did what. What changed.]`
|
||||
|
||||
Rules for timeline entries:
|
||||
- Use passive or system-focused language — avoid "X made a mistake"
|
||||
- Include: first symptom, detection, escalation, hypothesis tested, fix applied, confirmation of resolution
|
||||
- Note time between key events (e.g. "22 minutes between detection and escalation")
|
||||
|
||||
---
|
||||
|
||||
## Root Cause
|
||||
|
||||
**Primary root cause:** [One clear sentence. Technical but plain. "A misconfigured deployment config caused..."]
|
||||
|
||||
**Contributing factors:**
|
||||
- [Factor 1 — e.g. lack of canary deployment meant change hit 100% of traffic immediately]
|
||||
- [Factor 2 — e.g. alert threshold was set too high to catch the initial degradation]
|
||||
- [Factor 3 — add as many as are relevant]
|
||||
|
||||
**Why did our existing safeguards not prevent this?**
|
||||
[Honest paragraph explaining why monitoring, tests, or processes didn't catch this earlier. This is where blameless analysis matters most — focus on system gaps, not individual failures.]
|
||||
|
||||
---
|
||||
|
||||
## Detection
|
||||
|
||||
- **How was it first detected?** [Customer report / automated alert / internal monitoring / manual observation]
|
||||
- **Time from incident start to detection:** [X minutes]
|
||||
- **Should we have detected this faster?** [Yes / No — and why]
|
||||
|
||||
---
|
||||
|
||||
## Resolution
|
||||
|
||||
**What fixed it?** [Clear description of the actual fix — one paragraph]
|
||||
**Why did this work?** [Brief technical explanation]
|
||||
**Was there a temporary mitigation before full resolution?** [Yes/No — describe if yes]
|
||||
|
||||
---
|
||||
|
||||
## Action Items
|
||||
|
||||
| # | Action | Owner | Due Date | Priority |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Specific, testable action] | [Team or person] | [Date] | P1/P2/P3 |
|
||||
|
||||
Rules for action items:
|
||||
- Each action must be specific enough to close as "done" or "not done" — no vague items like "improve monitoring"
|
||||
- Distinguish between: **Prevent recurrence** (fix the root cause), **Improve detection** (catch it faster next time), **Improve response** (resolve it faster next time)
|
||||
- Assign a real owner — not "team" or "TBD" if avoidable
|
||||
- Flag P1 actions as items that block the incident from being marked fully closed
|
||||
|
||||
---
|
||||
|
||||
## What Went Well
|
||||
|
||||
[3–5 honest observations about the response. Include: fast collaboration, good runbooks used, effective escalation, clear communication. This section builds team confidence and reinforces good habits.]
|
||||
|
||||
---
|
||||
|
||||
## Lessons Learned
|
||||
|
||||
[3–5 key insights from this incident that are worth sharing beyond this team. Write these as transferable lessons — e.g. "Our runbook for database failover didn't account for read-replica lag. All runbooks involving database failover should be reviewed."]
|
||||
|
||||
---
|
||||
|
||||
## Communication Log
|
||||
|
||||
[Optional — list external communications sent: status page updates, customer emails, support responses. Include timestamps.]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Timeline has no blame-focused language
|
||||
- [ ] Root cause is specific (not "human error")
|
||||
- [ ] Contributing factors explain the systemic gaps
|
||||
- [ ] Every action item has an owner and due date
|
||||
- [ ] "What went well" section is genuine, not token
|
||||
- [ ] Executive summary is readable by non-technical leadership
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a postmortem for the [incident name] outage"
|
||||
- "Help me write a P1 incident report"
|
||||
- "Generate an RCA document for [service] going down on [date]"
|
||||
- "Draft a blameless postmortem from these notes: [paste notes]"
|
||||
@@ -0,0 +1,127 @@
|
||||
---
|
||||
name: investor-update
|
||||
description: "Write a structured monthly or quarterly investor update. Use when asked to write an investor update, investor newsletter, board update, or startup progress report for investors. Produces a clear, credible update with highlights, metrics, challenges, and asks — in the format investors actually want to read."
|
||||
---
|
||||
|
||||
# Investor Update Skill
|
||||
|
||||
This skill writes a complete investor update — structured for clarity, honest about challenges, and specific about asks. Output follows the format preferred by most early-stage and growth investors.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Company name and stage** (Seed / Series A / Series B / etc.)
|
||||
- **Period covered** (month or quarter)
|
||||
- **Key metrics this period** (revenue, MRR, users, churn, burn, runway — whatever's relevant)
|
||||
- **Biggest wins**
|
||||
- **Biggest challenges or misses**
|
||||
- **Specific asks from investors** (intros, advice, talent, partnerships)
|
||||
- **What's coming next period**
|
||||
- **Tone** (formal / conversational — most investors prefer conversational)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
**[Company Name] — [Month/Quarter] Update**
|
||||
*[Date]*
|
||||
|
||||
---
|
||||
|
||||
Hi [Investor names or "all"],
|
||||
|
||||
[One or two sentence opener — a specific highlight or honest framing of the period. Don't open with "Hope you're well." Open with the most important thing that happened.]
|
||||
|
||||
---
|
||||
|
||||
## The Numbers
|
||||
|
||||
| Metric | This Period | Last Period | Change |
|
||||
|---|---|---|---|
|
||||
| [MRR / ARR] | [Value] | [Value] | [+/- %] |
|
||||
| [Active users / customers] | | | |
|
||||
| [Churn rate] | | | |
|
||||
| [Burn rate] | | | |
|
||||
| [Runway] | | | |
|
||||
| [Other key metric] | | | |
|
||||
|
||||
[1–2 sentences of narrative on the numbers — what's the story behind the movement? Don't just repeat the table.]
|
||||
|
||||
---
|
||||
|
||||
## Highlights
|
||||
|
||||
**[Highlight 1 — 4–6 word title]**
|
||||
[2–4 sentences. What happened. Why it matters. Be specific — name the customer, the number, the milestone.]
|
||||
|
||||
**[Highlight 2]**
|
||||
[2–4 sentences]
|
||||
|
||||
**[Highlight 3 — optional]**
|
||||
|
||||
---
|
||||
|
||||
## Challenges
|
||||
|
||||
[This section is what separates trustworthy updates from self-promotional ones. Investors know you have challenges. Being direct builds trust.]
|
||||
|
||||
**[Challenge 1]**
|
||||
[2–4 sentences. What the problem is. What you've tried. What you're doing about it. Don't spin — investors see through it.]
|
||||
|
||||
**[Challenge 2 — if applicable]**
|
||||
|
||||
---
|
||||
|
||||
## Focus for Next [Month/Quarter]
|
||||
|
||||
[3–5 bullet points. What you're concentrating on next period and why. Keep it tight — not an exhaustive roadmap.]
|
||||
|
||||
- [Priority 1]
|
||||
- [Priority 2]
|
||||
- [Priority 3]
|
||||
|
||||
---
|
||||
|
||||
## Asks
|
||||
|
||||
[Be specific. "Let me know if you can help" is not an ask. These should be actionable items an investor can act on immediately.]
|
||||
|
||||
1. **[Ask type: e.g. Intro]** — [Specific request. e.g. "Looking for an intro to procurement leads at mid-market SaaS companies. Happy to share a warm intro note."]
|
||||
2. **[Ask type: e.g. Advice]** — [Specific question you want input on]
|
||||
3. **[Ask type: e.g. Talent]** — [Specific hire you're looking for — title, key requirements]
|
||||
|
||||
---
|
||||
|
||||
[Closing line — 1 sentence. Forward-looking or a genuine thanks. Not "as always, let me know if you have questions."]
|
||||
|
||||
[Signature]
|
||||
[Name]
|
||||
[Company]
|
||||
[One way to reply — email / Calendly / reply to this thread]
|
||||
|
||||
---
|
||||
|
||||
## Writing Rules
|
||||
|
||||
- Updates should take an investor 3–4 minutes to read. If it's longer, trim it.
|
||||
- Never lead with process ("This month we focused on...") — lead with outcomes
|
||||
- Challenges section must be honest. A missing challenges section signals the founder isn't self-aware or isn't being transparent.
|
||||
- Metrics table must include comparison to last period — a number without context is meaningless
|
||||
- Asks must be specific enough that an investor knows within 5 seconds if they can help
|
||||
- No jargon or buzzwords ("synergies," "crushing it," "hockey stick") — plain language only
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Opens with a specific highlight or honest framing (not a pleasantry)
|
||||
- [ ] Numbers include period-over-period comparison
|
||||
- [ ] Challenges section is present and honest
|
||||
- [ ] Asks are specific and actionable
|
||||
- [ ] Total length is skimmable in 3–4 minutes
|
||||
- [ ] No spin or buzzwords
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write an investor update for [month/quarter]"
|
||||
- "Draft a monthly update for our investors based on these notes: [paste notes]"
|
||||
- "Help me write a board update for Q[N]"
|
||||
- "Write our Series A investor newsletter"
|
||||
@@ -0,0 +1,128 @@
|
||||
---
|
||||
name: job-application
|
||||
description: "Tailor a CV and cover letter to a specific job description. Use when asked to write a cover letter, tailor a CV or resume, optimise for ATS, match a job description, or prepare a job application. Produces an ATS-optimised tailored CV summary and a personalised cover letter."
|
||||
---
|
||||
|
||||
# Job Application Skill
|
||||
|
||||
This skill tailors a CV and cover letter to a specific job description — optimising for ATS keyword matching while keeping the writing human and compelling. It also flags gaps between the candidate's profile and the role requirements.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Job description** (paste in full)
|
||||
- **Current CV / resume** (paste or describe key experience, roles, and skills)
|
||||
- **The specific thing that excites them about this role** (used in the cover letter — must be genuine)
|
||||
- **Any particular strengths to emphasise** (optional)
|
||||
- **Any gaps they're worried about** (optional — helps address them proactively)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
## Part 1: JD Analysis
|
||||
|
||||
Before writing anything, analyse the job description and output:
|
||||
|
||||
### Must-Have Requirements
|
||||
[List explicit requirements from the JD — qualifications, years of experience, specific skills]
|
||||
|
||||
### Key Themes in the JD
|
||||
[3–5 themes that repeat or are emphasised — these are the keywords and priorities the hiring manager cares about most]
|
||||
|
||||
### ATS Keywords to Include
|
||||
[List 10–15 specific keywords and phrases from the JD that should appear in the CV and cover letter. Include: tools, methodologies, job titles, skills]
|
||||
|
||||
### Gaps Assessment
|
||||
[Honest comparison between the candidate's profile and the JD requirements. Flag: "Strong match" / "Partial match — can be positioned as X" / "Gap — address in cover letter or don't apply"]
|
||||
|
||||
---
|
||||
|
||||
## Part 2: Tailored CV Summary / Profile Section
|
||||
|
||||
Rewrite or create the candidate's CV summary/profile section (the 3–5 lines at the top of a CV) specifically for this role:
|
||||
|
||||
**Rules:**
|
||||
- Open with the job title or a near-match (ATS reward)
|
||||
- Include 2–3 keywords from the JD naturally
|
||||
- Reference years of experience in the relevant area
|
||||
- End with a forward-looking line connecting their background to what this role needs
|
||||
- Keep to 60–80 words maximum
|
||||
|
||||
**Tailored CV Summary:**
|
||||
[Write the summary]
|
||||
|
||||
---
|
||||
|
||||
## Part 3: Experience Bullet Point Rewrites
|
||||
|
||||
For the 2–3 most relevant roles on the CV, suggest how to reframe existing bullet points to better match this JD:
|
||||
|
||||
**[Role Title] at [Company]**
|
||||
|
||||
| Original Bullet | Tailored Version | Why |
|
||||
|---|---|---|
|
||||
| [Candidate's original text] | [Improved version with JD keywords and stronger impact framing] | [Brief note on what changed] |
|
||||
|
||||
**Rules for bullet point rewrites:**
|
||||
- Lead with an action verb
|
||||
- Include a quantified outcome where possible (%, £, time saved, users impacted)
|
||||
- Weave in JD keywords naturally — not forced
|
||||
- Keep to one line (2 max)
|
||||
|
||||
---
|
||||
|
||||
## Part 4: Cover Letter
|
||||
|
||||
**Format:** 3 paragraphs + closing. Target: 250–350 words. Anything longer won't be read.
|
||||
|
||||
---
|
||||
|
||||
[Hiring Manager's name if known, otherwise "Hiring Team"]
|
||||
|
||||
**Paragraph 1 — The Hook (Why this role, specifically)**
|
||||
[2–4 sentences. Reference something specific about the company or role — not generic enthusiasm. The candidate's genuine reason for applying goes here. This is what makes it human. Generic openers like "I am writing to apply for..." are filtered out mentally within 3 seconds.]
|
||||
|
||||
**Paragraph 2 — The Evidence (Why them)**
|
||||
[3–5 sentences. 2–3 specific examples from their background that directly address the JD's key themes. Use the language of the JD. Include at least one quantified achievement. Don't list everything — pick the 2–3 strongest matches and go deep, not broad.]
|
||||
|
||||
**Paragraph 3 — The Forward Bridge (Why now)**
|
||||
[2–3 sentences. Connect their trajectory to this role. Why is this the logical next step? What do they want to learn or build that this role enables? This should feel like the natural continuation of their career, not just "I want a new challenge."]
|
||||
|
||||
---
|
||||
|
||||
I'd welcome the chance to discuss how my background could contribute to [Company/Team]. Thank you for your time.
|
||||
|
||||
[Name]
|
||||
[Email] | [LinkedIn URL] | [Location if relevant]
|
||||
|
||||
---
|
||||
|
||||
## Part 5: Application Checklist
|
||||
|
||||
Before submitting:
|
||||
- [ ] CV summary updated with tailored version above
|
||||
- [ ] ATS keywords appear in CV body (not just summary)
|
||||
- [ ] Cover letter is under 400 words
|
||||
- [ ] Company name is spelled correctly throughout (sounds obvious — it happens)
|
||||
- [ ] No generic phrases: "passionate about," "results-driven," "team player" without evidence
|
||||
- [ ] LinkedIn profile updated to match CV (recruiters cross-check)
|
||||
- [ ] Role title in subject line if emailing directly
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] JD analysis completed before writing (not skipped)
|
||||
- [ ] ATS keywords are integrated naturally (not stuffed)
|
||||
- [ ] Cover letter opens with something specific (not a generic opener)
|
||||
- [ ] Paragraph 2 includes at least one quantified achievement
|
||||
- [ ] Cover letter is 250–350 words
|
||||
- [ ] Gaps are either addressed or strategically omitted
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Help me apply for this job: [paste JD]"
|
||||
- "Tailor my CV for this role: [paste JD + CV]"
|
||||
- "Write a cover letter for [role] at [company]"
|
||||
- "Optimise my application for ATS for this job description"
|
||||
@@ -0,0 +1,103 @@
|
||||
---
|
||||
name: metrics-framework
|
||||
description: "Build a metrics framework for any product, team, or business. Use when asked for a metrics tree, KPI framework, North Star metric, AARRR funnel, HEART framework, or OKR metrics. Produces a structured metrics hierarchy from North Star down to leading indicators, with measurement guidance."
|
||||
---
|
||||
|
||||
# Metrics Framework Skill
|
||||
|
||||
This skill builds a complete metrics framework tailored to a product or business. It connects the North Star metric to actionable leading indicators, making it clear which metrics to track, which to optimise, and how they relate to each other.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Product or business description** (one paragraph is enough)
|
||||
- **Business model** (SaaS / Marketplace / E-commerce / Consumer app / B2B / Other)
|
||||
- **Stage** (Pre-PMF / Growth / Scale / Mature)
|
||||
- **Framework preference** (if they have one): North Star + Metric Tree / AARRR / HEART / OKRs / Custom
|
||||
- **Primary goal this quarter** (e.g. grow activation, reduce churn, increase revenue)
|
||||
|
||||
If no framework preference is given, recommend the best fit based on stage and business model.
|
||||
|
||||
## Output Structure
|
||||
|
||||
### 1. Framework Recommendation (if not specified)
|
||||
|
||||
Explain in 2–3 sentences why you're recommending this framework for their context.
|
||||
|
||||
---
|
||||
|
||||
### 2. North Star Metric
|
||||
|
||||
**[Metric Name]:** [Definition — exactly what is measured and how]
|
||||
|
||||
**Why this is the right North Star for this business:**
|
||||
[2–3 sentences. It should reflect customer value delivered, not just revenue or activity. Explain what behaviour it captures and why maximising it correlates with long-term business health.]
|
||||
|
||||
**How to measure it:** [Formula or data source]
|
||||
**Current baseline:** [Leave as [ADD BASELINE] for user to fill]
|
||||
**Target:** [Leave as [ADD TARGET] for user to fill]
|
||||
|
||||
---
|
||||
|
||||
### 3. Metric Tree
|
||||
|
||||
Show how supporting metrics roll up to the North Star. Format as a hierarchy:
|
||||
|
||||
```
|
||||
[North Star Metric]
|
||||
├── [Driver 1: e.g. Acquisition]
|
||||
│ ├── [L2 metric: e.g. Organic signups / week]
|
||||
│ └── [L2 metric: e.g. Paid CAC by channel]
|
||||
├── [Driver 2: e.g. Activation]
|
||||
│ ├── [L2 metric: e.g. % users completing onboarding within 7 days]
|
||||
│ └── [L2 metric: e.g. Time to first value action]
|
||||
└── [Driver 3: e.g. Retention]
|
||||
├── [L2 metric: e.g. Day 30 retention rate]
|
||||
└── [L2 metric: e.g. Feature adoption depth]
|
||||
```
|
||||
|
||||
For each L2 metric, provide:
|
||||
- **Definition:** [What exactly is measured]
|
||||
- **Why it matters:** [How it connects to the North Star]
|
||||
- **Leading or lagging?** [Leading = predictive / Lagging = outcome]
|
||||
- **How to measure:** [Data source or calculation]
|
||||
|
||||
---
|
||||
|
||||
### 4. Counter-Metrics
|
||||
|
||||
[2–3 metrics to watch that prevent optimising the North Star in ways that damage the business. E.g. "If we optimise for signups, we need to watch spam account rate. If we optimise for engagement, we need to watch support ticket volume."]
|
||||
|
||||
---
|
||||
|
||||
### 5. Dashboard Recommendation
|
||||
|
||||
Suggest a 3-tier dashboard structure:
|
||||
- **Exec view (weekly):** [3–5 metrics — outcomes only]
|
||||
- **Team view (daily):** [7–10 metrics — leading indicators + outputs]
|
||||
- **Diagnostic view (on demand):** [Metrics to drill into when something looks wrong]
|
||||
|
||||
---
|
||||
|
||||
### 6. Metric Health Check Questions
|
||||
|
||||
[5 questions the team should ask in their weekly metrics review to turn numbers into insights. e.g. "Is our activation rate improving while retention stays flat? That suggests onboarding quality issue, not a product-market fit problem."]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] North Star reflects customer value, not just business activity
|
||||
- [ ] Metric tree has 3–4 distinct drivers (not all one category)
|
||||
- [ ] Each L2 metric is classified as leading or lagging
|
||||
- [ ] Counter-metrics are included to prevent perverse incentives
|
||||
- [ ] Dashboard tiers are tailored to the product stage
|
||||
- [ ] All metric definitions are unambiguous (formula or clear description)
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Build a metrics framework for [product]"
|
||||
- "What should our North Star metric be?"
|
||||
- "Create a KPI tree for [business]"
|
||||
- "Give me an AARRR breakdown for [product]"
|
||||
- "What metrics should our [team type] team track?"
|
||||
@@ -0,0 +1,116 @@
|
||||
---
|
||||
name: performance-review
|
||||
description: "Write structured, balanced performance reviews from bullet-point inputs. Use when asked to write a performance review, self-assessment, peer review, 360 feedback, or manager evaluation. Produces a complete, fair, professionally written review covering achievements, areas for growth, and development goals."
|
||||
---
|
||||
|
||||
# Performance Review Skill
|
||||
|
||||
This skill turns rough notes, bullet points, or bullet-point memories into a complete, professionally written performance review. Output is ready to submit or use as a strong first draft.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Review type** (Self-assessment / Manager review / Peer/360 / Upward feedback)
|
||||
- **Review period** (e.g. H1 2025, Q2 2025, Annual)
|
||||
- **Name of person being reviewed** (or "myself" for self-assessment)
|
||||
- **Role / level**
|
||||
- **Key achievements or notable work** (rough notes are fine)
|
||||
- **Areas where they struggled or could improve** (be honest — reviews without growth areas aren't credible)
|
||||
- **Key projects or deliverables from the period**
|
||||
- **Company values or competencies to assess against** (optional — if provided, structure the review around them)
|
||||
- **Overall rating/recommendation** (if the form requires one)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Performance Review: [Name]
|
||||
**Role:** [Title / Level]
|
||||
**Review period:** [Period]
|
||||
**Review type:** [Manager / Self / Peer / Upward]
|
||||
**Reviewed by:** [If known]
|
||||
|
||||
---
|
||||
|
||||
## Overall Summary
|
||||
|
||||
[3–5 sentences. High-level characterisation of the period. Acknowledge standout contributions. Be specific — use project names and outcomes, not vague praise. For self-assessments, this should reflect honestly on the period without underselling or overselling.]
|
||||
|
||||
---
|
||||
|
||||
## Achievements & Impact
|
||||
|
||||
[3–5 achievements, each structured as:]
|
||||
|
||||
**[Achievement title — specific and concrete]**
|
||||
[2–4 sentences. What was the context? What did [name] do specifically? What was the measurable or observable outcome? Avoid generic praise — every sentence should be something only this person could have done.]
|
||||
|
||||
---
|
||||
|
||||
## Strengths Demonstrated
|
||||
|
||||
[3–4 bullet points. Each bullet = one strength, with one concrete example from the review period. No abstract traits without evidence.]
|
||||
|
||||
- **[Strength]:** [Example — specific project or behaviour that demonstrated this]
|
||||
|
||||
---
|
||||
|
||||
## Areas for Growth
|
||||
|
||||
[2–3 areas. Be direct and constructive — not vague. Frame as "opportunity to develop" not "failure." Each should include:]
|
||||
|
||||
**[Area name]**
|
||||
- **Observed pattern:** [What was noticed — be specific, not personal]
|
||||
- **Why it matters:** [Impact on team, output, or career progression]
|
||||
- **Suggested development:** [One concrete action — e.g. "Take on [X] responsibility next half" or "Shadow [role] on [process]"]
|
||||
|
||||
---
|
||||
|
||||
## Development Goals for Next Period
|
||||
|
||||
[2–3 goals. Format each as:]
|
||||
|
||||
**Goal [N]:** [Clear, outcome-oriented goal]
|
||||
- **Why:** [Connection to growth areas or career aspirations]
|
||||
- **How to measure:** [What "done" looks like]
|
||||
- **Support needed:** [Resources, training, or manager input required]
|
||||
|
||||
---
|
||||
|
||||
## Competency Ratings (if framework provided)
|
||||
|
||||
| Competency | Rating | Evidence |
|
||||
|---|---|---|
|
||||
| [Competency from company framework] | [Exceeds / Meets / Developing / Below] | [One-sentence example] |
|
||||
|
||||
---
|
||||
|
||||
## Closing Recommendation
|
||||
|
||||
[2–3 sentences. For manager reviews: overall assessment and any promotion/compensation recommendation. For self-assessments: what you're asking for or committing to. For peer reviews: one sentence on what it's like to work with this person.]
|
||||
|
||||
---
|
||||
|
||||
## Writing Rules
|
||||
|
||||
- Never use vague phrases: "strong communicator," "team player," "hardworking" — always back with evidence
|
||||
- Growth areas must be honest — reviewers who only write positives lose credibility and help no one
|
||||
- Use third person for manager/peer reviews, first person for self-assessments
|
||||
- Avoid jargon — "drove alignment" and "leveraged synergies" are meaningless. Use plain language.
|
||||
- If the user gives sparse notes, ask for one concrete example per achievement before writing
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Every achievement includes a specific outcome (not just activity)
|
||||
- [ ] Strengths have concrete examples from the review period
|
||||
- [ ] Growth areas are honest and constructive (not softened to meaninglessness)
|
||||
- [ ] Development goals are measurable
|
||||
- [ ] No vague phrases without evidence
|
||||
- [ ] Tone is professional and fair throughout
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a performance review for [name] based on these notes: [paste notes]"
|
||||
- "Help me write my self-assessment for [period]"
|
||||
- "Draft a peer review for my colleague who did [description]"
|
||||
- "Turn these bullet points into a full performance review: [paste bullets]"
|
||||
@@ -0,0 +1,143 @@
|
||||
---
|
||||
name: sql-query-explainer
|
||||
description: "Explain, optimise, or translate SQL queries into plain language. Use when asked to explain a SQL query, optimise slow SQL, write a data dictionary, translate SQL to plain English for non-technical stakeholders, or review a query for correctness and performance. Works across PostgreSQL, MySQL, BigQuery, Snowflake, and standard SQL."
|
||||
---
|
||||
|
||||
# SQL Query Explainer Skill
|
||||
|
||||
This skill explains SQL queries in plain language, identifies optimisation opportunities, and helps communicate data logic to non-technical stakeholders. It also writes and documents new queries from natural language descriptions.
|
||||
|
||||
## Modes
|
||||
|
||||
Detect which mode the user needs based on their request:
|
||||
|
||||
1. **Explain** — Translate existing SQL into plain English
|
||||
2. **Optimise** — Review SQL for performance issues and suggest improvements
|
||||
3. **Write** — Generate SQL from a natural language description
|
||||
4. **Document** — Produce a data dictionary or query documentation
|
||||
|
||||
---
|
||||
|
||||
## Mode 1: Explain
|
||||
|
||||
When given a SQL query, produce:
|
||||
|
||||
### Plain English Summary
|
||||
[1–3 sentences. What does this query do? What data does it return? Write as if explaining to a business analyst, not a developer.]
|
||||
|
||||
### Step-by-Step Walkthrough
|
||||
|
||||
Break the query into logical sections. For each section:
|
||||
- Quote the SQL clause
|
||||
- Explain what it does in plain English
|
||||
- Flag any complexity (e.g. window functions, subqueries, CTEs)
|
||||
|
||||
### What the Result Looks Like
|
||||
|
||||
[Describe the shape of the output: "Returns one row per user, with columns for X, Y, Z. Ordered by [field] descending."]
|
||||
|
||||
### Potential Issues to Flag
|
||||
|
||||
- [Gotchas, edge cases, or implicit assumptions in this query]
|
||||
- [e.g. "This will include NULLs in the user_id column if the LEFT JOIN finds no match"]
|
||||
|
||||
---
|
||||
|
||||
## Mode 2: Optimise
|
||||
|
||||
When asked to optimise a query, produce:
|
||||
|
||||
### Performance Assessment
|
||||
|
||||
Rate overall: 🟢 Well-optimised / 🟡 Some improvements possible / 🔴 Significant issues
|
||||
|
||||
### Issues Found
|
||||
|
||||
For each issue:
|
||||
|
||||
**Issue [N]: [Short name, e.g. "Missing index on join column"]**
|
||||
- **What it is:** [Plain explanation]
|
||||
- **Why it matters:** [Performance impact — e.g. "Full table scan on a 10M row table"]
|
||||
- **Fix:**
|
||||
```sql
|
||||
-- Before
|
||||
[original snippet]
|
||||
|
||||
-- After
|
||||
[improved snippet]
|
||||
```
|
||||
- **Expected improvement:** [Estimate if possible]
|
||||
|
||||
### Optimisation Checklist
|
||||
|
||||
- [ ] SELECT * used? (Replace with specific columns)
|
||||
- [ ] Implicit type conversions on JOIN/WHERE columns?
|
||||
- [ ] Missing indexes on JOIN or WHERE columns?
|
||||
- [ ] N+1 patterns (queries inside loops)?
|
||||
- [ ] DISTINCT used where GROUP BY would be faster?
|
||||
- [ ] Window functions used where a subquery would be clearer/faster?
|
||||
- [ ] CTEs re-used or materialised unnecessarily?
|
||||
- [ ] Large IN() lists that could use a JOIN instead?
|
||||
|
||||
---
|
||||
|
||||
## Mode 3: Write
|
||||
|
||||
When given a natural language description, generate the SQL query and then explain it using Mode 1.
|
||||
|
||||
Ask the user to confirm:
|
||||
- **Database/dialect** (PostgreSQL / MySQL / BigQuery / Snowflake / SQLite / Standard SQL)
|
||||
- **Table and column names** (if known; otherwise use descriptive placeholder names like `users`, `orders`, `user_id`)
|
||||
- **Any filters, sorting, or aggregation requirements**
|
||||
|
||||
Produce:
|
||||
1. The SQL query with inline comments
|
||||
2. Plain English explanation (Mode 1 format)
|
||||
|
||||
---
|
||||
|
||||
## Mode 4: Document
|
||||
|
||||
When asked to create documentation for a query or table:
|
||||
|
||||
### Query Documentation
|
||||
|
||||
```
|
||||
Query: [Name]
|
||||
Purpose: [One sentence — what business question this answers]
|
||||
Author: [If provided]
|
||||
Last reviewed: [If provided]
|
||||
|
||||
Inputs:
|
||||
- Table: [table_name] — [what it contains]
|
||||
- Filter: [any WHERE conditions and their business meaning]
|
||||
|
||||
Output columns:
|
||||
| Column | Type | Description |
|
||||
|--------|------|-------------|
|
||||
| [name] | [type] | [plain English description] |
|
||||
|
||||
Assumptions:
|
||||
- [Any implicit assumptions the query makes]
|
||||
|
||||
Known limitations:
|
||||
- [Edge cases not handled, data quality dependencies, etc.]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Plain English explanation avoids SQL jargon
|
||||
- [ ] Optimisation suggestions include before/after SQL
|
||||
- [ ] Written queries include inline comments
|
||||
- [ ] Output shape is described (columns, row grain, ordering)
|
||||
- [ ] Dialect-specific syntax is flagged when non-standard
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Explain this SQL query: [paste query]"
|
||||
- "Optimise this slow query: [paste query]"
|
||||
- "Write a SQL query that [natural language description]"
|
||||
- "Document this query for my non-technical stakeholders"
|
||||
- "Why is this query returning unexpected results?"
|
||||
@@ -0,0 +1,144 @@
|
||||
---
|
||||
name: team-offsite-planner
|
||||
description: "Plan a team offsite from goals to full agenda. Use when asked to plan a team offsite, away day, team retreat, quarterly offsite, or team-building event. Produces a full agenda, session designs, facilitation notes, and logistics checklist."
|
||||
---
|
||||
|
||||
# Team Offsite Planner Skill
|
||||
|
||||
This skill designs a complete team offsite — from goals to minute-by-minute agenda, including session facilitation guides and a logistics checklist.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Team size** (number of people)
|
||||
- **Duration** (half day / full day / 1.5 days / 2 days)
|
||||
- **Primary goal** (e.g. Q3 planning / team bonding / strategy alignment / retrospective / all of the above)
|
||||
- **Location type** (office / external venue / remote-first hybrid)
|
||||
- **Key topics to cover** (if known)
|
||||
- **Any constraints** (budget, accessibility, team dynamics to be aware of)
|
||||
- **Remote attendees?** (Yes/No — affects session design significantly)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# Team Offsite Plan: [Team Name]
|
||||
**Date:** [TBD or as provided]
|
||||
**Duration:** [X days]
|
||||
**Attendees:** [X people]
|
||||
**Goal:** [Primary goal from inputs]
|
||||
|
||||
---
|
||||
|
||||
## 1. Offsite Objectives
|
||||
|
||||
State 3–5 clear objectives. Each objective should be answerable at the end of the offsite — the team should be able to say "we achieved this" or "we didn't."
|
||||
|
||||
- By the end of this offsite, we will have [specific outcome].
|
||||
|
||||
---
|
||||
|
||||
## 2. Full Agenda
|
||||
|
||||
For each time block, produce:
|
||||
|
||||
**[Time] — [Session Title]** *(Duration: X min)*
|
||||
- **Type:** [Opening / Working session / Workshop / Decision / Social / Break]
|
||||
- **Owner:** [Who runs this — Facilitator / Specific person / Group]
|
||||
- **Goal:** [What this session produces or achieves]
|
||||
- **Format:** [How it runs — e.g. "Whole group discussion", "4 breakout groups of 3", "Silent async doc read + Q&A"]
|
||||
- **Output:** [What leaves the room — e.g. "Agreed list of H2 priorities", "Updated team norms doc", "Go/No-go decision on X"]
|
||||
|
||||
---
|
||||
|
||||
**Day 1 Example Structure:**
|
||||
|
||||
| Time | Session | Duration | Type |
|
||||
|---|---|---|---|
|
||||
| 09:00 | Arrival & coffee | 30 min | Social |
|
||||
| 09:30 | Opening & objectives | 20 min | Framing |
|
||||
| 09:50 | [Strategic session 1] | 90 min | Working |
|
||||
| 11:20 | Break | 15 min | — |
|
||||
| 11:35 | [Workshop or decision] | 75 min | Workshop |
|
||||
| 13:00 | Lunch | 60 min | Social |
|
||||
| 14:00 | [Working session 2] | 90 min | Working |
|
||||
| 15:30 | Break | 15 min | — |
|
||||
| 15:45 | [Team session / retro] | 60 min | Team |
|
||||
| 16:45 | Day close — commitments | 30 min | Close |
|
||||
| 17:15 | Social / dinner | Open | Social |
|
||||
|
||||
Adapt timing to duration and goals.
|
||||
|
||||
---
|
||||
|
||||
## 3. Session Facilitation Notes
|
||||
|
||||
For each working session, provide:
|
||||
|
||||
### Session: [Name]
|
||||
|
||||
**Time needed:** [X minutes]
|
||||
**Materials:** [Post-its, Miro board, printed docs, etc.]
|
||||
|
||||
**Step-by-step facilitation:**
|
||||
1. [What the facilitator says/does to open — 2–3 min]
|
||||
2. [Core activity — describe in detail]
|
||||
3. [How to gather/consolidate output]
|
||||
4. [Closing move — decision, vote, or commitment]
|
||||
|
||||
**If the group gets stuck:** [One facilitation technique to unstick — e.g. "Dot voting if no consensus", "Parking lot for off-topic items"]
|
||||
|
||||
**Watch out for:** [Common pitfall for this session type — e.g. "The loudest voices dominating. Use silent individual writing first."]
|
||||
|
||||
---
|
||||
|
||||
## 4. Pre-Offsite Prep Checklist
|
||||
|
||||
For the organiser to complete before the offsite:
|
||||
|
||||
**2 weeks before:**
|
||||
- [ ] Book venue and confirm capacity and AV
|
||||
- [ ] Send calendar invites with travel info
|
||||
- [ ] Share pre-read or pre-work doc (if any)
|
||||
- [ ] Confirm dietary requirements and accessibility needs
|
||||
|
||||
**1 week before:**
|
||||
- [ ] Send agenda to all attendees
|
||||
- [ ] Assign session owners and brief them
|
||||
- [ ] Prepare materials (print, Miro boards, name cards)
|
||||
- [ ] Confirm remote setup if hybrid
|
||||
|
||||
**Day before:**
|
||||
- [ ] Test AV and video conferencing setup
|
||||
- [ ] Prepare room layout
|
||||
- [ ] Confirm headcount and catering
|
||||
|
||||
---
|
||||
|
||||
## 5. Post-Offsite Actions
|
||||
|
||||
Template for the summary document to send within 48 hours:
|
||||
|
||||
**[Team] Offsite Summary — [Date]**
|
||||
- **Decisions made:** [List]
|
||||
- **Actions and owners:** [Table: Action | Owner | Due date]
|
||||
- **Parking lot items:** [Topics deferred for follow-up]
|
||||
- **Next check-in:** [When the team will review offsite commitments]
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Objectives are measurable at end of day
|
||||
- [ ] Sessions alternate between high-energy and reflective
|
||||
- [ ] No single session runs longer than 90 minutes without a break
|
||||
- [ ] Remote attendees have equal participation in working sessions
|
||||
- [ ] Each working session has a stated output
|
||||
- [ ] Agenda has social/informal time built in
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Plan a 1-day offsite for my team of [size]"
|
||||
- "Design a 2-day team retreat for [goal]"
|
||||
- "Build an agenda for our Q[N] team planning day"
|
||||
- "Help me plan a hybrid offsite for [team size] people"
|
||||
@@ -0,0 +1,160 @@
|
||||
---
|
||||
name: ux-research-plan
|
||||
description: "Create a structured UX research plan for any product question or feature. Use when asked to write a research plan, design a user study, create a discussion guide, write screener questions, or plan usability testing. Produces a full research plan with objectives, methodology, screener, discussion guide, and synthesis framework."
|
||||
---
|
||||
|
||||
# UX Research Plan Skill
|
||||
|
||||
This skill creates a complete, ready-to-execute UX research plan. Output covers everything from research objectives to screener questions, discussion guide, and synthesis framework.
|
||||
|
||||
## Required Inputs
|
||||
|
||||
Ask the user for these if not provided:
|
||||
- **Research question** (what decision will this research inform?)
|
||||
- **Product area or feature** being researched
|
||||
- **Research type** (Generative / Evaluative / Usability testing / Diary study / Survey)
|
||||
- **Stage** (Discovery / Concept validation / Prototype testing / Live product)
|
||||
- **Target participants** (role, demographics, behaviour — who should we talk to?)
|
||||
- **Timeline and number of sessions**
|
||||
- **Existing assumptions or hypotheses** (optional but valuable)
|
||||
|
||||
## Output Structure
|
||||
|
||||
---
|
||||
|
||||
# UX Research Plan: [Study Title]
|
||||
**Product area:** [Area]
|
||||
**Research type:** [Type]
|
||||
**Date:** [Timeline]
|
||||
**Researcher:** [Leave for user]
|
||||
|
||||
---
|
||||
|
||||
## 1. Research Objectives
|
||||
|
||||
State 2–4 clear research objectives. Each objective should map to a decision that will be made differently depending on what you find.
|
||||
|
||||
**Objective [N]:** Understand [specific thing] so we can [decision this informs].
|
||||
|
||||
---
|
||||
|
||||
## 2. Research Questions
|
||||
|
||||
[5–8 questions — the actual questions you want research to answer. These are not the interview questions; they're the knowledge gaps. Organised under each objective.]
|
||||
|
||||
**Objective 1:**
|
||||
- RQ1.1: [Research question]
|
||||
- RQ1.2: [Research question]
|
||||
|
||||
---
|
||||
|
||||
## 3. Methodology & Rationale
|
||||
|
||||
**Method chosen:** [e.g. Semi-structured interviews / Usability testing / Concept testing]
|
||||
|
||||
**Why this method:**
|
||||
[2–3 sentences. Match method to research type. If evaluative: usability testing. If generative: contextual inquiry or interviews. If testing comprehension: 5-second test or concept test.]
|
||||
|
||||
**What this method will and won't tell us:**
|
||||
- **Will tell us:** [What this method is good at revealing]
|
||||
- **Won't tell us:** [What's out of scope — be honest about limits]
|
||||
|
||||
**Sample size:** [Recommended number of sessions and why — e.g. "5–6 moderated interviews for generative research; 5–8 usability sessions to identify top issues"]
|
||||
|
||||
---
|
||||
|
||||
## 4. Participant Screener
|
||||
|
||||
**Recruitment criteria:**
|
||||
|
||||
| Criterion | Must Have / Nice to Have | Disqualify if |
|
||||
|---|---|---|
|
||||
| [e.g. Uses project management software daily] | Must Have | [Never uses any PM tool] |
|
||||
| [e.g. Works in a team of 5+] | Must Have | — |
|
||||
| [e.g. B2B industry] | Nice to Have | — |
|
||||
|
||||
**Screener questions (5–8 questions):**
|
||||
|
||||
[Q1] [Screening question — clear, not leading]
|
||||
- [Answer options — flag which qualify/disqualify]
|
||||
|
||||
[Q2] ...
|
||||
|
||||
**Incentive recommendation:** [Amount and format — e.g. "£50 gift voucher for a 60-min session is standard in the UK for professional participants"]
|
||||
|
||||
---
|
||||
|
||||
## 5. Discussion Guide
|
||||
|
||||
Structure the session:
|
||||
|
||||
### Opening (5 min)
|
||||
- Introduce yourself and the study
|
||||
- "We're testing the design, not you — there are no wrong answers"
|
||||
- Permission to record
|
||||
- Warm-up: [1–2 easy questions to build rapport — e.g. "Tell me about your role and what a typical week looks like"]
|
||||
|
||||
### Core Questions (by section)
|
||||
|
||||
**Section [A]: [Topic]** *(~X min)*
|
||||
|
||||
1. [Open question — start broad] *[Probe: Tell me more about...]*
|
||||
2. [Follow-up to go deeper] *[Probe: Can you walk me through what happened?]*
|
||||
3. [Specific scenario or past behaviour question]
|
||||
|
||||
**Section [B]: [Topic]** *(~X min)*
|
||||
[Continue with 2–3 questions per section]
|
||||
|
||||
**Usability tasks (if applicable):**
|
||||
> "I'm going to ask you to try a few things with this prototype. Please think aloud as you go."
|
||||
|
||||
- Task [N]: [Clear task instruction — write from the user's perspective, not "click on X" but "find where you would go to do Y"]
|
||||
- **Success criteria:** [What "completing this task" looks like]
|
||||
- **What to observe:** [Where friction typically appears]
|
||||
|
||||
### Closing (5 min)
|
||||
- "Is there anything about [topic] we haven't covered that you think is important?"
|
||||
- "If you could change one thing about [product/concept], what would it be?"
|
||||
- Debrief and thank
|
||||
|
||||
---
|
||||
|
||||
## 6. Synthesis Framework
|
||||
|
||||
After sessions, use this framework to synthesise findings:
|
||||
|
||||
**Step 1: Session notes → Key observations**
|
||||
For each session: 3–5 specific observations (behaviours, quotes, reactions — not interpretations yet)
|
||||
|
||||
**Step 2: Affinity mapping**
|
||||
Group observations by theme across all sessions. Aim for 4–7 clusters.
|
||||
|
||||
**Step 3: Insight statements**
|
||||
For each cluster: "When [context], users [behaviour/experience], because [underlying need or mental model]."
|
||||
|
||||
**Step 4: Implications**
|
||||
For each insight: "This means we should [design/product implication]" or "This challenges our assumption that [assumption]."
|
||||
|
||||
**Step 5: Research report structure:**
|
||||
- Key findings (3–5 headlines)
|
||||
- Supporting evidence per finding
|
||||
- Design recommendations
|
||||
- Open questions for next research cycle
|
||||
|
||||
---
|
||||
|
||||
## Quality Checks
|
||||
|
||||
- [ ] Research objectives map to real decisions
|
||||
- [ ] Discussion guide opens broad before going specific
|
||||
- [ ] Screener criteria are specific enough to get the right participants
|
||||
- [ ] Tasks (if usability) are written from the user's perspective
|
||||
- [ ] Synthesis framework is included
|
||||
- [ ] Incentive recommendation is included
|
||||
|
||||
## Example Trigger Phrases
|
||||
|
||||
- "Write a research plan for [feature or product area]"
|
||||
- "Create a discussion guide for user interviews about [topic]"
|
||||
- "Plan a usability test for [prototype or feature]"
|
||||
- "Write screener questions for [target user type]"
|
||||
Reference in New Issue
Block a user