This skill identifies anti-patterns that violate amplihack's development philosophy and provides constructive, specific fixes. It ensures code maintains ruthless simplicity, modular design, and zero-BS implementations.
Fetches code-smell-detector from rysweet/amplihack and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/code-smell-detector
Restart Cursor to activate code-smell-detector. Access via /code-smell-detector in your agent's command palette.
⚠
Security Notice
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.
This skill identifies anti-patterns that violate amplihack's development philosophy and provides constructive, specific fixes. It ensures code maintains ruthless simplicity, modular design, and zero-BS implementations.
When to Use This Skill
Code review: Identify violations before merging
Refactoring: Find opportunities to simplify and improve code quality
New module creation: Catch issues early in development
Philosophy compliance: Ensure code aligns with amplihack principles
Learning: Understand why patterns are problematic and how to fix them
Mentoring: Educate team members on philosophy-aligned code patterns
Core Philosophy Reference
Amplihack Development Philosophy focuses on:
Ruthless Simplicity: Every abstraction must justify its existence
What It Is: Functions that do too many things and are difficult to understand, test, and modify.
Why It's Bad: Violates single responsibility, makes testing harder, increases bug surface area, reduces code reusability.
Red Flags:
Functions with >50 lines of code
Multiple indentation levels (3+ nested if/for)
Functions with 5+ parameters
Functions that need scrolling to see all of them
Complex logic that's hard to name
Example - SMELL:
# BAD: Large function doing multiple thingsdefprocess_user_data(user_dict, validate=True, save=True, notify=True, log=True):if validate:ifnot user_dict.get('email'):raise ValueError("Email required")ifnot'@'in user_dict['email']:raise ValueError("Invalid email") user = User( name=user_dict['name'], email=user_dict['email'], phone=user_dict['phone'])if save: db.save(user)if notify: email_service.send(user.email,"Welcome!")if log: logger.info(f"User {user.name} created")# ... 30+ more lines of mixed concernsreturn user
Example - FIXED:
# GOOD: Separated concernsdefvalidate_user_data(user_dict):"""Validate user data structure."""ifnot user_dict.get('email'):raise ValueError("Email required")if'@'notin user_dict['email']:raise ValueError("Invalid email")defcreate_user(user_dict):"""Create user object from data."""return User( name=user_dict['name'], email=user_dict['email'], phone=user_dict['phone'])defprocess_user_data(user_dict):"""Orchestrate user creation workflow.""" validate_user_data(user_dict) user = create_user(user_dict) db.save(user) email_service.send(user.email,"Welcome!") logger.info(f"User {user.name} created")return user
Detection Checklist:
Function body >50 lines
3+ levels of nesting
Multiple unrelated operations
Hard to name succinctly
5+ parameters
Fix Strategy:
Extract helper functions for each concern
Give each function a clear, single purpose
Compose small functions into larger workflows
Each function should fit on one screen
Easy to name = usually doing one thing
4. Tight Coupling
What It Is: Modules/classes directly depend on concrete implementations instead of abstractions, making them hard to test and modify.
Why It's Bad: Changes in one module break others. Hard to test in isolation. Violates modularity principle.
Red Flags:
Direct instantiation of classes inside functions (db = Database())
Deep attribute access (obj.service.repository.data)
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ 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.
Learning Path
1Basic: user stories, feature specs, status updates
