add marketplace plugin structure
This commit is contained in:
mohitagw15856
@@ -0,0 +1,95 @@
|
||||
---
|
||||
name: ab-test-planner
|
||||
description: Designs statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, run an A/B test, calculate sample size, or interpret test results. Triggers on "A/B test", "experiment", "split test", "statistical significance", "sample size".
|
||||
---
|
||||
|
||||
# A/B Test Planner Skill
|
||||
|
||||
Design experiments that produce trustworthy results — not just directional signals. Every test output includes hypothesis, success metrics, sample size, duration, and a results interpretation guide.
|
||||
|
||||
## Experiment Design Checklist
|
||||
|
||||
Before running any test, confirm:
|
||||
- [ ] Clear hypothesis with predicted direction
|
||||
- [ ] Single primary metric (plus up to 2 guardrail metrics)
|
||||
- [ ] Minimum detectable effect (MDE) defined
|
||||
- [ ] Sample size calculated
|
||||
- [ ] Test duration estimated
|
||||
- [ ] Segment isolated (no overlap with other running tests)
|
||||
- [ ] Rollback plan defined
|
||||
|
||||
## Hypothesis Template
|
||||
|
||||
> "We believe that [change] will cause [primary metric] to [increase/decrease] by [X%] for [user segment], because [rationale based on data or insight]."
|
||||
|
||||
Never run a test without a directional hypothesis. "Let's just see what happens" is not a hypothesis.
|
||||
|
||||
## Sample Size Calculator Logic
|
||||
|
||||
Use this formula (provide the output, not the formula, to the user):
|
||||
|
||||
- **Baseline conversion rate:** Current rate of primary metric
|
||||
- **MDE:** Smallest change worth detecting (recommend 10–20% relative lift for most features)
|
||||
- **Statistical power:** 80% (standard)
|
||||
- **Significance level:** 95% (p < 0.05)
|
||||
|
||||
For common scenarios, provide pre-calculated estimates:
|
||||
|
||||
| Baseline Rate | MDE (Relative) | Required Sample per Variant |
|
||||
|---|---|---|
|
||||
| 5% | 20% | ~19,000 |
|
||||
| 10% | 15% | ~14,000 |
|
||||
| 20% | 10% | ~15,000 |
|
||||
| 40% | 10% | ~9,500 |
|
||||
| 60% | 5% | ~42,000 |
|
||||
|
||||
Always warn: "These are estimates. Use a tool like Evan Miller's calculator or Statsig for precision."
|
||||
|
||||
## Test Duration Guidance
|
||||
|
||||
Minimum: 2 full weeks (to capture weekly seasonality)
|
||||
Maximum: 4 weeks (novelty effect distorts results beyond this)
|
||||
|
||||
`Duration = Required sample ÷ (Daily traffic × % exposed)`
|
||||
|
||||
Flag if traffic is too low to reach significance in under 8 weeks — recommend a different approach (e.g., holdout test, qualitative research).
|
||||
|
||||
## Output Format
|
||||
|
||||
### A/B Test Plan — [Test Name] — [Date]
|
||||
|
||||
**Hypothesis:**
|
||||
> [Filled hypothesis template]
|
||||
|
||||
**Variants:**
|
||||
- Control (A): [Current experience]
|
||||
- Treatment (B): [Changed experience — be specific]
|
||||
|
||||
**Primary Metric:** [Metric name + how measured]
|
||||
**Guardrail Metrics:** [Metrics that must not degrade]
|
||||
|
||||
**Target Segment:** [Who sees the test — % of traffic, user type]
|
||||
**Traffic Split:** [50/50 recommended unless ramp-up needed]
|
||||
|
||||
**Sample Size Required:** ~[N] users per variant
|
||||
**Estimated Duration:** [X] weeks (based on [Y] daily eligible users)
|
||||
**Significance Threshold:** 95% confidence, 80% power
|
||||
|
||||
**Exclusions:** [Any user segments to exclude and why]
|
||||
|
||||
**Rollback Trigger:** If [guardrail metric] degrades by [X%], stop the test immediately.
|
||||
|
||||
**Results Interpretation Guide:**
|
||||
- ✅ Ship if: Treatment shows [X%]+ lift on primary metric at 95% confidence AND guardrail metrics are stable
|
||||
- 🔄 Iterate if: Direction is positive but not significant — consider extending or redesigning
|
||||
- ❌ Reject if: No lift or negative direction at significance
|
||||
- ⚠️ Inconclusive: Do not ship. Do not call it a win.
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always recommend against peeking at results before the test reaches planned sample size — explain p-hacking risk
|
||||
- If user wants to test multiple variants, explain the multiple comparisons problem and recommend a Bonferroni correction or a Bayesian approach
|
||||
- If traffic is very low (<1,000 users/day), recommend qualitative alternatives: moderated testing, 5-second tests, or user interviews
|
||||
- Never approve a test with no guardrail metrics — always protect revenue, retention, or core engagement
|
||||
@@ -0,0 +1,114 @@
|
||||
---
|
||||
name: go-to-market-planner
|
||||
description: Builds go-to-market (GTM) plans for product launches, feature releases, and new market entries. Use when planning a product launch, writing a GTM strategy, defining launch tiers, or coordinating cross-functional launch activities. Triggers on "go-to-market", "GTM plan", "product launch plan", "launch strategy", "release plan".
|
||||
---
|
||||
|
||||
# Go-to-Market Planner Skill
|
||||
|
||||
Produce a complete, cross-functional GTM plan that aligns product, marketing, sales, and support around a single launch — with clear owners, timelines, and success metrics.
|
||||
|
||||
## Launch Tier Framework
|
||||
|
||||
Before planning, classify the launch:
|
||||
|
||||
| Tier | Scope | Typical Effort | Examples |
|
||||
|---|---|---|---|
|
||||
| **Tier 1 — Major Launch** | New product / significant platform change | 8–12 weeks | New pricing model, platform rebrand, new product line |
|
||||
| **Tier 2 — Feature Launch** | Significant new capability | 4–6 weeks | Major feature, API release, new integration |
|
||||
| **Tier 3 — Incremental Release** | Improvement, bug fix, minor feature | 1–2 weeks | UI tweak, performance improvement, small enhancement |
|
||||
|
||||
Always confirm tier with the user before proceeding.
|
||||
|
||||
---
|
||||
|
||||
## GTM Plan Output Format
|
||||
|
||||
### GTM Plan — [Product/Feature Name] — [Launch Date]
|
||||
|
||||
**Launch Tier:** [1 / 2 / 3]
|
||||
**Launch Owner (PM):** [Name]
|
||||
**Target Launch Date:** [Date]
|
||||
**Soft Launch Date (Beta/Limited):** [Date, if applicable]
|
||||
|
||||
---
|
||||
|
||||
### 1. What We're Launching
|
||||
**One-line description:** [What it is, for whom, and why now]
|
||||
**Key customer problem solved:** [Specific pain point]
|
||||
**Key differentiator:** [Why ours, why now]
|
||||
|
||||
---
|
||||
|
||||
### 2. Target Audience
|
||||
**Primary segment:** [Who benefits most — be specific]
|
||||
**Secondary segment:** [Who else benefits]
|
||||
**Not for:** [Who this is NOT for — helps sales and support]
|
||||
|
||||
---
|
||||
|
||||
### 3. Messaging
|
||||
|
||||
**Headline:** [Customer-facing headline — lead with outcome, not feature]
|
||||
**Sub-headline:** [Supporting context — how it works or why it matters]
|
||||
**3 key messages:**
|
||||
1. [Problem solved]
|
||||
2. [How it works / what's new]
|
||||
3. [Proof / social proof / data]
|
||||
|
||||
**Elevator pitch (30 seconds):**
|
||||
> [For [target user] who [has this problem], [product/feature] is a [category] that [key benefit]. Unlike [alternative], we [differentiator].]
|
||||
|
||||
---
|
||||
|
||||
### 4. Launch Activities by Function
|
||||
|
||||
| Function | Activity | Owner | Due Date | Status |
|
||||
|---|---|---|---|---|
|
||||
| Product | Feature flagging / rollout plan | PM | [date] | |
|
||||
| Marketing | Blog post / landing page | Marketing | [date] | |
|
||||
| Marketing | Email campaign to existing users | Marketing | [date] | |
|
||||
| Marketing | Social media content | Marketing | [date] | |
|
||||
| Sales | Sales enablement deck | PM + Sales | [date] | |
|
||||
| Sales | FAQ for sales team | PM | [date] | |
|
||||
| Support | Help centre articles | Support | [date] | |
|
||||
| Support | Support team training | Support | [date] | |
|
||||
| Engineering | Monitoring/alerting in place | Eng | [date] | |
|
||||
|
||||
---
|
||||
|
||||
### 5. Success Metrics
|
||||
|
||||
| Metric | Baseline | Target | Measurement Window |
|
||||
|---|---|---|---|
|
||||
| [Adoption metric] | [X] | [Y] | 30 days post-launch |
|
||||
| [Engagement metric] | [X] | [Y] | 60 days post-launch |
|
||||
| [Business metric] | [X] | [Y] | 90 days post-launch |
|
||||
|
||||
---
|
||||
|
||||
### 6. Risks & Contingencies
|
||||
|
||||
| Risk | Likelihood | Impact | Mitigation |
|
||||
|---|---|---|---|
|
||||
| [Risk] | H/M/L | H/M/L | [Action if it happens] |
|
||||
|
||||
---
|
||||
|
||||
### 7. Launch Day Checklist
|
||||
- [ ] Feature live for [X%] of users
|
||||
- [ ] Monitoring dashboard active
|
||||
- [ ] Support team briefed
|
||||
- [ ] Blog post published
|
||||
- [ ] Email sent / scheduled
|
||||
- [ ] Sales team notified
|
||||
- [ ] Executive announcement sent (if Tier 1)
|
||||
- [ ] Rollback procedure confirmed
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Never plan a Tier 1 launch without at least 8 weeks of lead time
|
||||
- Always include a "Not for" section — it prevents misdirected sales and support tickets
|
||||
- Recommend a soft launch to 5–10% of users before full rollout for any Tier 1 or 2 launch
|
||||
- Post-launch retrospective should be scheduled at launch planning time — don't leave it to chance
|
||||
@@ -0,0 +1,117 @@
|
||||
---
|
||||
name: product-launch-checklist
|
||||
description: Generates comprehensive pre-launch, launch day, and post-launch checklists for product releases. Use when preparing for a product launch, feature release, or major update. Triggers on "launch checklist", "pre-launch", "launch day", "release checklist", "ship checklist", "go-live checklist".
|
||||
---
|
||||
|
||||
# Product Launch Checklist Skill
|
||||
|
||||
Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring.
|
||||
|
||||
## How to Use This Skill
|
||||
|
||||
Provide:
|
||||
- Launch name and date
|
||||
- Launch tier (1 = major, 2 = feature, 3 = incremental)
|
||||
- Team members and their roles
|
||||
|
||||
The skill generates a tiered checklist. Tier 3 launches use only the Essentials section. Tier 2 adds Marketing & Comms. Tier 1 uses all sections.
|
||||
|
||||
---
|
||||
|
||||
## Output Format
|
||||
|
||||
### Launch Checklist — [Feature/Product Name] — Target Date: [Date]
|
||||
|
||||
**Launch Tier:** [1 / 2 / 3]
|
||||
**Launch Owner:** [PM Name]
|
||||
**Engineering Lead:** [Name]
|
||||
**Go/No-Go Decision By:** [Date and time — typically 24 hours before launch]
|
||||
|
||||
---
|
||||
|
||||
### 🔧 PRE-LAUNCH — Engineering & Product (T-2 weeks)
|
||||
- [ ] Feature flag created and tested in staging
|
||||
- [ ] All acceptance criteria signed off by PM
|
||||
- [ ] Code reviewed and merged to main
|
||||
- [ ] QA sign-off completed (regression + new feature)
|
||||
- [ ] Performance testing completed (load, latency)
|
||||
- [ ] Security review completed (if data or auth changes)
|
||||
- [ ] Rollback procedure documented and tested
|
||||
- [ ] Monitoring and alerting configured
|
||||
- [ ] Error logging in place with correct severity levels
|
||||
- [ ] Database migrations tested on staging with production data volume
|
||||
|
||||
### 📢 PRE-LAUNCH — Marketing & Comms (T-1 week)
|
||||
- [ ] Blog post written, reviewed, and scheduled
|
||||
- [ ] In-app announcement or tooltip configured
|
||||
- [ ] Email campaign drafted and QA'd
|
||||
- [ ] Social media posts drafted and scheduled
|
||||
- [ ] Landing page or feature page live in staging
|
||||
- [ ] Press outreach sent (Tier 1 only)
|
||||
- [ ] Product Hunt / community posts prepared (Tier 1 only)
|
||||
|
||||
### 🎓 PRE-LAUNCH — Sales & Support (T-1 week)
|
||||
- [ ] Sales enablement one-pager completed
|
||||
- [ ] FAQ document shared with sales and support teams
|
||||
- [ ] Help centre articles written and published
|
||||
- [ ] Support team demo / training completed
|
||||
- [ ] Customer success team briefed on top accounts
|
||||
- [ ] Pricing updated (if applicable)
|
||||
- [ ] Contracts / ToS updated (if applicable)
|
||||
|
||||
### 📊 PRE-LAUNCH — Analytics (T-1 week)
|
||||
- [ ] Analytics events firing correctly in staging
|
||||
- [ ] Dashboard configured for launch metrics
|
||||
- [ ] Baseline metrics documented
|
||||
- [ ] Success criteria documented and shared with team
|
||||
- [ ] A/B test configured (if applicable)
|
||||
|
||||
---
|
||||
|
||||
### ✅ GO / NO-GO DECISION — T-24 hours
|
||||
|
||||
| Criteria | Status | Owner |
|
||||
|---|---|---|
|
||||
| All critical bugs resolved | 🟢 / 🔴 | Eng Lead |
|
||||
| QA sign-off complete | 🟢 / 🔴 | QA |
|
||||
| Rollback tested | 🟢 / 🔴 | Eng Lead |
|
||||
| Help centre articles live | 🟢 / 🔴 | Support |
|
||||
| Monitoring active | 🟢 / 🔴 | Eng Lead |
|
||||
| PM sign-off | 🟢 / 🔴 | PM |
|
||||
|
||||
**Go / No-Go Decision:** [GO / NO-GO]
|
||||
**Decision Owner:** [PM + Eng Lead jointly]
|
||||
|
||||
---
|
||||
|
||||
### 🚀 LAUNCH DAY
|
||||
- [ ] Feature flag enabled for [X%] of users (start low — 5–10%)
|
||||
- [ ] Launch confirmed in team Slack/channel
|
||||
- [ ] Metrics dashboard open and being monitored
|
||||
- [ ] Error rate checked at T+15 min, T+1 hr, T+4 hr
|
||||
- [ ] Blog post published / email sent
|
||||
- [ ] Social posts live
|
||||
- [ ] Support team on standby for first 4 hours
|
||||
- [ ] PM available and reachable all day
|
||||
- [ ] Feature flag expanded to 50% if T+2hr checks pass
|
||||
- [ ] Feature flag expanded to 100% if T+4hr checks pass
|
||||
|
||||
---
|
||||
|
||||
### 📈 POST-LAUNCH (D+7, D+30)
|
||||
- [ ] D+7 metrics review: adoption, errors, support tickets
|
||||
- [ ] D+7 customer feedback synthesised
|
||||
- [ ] Retrospective scheduled
|
||||
- [ ] Learnings documented
|
||||
- [ ] D+30 success metrics reviewed against targets
|
||||
- [ ] Feature flag removed from codebase (clean up)
|
||||
- [ ] Follow-up features added to backlog based on feedback
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- The Go/No-Go decision must have a named owner — "the team" is not an owner
|
||||
- Never launch on a Friday unless you have weekend engineering coverage
|
||||
- Recommend starting all launches at <10% traffic — even for simple features
|
||||
- Document rollback time: "We can revert this in X minutes" should be known before launch
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: retro-analysis
|
||||
description: Analyse sprint delivery data and produce a structured retrospective brief
|
||||
tool_integration: Jira, Miro
|
||||
---
|
||||
# Retrospective Analysis Skill
|
||||
|
||||
## Purpose
|
||||
Generate a data-grounded retrospective brief that separates facts from feelings, so the team spends retro time on solutions rather than debating what happened.
|
||||
|
||||
## Required Inputs
|
||||
- Sprint tickets: planned vs. completed
|
||||
- Carry-over tickets and reasons
|
||||
- Tickets reopened after closing
|
||||
- Any incidents or unplanned work
|
||||
- Sprint velocity vs. historical average
|
||||
|
||||
## Process
|
||||
1. Calculate: completion rate, carry-over rate, unplanned work percentage
|
||||
2. Identify patterns: which ticket types were most likely to carry over? Which caused blockers?
|
||||
3. Note any process or communication breakdowns visible in the data
|
||||
4. Prepare 3 "Start / Stop / Continue" prompts based on the data — not generic, specific to this sprint
|
||||
5. Suggest 1 concrete experiment for the next sprint based on the biggest friction point
|
||||
|
||||
## Output Format
|
||||
|
||||
### Sprint [Number] Retrospective Brief
|
||||
|
||||
**By the Numbers:**
|
||||
- Planned: [n] tickets | Completed: [n] | Carry-over: [n] | Completion rate: [%]
|
||||
- Unplanned work: [n] tickets ([%] of capacity)
|
||||
- Velocity: [points] vs. [average] average
|
||||
|
||||
**What the Data Suggests:**
|
||||
[2-3 observations grounded in the numbers above]
|
||||
|
||||
**Discussion Prompts:**
|
||||
- Start: [specific prompt]
|
||||
- Stop: [specific prompt]
|
||||
- Continue: [specific prompt]
|
||||
|
||||
**Suggested Experiment for Next Sprint:**
|
||||
[One concrete, testable process change]
|
||||
@@ -0,0 +1,43 @@
|
||||
---
|
||||
name: sprint-brief
|
||||
description: Generate a structured sprint brief from Jira sprint data and goals
|
||||
tool_integration: Jira, Slack
|
||||
---
|
||||
# Sprint Brief Skill
|
||||
|
||||
## Purpose
|
||||
Produce a clear, scannable sprint brief that every team member — engineer, designer, PM — can read in under three minutes and understand exactly what we're doing and why.
|
||||
|
||||
## Required Inputs
|
||||
- Sprint name and number
|
||||
- Sprint goal (1-2 sentences)
|
||||
- Ticket list with owners
|
||||
- Known dependencies or blockers
|
||||
- Carry-over items from previous sprint
|
||||
|
||||
## Process
|
||||
1. Read sprint goal and check it's specific and measurable — flag if it's too vague
|
||||
2. Group tickets by theme or feature area
|
||||
3. Identify the critical path — which tickets must complete for the sprint goal to be met?
|
||||
4. Flag risks: tickets with unclear acceptance criteria, missing designs, unresolved dependencies
|
||||
5. Note carry-over items and whether they affect this sprint's goal
|
||||
|
||||
## Output Format
|
||||
|
||||
### Sprint [Number] Brief — [Dates]
|
||||
**Sprint Goal:** [1-2 sentences]
|
||||
**Why This Sprint Matters:** [Connect to quarterly OKR in 2-3 sentences]
|
||||
|
||||
**What We're Building:**
|
||||
- [Theme 1]: [tickets and owners]
|
||||
- [Theme 2]: [tickets and owners]
|
||||
|
||||
**Critical Path:** [The 2-3 tickets everything else depends on]
|
||||
|
||||
**Risks to Flag:**
|
||||
- [Risk 1 + mitigation]
|
||||
- [Risk 2 + mitigation]
|
||||
|
||||
**Carry-over from Last Sprint:** [List + impact on current goal]
|
||||
|
||||
**Definition of Done:** [Specific, agreed criteria for sprint success]
|
||||
@@ -0,0 +1,89 @@
|
||||
---
|
||||
name: sprint-planning
|
||||
description: Structures and facilitates sprint planning sessions. Use when asked to plan a sprint, organise backlog items, assign story points, create sprint goals, or prepare sprint planning meeting agendas. Triggers on phrases like "plan sprint", "sprint planning", "sprint goal", "sprint backlog".
|
||||
---
|
||||
|
||||
# Sprint Planning Skill
|
||||
|
||||
Transform raw backlog items into a structured, achievable sprint with clear goals, velocity-calibrated scope, and team-ready output.
|
||||
|
||||
## What This Skill Produces
|
||||
|
||||
- **Sprint Goal** — single, outcome-focused sentence the whole team can rally around
|
||||
- **Sprint Backlog** — prioritised list of user stories with story point estimates and acceptance criteria
|
||||
- **Capacity Plan** — team availability breakdown accounting for holidays, meetings, and focus time
|
||||
- **Sprint Planning Agenda** — structured 2-hour meeting agenda with timings
|
||||
- **Risk Flags** — blockers or dependencies that could derail the sprint
|
||||
|
||||
## Inputs to Request From User
|
||||
|
||||
Ask for (if not already provided):
|
||||
- Sprint duration (1 or 2 weeks)
|
||||
- Team size and velocity (average story points per sprint)
|
||||
- Top 3–5 backlog items or epics to pull from
|
||||
- Any known absences, holidays, or team events
|
||||
- Previous sprint's incomplete items (carry-overs)
|
||||
|
||||
## Sprint Goal Formula
|
||||
|
||||
Use this structure:
|
||||
> "This sprint we will [deliver X outcome] so that [user/business benefit], measured by [success indicator]."
|
||||
|
||||
Never write sprint goals as task lists. Always outcome-first.
|
||||
|
||||
## Story Point Calibration
|
||||
|
||||
| Complexity | Points | Description |
|
||||
|---|---|---|
|
||||
| Trivial | 1 | Clearly understood, no unknowns |
|
||||
| Small | 2 | Straightforward, minor effort |
|
||||
| Medium | 3 | Some complexity, clear path |
|
||||
| Large | 5 | Complex, needs design or research |
|
||||
| Very Large | 8 | High uncertainty, may need splitting |
|
||||
| Epic | 13+ | Too large — must be split before sprint |
|
||||
|
||||
Flag any item estimated at 8+ and recommend splitting.
|
||||
|
||||
## Capacity Formula
|
||||
|
||||
```
|
||||
Available capacity = (Team size × Sprint days × Focus hours/day) × Availability factor
|
||||
Focus hours/day: 6 (accounting for meetings, Slack, admin)
|
||||
Availability factor: 0.7–0.85 depending on holidays/events
|
||||
Story points to commit = Historical velocity × Availability factor
|
||||
```
|
||||
|
||||
## Output Format
|
||||
|
||||
### Sprint [N] — [Start Date] to [End Date]
|
||||
|
||||
**Sprint Goal:**
|
||||
> [Goal statement]
|
||||
|
||||
**Team Capacity:** [X] story points available (based on [Y] team members, [Z]% availability)
|
||||
|
||||
**Sprint Backlog:**
|
||||
|
||||
| Priority | Story | Points | Owner | Acceptance Criteria |
|
||||
|---|---|---|---|---|
|
||||
| 1 | [Story title] | [N] | [Team member] | [When X then Y] |
|
||||
|
||||
**Carry-Overs from Previous Sprint:**
|
||||
- [Item] — Reason for carry-over: [brief explanation]
|
||||
|
||||
**Risks & Dependencies:**
|
||||
- [Risk description] → Mitigation: [action]
|
||||
|
||||
**Sprint Planning Agenda:**
|
||||
- 00:00–00:10 — Review sprint goal and team capacity
|
||||
- 00:10–00:40 — Walk through backlog items, confirm estimates
|
||||
- 00:40–01:20 — Assign stories, identify dependencies
|
||||
- 01:20–01:50 — Review acceptance criteria per story
|
||||
- 01:50–02:00 — Confirm sprint commitment and close
|
||||
|
||||
## Guidelines
|
||||
|
||||
- Always challenge stories missing acceptance criteria — flag them explicitly
|
||||
- Recommend the team commits to 80% of available capacity, not 100%
|
||||
- If no velocity data is provided, assume 20–30 points for a 5-person team as a starting point
|
||||
- Highlight any story with unclear ownership as a blocker
|
||||
@@ -0,0 +1,133 @@
|
||||
---
|
||||
name: technical-spec-template
|
||||
description: Creates structured technical specification documents that bridge product requirements and engineering implementation. Use when writing a tech spec, engineering spec, system design doc, or API specification. Triggers on "technical spec", "tech spec", "engineering spec", "system design doc", "API spec", "implementation spec".
|
||||
---
|
||||
|
||||
# Technical Spec Template Skill
|
||||
|
||||
Write technical specifications that engineers actually read — clear problem framing, unambiguous requirements, explicit decisions, and documented trade-offs.
|
||||
|
||||
## When to Write a Tech Spec
|
||||
|
||||
Write a tech spec when:
|
||||
- The feature requires changes to 2+ systems
|
||||
- There are significant architectural decisions to make
|
||||
- More than one engineer will work on the implementation
|
||||
- The feature has security, privacy, or compliance implications
|
||||
- Estimated effort is >5 story points
|
||||
|
||||
Skip the spec for trivial bug fixes or 1-2 hour changes.
|
||||
|
||||
---
|
||||
|
||||
## Technical Spec Output Format
|
||||
|
||||
### Technical Specification — [Feature Name]
|
||||
|
||||
**Author:** [Name]
|
||||
**Status:** Draft | In Review | Approved | Implemented
|
||||
**Created:** [Date] | **Last Updated:** [Date]
|
||||
**Reviewers:** [Eng Lead, Architect, PM, Security if needed]
|
||||
**Related PRD:** [Link] | **Jira Epic:** [Link]
|
||||
|
||||
---
|
||||
|
||||
#### 1. Problem Statement
|
||||
> [2–3 sentences. What problem are we solving and why now? No solution language here.]
|
||||
|
||||
#### 2. Goals & Non-Goals
|
||||
|
||||
**Goals (in scope):**
|
||||
- [Specific, measurable outcome]
|
||||
- [Specific, measurable outcome]
|
||||
|
||||
**Non-Goals (explicitly out of scope):**
|
||||
- [What this spec does NOT cover]
|
||||
- [Common assumption to shut down early]
|
||||
|
||||
#### 3. Background & Context
|
||||
[Any prior art, related systems, or context engineers need to understand the decision space. Link to previous specs, ADRs, or research.]
|
||||
|
||||
#### 4. Proposed Solution
|
||||
|
||||
**High-Level Approach:**
|
||||
[2–4 sentences describing the chosen solution. Why this approach vs alternatives?]
|
||||
|
||||
**System Architecture Diagram:**
|
||||
[Describe or embed: which services are involved, how data flows, what APIs are called]
|
||||
|
||||
**Data Model Changes:**
|
||||
```sql
|
||||
-- New tables or schema changes
|
||||
[Include DDL or schema definition]
|
||||
```
|
||||
|
||||
**API Design:**
|
||||
```
|
||||
[Endpoint] [Method]
|
||||
Request: { [fields and types] }
|
||||
Response: { [fields and types] }
|
||||
Error codes: [list]
|
||||
```
|
||||
|
||||
**Key Implementation Details:**
|
||||
- [Important technical constraint or approach]
|
||||
- [Edge case handling]
|
||||
- [Third-party dependency and version]
|
||||
|
||||
#### 5. Alternative Approaches Considered
|
||||
|
||||
| Option | Pros | Cons | Why Rejected |
|
||||
|---|---|---|---|
|
||||
| [Alt 1] | [Benefits] | [Drawbacks] | [Reason not chosen] |
|
||||
| [Alt 2] | [Benefits] | [Drawbacks] | [Reason not chosen] |
|
||||
|
||||
#### 6. Security & Privacy Considerations
|
||||
- Data stored: [What PII or sensitive data is involved]
|
||||
- Authentication: [How is access controlled]
|
||||
- Authorisation: [What permissions are required]
|
||||
- Encryption: [At rest / in transit requirements]
|
||||
- Compliance implications: [GDPR, SOC2, etc. if relevant]
|
||||
|
||||
#### 7. Performance & Scalability
|
||||
- Expected load: [Requests/second, data volume]
|
||||
- Latency requirements: [P50 / P95 targets]
|
||||
- Caching strategy: [If applicable]
|
||||
- Database indexing: [New indexes required]
|
||||
- Known bottlenecks: [Where to watch]
|
||||
|
||||
#### 8. Testing Plan
|
||||
- Unit tests: [Key scenarios to cover]
|
||||
- Integration tests: [System boundaries to test]
|
||||
- Load tests: [If performance-critical]
|
||||
- Edge cases: [Known tricky scenarios]
|
||||
- Rollback plan: [How to revert if something goes wrong]
|
||||
|
||||
#### 9. Rollout Plan
|
||||
- Feature flag: [Yes / No — name of flag]
|
||||
- Rollout stages: [% of users at each stage]
|
||||
- Monitoring: [Metrics and alerts to set up]
|
||||
- Success criteria to progress rollout: [What needs to be true]
|
||||
- Rollback trigger: [What would cause immediate rollback]
|
||||
|
||||
#### 10. Open Questions
|
||||
| Question | Owner | Due Date | Resolution |
|
||||
|---|---|---|---|
|
||||
| [Unresolved question] | [Name] | [Date] | [Pending] |
|
||||
|
||||
#### 11. Implementation Timeline (Rough)
|
||||
| Phase | Work | Estimated Effort |
|
||||
|---|---|---|
|
||||
| [Phase 1] | [What gets built] | [X days/points] |
|
||||
| [Phase 2] | [What gets built] | [X days/points] |
|
||||
| Total | | [X story points] |
|
||||
|
||||
---
|
||||
|
||||
## Guidelines
|
||||
|
||||
- The spec is a decision record, not a task list — document *why* decisions were made
|
||||
- All open questions must have an owner and due date
|
||||
- Security and privacy sections are never optional for features that touch user data
|
||||
- Recommend async review: engineers read first, then a 30-minute sync to resolve questions
|
||||
- Keep the spec updated as implementation progresses — stale specs are worse than no specs
|
||||
Reference in New Issue
Block a user