justin/pm-claude-skills
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: v14.0.0 — 12 community-inspired skills, pm-writers profession, extend pm-cross/operations/engineering

Browse Source 
New profession: Writers & Content Creators (pm-writers bundle, skills 156–160)
- instagram-post-downloader: Downloads Instagram images/carousels as high-res files + PDF stitch
- aeo-optimizer: Restructures articles for AI citation (AEO) — question H2s, answer capsules, trust signal audit
- thumbnail-creator: Generates brand-aligned thumbnail candidates via Gemini API with computer vision eval
- substack-notes-scraper: Scrapes Substack Notes engagement data to formatted .xlsx
- notes-humanizer: Strips AI writing patterns across 3 phases; injects genuine human signals

Extended pm-cross (+3 skills, skills 161–163):
- sycophancy-challenger: Argues against your idea first, holds position under pushback
- last-30-days-research: Multi-platform research (Reddit, X, web) with signal confidence scoring
- notebooklm-connector: Automates NotebookLM from Claude Code via Chrome extension

Extended pm-operations (+2 skills, skills 164–165):
- email-triage: Reads Gmail and surfaces only actionable emails with priority + reply starters
- morning-intelligence: 15-question interview → personalised master news brief prompt

Extended pm-engineering (+2 skills, skills 166–167):
- context-mode: Output filtering + session log for long Claude Code sessions
- claude-superpowers: Plan→Isolate→Test→Double-review framework for Claude Code

Updated: marketplace.json v14.0.0 (167 skills, 18 professions, 26 bundles)
Updated: README.md — title, badges, What's New, All 167 Skills table, install list

Credits: skills inspired by Frank & Diana Dovgopol, Gencay (LearnAIwithMe), Karen Spinner (Wondering About AI), Orel (TheIndiepreneur), Joel Salinas (Leadership in Change), Ilia Karelin (Prosper), Ashwin Francis (Cash&Cache), Nate Herk

