Restore trigger phrases as ## Usage Examples across 10 engineering skills
Renamed ## Example Trigger Phrases → ## Usage Examples to make the section clearly human-facing documentation rather than a system instruction. Restores content that was removed in the previous quality pass. Skills updated (both skills/ and plugins/pm-engineering/skills/): code-review-checklist, debugging-log-analyser, changelog-generator, pr-description-writer, system-design-interview, test-strategy-doc, runbook-writer, incident-postmortem, api-docs-writer, architecture-decision-record https://claude.ai/code/session_01C3HwChrccJd145vJ6Z7ajF
This commit is contained in:
mohitagw15856
Claude
@@ -137,3 +137,9 @@ data = response.json()
|
||||
- [ ] Auth method is clearly stated at the top
|
||||
- [ ] Enum values are listed where applicable
|
||||
- [ ] Pagination documented if the endpoint is a list endpoint
|
||||
|
||||
## Usage Examples
|
||||
- "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"
|
||||
|
||||
@@ -108,3 +108,9 @@ For each option, produce:
|
||||
- [ ] 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
|
||||
|
||||
## Usage Examples
|
||||
- "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]"
|
||||
|
||||
@@ -73,3 +73,10 @@ Follow [Keep a Changelog](https://keepachangelog.com) format:
|
||||
- [ ] Version and date header is correct
|
||||
- [ ] Empty sections are omitted
|
||||
- [ ] Tone is imperative mood throughout
|
||||
|
||||
## Usage Examples
|
||||
- "Write a changelog for version [X]" + [paste commits]
|
||||
- "Generate release notes from these commits"
|
||||
- "Turn this git log into a CHANGELOG entry"
|
||||
- "Write the CHANGELOG.md update for this release"
|
||||
- "What changed in this release?" + [paste commit list]
|
||||
|
||||
@@ -103,3 +103,9 @@ Based on the change type and language, flag 2-3 things reviewers typically miss
|
||||
- [ ] Change-type-specific section is included
|
||||
- [ ] Risk-appropriate depth matches stated risk level
|
||||
- [ ] Decision framework is explicit
|
||||
|
||||
## Usage Examples
|
||||
- "Generate a code review checklist for [PR description]"
|
||||
- "What should I check in this pull request?"
|
||||
- "Give me a code review checklist for a [language] [change type]"
|
||||
- "Review checklist for a high-risk PR in [language]"
|
||||
|
||||
@@ -75,3 +75,10 @@ One or two concrete things that would prevent this class of error recurring:
|
||||
- [ ] Next steps are actionable commands, not vague advice
|
||||
- [ ] Language-specific idioms are used correctly
|
||||
- [ ] Prevention is proactive (not just "add error handling")
|
||||
|
||||
## Usage Examples
|
||||
- "Why is this crashing?" + [paste log]
|
||||
- "Can you analyse this stack trace?"
|
||||
- "I'm getting this error, what does it mean?"
|
||||
- "Debug this log for me"
|
||||
- "What's causing this exception?"
|
||||
|
||||
@@ -135,3 +135,9 @@ Rules for action items:
|
||||
- [ ] 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
|
||||
|
||||
## Usage Examples
|
||||
- "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]"
|
||||
|
||||
@@ -78,3 +78,10 @@ Flag anything that warrants extra attention:
|
||||
- [ ] Changes list describes logical changes (not file-by-file changes)
|
||||
- [ ] Testing steps are reproducible by someone unfamiliar with the code
|
||||
- [ ] Risk-appropriate reviewer guidance is included
|
||||
|
||||
## Usage Examples
|
||||
- "Write a PR description for these changes" + [paste diff or description]
|
||||
- "Draft a pull request for [feature]"
|
||||
- "I need a PR description — here's what I changed"
|
||||
- "Summarise these commits into a PR description"
|
||||
- "Write the PR body for this branch"
|
||||
|
||||
@@ -135,3 +135,10 @@ After completing the runbook:
|
||||
- [ ] Rollback procedure is complete and independently testable
|
||||
- [ ] Escalation paths name specific contacts, not just team names
|
||||
- [ ] Runbook can be followed by someone who has never touched this system
|
||||
|
||||
## Usage Examples
|
||||
- "Write a runbook for [service] deployment"
|
||||
- "Create an incident response runbook for [alert type]"
|
||||
- "I need a runbook for [procedure]"
|
||||
- "Document the operational procedure for [X]"
|
||||
- "Write an ops playbook for [scenario]"
|
||||
|
||||
@@ -126,3 +126,10 @@ Things to tackle in production but out of scope for this design session:
|
||||
- [ ] At least 2 component deep-dives with technology choices justified
|
||||
- [ ] Trade-offs section is honest (not just benefits of chosen approach)
|
||||
- [ ] Data flow is described end-to-end for the critical path
|
||||
|
||||
## Usage Examples
|
||||
- "Help me answer a system design interview: [question]"
|
||||
- "Design [system] for a system design interview"
|
||||
- "How would I architect [system] at scale?"
|
||||
- "I have a system design interview — the question is [X]"
|
||||
- "Design a [URL shortener / chat system / notification service / feed]"
|
||||
|
||||
@@ -118,3 +118,10 @@ Testing is complete when:
|
||||
- [ ] P0 test cases cover the highest-risk paths specifically
|
||||
- [ ] Each test type names a concrete tool (not "some testing framework")
|
||||
- [ ] Definition of Done is measurable (not "tests are done when QA is happy")
|
||||
|
||||
## Usage Examples
|
||||
- "Write a test strategy for [feature]" + [paste spec or PRD]
|
||||
- "Create a test plan for [system]"
|
||||
- "How should we test [feature]?"
|
||||
- "I need a QA plan for this sprint"
|
||||
- "What tests do we need for [X]?"
|
||||
|
||||
@@ -137,3 +137,9 @@ data = response.json()
|
||||
- [ ] Auth method is clearly stated at the top
|
||||
- [ ] Enum values are listed where applicable
|
||||
- [ ] Pagination documented if the endpoint is a list endpoint
|
||||
|
||||
## Usage Examples
|
||||
- "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"
|
||||
|
||||
@@ -108,3 +108,9 @@ For each option, produce:
|
||||
- [ ] 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
|
||||
|
||||
## Usage Examples
|
||||
- "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]"
|
||||
|
||||
@@ -73,3 +73,10 @@ Follow [Keep a Changelog](https://keepachangelog.com) format:
|
||||
- [ ] Version and date header is correct
|
||||
- [ ] Empty sections are omitted
|
||||
- [ ] Tone is imperative mood throughout
|
||||
|
||||
## Usage Examples
|
||||
- "Write a changelog for version [X]" + [paste commits]
|
||||
- "Generate release notes from these commits"
|
||||
- "Turn this git log into a CHANGELOG entry"
|
||||
- "Write the CHANGELOG.md update for this release"
|
||||
- "What changed in this release?" + [paste commit list]
|
||||
|
||||
@@ -103,3 +103,9 @@ Based on the change type and language, flag 2-3 things reviewers typically miss
|
||||
- [ ] Change-type-specific section is included
|
||||
- [ ] Risk-appropriate depth matches stated risk level
|
||||
- [ ] Decision framework is explicit
|
||||
|
||||
## Usage Examples
|
||||
- "Generate a code review checklist for [PR description]"
|
||||
- "What should I check in this pull request?"
|
||||
- "Give me a code review checklist for a [language] [change type]"
|
||||
- "Review checklist for a high-risk PR in [language]"
|
||||
|
||||
@@ -75,3 +75,10 @@ One or two concrete things that would prevent this class of error recurring:
|
||||
- [ ] Next steps are actionable commands, not vague advice
|
||||
- [ ] Language-specific idioms are used correctly
|
||||
- [ ] Prevention is proactive (not just "add error handling")
|
||||
|
||||
## Usage Examples
|
||||
- "Why is this crashing?" + [paste log]
|
||||
- "Can you analyse this stack trace?"
|
||||
- "I'm getting this error, what does it mean?"
|
||||
- "Debug this log for me"
|
||||
- "What's causing this exception?"
|
||||
|
||||
@@ -135,3 +135,9 @@ Rules for action items:
|
||||
- [ ] 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
|
||||
|
||||
## Usage Examples
|
||||
- "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]"
|
||||
|
||||
@@ -78,3 +78,10 @@ Flag anything that warrants extra attention:
|
||||
- [ ] Changes list describes logical changes (not file-by-file changes)
|
||||
- [ ] Testing steps are reproducible by someone unfamiliar with the code
|
||||
- [ ] Risk-appropriate reviewer guidance is included
|
||||
|
||||
## Usage Examples
|
||||
- "Write a PR description for these changes" + [paste diff or description]
|
||||
- "Draft a pull request for [feature]"
|
||||
- "I need a PR description — here's what I changed"
|
||||
- "Summarise these commits into a PR description"
|
||||
- "Write the PR body for this branch"
|
||||
|
||||
@@ -135,3 +135,10 @@ After completing the runbook:
|
||||
- [ ] Rollback procedure is complete and independently testable
|
||||
- [ ] Escalation paths name specific contacts, not just team names
|
||||
- [ ] Runbook can be followed by someone who has never touched this system
|
||||
|
||||
## Usage Examples
|
||||
- "Write a runbook for [service] deployment"
|
||||
- "Create an incident response runbook for [alert type]"
|
||||
- "I need a runbook for [procedure]"
|
||||
- "Document the operational procedure for [X]"
|
||||
- "Write an ops playbook for [scenario]"
|
||||
|
||||
@@ -126,3 +126,10 @@ Things to tackle in production but out of scope for this design session:
|
||||
- [ ] At least 2 component deep-dives with technology choices justified
|
||||
- [ ] Trade-offs section is honest (not just benefits of chosen approach)
|
||||
- [ ] Data flow is described end-to-end for the critical path
|
||||
|
||||
## Usage Examples
|
||||
- "Help me answer a system design interview: [question]"
|
||||
- "Design [system] for a system design interview"
|
||||
- "How would I architect [system] at scale?"
|
||||
- "I have a system design interview — the question is [X]"
|
||||
- "Design a [URL shortener / chat system / notification service / feed]"
|
||||
|
||||
@@ -118,3 +118,10 @@ Testing is complete when:
|
||||
- [ ] P0 test cases cover the highest-risk paths specifically
|
||||
- [ ] Each test type names a concrete tool (not "some testing framework")
|
||||
- [ ] Definition of Done is measurable (not "tests are done when QA is happy")
|
||||
|
||||
## Usage Examples
|
||||
- "Write a test strategy for [feature]" + [paste spec or PRD]
|
||||
- "Create a test plan for [system]"
|
||||
- "How should we test [feature]?"
|
||||
- "I need a QA plan for this sprint"
|
||||
- "What tests do we need for [X]?"
|
||||
|
||||
Reference in New Issue
Block a user