Requirement to implementation

Skill emaraschio/cursor-commands/plugin/.cursor/skill-contracts/requirement-to-implementation

Production-grade Cursor slash commands with paired skill contracts, behavioral evals, and ship-gate CI. Install as a user plugin.

Install

npx -y skills add emaraschio/cursor-commands --skill requirement-to-implementation

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

9 stars9 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Structured workflow for taking a requirement (feature, bug, refactor, chore, or performance task) from any source (Notion, GitHub, conversation) through planning, approval, implementation, verification, and documentation. Use when the user provides a requirement, task, ticket, or asks to implement something.

SKILL.md

5.5 KB, as published. Nobody here has run it

Requirement to Implementation

Structured workflow that turns a requirement into verified, documented code. Every task (feature, bug fix, refactor, chore, or performance improvement) flows through the same phases.

Phase 0: Intake

Identify the requirement source and extract key information.

Source	Action
Notion ticket	Use Notion MCP to fetch ticket details, acceptance criteria, and linked context
GitHub issue	Use `gh issue view` to pull title, body, labels, and linked PRs
Conversation	Extract the requirement from what the user described
Sentry issue	Use Sentry MCP to pull error details, stack traces, and affected users

Produce a one-paragraph requirement summary confirming your understanding. Ask the user about literally anything:technical implementation, UI & UX, concerns, tradeoffs, etc. but make sure the questions are not obvious, be very in-depth and continue interviewing me continually until it's complete, then write the plan to the file.

Phase 1: Context Loading

Read the Memory Bank to ground yourself in project state:

.cursor/memory-bank/projectbrief.md: scope and goals
.cursor/memory-bank/productContext.md: product context
.cursor/memory-bank/techContext.md: tech stack and constraints
.cursor/memory-bank/systemPatterns.md: architecture and patterns
.cursor/user-memory-bank/activeContext.md: current focus
.cursor/user-memory-bank/progress.md: what's done, what's pending

If any file is missing or stale, note it; you'll update them in Phase 5.

Phase 2: Exploration & Analysis

Explore the codebase to map the blast radius of the change:

Identify affected files: entry points, services, APIs, jobs, UI, tests
Read existing patterns: find similar implementations to follow
Spot risks: PII/sensitive data exposure, authorization gaps, integration side effects, migration needs
Note test coverage: existing tests that need updating, gaps that need filling

Use exploratory subagents for broad investigations. Use targeted searches for specific lookups.

Phase 3: Plan & Approve

Present a structured plan to the user. Do not implement until approved.

Plan Template

## Requirement
[One-sentence summary]

## Approach
[High-level description of the solution]

## Changes
1. [File/area]: [what changes and why]
2. [File/area]: [what changes and why]
...

## Verification Strategy
- [ ] [How you'll verify correctness (tests, manual checks, etc.)]
- [ ] [Specific test files to create or update]

## Risks & Considerations
- [Anything the user should be aware of]

## Questions (if any)
- [Clarifying questions that surfaced during exploration]

Ask 4-6 clarifying questions if ambiguities remain. Wait for answers before finalizing the plan.

Once the user approves, proceed to implementation.

Phase 4: Implement

Create a TodoWrite task list mirroring the approved plan's changes
Mark each todo in_progress as you begin it, completed when done
Work step by step: one todo at a time, verifying as you go

Verification (flexible per task)

Choose the verification approach that fits:

Task Type	Approach
Bug fix	Write a failing test first, then fix, then verify it passes
New feature	Implement, then write specs covering happy path + edge cases
Refactor	Ensure existing specs still pass, add specs for new behavior
Performance	Benchmark before/after, verify no regression in specs
Chore	Verify with linter, specs, or manual confirmation as appropriate

After each meaningful change, run the project's test command for affected paths (for example npm test, pytest, go test ./..., bundle exec rspec; use what the host repo documents). Fix failures before moving on.

Implementation Principles

Follow existing patterns found in Phase 2
One concern per change: don't mix unrelated modifications
Check lints after substantive edits
If a step reveals the plan was wrong, stop and re-plan with the user

Phase 5: Document

After implementation is complete and verified:

Update .cursor/user-memory-bank/activeContext.md: reflect current focus and recent changes
Update .cursor/user-memory-bank/progress.md: mark what's done, note what's next
Update .cursor/memory-bank/systemPatterns.md: if new patterns were introduced
Update .cursor/memory-bank/techContext.md: if tech stack or constraints changed

Quick Reference: Phase Flow

Intake → Context → Explore → Plan → [Approve] → Implement → Document
  ↑                            ↓
  └──── Re-plan if needed ─────┘

Cardinal rule: No implementation without an approved plan. Plans are cheap; rework is expensive.

Guardrails

No implementation without an approved plan: present the plan and wait for explicit approval before writing production code.
Do not skip intake or exploration on an ambiguous requirement; map the blast radius first.
Commit or push only on explicit user request; never print or commit secrets.