mirror of
https://github.com/mattpocock/skills.git
synced 2026-04-30 14:03:53 +07:00
Standardize skill metadata: remove -user suffixes and add missing frontmatter
- Renamed 4 skill directories to remove -user suffix (improve-codebase-architecture, prd-to-issues, prd-to-plan, write-a-prd) - Added frontmatter (name + description) to 5 skills that were missing it (grill-me, prd-to-issues, scaffold-exercises, obsidian-vault, write-a-prd) - Improved vague descriptions on edit-article and request-refactor-plan Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
This commit is contained in:
Matt Pocock
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: edit-article
|
||||
description: The user will invoke this skill to help them edit an article.
|
||||
description: Edit and improve articles by restructuring sections, improving clarity, and tightening prose. Use when user wants to edit, revise, or improve an article draft.
|
||||
---
|
||||
|
||||
1. First, divide the article into sections based on its headings. Think about the main points you want to make during those sections.
|
||||
|
||||
@@ -1 +1,8 @@
|
||||
---
|
||||
name: grill-me
|
||||
description: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".
|
||||
---
|
||||
|
||||
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one.
|
||||
|
||||
If a question can be answered by exploring the codebase, explore the codebase instead.
|
||||
|
||||
@@ -0,0 +1,78 @@
|
||||
# Reference
|
||||
|
||||
## Dependency Categories
|
||||
|
||||
When assessing a candidate for deepening, classify its dependencies:
|
||||
|
||||
### 1. In-process
|
||||
|
||||
Pure computation, in-memory state, no I/O. Always deepenable — just merge the modules and test directly.
|
||||
|
||||
### 2. Local-substitutable
|
||||
|
||||
Dependencies that have local test stand-ins (e.g., PGLite for Postgres, in-memory filesystem). Deepenable if the test substitute exists. The deepened module is tested with the local stand-in running in the test suite.
|
||||
|
||||
### 3. Remote but owned (Ports & Adapters)
|
||||
|
||||
Your own services across a network boundary (microservices, internal APIs). Define a port (interface) at the module boundary. The deep module owns the logic; the transport is injected. Tests use an in-memory adapter. Production uses the real HTTP/gRPC/queue adapter.
|
||||
|
||||
Recommendation shape: "Define a shared interface (port), implement an HTTP adapter for production and an in-memory adapter for testing, so the logic can be tested as one deep module even though it's deployed across a network boundary."
|
||||
|
||||
### 4. True external (Mock)
|
||||
|
||||
Third-party services (Stripe, Twilio, etc.) you don't control. Mock at the boundary. The deepened module takes the external dependency as an injected port, and tests provide a mock implementation.
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
The core principle: **replace, don't layer.**
|
||||
|
||||
- Old unit tests on shallow modules are waste once boundary tests exist — delete them
|
||||
- Write new tests at the deepened module's interface boundary
|
||||
- Tests assert on observable outcomes through the public interface, not internal state
|
||||
- Tests should survive internal refactors — they describe behavior, not implementation
|
||||
|
||||
## Issue Template
|
||||
|
||||
<issue-template>
|
||||
|
||||
## Problem
|
||||
|
||||
Describe the architectural friction:
|
||||
|
||||
- Which modules are shallow and tightly coupled
|
||||
- What integration risk exists in the seams between them
|
||||
- Why this makes the codebase harder to navigate and maintain
|
||||
|
||||
## Proposed Interface
|
||||
|
||||
The chosen interface design:
|
||||
|
||||
- Interface signature (types, methods, params)
|
||||
- Usage example showing how callers use it
|
||||
- What complexity it hides internally
|
||||
|
||||
## Dependency Strategy
|
||||
|
||||
Which category applies and how dependencies are handled:
|
||||
|
||||
- **In-process**: merged directly
|
||||
- **Local-substitutable**: tested with [specific stand-in]
|
||||
- **Ports & adapters**: port definition, production adapter, test adapter
|
||||
- **Mock**: mock boundary for external services
|
||||
|
||||
## Testing Strategy
|
||||
|
||||
- **New boundary tests to write**: describe the behaviors to verify at the interface
|
||||
- **Old tests to delete**: list the shallow module tests that become redundant
|
||||
- **Test environment needs**: any local stand-ins or adapters required
|
||||
|
||||
## Implementation Recommendations
|
||||
|
||||
Durable architectural guidance that is NOT coupled to current file paths:
|
||||
|
||||
- What the module should own (responsibilities)
|
||||
- What it should hide (implementation details)
|
||||
- What it should expose (the interface contract)
|
||||
- How callers should migrate to the new interface
|
||||
|
||||
</issue-template>
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
name: improve-codebase-architecture
|
||||
description: Explore a codebase to find opportunities for architectural improvement, focusing on making the codebase more testable by deepening shallow modules. Use when user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more AI-navigable.
|
||||
---
|
||||
|
||||
# Improve Codebase Architecture
|
||||
|
||||
Explore a codebase like an AI would, surface architectural friction, discover opportunities for improving testability, and propose module-deepening refactors as GitHub issue RFCs.
|
||||
|
||||
A **deep module** (John Ousterhout, "A Philosophy of Software Design") has a small interface hiding a large implementation. Deep modules are more testable, more AI-navigable, and let you test at the boundary instead of inside.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Explore the codebase
|
||||
|
||||
Use the Agent tool with subagent_type=Explore to navigate the codebase naturally. Do NOT follow rigid heuristics — explore organically and note where you experience friction:
|
||||
|
||||
- Where does understanding one concept require bouncing between many small files?
|
||||
- Where are modules so shallow that the interface is nearly as complex as the implementation?
|
||||
- Where have pure functions been extracted just for testability, but the real bugs hide in how they're called?
|
||||
- Where do tightly-coupled modules create integration risk in the seams between them?
|
||||
- Which parts of the codebase are untested, or hard to test?
|
||||
|
||||
The friction you encounter IS the signal.
|
||||
|
||||
### 2. Present candidates
|
||||
|
||||
Present a numbered list of deepening opportunities. For each candidate, show:
|
||||
|
||||
- **Cluster**: Which modules/concepts are involved
|
||||
- **Why they're coupled**: Shared types, call patterns, co-ownership of a concept
|
||||
- **Dependency category**: See [REFERENCE.md](REFERENCE.md) for the four categories
|
||||
- **Test impact**: What existing tests would be replaced by boundary tests
|
||||
|
||||
Do NOT propose interfaces yet. Ask the user: "Which of these would you like to explore?"
|
||||
|
||||
### 3. User picks a candidate
|
||||
|
||||
### 4. Frame the problem space
|
||||
|
||||
Before spawning sub-agents, write a user-facing explanation of the problem space for the chosen candidate:
|
||||
|
||||
- The constraints any new interface would need to satisfy
|
||||
- The dependencies it would need to rely on
|
||||
- A rough illustrative code sketch to make the constraints concrete — this is not a proposal, just a way to ground the constraints
|
||||
|
||||
Show this to the user, then immediately proceed to Step 5. The user reads and thinks about the problem while the sub-agents work in parallel.
|
||||
|
||||
### 5. Design multiple interfaces
|
||||
|
||||
Spawn 3+ sub-agents in parallel using the Agent tool. Each must produce a **radically different** interface for the deepened module.
|
||||
|
||||
Prompt each sub-agent with a separate technical brief (file paths, coupling details, dependency category, what's being hidden). This brief is independent of the user-facing explanation in Step 4. Give each agent a different design constraint:
|
||||
|
||||
- Agent 1: "Minimize the interface — aim for 1-3 entry points max"
|
||||
- Agent 2: "Maximize flexibility — support many use cases and extension"
|
||||
- Agent 3: "Optimize for the most common caller — make the default case trivial"
|
||||
- Agent 4 (if applicable): "Design around the ports & adapters pattern for cross-boundary dependencies"
|
||||
|
||||
Each sub-agent outputs:
|
||||
|
||||
1. Interface signature (types, methods, params)
|
||||
2. Usage example showing how callers use it
|
||||
3. What complexity it hides internally
|
||||
4. Dependency strategy (how deps are handled — see [REFERENCE.md](REFERENCE.md))
|
||||
5. Trade-offs
|
||||
|
||||
Present designs sequentially, then compare them in prose.
|
||||
|
||||
After comparing, give your own recommendation: which design you think is strongest and why. If elements from different designs would combine well, propose a hybrid. Be opinionated — the user wants a strong read, not just a menu.
|
||||
|
||||
### 6. User picks an interface (or accepts recommendation)
|
||||
|
||||
### 7. Create GitHub issue
|
||||
|
||||
Create a refactor RFC as a GitHub issue using `gh issue create`. Use the template in [REFERENCE.md](REFERENCE.md). Do NOT ask the user to review before creating — just create it and share the URL.
|
||||
@@ -1,3 +1,8 @@
|
||||
---
|
||||
name: obsidian-vault
|
||||
description: Search, create, and manage notes in the Obsidian vault with wikilinks and index notes. Use when user wants to find, create, or organize notes in Obsidian.
|
||||
---
|
||||
|
||||
# Obsidian Vault
|
||||
|
||||
## Vault location
|
||||
|
||||
@@ -1,3 +1,8 @@
|
||||
---
|
||||
name: prd-to-issues
|
||||
description: Break a PRD into independently-grabbable GitHub issues using tracer-bullet vertical slices. Use when user wants to convert a PRD to issues, create implementation tickets, or break down a PRD into work items.
|
||||
---
|
||||
|
||||
# PRD to Issues
|
||||
|
||||
Break a PRD into independently-grabbable GitHub issues using vertical slices (tracer bullets).
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: request-refactor-plan
|
||||
description: Use this skill when user wants to create a refactor plan.
|
||||
description: Create a detailed refactor plan with tiny commits via user interview, then file it as a GitHub issue. Use when user wants to plan a refactor, create a refactoring RFC, or break a refactor into safe incremental steps.
|
||||
---
|
||||
|
||||
This skill will be invoked when the user wants to create a refactor request. You should go through the steps below. You may skip steps if you don't consider them necessary.
|
||||
|
||||
@@ -1,6 +1,11 @@
|
||||
---
|
||||
name: scaffold-exercises
|
||||
description: Create exercise directory structures with sections, problems, solutions, and explainers that pass linting. Use when user wants to scaffold exercises, create exercise stubs, or set up a new course section.
|
||||
---
|
||||
|
||||
# Scaffold Exercises
|
||||
|
||||
Create exercise directory structures that pass `pnpm ai-hero-cli internal lint`.
|
||||
Create exercise directory structures that pass `pnpm ai-hero-cli internal lint`, then commit with `git commit`.
|
||||
|
||||
## Directory naming
|
||||
|
||||
|
||||
@@ -0,0 +1,102 @@
|
||||
---
|
||||
name: triage-issue
|
||||
description: Triage a bug or issue by exploring the codebase to find root cause, then create a GitHub issue with a TDD-based fix plan. Use when user reports a bug, wants to file an issue, mentions "triage", or wants to investigate and plan a fix for a problem.
|
||||
---
|
||||
|
||||
# Triage Issue
|
||||
|
||||
Investigate a reported problem, find its root cause, and create a GitHub issue with a TDD fix plan. This is a mostly hands-off workflow - minimize questions to the user.
|
||||
|
||||
## Process
|
||||
|
||||
### 1. Capture the problem
|
||||
|
||||
Get a brief description of the issue from the user. If they haven't provided one, ask ONE question: "What's the problem you're seeing?"
|
||||
|
||||
Do NOT ask follow-up questions yet. Start investigating immediately.
|
||||
|
||||
### 2. Explore and diagnose
|
||||
|
||||
Use the Agent tool with subagent_type=Explore to deeply investigate the codebase. Your goal is to find:
|
||||
|
||||
- **Where** the bug manifests (entry points, UI, API responses)
|
||||
- **What** code path is involved (trace the flow)
|
||||
- **Why** it fails (the root cause, not just the symptom)
|
||||
- **What** related code exists (similar patterns, tests, adjacent modules)
|
||||
|
||||
Look at:
|
||||
- Related source files and their dependencies
|
||||
- Existing tests (what's tested, what's missing)
|
||||
- Recent changes to affected files (`git log` on relevant files)
|
||||
- Error handling in the code path
|
||||
- Similar patterns elsewhere in the codebase that work correctly
|
||||
|
||||
### 3. Identify the fix approach
|
||||
|
||||
Based on your investigation, determine:
|
||||
|
||||
- The minimal change needed to fix the root cause
|
||||
- Which modules/interfaces are affected
|
||||
- What behaviors need to be verified via tests
|
||||
- Whether this is a regression, missing feature, or design flaw
|
||||
|
||||
### 4. Design TDD fix plan
|
||||
|
||||
Create a concrete, ordered list of RED-GREEN cycles. Each cycle is one vertical slice:
|
||||
|
||||
- **RED**: Describe a specific test that captures the broken/missing behavior
|
||||
- **GREEN**: Describe the minimal code change to make that test pass
|
||||
|
||||
Rules:
|
||||
- Tests verify behavior through public interfaces, not implementation details
|
||||
- One test at a time, vertical slices (NOT all tests first, then all code)
|
||||
- Each test should survive internal refactors
|
||||
- Include a final refactor step if needed
|
||||
- **Durability**: Only suggest fixes that would survive radical codebase changes. Describe behaviors and contracts, not internal structure. Tests assert on observable outcomes (API responses, UI state, user-visible effects), not internal state. A good suggestion reads like a spec; a bad one reads like a diff.
|
||||
|
||||
### 5. Create the GitHub issue
|
||||
|
||||
Create a GitHub issue using `gh issue create` with the template below. Do NOT ask the user to review before creating - just create it and share the URL.
|
||||
|
||||
<issue-template>
|
||||
|
||||
## Problem
|
||||
|
||||
A clear description of the bug or issue, including:
|
||||
- What happens (actual behavior)
|
||||
- What should happen (expected behavior)
|
||||
- How to reproduce (if applicable)
|
||||
|
||||
## Root Cause Analysis
|
||||
|
||||
Describe what you found during investigation:
|
||||
- The code path involved
|
||||
- Why the current code fails
|
||||
- Any contributing factors
|
||||
|
||||
Do NOT include specific file paths, line numbers, or implementation details that couple to current code layout. Describe modules, behaviors, and contracts instead. The issue should remain useful even after major refactors.
|
||||
|
||||
## TDD Fix Plan
|
||||
|
||||
A numbered list of RED-GREEN cycles:
|
||||
|
||||
1. **RED**: Write a test that [describes expected behavior]
|
||||
**GREEN**: [Minimal change to make it pass]
|
||||
|
||||
2. **RED**: Write a test that [describes next behavior]
|
||||
**GREEN**: [Minimal change to make it pass]
|
||||
|
||||
...
|
||||
|
||||
**REFACTOR**: [Any cleanup needed after all tests pass]
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Criterion 1
|
||||
- [ ] Criterion 2
|
||||
- [ ] All new tests pass
|
||||
- [ ] Existing tests still pass
|
||||
|
||||
</issue-template>
|
||||
|
||||
After creating the issue, print the issue URL and a one-line summary of the root cause.
|
||||
@@ -1,4 +1,9 @@
|
||||
This skill will be invoked when the user wants to create a PRD. You should go through the steps below. You may skip steps if you don't consider them necessary.
|
||||
---
|
||||
name: write-a-prd
|
||||
description: Create a PRD through user interview, codebase exploration, and module design, then submit as a GitHub issue. Use when user wants to write a PRD, create a product requirements document, or plan a new feature.
|
||||
---
|
||||
|
||||
This skill will be invoked when the user wants to create a PRD. You may skip steps if you don't consider them necessary.
|
||||
|
||||
1. Ask the user for a long, detailed description of the problem they want to solve and any potential ideas for solutions.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user