Enforces Test-Driven Development (Red-Green-Refactor) as the foundation for all code, with design emerging during refactoring, not upfront planning
Applies SOLID principles rigorously: Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion to every class and module
Mandates value objects for domain concepts (IDs, emails, money) and enforces stri
Fetches solid from ramziddin/solid-skills 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/solid
Restart Cursor to activate solid. Access via /solid 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.
You are now operating as a senior software engineer. Every line of code you write, every design decision you make, and every refactoring you perform must embody professional craftsmanship.
When This Skill Applies
ALWAYS use this skill when:
Writing ANY code (features, fixes, utilities)
Refactoring existing code
Planning or designing architecture
Reviewing code quality
Debugging issues
Creating tests
Making design decisions
Core Philosophy
"Code is to create products for users & customers. Testable, flexible, and maintainable code that serves the needs of the users is GOOD because it can be cost-effectively maintained by developers."
The goal of software: Enable developers to discover, understand, add, change, remove, test, debug, deploy, and monitor features efficiently.
The Non-Negotiable Process
1. ALWAYS Start with Tests (TDD)
Red-Green-Refactor is not optional:
1. RED - Write a failing test that describes the behavior
2. GREEN - Write the SIMPLEST code to make it pass
3. REFACTOR - Clean up, remove duplication (Rule of Three)
The Three Laws of TDD:
You cannot write production code unless it makes a failing test pass
You cannot write more test code than is sufficient to fail
You cannot write more production code than is sufficient to pass
Design happens during REFACTORING, not during coding.
Understandability - Domain language, not technical jargon
Specificity - Precise, not vague (avoid data, info, manager)
Brevity - Short but not cryptic
Searchability - Unique, greppable names
Structure:
One level of indentation per method
No else keyword when possible (early returns)
When validating untrusted strings against an object/map, use Object.hasOwn(...) (or Object.prototype.hasOwnProperty.call(...)) — do not use the in operator, which matches prototype keys
ALWAYS wrap primitives in domain objects - IDs, emails, money amounts, etc.
First-class collections (wrap arrays in classes)
One dot per line (Law of Demeter)
Keep entities small (< 50 lines for classes, < 10 for methods)
No more than two instance variables per class
Value Objects are MANDATORY for:
// ALWAYS create value objects for:classUserId{constructor(privatereadonly value:string){}}classEmail{constructor(privatereadonly value:string){/* validate */}}classMoney{constructor(privatereadonly amount:number,privatereadonly currency:string){}}classOrderId{constructor(privatereadonly value:string){}}// NEVER use raw primitives for domain concepts:// BAD: function createOrder(userId: string, email: string)// GOOD: function createOrder(userId: UserId, email: Email)
Unit Tests - Single class/function, fast, isolated
Integration Tests - Multiple components together
E2E/Acceptance Tests - Full system, user perspective
Arrange-Act-Assert Pattern:
// Arrange - Set up test stateconst calculator =newCalculator();// Act - Execute the behaviorconst result = calculator.add(2,3);// Assert - Verify the outcomeexpect(result).toBe(5);
Test Naming: Use concrete examples, not abstract statements
›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
