claude-code-starter 0.0.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/commands/analyze.md +49 -0
- package/.claude/commands/done.md +44 -0
- package/.claude/commands/status.md +36 -0
- package/.claude/commands/task.md +53 -0
- package/.claude/settings.json +33 -0
- package/.claude/skills/pattern-discovery.md +67 -0
- package/.claude/skills/systematic-debugging.md +119 -0
- package/.claude/skills/testing-methodology.md +112 -0
- package/.claude/state/task.md +13 -0
- package/CLAUDE.md +32 -0
- package/LICENSE +21 -0
- package/README.md +509 -0
- package/init +341 -0
- package/package.json +34 -0
|
@@ -0,0 +1,49 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: analyze
|
|
3
|
+
description: Deep analysis of a specific area
|
|
4
|
+
arguments:
|
|
5
|
+
- name: area
|
|
6
|
+
description: The area or topic to analyze
|
|
7
|
+
required: true
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# /analyze - Deep Analysis
|
|
11
|
+
|
|
12
|
+
Analyze a specific area of the codebase.
|
|
13
|
+
|
|
14
|
+
## Instructions
|
|
15
|
+
|
|
16
|
+
1. **Determine scope**
|
|
17
|
+
What does the user want analyzed?
|
|
18
|
+
- A file or directory
|
|
19
|
+
- A feature or system
|
|
20
|
+
- A bug or issue
|
|
21
|
+
- Architecture question
|
|
22
|
+
|
|
23
|
+
2. **Gather context**
|
|
24
|
+
- Find relevant files
|
|
25
|
+
- Read key code sections
|
|
26
|
+
- Check related tests
|
|
27
|
+
- Look at dependencies
|
|
28
|
+
|
|
29
|
+
3. **Analyze by type:**
|
|
30
|
+
|
|
31
|
+
**Code Analysis**
|
|
32
|
+
- Structure and organization
|
|
33
|
+
- Dependencies and data flow
|
|
34
|
+
- Patterns used
|
|
35
|
+
- Potential issues
|
|
36
|
+
|
|
37
|
+
**Bug Analysis**
|
|
38
|
+
- Reproduce the issue
|
|
39
|
+
- Trace the code path
|
|
40
|
+
- Identify root cause
|
|
41
|
+
- Suggest fixes
|
|
42
|
+
|
|
43
|
+
**Architecture Analysis**
|
|
44
|
+
- Component relationships
|
|
45
|
+
- Data flow
|
|
46
|
+
- External dependencies
|
|
47
|
+
|
|
48
|
+
4. **Report findings**
|
|
49
|
+
Provide clear, actionable insights with `file:line` references.
|
|
@@ -0,0 +1,44 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: done
|
|
3
|
+
description: Mark current task complete
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /done - Mark Task Complete
|
|
7
|
+
|
|
8
|
+
Finish the current task.
|
|
9
|
+
|
|
10
|
+
## Instructions
|
|
11
|
+
|
|
12
|
+
1. **Verify completion**
|
|
13
|
+
- Did tests pass (if applicable)?
|
|
14
|
+
- Was the objective achieved?
|
|
15
|
+
- Any follow-up items?
|
|
16
|
+
|
|
17
|
+
2. **Update task.md:**
|
|
18
|
+
|
|
19
|
+
```markdown
|
|
20
|
+
# Current Task
|
|
21
|
+
|
|
22
|
+
## Status: Completed
|
|
23
|
+
|
|
24
|
+
**Task:** [completed task description]
|
|
25
|
+
|
|
26
|
+
## Summary
|
|
27
|
+
|
|
28
|
+
[What was accomplished]
|
|
29
|
+
|
|
30
|
+
## Files Changed
|
|
31
|
+
|
|
32
|
+
- [list of modified files]
|
|
33
|
+
|
|
34
|
+
## Follow-up
|
|
35
|
+
|
|
36
|
+
- [Any items for future tasks, or "None"]
|
|
37
|
+
|
|
38
|
+
## Decisions
|
|
39
|
+
|
|
40
|
+
[Key decisions that were made]
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
3. **Confirm to user**
|
|
44
|
+
Report completion and any follow-up items.
|
|
@@ -0,0 +1,36 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: status
|
|
3
|
+
description: Show current task and session state
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# /status - Show Current State
|
|
7
|
+
|
|
8
|
+
Show what you're working on.
|
|
9
|
+
|
|
10
|
+
## Instructions
|
|
11
|
+
|
|
12
|
+
1. **Read state**
|
|
13
|
+
- `.claude/state/task.md`
|
|
14
|
+
|
|
15
|
+
2. **Report:**
|
|
16
|
+
|
|
17
|
+
```
|
|
18
|
+
## Current Status
|
|
19
|
+
|
|
20
|
+
**Task:** [task name or "None"]
|
|
21
|
+
**Status:** [In Progress / Completed / Ready]
|
|
22
|
+
|
|
23
|
+
### Progress
|
|
24
|
+
[Summary of what's done vs remaining]
|
|
25
|
+
|
|
26
|
+
### Decisions Made
|
|
27
|
+
[Key decisions, if any]
|
|
28
|
+
|
|
29
|
+
### Next Steps
|
|
30
|
+
[What should happen next]
|
|
31
|
+
```
|
|
32
|
+
|
|
33
|
+
3. **Suggest actions**
|
|
34
|
+
- If no task: suggest `/task`
|
|
35
|
+
- If complete: suggest `/done`
|
|
36
|
+
- If stuck: suggest next steps
|
|
@@ -0,0 +1,53 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: task
|
|
3
|
+
description: Start or switch to a new task
|
|
4
|
+
arguments:
|
|
5
|
+
- name: description
|
|
6
|
+
description: What you want to work on
|
|
7
|
+
required: true
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
# /task - Start or Switch Task
|
|
11
|
+
|
|
12
|
+
Start a new task or switch focus.
|
|
13
|
+
|
|
14
|
+
## Instructions
|
|
15
|
+
|
|
16
|
+
1. **Check current state**
|
|
17
|
+
- Read `.claude/state/task.md`
|
|
18
|
+
- If task in progress, ask if user wants to save progress first
|
|
19
|
+
|
|
20
|
+
2. **Update task.md with:**
|
|
21
|
+
|
|
22
|
+
```markdown
|
|
23
|
+
# Current Task
|
|
24
|
+
|
|
25
|
+
## Status: In Progress
|
|
26
|
+
|
|
27
|
+
**Task:** [user's description]
|
|
28
|
+
|
|
29
|
+
## Context
|
|
30
|
+
|
|
31
|
+
[Brief context about what this involves]
|
|
32
|
+
|
|
33
|
+
## Next Steps
|
|
34
|
+
|
|
35
|
+
1. [First step]
|
|
36
|
+
2. [Second step]
|
|
37
|
+
3. ...
|
|
38
|
+
|
|
39
|
+
## Decisions
|
|
40
|
+
|
|
41
|
+
(None yet)
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
3. **Confirm and start**
|
|
45
|
+
Tell user the task is set and begin working on it.
|
|
46
|
+
|
|
47
|
+
## Example
|
|
48
|
+
|
|
49
|
+
```
|
|
50
|
+
/task Add user authentication
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
Creates a new task and begins planning/implementation.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://claude.ai/schemas/claude-code-settings.json",
|
|
3
|
+
"permissions": {
|
|
4
|
+
"allow": [
|
|
5
|
+
"Read(**)",
|
|
6
|
+
"Edit(**)",
|
|
7
|
+
"Write(.claude/**)",
|
|
8
|
+
"Bash(git:*)",
|
|
9
|
+
"Bash(npm:*)",
|
|
10
|
+
"Bash(yarn:*)",
|
|
11
|
+
"Bash(pnpm:*)",
|
|
12
|
+
"Bash(bun:*)",
|
|
13
|
+
"Bash(node:*)",
|
|
14
|
+
"Bash(npx:*)",
|
|
15
|
+
"Bash(tsc:*)",
|
|
16
|
+
"Bash(jest:*)",
|
|
17
|
+
"Bash(vitest:*)",
|
|
18
|
+
"Bash(eslint:*)",
|
|
19
|
+
"Bash(prettier:*)",
|
|
20
|
+
"Bash(python:*)",
|
|
21
|
+
"Bash(pip:*)",
|
|
22
|
+
"Bash(cargo:*)",
|
|
23
|
+
"Bash(go:*)",
|
|
24
|
+
"Bash(make:*)",
|
|
25
|
+
"Bash(docker:*)",
|
|
26
|
+
"Bash(ls:*)",
|
|
27
|
+
"Bash(mkdir:*)",
|
|
28
|
+
"Bash(cat:*)",
|
|
29
|
+
"Bash(echo:*)"
|
|
30
|
+
],
|
|
31
|
+
"deny": []
|
|
32
|
+
}
|
|
33
|
+
}
|
|
@@ -0,0 +1,67 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: pattern-discovery
|
|
3
|
+
description: Analyze existing codebase to discover and document patterns
|
|
4
|
+
globs: ["src/**/*", "lib/**/*", "app/**/*", "components/**/*", "pages/**/*", "api/**/*", "services/**/*", "utils/**/*", "helpers/**/*"]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Pattern Discovery
|
|
8
|
+
|
|
9
|
+
When starting work on a project, analyze the existing code to understand its patterns.
|
|
10
|
+
|
|
11
|
+
## Discovery Process
|
|
12
|
+
|
|
13
|
+
### 1. Check for Existing Documentation
|
|
14
|
+
```
|
|
15
|
+
Look for:
|
|
16
|
+
- README.md, CONTRIBUTING.md
|
|
17
|
+
- docs/ folder
|
|
18
|
+
- Code comments and JSDoc/TSDoc
|
|
19
|
+
- .editorconfig, .prettierrc, eslint config
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
### 2. Analyze Project Structure
|
|
23
|
+
```
|
|
24
|
+
Questions to answer:
|
|
25
|
+
- How are files organized? (by feature, by type, flat?)
|
|
26
|
+
- Where does business logic live?
|
|
27
|
+
- Where are tests located?
|
|
28
|
+
- How are configs managed?
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
### 3. Detect Code Patterns
|
|
32
|
+
```
|
|
33
|
+
Look at 3-5 similar files to find:
|
|
34
|
+
- Naming conventions (camelCase, snake_case, PascalCase)
|
|
35
|
+
- Import organization (grouped? sorted? relative vs absolute?)
|
|
36
|
+
- Export style (named, default, barrel files?)
|
|
37
|
+
- Error handling approach
|
|
38
|
+
- Logging patterns
|
|
39
|
+
- Comment style
|
|
40
|
+
```
|
|
41
|
+
|
|
42
|
+
### 4. Identify Architecture
|
|
43
|
+
```
|
|
44
|
+
Common patterns to detect:
|
|
45
|
+
- MVC / MVVM / Clean Architecture
|
|
46
|
+
- Repository pattern
|
|
47
|
+
- Service layer
|
|
48
|
+
- Dependency injection
|
|
49
|
+
- Event-driven
|
|
50
|
+
- Functional vs OOP
|
|
51
|
+
```
|
|
52
|
+
|
|
53
|
+
## When No Code Exists
|
|
54
|
+
|
|
55
|
+
If starting a new project:
|
|
56
|
+
|
|
57
|
+
1. Ask about preferred patterns
|
|
58
|
+
2. Check package.json/config files for framework hints
|
|
59
|
+
3. Use sensible defaults for detected stack
|
|
60
|
+
4. Document decisions in `.claude/state/task.md`
|
|
61
|
+
|
|
62
|
+
## Important
|
|
63
|
+
|
|
64
|
+
- **Match existing patterns** - don't impose new ones
|
|
65
|
+
- **When in doubt, check similar files** in the codebase
|
|
66
|
+
- **Document as you discover** - note patterns in task state
|
|
67
|
+
- **Ask if unclear** - better to ask than assume
|
|
@@ -0,0 +1,119 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: systematic-debugging
|
|
3
|
+
description: Language-agnostic debugging methodology
|
|
4
|
+
globs: ["**/*.log", "**/error*", "**/debug*", "**/logs/**/*", "src/**/*", "lib/**/*", "app/**/*"]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Systematic Debugging
|
|
8
|
+
|
|
9
|
+
A 4-phase approach that works for any language or framework.
|
|
10
|
+
|
|
11
|
+
## Phase 1: Reproduce
|
|
12
|
+
|
|
13
|
+
**Goal**: Reliably trigger the bug.
|
|
14
|
+
|
|
15
|
+
1. Get exact steps from user/logs
|
|
16
|
+
2. Note the environment (versions, OS, configs)
|
|
17
|
+
3. Determine if consistent or intermittent
|
|
18
|
+
4. Find minimal reproduction case
|
|
19
|
+
|
|
20
|
+
```
|
|
21
|
+
Questions to ask:
|
|
22
|
+
- "What exactly happens vs what should happen?"
|
|
23
|
+
- "When did it start? What changed?"
|
|
24
|
+
- "Does it happen every time?"
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
## Phase 2: Locate
|
|
28
|
+
|
|
29
|
+
**Goal**: Find where the bug originates.
|
|
30
|
+
|
|
31
|
+
### With Error/Stack Trace
|
|
32
|
+
- Read stack trace from bottom to top
|
|
33
|
+
- Find first file in project code (not dependencies)
|
|
34
|
+
- That's usually the bug location
|
|
35
|
+
|
|
36
|
+
### Without Error (Silent Failure)
|
|
37
|
+
- Add logging at key points
|
|
38
|
+
- Use binary search: log at middle, narrow down
|
|
39
|
+
- Check inputs/outputs at each step
|
|
40
|
+
|
|
41
|
+
### Data Issues
|
|
42
|
+
- Log the actual data vs expected
|
|
43
|
+
- Check data transformations
|
|
44
|
+
- Verify API responses match expectations
|
|
45
|
+
|
|
46
|
+
## Phase 3: Diagnose
|
|
47
|
+
|
|
48
|
+
**Goal**: Understand WHY it's broken.
|
|
49
|
+
|
|
50
|
+
### Common Causes (Any Language)
|
|
51
|
+
|
|
52
|
+
**Data Issues**
|
|
53
|
+
- Null/undefined/nil access
|
|
54
|
+
- Wrong data type
|
|
55
|
+
- Missing or malformed data
|
|
56
|
+
- Encoding issues
|
|
57
|
+
|
|
58
|
+
**Timing Issues**
|
|
59
|
+
- Race conditions
|
|
60
|
+
- Async operations completing out of order
|
|
61
|
+
- Stale data/cache
|
|
62
|
+
|
|
63
|
+
**Logic Errors**
|
|
64
|
+
- Off-by-one errors
|
|
65
|
+
- Wrong comparison operators
|
|
66
|
+
- Missing edge cases
|
|
67
|
+
- Incorrect boolean logic
|
|
68
|
+
|
|
69
|
+
**Environment Issues**
|
|
70
|
+
- Missing environment variables
|
|
71
|
+
- Wrong file paths
|
|
72
|
+
- Permission issues
|
|
73
|
+
- Version mismatches
|
|
74
|
+
|
|
75
|
+
### Diagnostic Questions
|
|
76
|
+
1. What are the exact inputs?
|
|
77
|
+
2. What's the expected output?
|
|
78
|
+
3. Where does actual diverge from expected?
|
|
79
|
+
4. What assumptions might be wrong?
|
|
80
|
+
|
|
81
|
+
## Phase 4: Fix
|
|
82
|
+
|
|
83
|
+
**Goal**: Apply minimal, correct fix.
|
|
84
|
+
|
|
85
|
+
### Fix Criteria
|
|
86
|
+
- Addresses root cause, not symptom
|
|
87
|
+
- Doesn't break other functionality
|
|
88
|
+
- Handles related edge cases
|
|
89
|
+
- Is the simplest solution that works
|
|
90
|
+
|
|
91
|
+
### Verification Checklist
|
|
92
|
+
- [ ] Original bug is fixed
|
|
93
|
+
- [ ] Related tests pass
|
|
94
|
+
- [ ] No new issues introduced
|
|
95
|
+
- [ ] Edge cases handled
|
|
96
|
+
- [ ] Fix makes sense to explain
|
|
97
|
+
|
|
98
|
+
## Quick Reference
|
|
99
|
+
|
|
100
|
+
| Symptom | Check First |
|
|
101
|
+
|---------|-------------|
|
|
102
|
+
| "undefined" errors | Data flow, null checks |
|
|
103
|
+
| Intermittent failures | Async/timing, race conditions |
|
|
104
|
+
| Works locally, fails in prod | Environment, configs |
|
|
105
|
+
| Works for some users | User-specific data, permissions |
|
|
106
|
+
| Slow performance | N+1 queries, loops, memory |
|
|
107
|
+
| Silent failures | Error handling, logging |
|
|
108
|
+
|
|
109
|
+
## Debug Without Debugger
|
|
110
|
+
|
|
111
|
+
When you can't use a debugger:
|
|
112
|
+
|
|
113
|
+
```
|
|
114
|
+
1. Strategic logging at entry/exit points
|
|
115
|
+
2. Log input/output of suspect functions
|
|
116
|
+
3. Add timestamps for timing issues
|
|
117
|
+
4. Log state before/after mutations
|
|
118
|
+
5. Use conditional logging for specific cases
|
|
119
|
+
```
|
|
@@ -0,0 +1,112 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: testing-methodology
|
|
3
|
+
description: Language-agnostic testing approach
|
|
4
|
+
globs: ["**/*.test.*", "**/*.spec.*", "**/*_test.*", "__tests__/**/*", "tests/**/*", "test/**/*"]
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# Testing Methodology
|
|
8
|
+
|
|
9
|
+
A framework-agnostic approach to writing effective tests.
|
|
10
|
+
|
|
11
|
+
## First: Check Existing Tests
|
|
12
|
+
|
|
13
|
+
Before writing tests:
|
|
14
|
+
1. Find existing test files in the project
|
|
15
|
+
2. Study their structure and style
|
|
16
|
+
3. Match the existing patterns exactly
|
|
17
|
+
4. Use the same testing framework
|
|
18
|
+
|
|
19
|
+
## Test Structure (AAA Pattern)
|
|
20
|
+
|
|
21
|
+
Works in any language:
|
|
22
|
+
|
|
23
|
+
```
|
|
24
|
+
Test: [what you're testing]
|
|
25
|
+
|
|
26
|
+
Arrange:
|
|
27
|
+
- Set up test data
|
|
28
|
+
- Configure mocks/stubs
|
|
29
|
+
- Prepare dependencies
|
|
30
|
+
|
|
31
|
+
Act:
|
|
32
|
+
- Execute the code under test
|
|
33
|
+
- Capture the result
|
|
34
|
+
|
|
35
|
+
Assert:
|
|
36
|
+
- Verify the result matches expected
|
|
37
|
+
- Check side effects if any
|
|
38
|
+
```
|
|
39
|
+
|
|
40
|
+
## What to Test
|
|
41
|
+
|
|
42
|
+
### Always Test
|
|
43
|
+
- Core business logic
|
|
44
|
+
- Data transformations
|
|
45
|
+
- Edge cases and boundaries
|
|
46
|
+
- Error handling paths
|
|
47
|
+
- Public API contracts
|
|
48
|
+
|
|
49
|
+
### Sometimes Test
|
|
50
|
+
- Integration points
|
|
51
|
+
- Complex UI interactions
|
|
52
|
+
- Database operations
|
|
53
|
+
|
|
54
|
+
### Rarely Test
|
|
55
|
+
- Framework code
|
|
56
|
+
- Simple getters/setters
|
|
57
|
+
- Configuration
|
|
58
|
+
- Third-party libraries
|
|
59
|
+
|
|
60
|
+
## Test Naming
|
|
61
|
+
|
|
62
|
+
Be descriptive about:
|
|
63
|
+
1. What is being tested
|
|
64
|
+
2. Under what conditions
|
|
65
|
+
3. What is expected
|
|
66
|
+
|
|
67
|
+
```
|
|
68
|
+
Good: "creates user when email is valid"
|
|
69
|
+
Bad: "test1" or "user test"
|
|
70
|
+
```
|
|
71
|
+
|
|
72
|
+
## Mocking Strategy
|
|
73
|
+
|
|
74
|
+
### Mock When
|
|
75
|
+
- External services (APIs, databases)
|
|
76
|
+
- Time-dependent code
|
|
77
|
+
- Random/non-deterministic behavior
|
|
78
|
+
- Slow operations
|
|
79
|
+
|
|
80
|
+
### Don't Mock
|
|
81
|
+
- The code you're testing
|
|
82
|
+
- Simple utility functions
|
|
83
|
+
- When you can use real implementations
|
|
84
|
+
|
|
85
|
+
## Test Data
|
|
86
|
+
|
|
87
|
+
### Good Test Data
|
|
88
|
+
- Minimal but complete
|
|
89
|
+
- Clearly shows the test case
|
|
90
|
+
- Uses realistic values
|
|
91
|
+
- Isolated per test
|
|
92
|
+
|
|
93
|
+
### Bad Test Data
|
|
94
|
+
- Shared between tests
|
|
95
|
+
- Uses magic numbers without context
|
|
96
|
+
- Overly complex for the test case
|
|
97
|
+
|
|
98
|
+
## Coverage Philosophy
|
|
99
|
+
|
|
100
|
+
Focus on:
|
|
101
|
+
- **Critical paths**: What breaks the app if it fails?
|
|
102
|
+
- **Complex logic**: Where are bugs likely?
|
|
103
|
+
- **Regression prevention**: What broke before?
|
|
104
|
+
|
|
105
|
+
Don't chase percentages - chase confidence.
|
|
106
|
+
|
|
107
|
+
## Test Maintenance
|
|
108
|
+
|
|
109
|
+
- Delete tests that don't add value
|
|
110
|
+
- Update tests when requirements change
|
|
111
|
+
- Keep tests fast (< 100ms unit tests)
|
|
112
|
+
- Make failures easy to diagnose
|
package/CLAUDE.md
ADDED
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Claude Code Starter
|
|
2
|
+
|
|
3
|
+
## Start Here
|
|
4
|
+
|
|
5
|
+
Check `.claude/state/task.md` for your current task.
|
|
6
|
+
|
|
7
|
+
## Commands
|
|
8
|
+
|
|
9
|
+
| Command | Purpose |
|
|
10
|
+
|---------|---------|
|
|
11
|
+
| `/task <desc>` | Start or switch to a new task |
|
|
12
|
+
| `/status` | Show current task state |
|
|
13
|
+
| `/done` | Mark current task complete |
|
|
14
|
+
| `/analyze <area>` | Deep-dive into specific code |
|
|
15
|
+
|
|
16
|
+
## Rules
|
|
17
|
+
|
|
18
|
+
1. **State First** - Always read `.claude/state/task.md` when resuming
|
|
19
|
+
2. **One Task** - Focus on one thing at a time
|
|
20
|
+
3. **Test Before Done** - Run tests before marking complete
|
|
21
|
+
4. **Update State** - Keep task.md current as you work
|
|
22
|
+
|
|
23
|
+
## Skills
|
|
24
|
+
|
|
25
|
+
Reference these for specialized workflows:
|
|
26
|
+
- `.claude/skills/pattern-discovery.md` - Finding codebase patterns
|
|
27
|
+
- `.claude/skills/systematic-debugging.md` - Debugging approach
|
|
28
|
+
- `.claude/skills/testing-methodology.md` - Testing strategy
|
|
29
|
+
|
|
30
|
+
## File References
|
|
31
|
+
|
|
32
|
+
Use `path/to/file.ts:123` format when referencing code.
|
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2025 Cassiano Montanari
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|