@esreekarreddy/ai-prompts 1.0.0

package/skills/pr-description.md

@@ -0,0 +1,116 @@
+# Skill: PR Description
+
+> Writing clear, helpful pull request descriptions
+
+## When to Activate
+
+- Creating a pull request
+- Asked to write PR description
+- Summarizing code changes
+
+## Behavior
+
+1. **Summarize the Change**
+   - What does this PR do?
+   - Why is it needed?
+   - What's the impact?
+
+2. **Provide Context**
+   - Link to issue/ticket
+   - Reference related PRs
+   - Note any dependencies
+
+3. **Guide Reviewers**
+   - Highlight key changes
+   - Note areas needing attention
+   - Explain non-obvious decisions
+
+4. **Document Testing**
+   - What was tested?
+   - How to test locally?
+   - Any edge cases to verify?
+
+## PR Description Template
+
+```markdown
+## Summary
+
+[1-2 sentence description of what this PR does]
+
+## Changes
+
+- [Change 1]
+- [Change 2]
+- [Change 3]
+
+## Why
+
+[Explain the motivation - link to issue if applicable]
+
+## Testing
+
+- [ ] Unit tests added/updated
+- [ ] Manual testing performed
+- [ ] Edge cases considered
+
+### How to Test
+
+1. [Step 1]
+2. [Step 2]
+3. [Expected result]
+
+## Screenshots
+
+[If UI changes, include before/after screenshots]
+
+## Notes for Reviewers
+
+- [Any specific areas to focus on]
+- [Known limitations]
+- [Follow-up work planned]
+
+## Checklist
+
+- [ ] Code follows project conventions
+- [ ] Self-review completed
+- [ ] Documentation updated
+- [ ] No console.logs or debug code
+```
+
+## Examples
+
+### Good Summary
+```
+Add rate limiting to authentication endpoints
+
+Implements rate limiting on /auth/* endpoints to prevent brute force attacks.
+Limits: 5 attempts per 15 minutes per IP.
+```
+
+### Bad Summary
+```
+Updates
+
+Fixed stuff and added some features
+```
+
+## Commit Message Convention
+
+If using conventional commits:
+```
+feat: add user authentication
+fix: resolve login redirect issue
+docs: update API documentation
+refactor: extract validation logic
+test: add user service tests
+chore: update dependencies
+```
+
+## Size Guidelines
+
+| PR Size | Lines Changed | Review Time |
+|---------|---------------|-------------|
+| Small | < 100 | < 30 min |
+| Medium | 100-300 | 30-60 min |
+| Large | 300-500 | 1-2 hours |
+| Too Large | > 500 | Consider splitting |

package/skills/project-setup.md

@@ -0,0 +1,123 @@
+# Skill: Project Setup
+
+> Setting up new projects with best practices
+
+## When to Activate
+
+- Starting a new project
+- Setting up development environment
+- Configuring tooling
+- Initializing repository
+
+## Behavior
+
+1. **Understand Requirements First**
+   - What type of project? (web app, API, CLI, library)
+   - What's the tech stack?
+   - Who will work on this?
+   - What's the deployment target?
+
+2. **Choose Minimal Dependencies**
+   - Start with essentials only
+   - Add dependencies as needed
+   - Prefer maintained, popular packages
+   - Consider bundle size (frontend)
+
+3. **Set Up for Success**
+   - TypeScript/type checking
+   - Linting and formatting
+   - Pre-commit hooks
+   - Testing framework
+   - CI/CD basics
+
+4. **Document from Day One**
+   - README with quick start
+   - Environment setup
+   - Development workflow
+   - CLAUDE.md for AI assistance
+
+## Project Checklist
+
+### Repository
+- [ ] `.gitignore` appropriate for stack
+- [ ] `README.md` with quick start
+- [ ] `LICENSE` file
+- [ ] `.env.example` for environment vars
+
+### Code Quality
+- [ ] TypeScript or type hints configured
+- [ ] ESLint/Pylint/formatter configured
+- [ ] Prettier/Black for formatting
+- [ ] Pre-commit hooks (Husky/pre-commit)
+
+### Development
+- [ ] Package manager lockfile
+- [ ] Development server script
+- [ ] Build script
+- [ ] Test script
+
+### CI/CD
+- [ ] GitHub Actions / GitLab CI setup
+- [ ] Lint check in CI
+- [ ] Test run in CI
+- [ ] Build verification
+
+## Stack-Specific Setup
+
+### TypeScript/Node.js
+```bash
+npm init -y
+npm install typescript @types/node -D
+npx tsc --init
+```
+
+Essential configs:
+- `tsconfig.json` with strict mode
+- `.eslintrc` with TypeScript parser
+- `.prettierrc` for formatting
+
+### Next.js
+```bash
+npx create-next-app@latest --typescript --tailwind --app
+```
+
+Add:
+- Path aliases in `tsconfig.json`
+- Environment validation
+- CLAUDE.md from templates
+
+### Python
+```bash
+python -m venv venv
+pip install ruff pytest
+```
+
+Add:
+- `pyproject.toml` with tool configs
+- `requirements.txt` and `requirements-dev.txt`
+- Type hints throughout
+
+## Output Format
+
+When setting up a project, provide:
+
+```markdown
+## Project Setup Complete
+
+### Created Files
+- [list of files created]
+
+### Installed Dependencies
+- [production deps]
+- [dev deps]
+
+### Next Steps
+1. [First thing to do]
+2. [Second thing]
+3. [Third thing]
+
+### Development Commands
+- `npm run dev` - Start development server
+- `npm test` - Run tests
+- `npm run build` - Build for production
+```

