Skip to content

Commit 8bd22b4

Browse files
nirukk52nirukk52
committed
merge main into backend-testing-infrastructure
2 parents 24cf2e8 + 713b328 commit 8bd22b4

39 files changed

+6588
-2064
lines changed

‎.claude-skills/backend-testing_skill/SKILL.md‎

Lines changed: 95 additions & 265 deletions
Large diffs are not rendered by default.

‎.claude-skills/backend-testing_skill/references/api_testing_examples.md‎

Lines changed: 676 additions & 0 deletions
Large diffs are not rendered by default.

‎.claude-skills/backend-testing_skill/references/encore_mcp_testing_patterns.md‎

Lines changed: 438 additions & 0 deletions
Large diffs are not rendered by default.

‎.claude-skills/backend-testing_skill/references/integration_test_patterns.md‎

Lines changed: 720 additions & 0 deletions
Large diffs are not rendered by default.

‎.claude-skills/code-review_skill/README.md‎

Lines changed: 169 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,169 @@
1+
# Code Review Skill
2+
3+
**Category:** Quality
4+
**Type:** Knowledge-based skill
5+
**Status:** Active
6+
7+
## Purpose
8+
9+
Conduct focused, structured code reviews that emphasize understanding over criticism. Reviews prioritize questions about ambiguity and code/data flow rather than nitpicking style.
10+
11+
## When to Use
12+
13+
- Reviewing pull requests or code changes
14+
- Analyzing diffs before merge
15+
- Evaluating code quality
16+
- When explicitly asked to "review this code"
17+
- When JIRA tickets reference code changes
18+
19+
## Key Features
20+
21+
✅ **Structured Format:** Consistent review structure with summary, assumptions, and priority-based feedback
22+
✅ **Question-Focused:** Frames feedback as questions rather than commands
23+
✅ **Priority-Based:** Organizes feedback into High/Medium/Low priority
24+
✅ **Concise:** Enforces 50-150 word limit per comment
25+
✅ **JIRA Integration:** Automatically saves reviews to ticket folders when references detected
26+
✅ **No Nitpicking:** Focuses on correctness, clarity, and data flow—not style
27+
28+
## Usage
29+
30+
### Trigger the Skill
31+
32+
Say to Claude:
33+
```
34+
"Review this code"
35+
"Conduct a code review for these changes"
36+
"Use the code-review skill to analyze this PR"
37+
```
38+
39+
Or explicitly mention when analyzing code:
40+
```
41+
"I need a focused code review following our guidelines"
42+
```
43+
44+
### Review Format
45+
46+
Every review produces:
47+
48+
1. **What These Changes Do** (3-5 bullet points)
49+
2. **Assumptions** (brief bullets)
50+
3. **High Priority Comments** (critical issues, 50-150 words each)
51+
4. **Medium Priority Comments** (concerns/questions, 50-150 words each)
52+
5. **Low Priority Comments** (suggestions, 50-150 words each)
53+
54+
### JIRA Integration
55+
56+
If the code references a JIRA ticket (e.g., `FR-123`, `BUG-456`), the review is automatically saved to:
57+
58+
```
59+
jira/{category}/{ticket-id}/code-review-{YYYY-MM-DD}.md
60+
```
61+
62+
Examples:
63+
- `jira/feature-requests/FR-123/code-review-2025-11-09.md`
64+
- `jira/bugs/BUG-456/code-review-2025-11-09.md`
65+
- `jira/tech-debt/TD-789/code-review-2025-11-09.md`
66+
67+
## Review Principles
68+
69+
### DO Focus On
70+
✅ Understanding code intent and flow
71+
✅ Asking questions about ambiguity
72+
✅ Identifying security and correctness issues
73+
✅ Flagging unclear data flow
74+
✅ Noting missing error handling
75+
76+
### DON'T Focus On
77+
❌ Nitpicking style preferences
78+
❌ Subjective organization debates
79+
❌ Minor naming suggestions
80+
❌ Formatting (linters handle this)
81+
❌ Personal syntax preferences
82+
83+
## Resources
84+
85+
### SKILL.md
86+
Main skill documentation with:
87+
- Complete review process (7 steps)
88+
- Priority classification guidelines
89+
- Question framing patterns
90+
- JIRA integration workflow
91+
- Anti-patterns to avoid
92+
93+
### assets/review-template.md
94+
Pre-formatted template for consistent reviews. Copy and populate all sections.
95+
96+
### references/review-guidelines.md
97+
Expanded guidance including:
98+
- Priority classification indicators
99+
- Effective question framing patterns
100+
- Word count management tips
101+
- JIRA integration details
102+
- Common review scenarios
103+
- Anti-patterns and best practices
104+
105+
## Examples
106+
107+
### High Priority Comment (Security)
108+
> **SQL Injection Risk in User Query**
109+
>
110+
> The `getUserData()` function at line 42 concatenates user input directly into the SQL query without sanitization. This creates an SQL injection vulnerability where malicious input could execute arbitrary database commands.
111+
>
112+
> Should we use parameterized queries here instead? Our security guidelines in `.cursor/rules/founder_rules.mdc` require all user input to be validated before database operations.
113+
114+
### Medium Priority Comment (Clarity)
115+
> **Unclear Error Flow in Async Handler**
116+
>
117+
> What happens when the API call at line 78 rejects? The promise doesn't have a `.catch()` handler, and I don't see error handling in the calling function. This could result in unhandled promise rejections that crash the app.
118+
>
119+
> Should we add error handling here, or is there an error boundary higher in the call stack that we're relying on?
120+
121+
### Low Priority Comment (Organization)
122+
> **Consider Extracting Validation Logic**
123+
>
124+
> The validation logic in `processUserInput()` (lines 112-145) could be extracted into a separate utility function for reusability. Several other endpoints perform similar validation, and extracting this would reduce duplication and make updates easier in the future.
125+
126+
## Integration with Workflow
127+
128+
### Before Code Review
129+
1. Ensure changes are ready for review
130+
2. Check if JIRA ticket exists
131+
3. Have commit messages/PR descriptions available
132+
133+
### During Code Review
134+
1. Claude reads through changes
135+
2. Identifies scope and impact
136+
3. Checks for JIRA references
137+
4. Analyzes code flow and logic
138+
5. Formulates priority-based questions
139+
6. Generates structured review
140+
141+
### After Code Review
142+
1. Review saved to JIRA folder (if applicable) or presented inline
143+
2. Developer addresses High priority items
144+
3. Discussion on Medium priority questions
145+
4. Low priority items tracked for future
146+
147+
## Skill Maintenance
148+
149+
Update this skill when:
150+
- New code review patterns emerge
151+
- Team feedback reveals gaps
152+
- Common issues consistently missed
153+
- Coding standards change
154+
155+
## Related Skills
156+
157+
- **check-founder-rules** - Automated founder rules validation
158+
- **typecheck-frontend** - TypeScript type checking
159+
- **lint-frontend** - Linting checks
160+
- **backend-debugging** - Systematic backend debugging
161+
- **frontend-debugging** - Systematic frontend debugging
162+
163+
## Skill Metadata
164+
165+
**Created:** 2025-11-09
166+
**Last Updated:** 2025-11-09
167+
**Version:** 1.0
168+
**Maintainer:** Founder
169+

