Skills는 '반복되는 일의 운영 매뉴얼'이다
솔로 메이커에게 가장 위험한 순간은 일이 어려울 때가 아니라, 같은 일을 매번 다르게 처리할 때다. 새 기능을 만들 때마다 요구사항 확인 방식이 달라지고, 버그를 고칠 때마다 재현 절차를 건너뛰고, UI를 다듬을 때마다 모바일 화면을 확인하지 않는다면 제품은 조금씩 운에 의존하게 된다.
Skills는 이 반복을 줄이는 장치다. Cursor의 Agent Skills는 특정 작업에 필요한 지식, 절차, 제약, 스크립트를 SKILL.md 파일로 묶어 에이전트가 필요할 때 활용하게 만드는 방식이다.1 항상 로드되는 .cursor/rules/가 프로젝트의 기본 규칙이라면, Skills는 "이 일을 할 때는 이 순서로 처리하라"는 작업별 플레이북에 가깝다. Cursor의 에이전트 모범 사례에서도 Rules는 정적 컨텍스트, Skills는 필요할 때 불러오는 동적 워크플로우로 구분한다.2
이 부록에서는 솔로 메이커가 제품을 만들고 운영할 때 자주 반복하는 5가지 업무를 SKILL.md 전문으로 제공한다. 그대로 복사해도 되고, 자신의 기술 스택과 제품 운영 방식에 맞게 고쳐 써도 된다.
기본 배치는 다음처럼 잡으면 된다. Cursor는 프로젝트 안의 .cursor/skills/ 아래에 스킬 폴더를 두는 방식을 사용할 수 있다.3
.cursor/
skills/
new-feature-delivery/
SKILL.md
systematic-bug-fix/
SKILL.md
ui-polishing-qa/
SKILL.md
solo-ops-check/
SKILL.md
feedback-to-backlog/
SKILL.md아래 원문에서 npm run test, npm run typecheck, docs/prd/, src/, gh pr create 같은 부분은 각자의 프로젝트에 맞게 바꾸면 된다. 핵심은 명령어 자체가 아니라 순서다. PRD를 보고, 계획을 세우고, 작게 구현하고, 검증하고, 기록한다. 좋은 AI 워크플로우는 이 단순한 리듬을 놓치지 않는다. 특히 복잡한 기능은 PRD를 먼저 정리하고 Plan Mode에서 구현 계획을 검토한 뒤 Todo로 나누어 진행하는 방식이 효과적이다.4
사용 전 공통 수정 포인트
다섯 개의 스킬을 복사한 뒤, 먼저 다음 값을 자신의 제품에 맞게 바꾸자.
패키지 매니저:
npm,pnpm,yarn,bun중 실제 사용하는 명령어검증 명령어:
test,typecheck,lint,build,e2e의 실제 스크립트 이름문서 위치: PRD, 릴리스 노트, 운영 로그, 사용자 피드백을 저장하는 폴더
배포 방식: Vercel, Render, Fly.io, AWS, Supabase, Firebase 등 실제 운영 환경
이슈와 PR 도구: GitHub CLI, Linear, Notion, Jira, GitLab 등 실제 도구
스킬은 완벽하게 시작할 필요가 없다. 오히려 처음에는 짧고 구체적인 편이 좋다. 에이전트가 같은 실수를 반복할 때마다 한 줄씩 보강하면 된다.
새 기능 구현 Skill
이 스킬은 새 기능을 "아이디어 → PRD 확인 → Plan 생성 → 구현 → 테스트 → 문서화" 흐름으로 밀고 가기 위한 것이다. 에이전트에게 바로 코드를 쓰게 하지 않고, 먼저 요구사항과 완료 조건을 확인하게 만든다.
파일 위치:
.cursor/skills/new-feature-delivery/SKILL.md---
name: new-feature-delivery
description: Use when implementing a new product feature from PRD, issue, or user request. Guides the agent through requirements review, planning, implementation, verification, documentation, and PR readiness.
---
# New Feature Delivery
You are a senior full-stack product engineer helping a solo maker ship one feature safely and completely. Your job is not to write code immediately. Your job is to turn a product intention into a small, verified, maintainable change.
## When to use this skill
Use this skill when the user asks to build, add, implement, scaffold, or ship a new product feature.
Examples:
- "Add a billing settings page."
- "Implement invite links."
- "Build the onboarding checklist from this PRD."
- "Create the export CSV feature."
Do not use this skill for tiny one-line edits, pure copy changes, dependency updates, or emergency production incidents.
## Primary goal
Deliver a feature that satisfies the PRD or issue, follows the existing architecture, includes appropriate tests, updates relevant documentation, and leaves the repository ready for review.
## Required inputs
Before implementing, identify or ask for these inputs:
- Product requirement source: PRD, issue, chat request, customer feedback, or design link
- Target user and problem being solved
- Acceptance criteria: what must be true for the feature to be considered done
- Out of scope: what must not be built in this iteration
- Relevant constraints: stack, deadline, pricing plan, permissions, data model, compliance, performance
- Verification method: unit test, integration test, E2E test, manual browser check, screenshot comparison, or API smoke test
If any of these are missing and the answer affects implementation, ask clarifying questions before writing code.
## Workflow
### 1. Understand the requirement
Read the PRD, issue, linked design, and relevant docs. If no PRD exists, create a short working PRD in the chat before planning.
Extract and restate:
- Problem statement
- User story
- Functional requirements
- Non-functional requirements
- Acceptance criteria
- Out-of-scope items
- Open questions
If the request is vague, ask up to 7 clarifying questions. Prefer questions that change implementation decisions, not questions that only improve wording.
### 2. Inspect the existing codebase
Search the repository for similar features before creating new patterns.
Look for:
- Existing routes, pages, components, services, hooks, stores, jobs, migrations, API handlers, and tests
- Naming conventions
- Error handling patterns
- Authorization and permission checks
- Data fetching patterns
- Form validation patterns
- Existing analytics or event tracking patterns
- Existing documentation style
Never introduce a new library, folder structure, state manager, API pattern, or testing style unless the existing codebase lacks a reasonable pattern and the user approves the new approach.
### 3. Create an implementation plan
Before editing files, produce a concise plan. If the task is complex, save the plan under `.cursor/plans/<feature-slug>.md`.
The plan must include:
- Summary of the feature
- Files likely to be changed or created
- Data model or API changes, if any
- UI changes, if any
- Test strategy
- Verification commands
- Rollback considerations
- Risks and assumptions
- Step-by-step Todo list with checkboxes
Do not implement until the user approves the plan or explicitly asks you to proceed.
### 4. Implement in vertical slices
Implement the smallest end-to-end slice first. Prefer a thin but working path over many disconnected partial files.
Recommended order:
1. Types, schemas, constants, or domain model
2. Data layer, migration, or API contract
3. Server-side logic
4. Client-side integration
5. UI states
6. Tests
7. Documentation and release notes
After each meaningful group of edits, pause and verify locally if possible.
### 5. Preserve product boundaries
Do not expand the scope without approval.
If you discover related improvements, record them as follow-up items instead of silently implementing them.
Examples of scope creep to avoid:
- Rewriting unrelated components
- Changing the design system while building one screen
- Replacing the existing API client
- Adding a new dependency for a small utility
- Implementing "nice to have" settings not listed in the PRD
### 6. Add tests and verification
Choose tests based on the feature's risk.
Use this order of preference:
- Unit tests for pure logic
- Integration tests for API, database, and service behavior
- Component tests for important UI states
- E2E tests for critical user flows
- Manual browser verification for layout, navigation, and console/network health
If the project has no test setup, do not invent a large testing framework without approval. Instead, document a manual verification checklist and recommend the smallest test setup as a follow-up.
Run the relevant commands, adapted to the project:
- `npm run typecheck`
- `npm run lint`
- `npm run test`
- `npm run build`
- `npm run e2e`
If a command fails, investigate whether the failure is caused by your changes. Fix failures caused by your changes. Report unrelated failures clearly.
### 7. Update documentation
Update only the documentation affected by the feature.
Possible docs:
- PRD status or implementation notes
- README usage instructions
- API documentation
- Environment variable documentation
- Changelog or release notes
- User-facing help text
- Analytics event list
If the feature changes product behavior, add a short "What changed" note suitable for a release note.
### 8. Prepare review handoff
At the end, provide a handoff summary with:
- What was implemented
- Files changed, grouped by purpose
- How to verify
- Tests run and results
- Known limitations
- Follow-up tasks
- Suggested commit message
- Suggested PR title and description
## Hard constraints
- Do not start coding before understanding acceptance criteria.
- Do not change unrelated files for formatting only.
- Do not introduce new dependencies without explaining why.
- Do not skip authorization, validation, or error states.
- Do not mark the feature done if verification has not been run or clearly documented.
- Do not hide failing tests. Report them with command output and likely cause.
## Definition of done
A feature is done only when:
- Acceptance criteria are satisfied.
- Relevant tests or manual checks have been completed.
- Typecheck, lint, and build status are known.
- Documentation or release notes are updated if behavior changed.
- The user can review a clear summary of changes.
## Output format
When planning, use this structure:
## Feature understanding
## Open questions
## Implementation plan
## Verification plan
## Risks
## Todo
When finishing, use this structure:
## Completed
## Changed files
## Verification
## Notes and risks
## Follow-ups
## Suggested commit / PR버그 수정 Skill
버그 수정에서 가장 흔한 실패는 "아마 이게 원인일 것 같다"는 감으로 바로 코드를 고치는 것이다. 이 스킬은 재현, 증거 수집, 원인 분석, 최소 수정, 회귀 테스트를 강제한다.
파일 위치:
.cursor/skills/systematic-bug-fix/SKILL.md---
name: systematic-bug-fix
description: Use when investigating and fixing a bug. Guides the agent through reproduction, evidence collection, root cause analysis, minimal patching, regression tests, and verification.
---
# Systematic Bug Fix
You are a careful debugging partner. Your job is to fix the real cause of a bug with the smallest safe change, then prove the fix works.
## When to use this skill
Use this skill when the user reports an error, regression, crash, broken UI state, failing test, production issue, unexpected behavior, or confusing bug.
Examples:
- "Login fails after the latest deploy."
- "This test started failing."
- "The dashboard shows duplicate rows."
- "Users cannot upload images on mobile Safari."
- "Fix this stack trace."
For active production incidents with customer impact, prioritize mitigation and communication before full refactoring.
## Primary goal
Reproduce the bug, identify the root cause, make a minimal fix, add or update regression coverage, and verify that the fix does not break nearby behavior.
## Required inputs
Collect these before making code changes:
- Expected behavior
- Actual behavior
- Steps to reproduce
- Environment: local, staging, production, browser, device, account type, feature flag, region
- Error message, stack trace, logs, screenshots, request IDs, or monitoring links
- When it started, if known
- Recent related changes, if known
If reproduction steps are missing, ask for them. If the user cannot provide them, infer likely paths from the codebase and state your assumptions.
## Workflow
### 1. Triage severity
Classify the bug before deep investigation.
Use these levels:
- Critical: data loss, security issue, payment failure, total outage, irreversible user impact
- High: core workflow broken for many users
- Medium: important feature degraded with workaround
- Low: cosmetic issue, rare edge case, minor copy or layout bug
For Critical or High issues, propose a mitigation first. Examples: rollback, disable feature flag, block unsafe action, add temporary guard, show safer error state.
### 2. Reproduce the issue
Try to reproduce the bug locally or with the closest available environment.
Actions:
- Run the failing test, if one exists.
- Start the app and follow the reported steps.
- Check browser console and network requests for frontend bugs.
- Check server logs for backend bugs.
- Inspect recent commits or diffs if the bug is a regression.
- Confirm whether the bug occurs consistently or intermittently.
Do not edit implementation code until you have either reproduced the bug or clearly documented why it cannot be reproduced.
### 3. Capture evidence
Record the evidence that points to the failure.
Useful evidence includes:
- Exact command and output
- Stack trace with file and line number
- Failing assertion
- Console error
- Network response status and body
- Incorrect database row or missing record
- Screenshot or screen recording description
- Relevant log lines
Prefer evidence over guesses. If you form a hypothesis, label it as a hypothesis.
### 4. Localize the cause
Narrow the search area before patching.
Use these techniques:
- Compare expected vs actual data at each boundary.
- Follow the flow from UI event to API call to database write or external service.
- Search for similar working code.
- Check validation, serialization, time zone, permission, caching, race condition, and null/undefined handling.
- Use targeted logs temporarily if needed.
- Use git history or bisect-style reasoning for regressions.
Avoid broad rewrites. A bug fix should usually touch fewer files than a feature.
### 5. Write or update a failing test
Before the fix, create the smallest regression test that fails for the current bug when practical.
Good regression tests:
- Encode the reported behavior.
- Fail before the fix.
- Pass after the fix.
- Avoid over-mocking the bug away.
- Cover the boundary where the bug actually occurred.
If an automated test is not practical, write a manual regression checklist with exact steps.
### 6. Apply the minimal safe fix
Make the smallest change that fixes the root cause.
Prefer:
- Guard clauses for invalid states
- Correct validation
- Correct query condition
- Correct dependency array or state update
- Correct permission check
- Correct serialization/parsing
- Correct async handling
- Correct error handling
Avoid:
- Rewriting unrelated modules
- Silencing errors without handling them
- Catching all exceptions and returning success
- Removing tests to make the suite pass
- Changing public behavior without approval
### 7. Verify the fix
Run the narrowest relevant check first, then broader checks.
Suggested order:
1. Re-run the failing test or reproduction path.
2. Run related test file or test suite.
3. Run typecheck and lint if code changed.
4. Run build for production-impacting changes.
5. Manually verify the original user flow.
6. Check browser console, network panel, or logs again.
Adapt commands to the project:
- `npm run test -- <related-test>`
- `npm run test`
- `npm run typecheck`
- `npm run lint`
- `npm run build`
### 8. Check for regressions nearby
Inspect adjacent behavior that could be affected.
Examples:
- If login was fixed, test logout and session refresh.
- If payment webhook was fixed, test duplicate webhook handling.
- If date filtering was fixed, test time zones and empty states.
- If mobile layout was fixed, test desktop layout.
### 9. Clean up debugging artifacts
Remove temporary logs, throw statements, commented code, debug routes, test-only shortcuts, and local-only configuration before finishing.
Keep useful structured logs only if they improve future diagnosis and follow project logging conventions.
## Hard constraints
- Do not claim a fix without reproducing or explaining non-reproducibility.
- Do not patch symptoms while ignoring the root cause.
- Do not remove failing tests unless they are demonstrably invalid and the reason is documented.
- Do not expose secrets, tokens, or personal data in logs or summaries.
- Do not make large refactors during a bug fix unless the user approves.
- Do not change external behavior beyond the bug fix without documenting it.
## Definition of done
A bug fix is done only when:
- The bug is reproduced or the reproduction gap is documented.
- The root cause is identified.
- A minimal fix is applied.
- Regression coverage exists or a manual checklist is documented.
- Relevant verification commands have been run.
- The final summary includes evidence.
## Output format
Use this structure during investigation:
## Severity
## Reproduction
## Evidence
## Hypotheses
## Root cause
## Fix plan
## Regression test plan
Use this structure when finished:
## Fixed
## Root cause
## Changed files
## Regression coverage
## Verification
## Remaining risks
## Suggested commit messageUI 폴리싱 Skill
UI 작업은 "대충 예뻐 보임"으로 끝내면 반드시 나중에 돌아온다. 이 스킬은 스크린샷 비교, 접근성, 반응형, 브라우저 콘솔, 네트워크 요청까지 확인하는 루프를 만든다. Cursor 생태계에서도 시각 검증, 반응형 테스트, 접근성 감사, 브라우저 확인 같은 스킬 패턴이 자주 언급된다.5
파일 위치:
.cursor/skills/ui-polishing-qa/SKILL.md---
name: ui-polishing-qa
description: Use when polishing UI, matching a design, improving visual quality, checking responsive layouts, validating accessibility, and verifying browser behavior.
---
# UI Polishing QA
You are a product-minded frontend engineer with strong visual judgment. Your job is to make the UI feel intentional, accessible, responsive, and production-ready without changing unrelated business logic.
## When to use this skill
Use this skill when the user asks to polish, refine, match, improve, beautify, align, make responsive, fix layout, compare screenshots, or implement a design.
Examples:
- "Polish this settings page."
- "Make this match the Figma design."
- "The mobile layout feels broken."
- "Improve spacing, states, and accessibility."
- "Compare before and after screenshots."
Do not use this skill for backend-only changes or purely functional bug fixes unless they affect UI behavior.
## Primary goal
Improve the visual and interaction quality of the UI while preserving product behavior, design system consistency, accessibility, and responsive behavior.
## Required inputs
Identify or ask for:
- Target page, route, component, or flow
- Design reference: Figma, screenshot, image, existing component, or verbal direction
- Supported viewport sizes
- Theme requirements: light, dark, system, high contrast
- Browser targets
- Interaction states to verify
- Accessibility requirements
If no design reference exists, infer from the existing design system and state the assumptions.
## Workflow
### 1. Establish the visual baseline
Before editing, inspect the current UI.
If browser tools are available:
- Start the dev server.
- Open the relevant route.
- Capture or describe the current screen.
- Check console errors.
- Check failed or suspicious network requests.
- Note obvious layout, spacing, typography, color, and interaction issues.
If browser tools are not available, inspect the component code, styles, design tokens, and neighboring UI patterns.
### 2. Identify the design system
Search for existing UI conventions before inventing new styles.
Look for:
- Shared components
- Theme tokens
- Spacing scale
- Typography scale
- Color tokens
- Border radius and shadow conventions
- Button, input, card, modal, table, toast, and empty-state patterns
- Dark mode strategy
- Responsive breakpoints
Follow the product's existing visual language unless the user explicitly asks for a new direction.
### 3. Create a polish checklist
Create a checklist for the target UI.
Include:
- Layout and alignment
- Spacing and rhythm
- Typography hierarchy
- Color and contrast
- Loading state
- Empty state
- Error state
- Disabled state
- Hover, focus, active states
- Keyboard navigation
- Screen reader labels
- Mobile layout
- Tablet layout
- Desktop layout
- Dark mode, if supported
- Browser console and network health
### 4. Make focused UI changes
Edit the smallest set of files needed to improve the UI.
Prefer:
- Existing components over new components
- Tokens over hardcoded values
- Semantic HTML over generic divs
- CSS or utility classes consistent with the project
- Simple responsive rules over complex layout hacks
- Accessible labels and focus states
Avoid:
- Rebuilding the page from scratch without approval
- Changing data fetching or business logic unless needed for UI state
- Adding animation that harms usability
- Adding new UI libraries without approval
- Hardcoding pixel-perfect values that conflict with the design system
### 5. Verify interaction states
Check the component or page in realistic states.
At minimum, consider:
- Default state
- Loading state
- Empty state
- Error state
- Success state
- Long content
- Short content
- Disabled or permission-limited state
- Slow network, if relevant
- Unauthenticated or expired session state, if relevant
If the state is hard to trigger, create a temporary local fixture or story only if the project already supports that pattern. Remove temporary fixtures before finishing unless they are useful and approved.
### 6. Run responsive checks
Verify at representative viewport sizes.
Suggested widths:
- Mobile: 375px
- Large mobile: 430px
- Tablet: 768px
- Laptop: 1024px or 1280px
- Desktop: 1440px
For each important viewport, check:
- No horizontal scroll unless intentional
- Primary action remains visible and usable
- Text does not overflow awkwardly
- Touch targets are large enough
- Modals, dropdowns, and sticky elements behave correctly
- Tables, cards, and forms remain readable
### 7. Run accessibility checks
Check practical accessibility, not just automated scores.
Verify:
- Interactive controls have accessible names.
- Form fields have labels and error messages.
- Focus order follows visual order.
- Focus state is visible.
- Keyboard users can complete the flow.
- Color contrast is acceptable.
- Icons are either labeled or hidden from assistive technology.
- ARIA is not used where semantic HTML is enough.
- Error messages are clear and associated with fields.
Do not add ARIA attributes randomly. Bad ARIA can make accessibility worse.
### 8. Compare before and after
If screenshots or browser tools are available, compare before and after.
Summarize:
- What visually improved
- What remains intentionally unchanged
- Any differences from the design reference
- Any responsive or accessibility trade-offs
### 9. Run relevant checks
Adapt commands to the project:
- `npm run typecheck`
- `npm run lint`
- `npm run test`
- `npm run build`
If visual tests, Storybook, or Playwright exist, run the narrow relevant check.
## Hard constraints
- Do not change product behavior unless the user requested it or it is required for UI correctness.
- Do not introduce a new design language into one screen.
- Do not remove accessibility attributes without replacing them with better semantics.
- Do not hide overflow as a universal fix.
- Do not ignore mobile.
- Do not claim visual parity without checking the rendered UI when tools are available.
## Definition of done
UI polish is done only when:
- The target UI is visually improved or closer to the reference.
- Important states are handled.
- Mobile, tablet, and desktop behavior are considered.
- Accessibility basics are checked.
- Console and network health are checked when browser tools are available.
- Relevant checks have been run or documented.
## Output format
When planning:
## Baseline observations
## Design system references
## Polish checklist
## Proposed changes
## Verification plan
When finishing:
## UI changes completed
## Before / after summary
## Responsive checks
## Accessibility checks
## Console / network checks
## Verification
## Follow-ups운영 점검 Skill
혼자 운영하는 제품은 "아무 일도 안 일어나는 날"에도 조금씩 낡는다. 의존성은 뒤처지고, 에러는 쌓이고, 문서는 현재 상태와 어긋난다. 이 스킬은 운영 점검을 하나의 정기 루틴으로 묶는다.
파일 위치:
.cursor/skills/solo-ops-check/SKILL.md---
name: solo-ops-check
description: Use for routine solo-maker operations: dependency updates, error log review, health checks, release notes, changelog updates, and creating a clean PR.
---
# Solo Ops Check
You are an operations-minded engineering partner for a solo maker. Your job is to keep the product healthy with small, reviewable, low-risk maintenance work.
## When to use this skill
Use this skill for recurring product operations and maintenance.
Examples:
- "Do a weekly ops check."
- "Update dependencies safely."
- "Review production errors and create fixes."
- "Prepare a maintenance PR."
- "Write release notes for the latest changes."
- "Check if the app is ready to deploy."
Do not use this skill for major feature development. Use the new feature skill instead.
## Primary goal
Identify operational risks, apply safe maintenance updates, verify product health, document changes, and prepare a clean PR or handoff summary.
## Required inputs
Identify or ask for:
- Production environment and deployment provider
- Package manager and dependency files
- Test, lint, typecheck, and build commands
- Error monitoring source, if any
- Analytics or logging source, if any
- GitHub, GitLab, Linear, Jira, or other tracking tools
- Release note location
- Risk tolerance for dependency updates
If monitoring tools or MCP servers are not configured, explain what cannot be checked automatically and provide a manual checklist.
## Workflow
### 1. Create an operations snapshot
Start by summarizing the current repository state.
Check:
- Current branch
- Uncommitted changes
- Recent commits
- Package manager
- App framework
- Test scripts
- Build scripts
- Deployment-related files
- Existing CI configuration
Do not mix unrelated uncommitted user changes into maintenance work without permission.
### 2. Review dependency health
Inspect dependency files.
Look for:
- Outdated direct dependencies
- Security advisories, if available
- Deprecated packages
- Major version upgrades
- Lockfile consistency
- Framework-specific upgrade notes
Update safely:
- Patch updates are usually low risk.
- Minor updates require test and build verification.
- Major updates require release notes, migration guide review, and explicit user approval.
Do not upgrade many major dependencies in one PR unless the user explicitly asks for a migration PR.
### 3. Run baseline checks
Before making changes, run or identify baseline health commands.
Common commands:
- `npm run typecheck`
- `npm run lint`
- `npm run test`
- `npm run build`
If baseline checks already fail before your changes, document the failures. Do not claim your maintenance change caused them unless evidence shows it.
### 4. Review error and health signals
If tools are available, inspect production health.
Possible sources:
- Sentry or error tracking
- Vercel, Render, Fly.io, Railway, AWS, or other deployment logs
- Database logs
- Queue or worker logs
- Browser console in production or staging
- Analytics event anomalies
- Failed cron jobs or background tasks
- Uptime checks
For each issue, classify:
- User impact
- Frequency
- First seen time
- Affected route or job
- Likely owner area
- Recommended action
Do not expose secrets, tokens, emails, payment data, or personal data in summaries.
### 5. Apply safe maintenance changes
Make small, isolated changes.
Allowed without extra approval if low risk:
- Patch dependency updates
- Documentation corrections
- Release note updates
- CI command fixes that match existing scripts
- Small logging improvements that do not expose sensitive data
- Removing obviously unused generated artifacts if confirmed
Require approval before:
- Major dependency upgrades
- Database migrations
- Auth, billing, permission, or security changes
- Deployment infrastructure changes
- Large refactors
- New monitoring vendors
- New paid services
### 6. Verify after changes
Run checks again after edits.
Suggested order:
1. Install dependencies if needed.
2. Run lockfile consistency check if available.
3. Run typecheck.
4. Run lint.
5. Run tests.
6. Run build.
7. Run relevant smoke test.
If dependency updates were made, pay special attention to framework warnings and peer dependency conflicts.
### 7. Write release notes
Create or update release notes in the project's usual location.
Use this structure:
- Added: new user-visible capabilities
- Changed: behavior or UI changes
- Fixed: bug fixes
- Maintenance: dependency, CI, docs, internal updates
- Known issues: anything users or the maker should know
For maintenance-only work, keep the note short and practical.
### 8. Prepare a PR or handoff
If GitHub CLI is available and the user wants a PR:
- Review `git diff`.
- Group changes logically.
- Write a conventional commit message if the project uses one.
- Push the branch only with user approval if credentials or remote behavior are unclear.
- Create a PR with summary, verification, risk, and rollback notes.
If PR creation is not possible, provide a ready-to-copy PR title and description.
## Weekly solo-maker checklist
Use this checklist for a routine weekly pass:
- Check production error trends.
- Check failed jobs or cron tasks.
- Check dependency updates.
- Run typecheck, lint, tests, and build.
- Review recent user-impacting changes.
- Update release notes.
- Create a small maintenance PR.
- Record follow-up issues for anything too large to fix now.
## Hard constraints
- Do not deploy automatically unless the user explicitly asks.
- Do not perform major upgrades without approval.
- Do not mix feature work with maintenance work.
- Do not delete lockfiles or regenerate project structure casually.
- Do not print secrets or personal data.
- Do not hide failing checks.
- Do not create noisy PRs with unrelated formatting changes.
## Definition of done
An operations check is done only when:
- Repository state is understood.
- Dependency and health signals are reviewed as far as tools allow.
- Safe changes are applied or risky changes are listed separately.
- Verification status is known.
- Release notes or maintenance notes are updated.
- A PR, commit suggestion, or handoff summary is ready.
## Output format
When starting:
## Ops snapshot
## Available tools
## Baseline checks
## Risks / constraints
## Proposed maintenance plan
When finishing:
## Maintenance completed
## Dependency changes
## Error / health findings
## Verification
## Release notes
## PR / commit suggestion
## Follow-up issues피드백을 백로그로 바꾸는 Skill
솔로 메이커에게 사용자 피드백은 가장 값싼 리서치이지만, 가장 쉽게 흘러가 버리는 자산이기도 하다. DM, 이메일, 고객 인터뷰, 앱스토어 리뷰, 결제 취소 사유, 오류 로그가 제각각 쌓이면 다음에 무엇을 만들지 흐려진다. 이 스킬은 흩어진 신호를 기능 후보, 버그, 문서 개선, 실험 아이디어로 정리한다.
파일 위치:
.cursor/skills/feedback-to-backlog/SKILL.md---
name: feedback-to-backlog
description: Use when turning customer feedback, support messages, analytics notes, reviews, sales calls, or founder observations into prioritized backlog items, PRD drafts, and implementation-ready issues.
---
# Feedback to Backlog
You are a product-minded operator for a solo maker. Your job is to convert messy feedback into clear decisions: what to fix now, what to build next, what to ignore, and what to learn more about.
## When to use this skill
Use this skill when the user provides customer feedback, support messages, interview notes, app reviews, analytics observations, churn reasons, sales objections, or founder notes.
Examples:
- "Turn these support emails into issues."
- "What should I build next from this feedback?"
- "Cluster these user complaints."
- "Create a PRD from these customer interviews."
- "Review churn reasons and suggest product work."
Do not use this skill to invent a roadmap without evidence. If evidence is weak, say so.
## Primary goal
Transform raw feedback into a prioritized, evidence-backed backlog with clear problem statements, candidate solutions, acceptance criteria, and next actions.
## Required inputs
Identify or ask for:
- Feedback source
- User segment or plan, if known
- Frequency or number of affected users
- Revenue or retention impact, if known
- Current workaround, if any
- Related product area
- Existing roadmap or strategic priority
- Time horizon: fix today, plan this week, roadmap this quarter
If the data contains personal information, avoid repeating it in summaries unless necessary. Anonymize users by default.
## Workflow
### 1. Normalize the raw feedback
Convert each feedback item into a structured note.
Use this shape:
- Source
- User segment
- Quote or paraphrase
- Product area
- User problem
- Requested solution
- Underlying need
- Severity
- Frequency
- Evidence strength
- Related links or files
Separate what the user asked for from what the user needs. Users often request a solution, but the product decision should start from the problem.
### 2. Cluster themes
Group feedback into themes.
Common theme types:
- Bug or broken expectation
- Missing feature
- Confusing UX
- Onboarding friction
- Pricing or packaging issue
- Performance issue
- Trust, security, or privacy concern
- Documentation gap
- Integration request
- Power-user workflow
For each cluster, write:
- Theme name
- Representative feedback
- Affected users
- Product area
- Why it matters
- Confidence level
### 3. Separate fixes, features, docs, and experiments
Classify each item by the best next response.
Use these categories:
- Fix now: clear bug, high pain, low ambiguity
- Improve UX: same capability exists but users cannot find or complete it
- Write docs: product works but understanding is missing
- Build feature: real unmet need requiring new capability
- Run experiment: demand is plausible but solution is uncertain
- Research more: not enough evidence
- Do not pursue: off-strategy, too narrow, or not worth the cost
Do not turn every complaint into a feature. Sometimes the best product move is copy, onboarding, pricing clarity, or documentation.
### 4. Score priority lightly
Use a simple solo-maker priority score. Do not overcomplicate it.
Score each candidate from 1 to 5:
- Reach: how many relevant users are affected
- Pain: how intense the problem is
- Business value: retention, activation, revenue, trust, or support reduction
- Confidence: how strong the evidence is
- Effort: how expensive it is, where 1 is easy and 5 is hard
Suggested priority formula:
Priority = (Reach + Pain + Business value + Confidence) - Effort
Use the score as a conversation aid, not as an absolute truth. Explain judgment calls.
### 5. Create backlog items
For each recommended item, create an implementation-ready backlog entry.
Use this template:
## Title
Short action-oriented title.
## Problem
What user problem are we solving?
## Evidence
What feedback, data, or observation supports this?
## User story
As a [user segment], I want [capability or improvement], so that [benefit].
## Proposed solution
Describe the smallest useful solution.
## Acceptance criteria
- Clear, testable condition 1
- Clear, testable condition 2
- Clear, testable condition 3
## Out of scope
What should not be included in this iteration?
## Analytics / learning
What should we measure after shipping?
## Priority
Score and reasoning.
## Effort estimate
Small, medium, or large. Include uncertainty.
## Risks
Technical, UX, product, or operational risks.
### 6. Draft PRD for the top item
For the highest-priority feature or improvement, draft a lightweight PRD if the user wants to proceed.
Include:
- Problem statement
- Target user
- Goals
- Non-goals
- User flow
- Requirements
- Acceptance criteria
- Edge cases
- Analytics events
- Rollout plan
- Open questions
Keep the PRD concise. The goal is to make the next implementation conversation easier.
### 7. Create implementation prompts
For the top 1 to 3 items, create ready-to-use Cursor prompts.
Each prompt should include:
- Relevant context
- Files or product areas to inspect
- Expected output
- Verification requirements
- Instruction to ask clarifying questions before implementation
Example:
"Use the new-feature-delivery skill. Build the smallest version of [feature] based on this PRD. First inspect existing patterns in [area]. Create a plan before editing files. Include tests for [critical behavior]."
### 8. Update product memory
If the project has a product notes, roadmap, changelog, or decision log file, suggest an update.
Possible files:
- `docs/product/feedback.md`
- `docs/product/roadmap.md`
- `docs/prd/<feature>.md`
- `docs/decisions/<date>-<topic>.md`
- `.cursor/plans/<feature>.md`
Do not create a large documentation system without approval.
## Hard constraints
- Do not treat one loud user as the entire market.
- Do not discard minority feedback if it indicates severe pain, accessibility barriers, or revenue risk.
- Do not expose personal data in summaries.
- Do not invent metrics that were not provided.
- Do not recommend building a feature when copy, docs, onboarding, or support flow would solve the problem faster.
- Do not prioritize only by ease. Impact matters.
- Do not create implementation tasks without acceptance criteria.
## Definition of done
Feedback processing is done only when:
- Raw feedback is normalized.
- Themes are clustered.
- Items are classified by response type.
- Top candidates are prioritized with reasoning.
- Backlog entries have problem, evidence, acceptance criteria, and out-of-scope notes.
- The next implementation prompt or PRD is ready if needed.
## Output format
Use this structure:
## Input summary
## Feedback themes
## Classification
## Priority table
## Recommended backlog items
## Top PRD draft
## Ready-to-use Cursor prompts
## Follow-up research questions다섯 스킬을 함께 쓰는 흐름
다섯 개의 스킬은 따로 쓰는 도구가 아니라 하나의 운영 시스템처럼 연결된다.
사용자 피드백이 쌓이면 feedback-to-backlog로 문제를 정리한다. 그중 하나를 이번 주에 만들기로 했다면 new-feature-delivery로 PRD와 구현 계획을 만든다. 구현 중 문제가 터지면 systematic-bug-fix로 재현과 회귀 테스트를 잡는다. 화면이 어색하면 ui-polishing-qa로 브라우저와 접근성까지 확인한다. 배포 전이나 주간 점검 시간에는 solo-ops-check로 의존성, 에러, 릴리스 노트, PR 상태를 정리한다.
이 흐름의 장점은 에이전트에게 매번 긴 설명을 하지 않아도 된다는 데 있다. "이 기능 만들어줘"가 아니라 "new-feature-delivery 스킬로 이 PRD를 구현하자"라고 말하면 된다. "버그 고쳐줘"가 아니라 "systematic-bug-fix로 재현부터 해줘"라고 말하면 된다. 말이 짧아지는 것이 아니라, 일이 정돈되는 것이다.
내 제품에 맞게 고치는 법
처음부터 모든 스킬을 완성하려고 하지 말자. 실제로 써 보면서 세 가지만 계속 고치면 충분하다.
첫째, 에이전트가 자주 틀리는 부분을 제약으로 추가한다. 예를 들어 매번 fetch를 쓰는데 프로젝트는 axios 래퍼를 써야 한다면 스킬보다 .cursor/rules/에 넣는 편이 낫다. 반대로 "버그 수정 때 회귀 테스트를 빼먹는다"처럼 특정 작업에서만 생기는 문제라면 버그 수정 스킬에 넣는다.
둘째, 명령어를 실제 프로젝트 기준으로 바꾼다. npm run test라고 적혀 있어도 내 프로젝트가 pnpm test:unit을 쓴다면 스킬 안의 명령어를 바꿔야 한다. 에이전트가 추측하게 두지 말고 복사해 실행할 수 있는 명령어를 적어 두자.
셋째, 출력 형식을 유지한다. 솔로 메이커에게 중요한 것은 코드만이 아니다. "무엇을 했는지, 어떻게 확인했는지, 무엇이 남았는지"가 남아야 다음날 다시 이어서 일할 수 있다. 좋은 스킬은 에이전트가 코드를 만들게 하는 문서가 아니라, 내일의 나에게 인수인계를 남기게 하는 문서다.
참고
2에이전트와 함께 코딩할 때의 모범 사례 · Cursor
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.