package/skills/refactoring.md

@@ -0,0 +1,93 @@
+# Skill: Refactoring
+
+> Safe, incremental code improvement
+
+## When to Activate
+
+- Code needs restructuring
+- Duplicate code should be consolidated
+- Performance optimization needed
+- Technical debt cleanup
+
+## Behavior
+
+1. **Assess Before Changing**
+   - What's the current state?
+   - What tests exist?
+   - What depends on this code?
+   - What's the risk?
+
+2. **Plan the Refactor**
+   - Define the target state
+   - Break into small, safe steps
+   - Identify rollback points
+   - Consider feature flags for big changes
+
+3. **Refactor Incrementally**
+   - One change at a time
+   - Run tests after each change
+   - Commit at stable points
+   - Don't mix refactoring with features
+
+4. **Verify Behavior Preservation**
+   - Same inputs → same outputs
+   - Performance not degraded
+   - No breaking changes to API
+
+## Refactoring Principles
+
+- **No behavior changes**: Refactoring changes structure, not behavior
+- **Small steps**: Each step should be safe to revert
+- **Tests first**: Ensure tests exist before refactoring
+- **One thing at a time**: Don't rename AND restructure in same commit
+
+## Common Refactoring Patterns
+
+| Pattern | When to Use |
+|---------|-------------|
+| Extract Function | Repeated code, long functions |
+| Extract Component | Repeated UI patterns |
+| Rename | Names don't reflect purpose |
+| Move | Code in wrong module/file |
+| Replace Conditional with Polymorphism | Complex if/switch chains |
+| Introduce Parameter Object | Too many parameters |
+
+## Output Format
+
+```markdown
+## Refactoring Plan
+
+### Current State
+[Description of current code structure]
+
+### Target State
+[What we want to achieve]
+
+### Steps
+1. [ ] [First safe step]
+   - Risk: Low
+   - Verify: [how to verify]
+2. [ ] [Second step]
+   - Risk: [level]
+   - Verify: [how to verify]
+
+### Rollback Plan
+[How to undo if something goes wrong]
+
+### Testing
+[What tests to run at each step]
+```
+
+## Safety Checklist
+
+Before refactoring:
+- [ ] Tests exist and pass
+- [ ] Understand all callers/consumers
+- [ ] Have a rollback plan
+- [ ] Scope is well-defined
+
+After refactoring:
+- [ ] All tests still pass
+- [ ] No performance regression
+- [ ] Code is cleaner/simpler
+- [ ] Documentation updated if needed

package/skills/testing.md