https://claude.ai/code/session_01E4bTUWxx4Zo5rsFpad5X5B
This commit is contained in:
Mohit Aggarwal
2026-05-27 12:29:45 +00:00
parent 6bb25a8c13
commit 20eda05cc6
16 changed files with 4420 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files
plugins/pm-engineering/skills/claude-superpowers/SKILL.md
+282
View File
@@ -0,0 +1,282 @@
---
name: claude-superpowers
description: "Force Claude Code to work like a senior developer: plan before coding, work in isolation, write tests first, and review its own output twice before presenting it. Use when asked to enable superpowers mode, activate the superpowers framework, or turn on superpowers for this session. Installs a 4-stage framework — Plan, Isolate, Test First, Double Review — that prevents Claude from sprinting into broken code."
---
# Claude Superpowers Skill
Stop Claude from shipping the first thing it writes. Superpowers mode locks Claude into four stages — Plan, Isolate, Test First, Double Review — so that what it presents at the end is actually right.
The default problem: Claude sprints out of the gate, writes the whole thing in one shot, and it looks great — until someone runs it. It doesn't plan. It doesn't test. It doesn't verify. The result: code that breaks on edge cases, debugging rounds that burn tokens, and rework that costs more than doing it right the first time.
> **Credit:** Inspired by a skill from Nate Herk's YouTube channel — adapted and extended for this library.
---
## Required Inputs
No inputs required. Superpowers activates on command, then applies to whatever coding task follows.
---
## The Four Stages
### Stage 1 — Plan
Before writing a single line of code, Claude must produce a written plan and wait for user confirmation.
**Plan format:**
```
PLAN
════
TASK
[One-sentence restatement of what was asked. If anything is ambiguous, flag it here before proceeding.]
APPROACH
[2–4 sentences describing the implementation approach and key decisions. If there are multiple valid approaches, briefly explain why this one was chosen.]
FILES TO CREATE OR MODIFY
- [path/to/file.ts] — [what changes: create / modify / delete — one line reason]
- [path/to/file.ts] — [what changes]
EDGE CASES I WILL HANDLE
- [Edge case 1]
- [Edge case 2]
- [Edge case 3]
EDGE CASES I AM NOT HANDLING (out of scope)
- [Out of scope case — reason]
ASSUMPTIONS
- [Any assumption made where the requirements were unclear]
Confirm this plan before I start coding.
```
Claude must not proceed until the user says yes (or provides corrections). If the user corrects the plan, revise and re-confirm before starting.
---
### Stage 2 — Isolate
Claude works in isolation until the output is complete and reviewed. Nothing touches the main project until explicitly approved.
**Isolation rules:**
- If git is available: create a feature branch before making any changes. Branch name format: `superpowers/[task-slug]`
- If no git: note that changes are being made to a working copy and flag all modified files at the end for user review before they're considered "shipped"
- Do not modify files outside the scope defined in the plan unless the user explicitly expands scope during the session
- If new scope is discovered mid-task (e.g. a dependency needs to change), surface it: "This requires also modifying [X] — should I include that in scope?"
**On starting Stage 2, announce:**
```
ISOLATE
Working in isolation on branch: superpowers/[task-slug]
No changes will be considered final until Stage 4 review is complete.
```
---
### Stage 3 — Test First
Before writing the implementation, write the tests (or at minimum, define the expected behaviour as executable assertions).
**Test-first approach:**
1. Write tests that define the expected behaviour for the task
2. Write tests that cover each edge case identified in the plan
3. Run the tests — they should fail (implementation doesn't exist yet)
4. Confirm the tests are failing for the right reason before writing implementation
5. Write the implementation
6. Run the tests — they should now pass
7. If tests fail: fix the implementation, not the tests
**If the project has no test setup:** flag it and offer two options:
- Option A: Set up a minimal test harness before proceeding (recommended)
- Option B: Define the expected behaviour as a checklist of manual verification steps (faster but weaker)
**Test summary to show before writing implementation:**
```
TESTS WRITTEN
─────────────
File: [test file path]
Tests:
✗ [test description — covers: happy path]
✗ [test description — covers: edge case 1]
✗ [test description — covers: edge case 2]
✗ [test description — covers: error state]
All tests failing as expected. Starting implementation.
```
---
### Stage 4 — Double Review
After completing the code and running tests, Claude reviews its own work twice before presenting it. Neither review is a formality.
**Review 1 — "Does this match what was asked for?"**
Check the completed code against the original request and confirmed plan:
- Does it do everything that was asked?
- Does it handle all edge cases from the plan?
- Are there any mismatches between what was planned and what was built?
- Are there any assumptions baked in that weren't confirmed?
**Review 2 — "Is this good code?"**
Check for technical quality independent of the requirements:
- Obvious bugs or logic errors
- Missing error handling (especially at boundaries: API calls, file I/O, user input)
- Security issues (injection vulnerabilities, exposed secrets, missing auth checks)
- Readability: would another developer understand this in 6 months?
- Performance: any obvious inefficiencies on the critical path?
- Dead code or unused imports introduced
**Double Review output format:**
```
REVIEW 1 — CORRECTNESS
───────────────────────
✅ Handles [requirement 1]
✅ Handles [requirement 2]
✅ Edge case [X] covered
⚠️ [Issue found — what it is and what was changed to fix it]
REVIEW 2 — CODE QUALITY
────────────────────────
✅ Error handling present at all API boundaries
✅ No obvious security issues
⚠️ [Issue found — what it was and how it was fixed]
✅ Readable — no unexplained complexity
VERDICT: [Ready to present / Fixed N issues before presenting]
```
If issues are found in either review, fix them and note what was fixed. Present the corrected version, not the original draft.
---
## Activation Response
When the user triggers Superpowers mode, respond with:
```
Superpowers mode active.
I'll work in 4 stages for every coding task this session:
1. PLAN — Write a plan and wait for your confirmation before coding
2. ISOLATE — Work on a branch; nothing ships until you approve
3. TEST — Write tests before the implementation
4. REVIEW — Review my own work twice before presenting it
What are we building?
```
---
## Output Structure
### Full task flow (all four stages)
```
PLAN
════
[Plan format as above]
Confirm this plan before I start coding.
---
[User confirms]
---
ISOLATE
Working in isolation on branch: superpowers/[task-slug]
TESTS WRITTEN
─────────────
[Test summary — all failing]
Starting implementation.
---
[Implementation runs]
---
REVIEW 1 — CORRECTNESS
───────────────────────
[Checklist]
REVIEW 2 — CODE QUALITY
────────────────────────
[Checklist]
VERDICT: Ready to present.
---
COMPLETE
════════
[Summary of what was built, files created/modified, how to run/test it]
Branch: superpowers/[task-slug] — merge when ready.
```
---
## CLAUDE.md Installation Text
After activating Superpowers for the session, provide the user with the exact text to add to their `CLAUDE.md` to make it permanent:
````
```
## Superpowers Framework
This framework is always active for coding tasks in this project.
### Stage 1 — Plan
Before writing any code: produce a written plan including task restatement, approach, files to create/modify, edge cases to handle, and assumptions. Wait for explicit user confirmation before proceeding.
### Stage 2 — Isolate
Work on a feature branch (superpowers/[task-slug]) or clearly flagged working copy. Nothing is considered shipped until the user approves after Stage 4.
### Stage 3 — Test First
Write tests before writing the implementation. Tests should fail before implementation, pass after. If no test setup exists, offer to create one or produce a manual verification checklist.
### Stage 4 — Double Review
After completing code, run two reviews before presenting:
- Review 1: Does this match what was asked for? Check against original request and plan.
- Review 2: Is this good code? Check for bugs, missing error handling, security issues, readability.
Fix any issues found. Present the corrected version. Show the review checklist.
```
````
Tell the user: "Add this to your CLAUDE.md and Superpowers will be active permanently for this project."
---
## Quality Checks
- [ ] Stage 1 plan was shown and user explicitly confirmed before any code was written
- [ ] Plan includes: task restatement, approach, files to modify, edge cases in scope, edge cases out of scope, assumptions
- [ ] Ambiguities in the original request were flagged in the plan (not silently assumed)
- [ ] Stage 2 isolation: a feature branch was created (or flagged as working copy if no git)
- [ ] Stage 3 tests were written before implementation — not after
- [ ] Tests were run and confirmed to be failing before implementation started
- [ ] Stage 4 Review 1 checked against the original request — not just against the plan
- [ ] Stage 4 Review 2 checked for bugs, error handling, security, readability — all four
- [ ] Issues found in either review were fixed before presenting — not flagged as "things to fix later"
- [ ] Final output shows what was built, which files were changed, and how to run/test it
- [ ] CLAUDE.md installation text was offered after activation
---
## Example Trigger Phrases
- "Enable superpowers mode"
- "Activate superpowers"
- "Turn on superpowers for this session"
- "Use the superpowers framework"
- "Make sure you plan before coding"
- "I want you to review your work before showing me"
- "Write tests first this time"
- "Slow down and plan it out before you start building"
- "Work on a branch and show me a plan before touching anything"
plugins/pm-engineering/skills/context-mode/SKILL.md
+248
View File
@@ -0,0 +1,248 @@
---
name: context-mode
description: "Activate output filtering, session logging, and auto-resume to keep Claude Code sessions running for hours without context bloat or memory loss. Use when asked to enable context mode, turn on long session mode, or activate session persistence. Installs a session log at project root, filters verbose command output before it enters context, and auto-resumes after Claude resets."
---
# Context Mode Skill
Fix the two session killers that end most Claude Code sessions in under 30 minutes: context bloat from raw command output, and memory loss after a reset.
Context Mode runs three systems simultaneously to keep sessions alive:
- **Output Filtering** — strips verbose command output before it enters context
- **Session Log** — writes a running log of everything that happened
- **Auto-Resume** — reads the log on reset and picks up exactly where you left off
> **Credit:** Inspired by a skill from Nate Herk's YouTube channel — adapted and extended for this library.
---
## Required Inputs
No inputs required. Context Mode activates on command.
Optional: user can specify a custom log file path if they don't want `session.log` in the project root.
---
## How Context Mode Works
### Part 1 — Output Filtering
The problem: every time Claude Code runs a command, the full raw output enters the context window. A single `npm install` can dump hundreds of lines. A test suite run? Thousands. Within 30 minutes, the context is full of noise and Claude resets.
The fix: before any command output enters context, filter it to the useful summary only.
**What gets kept:**
- Last 10 lines of stdout
- Every line containing `error`, `warn`, `fail`, `exception`, `traceback`, or `fatal` (case-insensitive)
- The exit code
- A one-line summary of what the command did and whether it succeeded
**What gets discarded:**
- Middle section of long stdout (replaced with `[... N lines of output truncated ...]`)
- Progress bars, download indicators, verbose install logs
- Repeated identical lines (deduplicated)
**Filtering summary format:**
```
COMMAND: [command run]
STATUS: [exit code — success / failed]
SUMMARY: [one sentence: what happened]
ERRORS: [any error/warn lines — or "none"]
TAIL: [last 10 lines of stdout]
```
---
### Part 2 — Session Log
Claude maintains a running log file at `[project root]/session.log`. This file is written after every significant action and is the source of truth for resuming after a reset.
**Session log format:**
```
SESSION LOG
===========
Started: [timestamp]
Branch: [current git branch]
Directory: [working directory]
FILES EDITED
────────────
[timestamp] [file path] — [one-line description of what changed]
COMMANDS RUN
────────────
[timestamp] [command] — [outcome: success / failed — brief reason]
TASKS IN PROGRESS
─────────────────
[ ] [Task description — what's been done so far and what's left]
[x] [Completed task]
LAST USER PROMPT
────────────────
[The most recent instruction from the user, verbatim]
LAST ACTION TAKEN
─────────────────
[What Claude did last, in one sentence]
```
**Log update rules:**
- Write to `session.log` after every file edit
- Write to `session.log` after every command run
- Update "Tasks in Progress" when a task is started, progressed, or completed
- Always overwrite "Last User Prompt" and "Last Action Taken" with the current values — don't append, replace
---
### Part 3 — Resume on Reset
When a new Claude session starts, the first action is:
1. Check for `session.log` in the project root
2. If found, read it and announce the resume:
```
Resuming session.
Branch: [branch]
Last working on: [last task in progress]
Files edited: [list from session log]
Tasks pending: [incomplete tasks]
Last prompt: "[last user prompt]"
Continuing from where we left off.
```
3. Continue with the next logical step — don't ask "what should I do?" — check the task list and carry on
If no `session.log` exists, start fresh and initialise the log.
---
## Activation Response
When the user triggers Context Mode, respond with:
```
Context Mode active.
Session log initialised at: [absolute path to session.log]
Output filtering: enabled
Auto-resume: enabled
I'll maintain your session state across resets. Long sessions won't lose context.
```
Then immediately initialise `session.log` with the current timestamp, branch, and directory.
---
## Output Structure
### On activation
```
Context Mode active.
Session log initialised at: [path]
Output filtering: enabled
Auto-resume: enabled
I'll maintain your session state across resets. Long sessions won't lose context.
```
### On command execution (filtered output format)
```
COMMAND: npm test
STATUS: exit 1 — failed
SUMMARY: 47 tests passed, 3 failed in auth.test.ts
ERRORS: Error: Expected 200, received 401 (line 84)
Error: Token not found in response (line 112)
TAIL:
✓ login with valid credentials (23ms)
✓ logout clears session (11ms)
✗ refresh token after expiry
...
```
### On reset / new session (resume announcement)
```
Resuming session.
Branch: feature/auth-refresh
Last working on: Fixing token refresh logic in auth.service.ts
Files edited: src/auth/auth.service.ts, src/auth/auth.test.ts
Tasks pending: [ ] Fix failing test on line 112
[ ] Run full test suite once fix is applied
Last prompt: "The refresh token test is still failing — look at the 401 handling"
Continuing from where we left off.
```
---
## CLAUDE.md Installation Text
After activating Context Mode for the session, provide the user with the exact text to add to their `CLAUDE.md` to make it permanent across all sessions:
````
```
## Context Mode
Context Mode is always active in this project.
### Output Filtering
Before any command output enters context, filter it to:
- Last 10 lines of stdout
- Any lines containing: error, warn, fail, exception, traceback, fatal (case-insensitive)
- Exit code
- One-line summary of what the command did
Use this format for filtered output:
COMMAND: [command]
STATUS: [exit code — success/failed]
SUMMARY: [one sentence]
ERRORS: [error lines or "none"]
TAIL: [last 10 lines]
### Session Log
Maintain a running session log at ./session.log. Write to it after every file edit and every command run. Track: files edited, commands run, tasks in progress, last user prompt, last action taken. Format defined in Context Mode skill.
### Auto-Resume
At the start of every new session, check for ./session.log. If it exists, read it and announce the resume state. Continue from the last task in progress without asking for instructions.
```
````
Tell the user: "Add this to your CLAUDE.md and Context Mode will be active permanently for this project — even after you close and reopen the session."
---
## Quality Checks
- [ ] `session.log` was initialised immediately on activation (not deferred)
- [ ] Log path shown to user is the absolute path, not relative
- [ ] Output filtering is applied on the very next command run — not just announced
- [ ] Filtered output format includes: command, status, summary, errors, and tail — all five fields
- [ ] Session log tracks all four categories: files edited, commands run, tasks in progress, last prompt
- [ ] Resume announcement reads the actual log contents — not a generic template
- [ ] On resume, Claude continues the work without prompting the user for instructions
- [ ] CLAUDE.md installation text was offered after activation
- [ ] Log update rule is clear: "Last User Prompt" and "Last Action Taken" replace previous values, not append
---
## Example Trigger Phrases
- "Enable context mode"
- "Turn on context mode for this session"
- "Activate long session mode"
- "I keep losing context — fix it"
- "Set up session logging"
- "Keep track of what you've done so you can resume after a reset"
- "Enable output filtering to save context"
- "Set up auto-resume so we don't lose our place"