‎.claude-skills/code-review_skill/SKILL.md‎

Lines changed: 200 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,200 @@
1+
---
2+
name: code-review
3+
description: This skill should be used when conducting focused code reviews that emphasize clarity, data flow understanding, and minimal assumptions. Trigger when reviewing pull requests, code changes, or when explicitly asked to review code. Produces structured reviews with priority-based feedback.
4+
---
5+
6+
# Code Review
7+
8+
## Overview
9+
10+
Conduct focused, structured code reviews that emphasize understanding over criticism. Reviews prioritize questions about ambiguity and code/data flow rather than nitpicking style. Each review produces a consistent format with summary, assumptions, and priority-based comments.
11+
12+
## When to Use This Skill
13+
14+
Trigger this skill when:
15+
- Reviewing pull requests or code changes
16+
- User explicitly requests "review this code" or "conduct a code review"
17+
- Analyzing a diff or set of file changes
18+
- Evaluating code before merge or deployment
19+
- JIRA tickets reference code changes that need review
20+
21+
## Review Format
22+
23+
All code reviews follow this structure:
24+
25+
### 1. What These Changes Do
26+
3-5 concise bullet points summarizing the intent and scope of changes.
27+
28+
**Example:**
29+
- Adds GraphQL endpoint for querying user preferences
30+
- Refactors authentication middleware to support JWT tokens
31+
- Introduces caching layer for frequently accessed data
32+
33+
### 2. Assumptions
34+
Brief bullet points documenting assumptions made during the review.
35+
36+
**Example:**
37+
- Assuming PostgreSQL is the target database (not explicitly stated)
38+
- Type definitions suggest this is part of a larger refactor
39+
- Error handling strategy follows existing patterns in the codebase
40+
41+
### 3. Priority Comments
42+
43+
Comments organized into three priority levels. Each comment is 50-150 words maximum.
44+
45+
#### High Priority
46+
Issues that must be addressed before merge:
47+
- Security vulnerabilities
48+
- Data loss risks
49+
- Breaking changes without migration path
50+
- Critical logic errors
51+
- Major performance regressions
52+
53+
#### Medium Priority
54+
Issues that should be addressed soon:
55+
- Unclear code/data flow requiring clarification
56+
- Missing error handling
57+
- Ambiguous function behavior
58+
- Type safety concerns
59+
- Potential edge cases
60+
61+
#### Low Priority
62+
Suggestions for future improvement:
63+
- Code organization opportunities
64+
- Documentation enhancements
65+
- Minor performance optimizations
66+
- Consistency improvements
67+
68+
## Review Process
69+
70+
### Step 1: Identify Changes Scope
71+
Read through all modified files to understand:
72+
- What functionality is being added/modified/removed
73+
- Which systems/services are affected
74+
- Whether this is a feature, bug fix, refactor, or chore
75+
76+
### Step 2: Check for JIRA Reference
77+
Scan commit messages, PR descriptions, and file paths for JIRA ticket references:
78+
- Pattern: `FR-###`, `BUG-###`, `TD-###`, `CHORE-###`
79+
- If found, prepare to save review document in the JIRA folder: `jira/{category}/{ticket-id}/code-review-{date}.md`
80+
81+
**JIRA Folder Structure:**
82+
```
83+
jira/
84+
├── feature-requests/
85+
│ └── FR-XXX/
86+
│ ├── code-review-2025-11-09.md
87+
│ └── DESCRIPTION.md
88+
├── bugs/
89+
│ └── BUG-XXX/
90+
├── tech-debt/
91+
│ └── TD-XXX/
92+
└── chores/
93+
└── CHORE-XXX/
94+
```
95+
96+
### Step 3: Analyze Code Flow
97+
Focus on understanding:
98+
- **Data flow**: How data moves through functions/components
99+
- **Control flow**: Branching logic, error paths, edge cases
100+
- **Dependencies**: What this code relies on and what relies on it
101+
- **Assumptions**: What must be true for this code to work correctly
102+
103+
### Step 4: Formulate Questions
104+
Instead of prescriptive feedback, ask questions about:
105+
- Ambiguous behavior: "What happens when userId is null here?"
106+
- Flow clarity: "How does error propagate from this async call?"
107+
- Missing context: "Is there a reason we're not validating input X?"
108+
- Edge cases: "Have we considered the case where the array is empty?"
109+
110+
### Step 5: Prioritize Feedback
111+
Categorize each comment:
112+
- **High**: Must fix before merge (security, correctness, data integrity)
113+
- **Medium**: Should address (clarity, robustness, maintainability)
114+
- **Low**: Nice to have (style, organization, minor optimizations)
115+
116+
### Step 6: Write Review
117+
Use the review template from `assets/review-template.md` and populate all sections:
118+
1. **What These Changes Do** (3-5 bullets)
119+
2. **Assumptions** (as many bullets as needed, keep short)
120+
3. **High Priority** (only critical issues)
121+
4. **Medium Priority** (questions and concerns)
122+
5. **Low Priority** (suggestions for future)
123+
124+
### Step 7: Save Review Document
125+
If JIRA ticket found:
126+
- Save to `jira/{category}/{ticket-id}/code-review-{YYYY-MM-DD}.md`
127+
- Use today's date for the filename
128+
129+
If no JIRA ticket:
130+
- Present review inline in the conversation
131+
132+
## Review Principles
133+
134+
### DO Focus On
135+
✅ Understanding code intent and flow
136+
✅ Asking questions about ambiguity
137+
✅ Identifying security and correctness issues
138+
✅ Flagging unclear data flow
139+
✅ Noting missing error handling
140+
✅ Highlighting assumptions that need validation
141+
142+
### DON'T Focus On
143+
❌ Nitpicking style preferences
144+
❌ Subjective code organization debates
145+
❌ Minor naming suggestions
146+
❌ Formatting (linters handle this)
147+
❌ Personal preference for syntax
148+
❌ Extensive refactoring suggestions (unless critical)
149+
150+
### Question Framing
151+
Always frame feedback as questions or observations, not commands:
152+
153+
**Good:**
154+
- "What happens if the API returns null here?"
155+
- "Should we validate userId before passing to the database?"
156+
- "Is there a reason we're not handling the rejected promise?"
157+
158+
**Avoid:**
159+
- "You need to add validation here."
160+
- "This should use async/await instead."
161+
- "Change this to use map() instead of forEach()."
162+
163+
## Word Count Guidelines
164+
165+
Keep reviews concise:
166+
- **What These Changes Do**: 1-2 sentences per bullet
167+
- **Assumptions**: 1 sentence per bullet
168+
- **Comments**: 50-150 words each (strictly enforced)
169+
170+
Short, focused reviews are more actionable than lengthy critiques.
171+
172+
## Resources
173+
174+
### assets/review-template.md
175+
Pre-formatted template for consistent review structure. Copy and populate all sections.
176+
177+
### references/review-guidelines.md
178+
Expanded guidance on identifying different priority levels and framing effective review questions.
179+
180+
## Example Review
181+
182+
**What These Changes Do:**
183+
- Adds real-time WebSocket connection management for live screen updates
184+
- Introduces connection pooling to handle up to 1000 concurrent sessions
185+
- Implements automatic reconnection logic with exponential backoff
186+
187+
**Assumptions:**
188+
- Redis is available and configured for session storage
189+
- Frontend implements WebSocket protocol correctly
190+
- Network latency is acceptable for real-time requirements
191+
192+
**High Priority:**
193+
- Memory leak risk: WebSocket connections appear to be held indefinitely without cleanup when clients disconnect unexpectedly. Should we implement a timeout or heartbeat mechanism?
194+
195+
**Medium Priority:**
196+
- Error handling: What happens when Redis connection fails mid-session? The code doesn't appear to handle this case, which could leave clients in an inconsistent state.
197+
- Type safety: The `message` parameter in `handleIncomingMessage()` is typed as `any`. Can we define a discriminated union for the expected message types?
198+
199+
**Low Priority:**
200+
- Consider extracting the reconnection logic into a separate utility function for reusability across other real-time features.

0 commit comments

Comments
 (0)