@@ -0,0 +1,134 @@
+# Skill: Testing
+
+> Writing effective, maintainable tests
+
+## When to Activate
+
+- Writing new tests
+- Reviewing test coverage
+- Setting up testing infrastructure
+- Improving existing tests
+
+## Behavior
+
+1. **Test Behavior, Not Implementation**
+   - Focus on what code does, not how
+   - Tests should survive refactoring
+   - Avoid testing private methods directly
+
+2. **Follow AAA Pattern**
+   ```typescript
+   it('should do something', () => {
+     // Arrange - set up test data
+     const input = createTestData();
+     
+     // Act - perform the action
+     const result = doSomething(input);
+     
+     // Assert - verify outcome
+     expect(result).toEqual(expected);
+   });
+   ```
+
+3. **Write Independent Tests**
+   - No shared mutable state
+   - Each test can run alone
+   - Order doesn't matter
+
+4. **Name Tests Clearly**
+   - Describe the scenario
+   - State the expected outcome
+   - `should [do X] when [condition]`
+
+## Test Types
+
+| Type | Purpose | Speed | Scope |
+|------|---------|-------|-------|
+| Unit | Test single functions/classes | Fast | Narrow |
+| Integration | Test component interactions | Medium | Medium |
+| E2E | Test full user flows | Slow | Wide |
+
+## Test Pyramid
+
+```
+       /\
+      /E2E\         Few - critical paths only
+     /------\
+    /Integration\   Some - key integrations
+   /--------------\
+  /     Unit       \  Many - all logic branches
+ /------------------\
+```
+
+## What to Test
+
+### Always Test
+- Happy path (main success scenario)
+- Edge cases (empty, null, max values)
+- Error handling
+- Authorization/authentication
+- Data validation
+
+### Consider Testing
+- Error messages are correct
+- Logging happens appropriately
+- Performance-critical paths
+
+### Avoid Testing
+- Third-party library internals
+- Simple getters/setters
+- Framework code
+
+## Test Quality Checklist
+
+- [ ] Tests are independent (no order dependency)
+- [ ] Tests are deterministic (same result every time)
+- [ ] Tests are fast (unit tests < 100ms)
+- [ ] Tests have clear names
+- [ ] Tests have single assertion focus
+- [ ] Mocks are minimal and justified
+
+## Example Test Structure
+
+```typescript
+describe('UserService', () => {
+  describe('createUser', () => {
+    it('should create user with valid data', async () => {
+      // Arrange
+      const userData = { email: 'test@example.com', name: 'Test' };
+      
+      // Act
+      const user = await userService.createUser(userData);
+      
+      // Assert
+      expect(user.id).toBeDefined();
+      expect(user.email).toBe(userData.email);
+    });
+
+    it('should throw when email already exists', async () => {
+      // Arrange
+      await createExistingUser('taken@example.com');
+      
+      // Act & Assert
+      await expect(
+        userService.createUser({ email: 'taken@example.com', name: 'Test' })
+      ).rejects.toThrow('Email already exists');
+    });
+
+    it('should hash password before storing', async () => {
+      // Arrange
+      const plainPassword = 'password123';
+      
+      // Act
+      const user = await userService.createUser({
+        email: 'test@example.com',
+        password: plainPassword
+      });
+      
+      // Assert
+      expect(user.password).not.toBe(plainPassword);
+      expect(await verifyHash(user.password, plainPassword)).toBe(true);
+    });
+  });
+});
+```

package/snippets/_index.md

@@ -0,0 +1,57 @@
+# Snippets Index
+
+> Small, composable pieces to enhance any prompt
+
+## How to Use
+
+Append these snippets to any prompt to modify behavior or output format.
+
+```bash
+# Example: Combine debugger with ultrathink
+cat prompts/development/debugger.md snippets/modifiers/ultrathink.md | pbcopy
+```
+
+## Modifiers
+
+Change how the AI approaches the task.
+
+| Snippet | Effect | When to Use |
+|---------|--------|-------------|
+| [ultrathink.md](modifiers/ultrathink.md) | Deeper analysis | Complex problems |
+| [step-by-step.md](modifiers/step-by-step.md) | Methodical approach | Need visibility |
+| [no-code-yet.md](modifiers/no-code-yet.md) | Planning only | Before implementation |
+| [be-thorough.md](modifiers/be-thorough.md) | Exhaustive analysis | Can't miss anything |
+| [be-ruthless.md](modifiers/be-ruthless.md) | Aggressive cuts | Scope creep |
+| [explain-reasoning.md](modifiers/explain-reasoning.md) | Show logic | Learning/verification |
+
+## Output Formats
+
+Specify how you want the response structured.
+
+| Snippet | Output | When to Use |
+|---------|--------|-------------|
+| [markdown-table.md](output-formats/markdown-table.md) | Tables | Comparisons |
+| [json.md](output-formats/json.md) | JSON | Programmatic use |
+| [checklist.md](output-formats/checklist.md) | Checklists | Actionable items |
+| [numbered-list.md](output-formats/numbered-list.md) | Numbered list | Ordered steps |
+
+## Constraints
+
+Add boundaries and limitations.
+
+| Snippet | Effect | When to Use |
+|---------|--------|-------------|
+| [mvp-only.md](constraints/mvp-only.md) | Minimal scope | Ship fast |
+| [read-only.md](constraints/read-only.md) | No changes | Analysis only |
+| [no-external-deps.md](constraints/no-external-deps.md) | No new packages | Keep simple |
+| [security-first.md](constraints/security-first.md) | Security priority | Sensitive code |
+
+## Common Combinations
+
+| Task | Snippets |
+|------|----------|
+| Security audit | `be-thorough` + `ultrathink` + `checklist` |
+| Planning | `no-code-yet` + `step-by-step` |
+| Scope cutting | `be-ruthless` + `mvp-only` |
+| Learning | `explain-reasoning` + `step-by-step` |
+| Quick analysis | `read-only` + `markdown-table` |

