Verification-driven coding with tight feedback loops. Distilled from 21,321 tracked operations across 64+ projects, 612 debugging sessions, and 2,476 conversation histories. These are the patterns that consistently ship working code.
Works with
AI-first code editor with Composer
Before installing skills in Cursor, ensure your development environment meets these requirements:
node --versionimplementExecute the skills CLI command in your project's root directory to begin installation:
Fetches implement from hyperb1iss/hyperskills and configures it for Cursor.
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
Confirm successful installation by checking the skill directory location:
Restart Cursor to activate implement. Access via /implement in your agent's command palette.
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
Submit your Claude Code skill and start earning
Create detailed user stories, acceptance criteria, and feature specs
Example
Generate user stories for 'password reset feature' with acceptance criteria, edge cases, and test scenarios
Reduce spec writing time by 50%, ensure comprehensive coverage
Research competitors, compare features, identify gaps
Example
Analyze 5 competitor products, create feature comparison matrix, suggest differentiation opportunities
Complete competitive research in 2 hours instead of 2 days
Evaluate features using frameworks (RICE, ICE, Kano) and create prioritized backlogs
Example
Score 20 feature ideas using RICE framework, generate prioritized roadmap with rationale
0
total installs
0
this week
3
GitHub stars
0
upvotes
Run in your terminal
0
installs
0
this week
3
stars
Verification-driven coding with tight feedback loops. Distilled from 21,321 tracked operations across 64+ projects, 612 debugging sessions, and 2,476 conversation histories. These are the patterns that consistently ship working code.
Core insight: 2-3 edits then verify. 73% of fixes go unverified — that's the #1 quality gap. The difference between a clean session and a debugging spiral is verification cadence.
Every implementation follows the same macro-sequence, regardless of scale:
digraph implement {
rankdir=LR;
node [shape=box];
"ORIENT" [style=filled, fillcolor="#e8e8ff"];
"PLAN" [style=filled, fillcolor="#fff8e0"];
"IMPLEMENT" [style=filled, fillcolor="#ffe8e8"];
"VERIFY" [style=filled, fillcolor="#e8ffe8"];
"COMMIT" [style=filled, fillcolor="#e8e8ff"];
"ORIENT" -> "PLAN";
"PLAN" -> "IMPLEMENT";
"IMPLEMENT" -> "VERIFY";
"VERIFY" -> "IMPLEMENT" [label="fix", style=dashed];
"VERIFY" -> "COMMIT" [label="pass"];
}
ORIENT — Read existing code before touching anything. Grep -> Read -> Read is the dominant opening. Sessions that read 10+ files before the first edit require fewer fix iterations. Never start with blind changes.
PLAN — Scale-dependent (see below). Skip for trivial fixes, write a task list for features, run a research swarm for epics.
IMPLEMENT — Work in batches of 2-3 edits, then verify. Follow the dependency chain. Edit existing files 9:1 over creating new ones. Fix errors immediately — don't accumulate them.
VERIFY — Typecheck is the primary gate. Run it after every 2-3 edits. Run tests after feature-complete. Run the full suite before commit.
COMMIT — Tests are the final gate. Stage specific files only, never git add -A. HEREDOC commit messages with conventional commit format.
Strategy changes dramatically based on scope. Pick the right weight class:
| Scale | Edits | Strategy |
|---|---|---|
| Trivial (config, typo) | 1-5 | Read -> Edit -> Verify -> Commit |
| Small fix | 5-20 | Grep error -> Read -> Fix -> Test -> Commit |
| Feature | 50-200 | Plan -> Layer-by-layer impl -> Verify per layer |
| Subsystem | 300-500 | Task planning -> Wave dispatch -> Layer-by-layer |
| Epic | 1000+ | Research swarm -> Spec -> Parallel agents -> Integration |
Skip planning when: Scope is clear, single-file change, fix describable in one sentence.
Plan when: Multiple files, unfamiliar code, uncertain approach.
Build things in this order. Validated across fullstack, Rust, and monorepo projects:
Types/Models -> Backend Logic -> API Routes -> Frontend Types -> Hooks/Client -> UI Components -> Tests
Fullstack (Python + TypeScript):
Rust:
thiserror enum with #[from])impl blocks)mod.rs re-exports)cargo check -> cargo clippy -> cargo testKey finding: Database migrations are written AFTER the code that needs them. Frontend drives backend changes as often as the reverse.
The single most impactful practice. Get this right and everything else follows.
| Gate | When | Speed |
|---|---|---|
| Typecheck | After every 2-3 edits | Fast (primary gate) |
| Lint (autofix) | After implementation batch | Fast |
| Tests (specific) | After feature complete | Medium |
| Tests (full suite) | Before commit | Slow |
| Build | Before PR/deploy only | Slowest |
The sweet spot: 3 changes -> verify -> 1 fix. This is the most common successful pattern.
The expensive pattern: 2 changes -> typecheck -> 15 fixes (type cascade). Prevent by grepping all consumers before modifying shared types.
Combined gates save time: turbo lint:fix typecheck --filter=pkg runs both in one shot. Scope verification to affected packages, never the full monorepo.
Practical tips:
lint:fix BEFORE lint check to reduce iterationscargo check over cargo build (2-3x faster, same error detection)2>&1 | tail -20timeout 120 uv run pytestFamiliar file you edited this session?
Yes -> Edit directly (verify after)
No -> Read it this session?
Yes -> Edit
No -> Read first (79% of quick fixes start with reading)
Self-contained with a clear deliverable?
Yes -> Produces verbose output (tests, logs, research)?
Yes -> Subagent (keeps context clean)
No -> Need frequent back-and-forth?
Yes -> Direct
No -> Subagent
No -> Direct (iterative refinement needs shared context)
Can changes be made incrementally?
Yes -> Move first, THEN consolidate (separate commits)
New code alongside old, remove old only after tests pass
No -> Analysis phase first (parallel review agents)
Gap analysis: old vs new function-by-function
Implement gaps as focused tasks
| Type | Cadence | Typical Cycles |
|---|---|---|
| Bug fix | Grep error -> Read 2-5 files -> Edit 1-3 files -> Test -> Commit | 1-2 |
| Feature | Plan -> Models -> API -> Frontend -> Test -> Commit | 5-15 |
| Refactor | Audit -> Gap analysis -> Incremental migration -> Verify parity | 10-30+ |
| Upgrade | Research changelog -> Identify breaking changes -> Bump -> Fix consumers | Variable |
65% of debugging sessions resolve in 1-2 iterations. The remaining 35% risk spiraling into 6+ iterations.
/clear and start fresh. A clean session with a better prompt beats accumulated corrections every time.If you've corrected the same issue twice, /clear and restart. Accumulated context noise defeats accuracy.
| Anti-Pattern | Fix |
|---|---|
| 20+ edits without verification | Verify every 2-3 edits |
| Fix without verifying the fix (73% of fixes!) | One fix, one verify, repeat |
fix -> fix -> fix chains without checking |
Always verify between fixes |
| Editing without reading first | Read the file immediately before editing |
| Writing tests from memory | Read actual function signatures first |
| Changing shared types without grepping consumers | Grep all usages before modifying shared types |
| Mixing move and change in one commit | Move first commit, change second commit |
| Debugging spiral past 3 attempts | Change approach or escalate |
| Premature optimization | Correctness first, optimize after tests pass |
For high-stakes changes, use /hyperskills:codex-review after implementation. A fresh model context eliminates implementation bias and catches real bugs: migration idempotency, PII in debug logging, empty array edge cases, missing batch limits.
For quantitative benchmarks and implementation archetype templates, consult references/benchmarks.md.
/hyperskills:plan for task decomposition.Make data-driven prioritization decisions faster
Draft PRDs, status updates, and stakeholder presentations
Example
Create executive summary of Q3 roadmap, monthly progress report, feature launch announcement
Save 3-5 hours/week on communication overhead
Prerequisites
Time Estimate
30-60 minutes to see productivity improvements
Steps
Common Pitfalls
✓ Do
✗ Don't
💡 Pro Tips
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
hyperb1iss/hyperskills
mattpocock/skills
parcadei/continuous-claude-v3
cursor/plugins
ailabs-393/ai-labs-claude-skills
pproenca/dot-skills
Keeps context tight: implement is the kind of skill you can hand to a new teammate without a long onboarding doc.
Solid pick for teams standardizing on skills: implement is focused, and the summary matches what you get after install.
We added implement from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
Solid pick for teams standardizing on skills: implement is focused, and the summary matches what you get after install.
We added implement from the explainx registry; install was straightforward and the SKILL.md answered most questions upfront.
Keeps context tight: implement is the kind of skill you can hand to a new teammate without a long onboarding doc.
implement has been reliable in day-to-day use. Documentation quality is above average for community skills.
implement fits our agent workflows well — practical, well scoped, and easy to wire into existing repos.
implement is among the better-maintained entries we tried; worth keeping pinned for repeat workflows.
Registry listing for implement matched our evaluation — installs cleanly and behaves as described in the markdown.
showing 1-10 of 42