package/snippets/constraints/mvp-only.md

@@ -0,0 +1,50 @@
+# MVP Only
+
+> Constrain to minimum viable scope
+
+## Snippet
+
+```
+MVP only. No nice-to-haves. What's the absolute minimum to deliver value?
+```
+
+## Usage
+
+Use when:
+- Time is limited
+- Scope is creeping
+- Need to validate fast
+- Resources are constrained
+
+## Examples
+
+### Feature Design
+```
+Design a user authentication system.
+
+MVP only. No nice-to-haves. What's the absolute minimum to deliver value?
+```
+
+### Implementation
+```
+Implement file upload.
+
+MVP only. No nice-to-haves. What's the absolute minimum to deliver value?
+```
+
+## Variations
+
+### Time-Boxed
+```
+I have 4 hours. What's the MVP I can ship in that time?
+```
+
+### V1 Only
+```
+This is v1. What do we absolutely need? Everything else is v2.
+```
+
+### 80/20
+```
+Apply the 80/20 rule. What 20% of features deliver 80% of value?
+```

package/snippets/constraints/no-external-deps.md

@@ -0,0 +1,45 @@
+# No External Dependencies
+
+> Avoid adding new dependencies
+
+## Snippet
+
+```
+Do not add new external dependencies. Use only what's already in the project.
+```
+
+## Usage
+
+Use when:
+- Minimizing bundle size
+- Security concerns about new deps
+- Keeping project simple
+- Vendor restrictions
+
+## Examples
+
+### Feature Implementation
+```
+Implement date formatting.
+
+Do not add new external dependencies. Use only what's already in the project.
+```
+
+### Utility Functions
+```
+Create a debounce function.
+
+Do not add new external dependencies. Use only what's already in the project.
+```
+
+## Variations
+
+### Prefer Native
+```
+Use native APIs where possible. Only suggest dependencies as last resort.
+```
+
+### Justify Dependencies
+```
+If you recommend a new dependency, explain why it's essential and what alternatives exist.
+```

package/snippets/constraints/read-only.md

@@ -0,0 +1,45 @@
+# Read Only
+
+> Analysis only, no changes
+
+## Snippet
+
+```
+Read only. Analyze and report. Do not make any changes to files.
+```
+
+## Usage
+
+Use when:
+- You want analysis before action
+- Learning about unfamiliar code
+- Need to understand before modifying
+- Review before approval
+
+## Examples
+
+### Code Review
+```
+Review this pull request.
+
+Read only. Analyze and report. Do not make any changes to files.
+```
+
+### Codebase Analysis
+```
+Understand this codebase structure.
+
+Read only. Analyze and report. Do not make any changes to files.
+```
+
+## Variations
+
+### Explain Only
+```
+Explain what this code does. Do not modify anything.
+```
+
+### Audit Mode
+```
+Audit this code. Report findings only. No fixes yet.
+```

package/snippets/constraints/security-first.md

@@ -0,0 +1,50 @@
+# Security First
+
+> Prioritize security in all decisions
+
+## Snippet
+
+```
+Security first. At every decision point, choose the more secure option. Flag any security tradeoffs.
+```
+
+## Usage
+
+Use when:
+- Building auth/payment features
+- Handling sensitive data
+- Security-critical systems
+- Pre-production review
+
+## Examples
+
+### Feature Implementation
+```
+Implement user authentication.
+
+Security first. At every decision point, choose the more secure option. Flag any security tradeoffs.
+```
+
+### Code Review
+```
+Review this API endpoint.
+
+Security first. At every decision point, choose the more secure option. Flag any security tradeoffs.
+```
+
+## Variations
+
+### Paranoid Mode
+```
+Assume attackers are actively trying to exploit this. How do we defend?
+```
+
+### Defense in Depth
+```
+Apply defense in depth. What happens if each security layer fails?
+```
+
+### Security Review
+```
+Review this with a security mindset. What could go wrong? How could this be exploited?
+```