@cregis-dev/cckit 0.5.0 → 0.6.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/package.json +54 -53
- package/registry.json +116 -92
- package/src/cli.js +2 -2
- package/src/steps/configure-user.js +23 -8
- package/src/steps/install-rules.js +11 -52
- package/templates/rules/README.md +103 -0
- package/templates/rules/common/agents.md +49 -0
- package/templates/rules/common/coding-style.md +48 -0
- package/templates/rules/common/development-workflow.md +37 -0
- package/templates/rules/common/git-workflow.md +24 -0
- package/templates/rules/common/hooks.md +30 -0
- package/templates/rules/common/patterns.md +31 -0
- package/templates/rules/common/performance.md +55 -0
- package/templates/rules/common/security.md +29 -0
- package/templates/rules/common/testing.md +29 -0
- package/templates/rules/golang/coding-style.md +32 -0
- package/templates/rules/golang/hooks.md +17 -0
- package/templates/rules/golang/patterns.md +45 -0
- package/templates/rules/golang/security.md +34 -0
- package/templates/rules/golang/testing.md +31 -0
- package/templates/rules/python/coding-style.md +42 -0
- package/templates/rules/python/hooks.md +19 -0
- package/templates/rules/python/patterns.md +39 -0
- package/templates/rules/python/security.md +30 -0
- package/templates/rules/python/testing.md +38 -0
- package/templates/rules/swift/coding-style.md +47 -0
- package/templates/rules/swift/hooks.md +20 -0
- package/templates/rules/swift/patterns.md +66 -0
- package/templates/rules/swift/security.md +33 -0
- package/templates/rules/swift/testing.md +45 -0
- package/templates/rules/typescript/coding-style.md +65 -0
- package/templates/rules/typescript/hooks.md +22 -0
- package/templates/rules/typescript/patterns.md +52 -0
- package/templates/rules/typescript/security.md +28 -0
- package/templates/rules/typescript/testing.md +18 -0
|
@@ -0,0 +1,48 @@
|
|
|
1
|
+
# Coding Style
|
|
2
|
+
|
|
3
|
+
## Immutability (CRITICAL)
|
|
4
|
+
|
|
5
|
+
ALWAYS create new objects, NEVER mutate existing ones:
|
|
6
|
+
|
|
7
|
+
```
|
|
8
|
+
// Pseudocode
|
|
9
|
+
WRONG: modify(original, field, value) → changes original in-place
|
|
10
|
+
CORRECT: update(original, field, value) → returns new copy with change
|
|
11
|
+
```
|
|
12
|
+
|
|
13
|
+
Rationale: Immutable data prevents hidden side effects, makes debugging easier, and enables safe concurrency.
|
|
14
|
+
|
|
15
|
+
## File Organization
|
|
16
|
+
|
|
17
|
+
MANY SMALL FILES > FEW LARGE FILES:
|
|
18
|
+
- High cohesion, low coupling
|
|
19
|
+
- 200-400 lines typical, 800 max
|
|
20
|
+
- Extract utilities from large modules
|
|
21
|
+
- Organize by feature/domain, not by type
|
|
22
|
+
|
|
23
|
+
## Error Handling
|
|
24
|
+
|
|
25
|
+
ALWAYS handle errors comprehensively:
|
|
26
|
+
- Handle errors explicitly at every level
|
|
27
|
+
- Provide user-friendly error messages in UI-facing code
|
|
28
|
+
- Log detailed error context on the server side
|
|
29
|
+
- Never silently swallow errors
|
|
30
|
+
|
|
31
|
+
## Input Validation
|
|
32
|
+
|
|
33
|
+
ALWAYS validate at system boundaries:
|
|
34
|
+
- Validate all user input before processing
|
|
35
|
+
- Use schema-based validation where available
|
|
36
|
+
- Fail fast with clear error messages
|
|
37
|
+
- Never trust external data (API responses, user input, file content)
|
|
38
|
+
|
|
39
|
+
## Code Quality Checklist
|
|
40
|
+
|
|
41
|
+
Before marking work complete:
|
|
42
|
+
- [ ] Code is readable and well-named
|
|
43
|
+
- [ ] Functions are small (<50 lines)
|
|
44
|
+
- [ ] Files are focused (<800 lines)
|
|
45
|
+
- [ ] No deep nesting (>4 levels)
|
|
46
|
+
- [ ] Proper error handling
|
|
47
|
+
- [ ] No hardcoded values (use constants or config)
|
|
48
|
+
- [ ] No mutation (immutable patterns used)
|
|
@@ -0,0 +1,37 @@
|
|
|
1
|
+
# Development Workflow
|
|
2
|
+
|
|
3
|
+
> This file extends [common/git-workflow.md](./git-workflow.md) with the full feature development process that happens before git operations.
|
|
4
|
+
|
|
5
|
+
The Feature Implementation Workflow describes the development pipeline: research, planning, TDD, code review, and then committing to git.
|
|
6
|
+
|
|
7
|
+
## Feature Implementation Workflow
|
|
8
|
+
|
|
9
|
+
0. **Research & Reuse** _(mandatory before any new implementation)_
|
|
10
|
+
- **GitHub code search first:** Run `gh search repos` and `gh search code` to find existing implementations, templates, and patterns before writing anything new.
|
|
11
|
+
- **Exa MCP for research:** Use `exa-web-search` MCP during the planning phase for broader research, data ingestion, and discovering prior art.
|
|
12
|
+
- **Check package registries:** Search npm, PyPI, crates.io, and other registries before writing utility code. Prefer battle-tested libraries over hand-rolled solutions.
|
|
13
|
+
- **Search for adaptable implementations:** Look for open-source projects that solve 80%+ of the problem and can be forked, ported, or wrapped.
|
|
14
|
+
- Prefer adopting or porting a proven approach over writing net-new code when it meets the requirement.
|
|
15
|
+
|
|
16
|
+
1. **Plan First**
|
|
17
|
+
- Use **planner** agent to create implementation plan
|
|
18
|
+
- Generate planning docs before coding: PRD, architecture, system_design, tech_doc, task_list
|
|
19
|
+
- Identify dependencies and risks
|
|
20
|
+
- Break down into phases
|
|
21
|
+
|
|
22
|
+
2. **TDD Approach**
|
|
23
|
+
- Use **tdd-guide** agent
|
|
24
|
+
- Write tests first (RED)
|
|
25
|
+
- Implement to pass tests (GREEN)
|
|
26
|
+
- Refactor (IMPROVE)
|
|
27
|
+
- Verify 80%+ coverage
|
|
28
|
+
|
|
29
|
+
3. **Code Review**
|
|
30
|
+
- Use **code-reviewer** agent immediately after writing code
|
|
31
|
+
- Address CRITICAL and HIGH issues
|
|
32
|
+
- Fix MEDIUM issues when possible
|
|
33
|
+
|
|
34
|
+
4. **Commit & Push**
|
|
35
|
+
- Detailed commit messages
|
|
36
|
+
- Follow conventional commits format
|
|
37
|
+
- See [git-workflow.md](./git-workflow.md) for commit message format and PR process
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# Git Workflow
|
|
2
|
+
|
|
3
|
+
## Commit Message Format
|
|
4
|
+
```
|
|
5
|
+
<type>: <description>
|
|
6
|
+
|
|
7
|
+
<optional body>
|
|
8
|
+
```
|
|
9
|
+
|
|
10
|
+
Types: feat, fix, refactor, docs, test, chore, perf, ci
|
|
11
|
+
|
|
12
|
+
Note: Attribution disabled globally via ~/.claude/settings.json.
|
|
13
|
+
|
|
14
|
+
## Pull Request Workflow
|
|
15
|
+
|
|
16
|
+
When creating PRs:
|
|
17
|
+
1. Analyze full commit history (not just latest commit)
|
|
18
|
+
2. Use `git diff [base-branch]...HEAD` to see all changes
|
|
19
|
+
3. Draft comprehensive PR summary
|
|
20
|
+
4. Include test plan with TODOs
|
|
21
|
+
5. Push with `-u` flag if new branch
|
|
22
|
+
|
|
23
|
+
> For the full development process (planning, TDD, code review) before git operations,
|
|
24
|
+
> see [development-workflow.md](./development-workflow.md).
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
# Hooks System
|
|
2
|
+
|
|
3
|
+
## Hook Types
|
|
4
|
+
|
|
5
|
+
- **PreToolUse**: Before tool execution (validation, parameter modification)
|
|
6
|
+
- **PostToolUse**: After tool execution (auto-format, checks)
|
|
7
|
+
- **Stop**: When session ends (final verification)
|
|
8
|
+
|
|
9
|
+
## Auto-Accept Permissions
|
|
10
|
+
|
|
11
|
+
Use with caution:
|
|
12
|
+
- Enable for trusted, well-defined plans
|
|
13
|
+
- Disable for exploratory work
|
|
14
|
+
- Never use dangerously-skip-permissions flag
|
|
15
|
+
- Configure `allowedTools` in `~/.claude.json` instead
|
|
16
|
+
|
|
17
|
+
## TodoWrite Best Practices
|
|
18
|
+
|
|
19
|
+
Use TodoWrite tool to:
|
|
20
|
+
- Track progress on multi-step tasks
|
|
21
|
+
- Verify understanding of instructions
|
|
22
|
+
- Enable real-time steering
|
|
23
|
+
- Show granular implementation steps
|
|
24
|
+
|
|
25
|
+
Todo list reveals:
|
|
26
|
+
- Out of order steps
|
|
27
|
+
- Missing items
|
|
28
|
+
- Extra unnecessary items
|
|
29
|
+
- Wrong granularity
|
|
30
|
+
- Misinterpreted requirements
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Common Patterns
|
|
2
|
+
|
|
3
|
+
## Skeleton Projects
|
|
4
|
+
|
|
5
|
+
When implementing new functionality:
|
|
6
|
+
1. Search for battle-tested skeleton projects
|
|
7
|
+
2. Use parallel agents to evaluate options:
|
|
8
|
+
- Security assessment
|
|
9
|
+
- Extensibility analysis
|
|
10
|
+
- Relevance scoring
|
|
11
|
+
- Implementation planning
|
|
12
|
+
3. Clone best match as foundation
|
|
13
|
+
4. Iterate within proven structure
|
|
14
|
+
|
|
15
|
+
## Design Patterns
|
|
16
|
+
|
|
17
|
+
### Repository Pattern
|
|
18
|
+
|
|
19
|
+
Encapsulate data access behind a consistent interface:
|
|
20
|
+
- Define standard operations: findAll, findById, create, update, delete
|
|
21
|
+
- Concrete implementations handle storage details (database, API, file, etc.)
|
|
22
|
+
- Business logic depends on the abstract interface, not the storage mechanism
|
|
23
|
+
- Enables easy swapping of data sources and simplifies testing with mocks
|
|
24
|
+
|
|
25
|
+
### API Response Format
|
|
26
|
+
|
|
27
|
+
Use a consistent envelope for all API responses:
|
|
28
|
+
- Include a success/status indicator
|
|
29
|
+
- Include the data payload (nullable on error)
|
|
30
|
+
- Include an error message field (nullable on success)
|
|
31
|
+
- Include metadata for paginated responses (total, page, limit)
|
|
@@ -0,0 +1,55 @@
|
|
|
1
|
+
# Performance Optimization
|
|
2
|
+
|
|
3
|
+
## Model Selection Strategy
|
|
4
|
+
|
|
5
|
+
**Haiku 4.5** (90% of Sonnet capability, 3x cost savings):
|
|
6
|
+
- Lightweight agents with frequent invocation
|
|
7
|
+
- Pair programming and code generation
|
|
8
|
+
- Worker agents in multi-agent systems
|
|
9
|
+
|
|
10
|
+
**Sonnet 4.6** (Best coding model):
|
|
11
|
+
- Main development work
|
|
12
|
+
- Orchestrating multi-agent workflows
|
|
13
|
+
- Complex coding tasks
|
|
14
|
+
|
|
15
|
+
**Opus 4.5** (Deepest reasoning):
|
|
16
|
+
- Complex architectural decisions
|
|
17
|
+
- Maximum reasoning requirements
|
|
18
|
+
- Research and analysis tasks
|
|
19
|
+
|
|
20
|
+
## Context Window Management
|
|
21
|
+
|
|
22
|
+
Avoid last 20% of context window for:
|
|
23
|
+
- Large-scale refactoring
|
|
24
|
+
- Feature implementation spanning multiple files
|
|
25
|
+
- Debugging complex interactions
|
|
26
|
+
|
|
27
|
+
Lower context sensitivity tasks:
|
|
28
|
+
- Single-file edits
|
|
29
|
+
- Independent utility creation
|
|
30
|
+
- Documentation updates
|
|
31
|
+
- Simple bug fixes
|
|
32
|
+
|
|
33
|
+
## Extended Thinking + Plan Mode
|
|
34
|
+
|
|
35
|
+
Extended thinking is enabled by default, reserving up to 31,999 tokens for internal reasoning.
|
|
36
|
+
|
|
37
|
+
Control extended thinking via:
|
|
38
|
+
- **Toggle**: Option+T (macOS) / Alt+T (Windows/Linux)
|
|
39
|
+
- **Config**: Set `alwaysThinkingEnabled` in `~/.claude/settings.json`
|
|
40
|
+
- **Budget cap**: `export MAX_THINKING_TOKENS=10000`
|
|
41
|
+
- **Verbose mode**: Ctrl+O to see thinking output
|
|
42
|
+
|
|
43
|
+
For complex tasks requiring deep reasoning:
|
|
44
|
+
1. Ensure extended thinking is enabled (on by default)
|
|
45
|
+
2. Enable **Plan Mode** for structured approach
|
|
46
|
+
3. Use multiple critique rounds for thorough analysis
|
|
47
|
+
4. Use split role sub-agents for diverse perspectives
|
|
48
|
+
|
|
49
|
+
## Build Troubleshooting
|
|
50
|
+
|
|
51
|
+
If build fails:
|
|
52
|
+
1. Use **build-error-resolver** agent
|
|
53
|
+
2. Analyze error messages
|
|
54
|
+
3. Fix incrementally
|
|
55
|
+
4. Verify after each fix
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Security Guidelines
|
|
2
|
+
|
|
3
|
+
## Mandatory Security Checks
|
|
4
|
+
|
|
5
|
+
Before ANY commit:
|
|
6
|
+
- [ ] No hardcoded secrets (API keys, passwords, tokens)
|
|
7
|
+
- [ ] All user inputs validated
|
|
8
|
+
- [ ] SQL injection prevention (parameterized queries)
|
|
9
|
+
- [ ] XSS prevention (sanitized HTML)
|
|
10
|
+
- [ ] CSRF protection enabled
|
|
11
|
+
- [ ] Authentication/authorization verified
|
|
12
|
+
- [ ] Rate limiting on all endpoints
|
|
13
|
+
- [ ] Error messages don't leak sensitive data
|
|
14
|
+
|
|
15
|
+
## Secret Management
|
|
16
|
+
|
|
17
|
+
- NEVER hardcode secrets in source code
|
|
18
|
+
- ALWAYS use environment variables or a secret manager
|
|
19
|
+
- Validate that required secrets are present at startup
|
|
20
|
+
- Rotate any secrets that may have been exposed
|
|
21
|
+
|
|
22
|
+
## Security Response Protocol
|
|
23
|
+
|
|
24
|
+
If security issue found:
|
|
25
|
+
1. STOP immediately
|
|
26
|
+
2. Use **security-reviewer** agent
|
|
27
|
+
3. Fix CRITICAL issues before continuing
|
|
28
|
+
4. Rotate any exposed secrets
|
|
29
|
+
5. Review entire codebase for similar issues
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Testing Requirements
|
|
2
|
+
|
|
3
|
+
## Minimum Test Coverage: 80%
|
|
4
|
+
|
|
5
|
+
Test Types (ALL required):
|
|
6
|
+
1. **Unit Tests** - Individual functions, utilities, components
|
|
7
|
+
2. **Integration Tests** - API endpoints, database operations
|
|
8
|
+
3. **E2E Tests** - Critical user flows (framework chosen per language)
|
|
9
|
+
|
|
10
|
+
## Test-Driven Development
|
|
11
|
+
|
|
12
|
+
MANDATORY workflow:
|
|
13
|
+
1. Write test first (RED)
|
|
14
|
+
2. Run test - it should FAIL
|
|
15
|
+
3. Write minimal implementation (GREEN)
|
|
16
|
+
4. Run test - it should PASS
|
|
17
|
+
5. Refactor (IMPROVE)
|
|
18
|
+
6. Verify coverage (80%+)
|
|
19
|
+
|
|
20
|
+
## Troubleshooting Test Failures
|
|
21
|
+
|
|
22
|
+
1. Use **tdd-guide** agent
|
|
23
|
+
2. Check test isolation
|
|
24
|
+
3. Verify mocks are correct
|
|
25
|
+
4. Fix implementation, not tests (unless tests are wrong)
|
|
26
|
+
|
|
27
|
+
## Agent Support
|
|
28
|
+
|
|
29
|
+
- **tdd-guide** - Use PROACTIVELY for new features, enforces write-tests-first
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.go"
|
|
4
|
+
- "**/go.mod"
|
|
5
|
+
- "**/go.sum"
|
|
6
|
+
---
|
|
7
|
+
# Go Coding Style
|
|
8
|
+
|
|
9
|
+
> This file extends [common/coding-style.md](../common/coding-style.md) with Go specific content.
|
|
10
|
+
|
|
11
|
+
## Formatting
|
|
12
|
+
|
|
13
|
+
- **gofmt** and **goimports** are mandatory — no style debates
|
|
14
|
+
|
|
15
|
+
## Design Principles
|
|
16
|
+
|
|
17
|
+
- Accept interfaces, return structs
|
|
18
|
+
- Keep interfaces small (1-3 methods)
|
|
19
|
+
|
|
20
|
+
## Error Handling
|
|
21
|
+
|
|
22
|
+
Always wrap errors with context:
|
|
23
|
+
|
|
24
|
+
```go
|
|
25
|
+
if err != nil {
|
|
26
|
+
return fmt.Errorf("failed to create user: %w", err)
|
|
27
|
+
}
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
## Reference
|
|
31
|
+
|
|
32
|
+
See skill: `golang-patterns` for comprehensive Go idioms and patterns.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.go"
|
|
4
|
+
- "**/go.mod"
|
|
5
|
+
- "**/go.sum"
|
|
6
|
+
---
|
|
7
|
+
# Go Hooks
|
|
8
|
+
|
|
9
|
+
> This file extends [common/hooks.md](../common/hooks.md) with Go specific content.
|
|
10
|
+
|
|
11
|
+
## PostToolUse Hooks
|
|
12
|
+
|
|
13
|
+
Configure in `~/.claude/settings.json`:
|
|
14
|
+
|
|
15
|
+
- **gofmt/goimports**: Auto-format `.go` files after edit
|
|
16
|
+
- **go vet**: Run static analysis after editing `.go` files
|
|
17
|
+
- **staticcheck**: Run extended static checks on modified packages
|
|
@@ -0,0 +1,45 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.go"
|
|
4
|
+
- "**/go.mod"
|
|
5
|
+
- "**/go.sum"
|
|
6
|
+
---
|
|
7
|
+
# Go Patterns
|
|
8
|
+
|
|
9
|
+
> This file extends [common/patterns.md](../common/patterns.md) with Go specific content.
|
|
10
|
+
|
|
11
|
+
## Functional Options
|
|
12
|
+
|
|
13
|
+
```go
|
|
14
|
+
type Option func(*Server)
|
|
15
|
+
|
|
16
|
+
func WithPort(port int) Option {
|
|
17
|
+
return func(s *Server) { s.port = port }
|
|
18
|
+
}
|
|
19
|
+
|
|
20
|
+
func NewServer(opts ...Option) *Server {
|
|
21
|
+
s := &Server{port: 8080}
|
|
22
|
+
for _, opt := range opts {
|
|
23
|
+
opt(s)
|
|
24
|
+
}
|
|
25
|
+
return s
|
|
26
|
+
}
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
## Small Interfaces
|
|
30
|
+
|
|
31
|
+
Define interfaces where they are used, not where they are implemented.
|
|
32
|
+
|
|
33
|
+
## Dependency Injection
|
|
34
|
+
|
|
35
|
+
Use constructor functions to inject dependencies:
|
|
36
|
+
|
|
37
|
+
```go
|
|
38
|
+
func NewUserService(repo UserRepository, logger Logger) *UserService {
|
|
39
|
+
return &UserService{repo: repo, logger: logger}
|
|
40
|
+
}
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
## Reference
|
|
44
|
+
|
|
45
|
+
See skill: `golang-patterns` for comprehensive Go patterns including concurrency, error handling, and package organization.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.go"
|
|
4
|
+
- "**/go.mod"
|
|
5
|
+
- "**/go.sum"
|
|
6
|
+
---
|
|
7
|
+
# Go Security
|
|
8
|
+
|
|
9
|
+
> This file extends [common/security.md](../common/security.md) with Go specific content.
|
|
10
|
+
|
|
11
|
+
## Secret Management
|
|
12
|
+
|
|
13
|
+
```go
|
|
14
|
+
apiKey := os.Getenv("OPENAI_API_KEY")
|
|
15
|
+
if apiKey == "" {
|
|
16
|
+
log.Fatal("OPENAI_API_KEY not configured")
|
|
17
|
+
}
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
## Security Scanning
|
|
21
|
+
|
|
22
|
+
- Use **gosec** for static security analysis:
|
|
23
|
+
```bash
|
|
24
|
+
gosec ./...
|
|
25
|
+
```
|
|
26
|
+
|
|
27
|
+
## Context & Timeouts
|
|
28
|
+
|
|
29
|
+
Always use `context.Context` for timeout control:
|
|
30
|
+
|
|
31
|
+
```go
|
|
32
|
+
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
|
|
33
|
+
defer cancel()
|
|
34
|
+
```
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.go"
|
|
4
|
+
- "**/go.mod"
|
|
5
|
+
- "**/go.sum"
|
|
6
|
+
---
|
|
7
|
+
# Go Testing
|
|
8
|
+
|
|
9
|
+
> This file extends [common/testing.md](../common/testing.md) with Go specific content.
|
|
10
|
+
|
|
11
|
+
## Framework
|
|
12
|
+
|
|
13
|
+
Use the standard `go test` with **table-driven tests**.
|
|
14
|
+
|
|
15
|
+
## Race Detection
|
|
16
|
+
|
|
17
|
+
Always run with the `-race` flag:
|
|
18
|
+
|
|
19
|
+
```bash
|
|
20
|
+
go test -race ./...
|
|
21
|
+
```
|
|
22
|
+
|
|
23
|
+
## Coverage
|
|
24
|
+
|
|
25
|
+
```bash
|
|
26
|
+
go test -cover ./...
|
|
27
|
+
```
|
|
28
|
+
|
|
29
|
+
## Reference
|
|
30
|
+
|
|
31
|
+
See skill: `golang-testing` for detailed Go testing patterns and helpers.
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.py"
|
|
4
|
+
- "**/*.pyi"
|
|
5
|
+
---
|
|
6
|
+
# Python Coding Style
|
|
7
|
+
|
|
8
|
+
> This file extends [common/coding-style.md](../common/coding-style.md) with Python specific content.
|
|
9
|
+
|
|
10
|
+
## Standards
|
|
11
|
+
|
|
12
|
+
- Follow **PEP 8** conventions
|
|
13
|
+
- Use **type annotations** on all function signatures
|
|
14
|
+
|
|
15
|
+
## Immutability
|
|
16
|
+
|
|
17
|
+
Prefer immutable data structures:
|
|
18
|
+
|
|
19
|
+
```python
|
|
20
|
+
from dataclasses import dataclass
|
|
21
|
+
|
|
22
|
+
@dataclass(frozen=True)
|
|
23
|
+
class User:
|
|
24
|
+
name: str
|
|
25
|
+
email: str
|
|
26
|
+
|
|
27
|
+
from typing import NamedTuple
|
|
28
|
+
|
|
29
|
+
class Point(NamedTuple):
|
|
30
|
+
x: float
|
|
31
|
+
y: float
|
|
32
|
+
```
|
|
33
|
+
|
|
34
|
+
## Formatting
|
|
35
|
+
|
|
36
|
+
- **black** for code formatting
|
|
37
|
+
- **isort** for import sorting
|
|
38
|
+
- **ruff** for linting
|
|
39
|
+
|
|
40
|
+
## Reference
|
|
41
|
+
|
|
42
|
+
See skill: `python-patterns` for comprehensive Python idioms and patterns.
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.py"
|
|
4
|
+
- "**/*.pyi"
|
|
5
|
+
---
|
|
6
|
+
# Python Hooks
|
|
7
|
+
|
|
8
|
+
> This file extends [common/hooks.md](../common/hooks.md) with Python specific content.
|
|
9
|
+
|
|
10
|
+
## PostToolUse Hooks
|
|
11
|
+
|
|
12
|
+
Configure in `~/.claude/settings.json`:
|
|
13
|
+
|
|
14
|
+
- **black/ruff**: Auto-format `.py` files after edit
|
|
15
|
+
- **mypy/pyright**: Run type checking after editing `.py` files
|
|
16
|
+
|
|
17
|
+
## Warnings
|
|
18
|
+
|
|
19
|
+
- Warn about `print()` statements in edited files (use `logging` module instead)
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.py"
|
|
4
|
+
- "**/*.pyi"
|
|
5
|
+
---
|
|
6
|
+
# Python Patterns
|
|
7
|
+
|
|
8
|
+
> This file extends [common/patterns.md](../common/patterns.md) with Python specific content.
|
|
9
|
+
|
|
10
|
+
## Protocol (Duck Typing)
|
|
11
|
+
|
|
12
|
+
```python
|
|
13
|
+
from typing import Protocol
|
|
14
|
+
|
|
15
|
+
class Repository(Protocol):
|
|
16
|
+
def find_by_id(self, id: str) -> dict | None: ...
|
|
17
|
+
def save(self, entity: dict) -> dict: ...
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
## Dataclasses as DTOs
|
|
21
|
+
|
|
22
|
+
```python
|
|
23
|
+
from dataclasses import dataclass
|
|
24
|
+
|
|
25
|
+
@dataclass
|
|
26
|
+
class CreateUserRequest:
|
|
27
|
+
name: str
|
|
28
|
+
email: str
|
|
29
|
+
age: int | None = None
|
|
30
|
+
```
|
|
31
|
+
|
|
32
|
+
## Context Managers & Generators
|
|
33
|
+
|
|
34
|
+
- Use context managers (`with` statement) for resource management
|
|
35
|
+
- Use generators for lazy evaluation and memory-efficient iteration
|
|
36
|
+
|
|
37
|
+
## Reference
|
|
38
|
+
|
|
39
|
+
See skill: `python-patterns` for comprehensive patterns including decorators, concurrency, and package organization.
|
|
@@ -0,0 +1,30 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.py"
|
|
4
|
+
- "**/*.pyi"
|
|
5
|
+
---
|
|
6
|
+
# Python Security
|
|
7
|
+
|
|
8
|
+
> This file extends [common/security.md](../common/security.md) with Python specific content.
|
|
9
|
+
|
|
10
|
+
## Secret Management
|
|
11
|
+
|
|
12
|
+
```python
|
|
13
|
+
import os
|
|
14
|
+
from dotenv import load_dotenv
|
|
15
|
+
|
|
16
|
+
load_dotenv()
|
|
17
|
+
|
|
18
|
+
api_key = os.environ["OPENAI_API_KEY"] # Raises KeyError if missing
|
|
19
|
+
```
|
|
20
|
+
|
|
21
|
+
## Security Scanning
|
|
22
|
+
|
|
23
|
+
- Use **bandit** for static security analysis:
|
|
24
|
+
```bash
|
|
25
|
+
bandit -r src/
|
|
26
|
+
```
|
|
27
|
+
|
|
28
|
+
## Reference
|
|
29
|
+
|
|
30
|
+
See skill: `django-security` for Django-specific security guidelines (if applicable).
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.py"
|
|
4
|
+
- "**/*.pyi"
|
|
5
|
+
---
|
|
6
|
+
# Python Testing
|
|
7
|
+
|
|
8
|
+
> This file extends [common/testing.md](../common/testing.md) with Python specific content.
|
|
9
|
+
|
|
10
|
+
## Framework
|
|
11
|
+
|
|
12
|
+
Use **pytest** as the testing framework.
|
|
13
|
+
|
|
14
|
+
## Coverage
|
|
15
|
+
|
|
16
|
+
```bash
|
|
17
|
+
pytest --cov=src --cov-report=term-missing
|
|
18
|
+
```
|
|
19
|
+
|
|
20
|
+
## Test Organization
|
|
21
|
+
|
|
22
|
+
Use `pytest.mark` for test categorization:
|
|
23
|
+
|
|
24
|
+
```python
|
|
25
|
+
import pytest
|
|
26
|
+
|
|
27
|
+
@pytest.mark.unit
|
|
28
|
+
def test_calculate_total():
|
|
29
|
+
...
|
|
30
|
+
|
|
31
|
+
@pytest.mark.integration
|
|
32
|
+
def test_database_connection():
|
|
33
|
+
...
|
|
34
|
+
```
|
|
35
|
+
|
|
36
|
+
## Reference
|
|
37
|
+
|
|
38
|
+
See skill: `python-testing` for detailed pytest patterns and fixtures.
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
---
|
|
2
|
+
paths:
|
|
3
|
+
- "**/*.swift"
|
|
4
|
+
- "**/Package.swift"
|
|
5
|
+
---
|
|
6
|
+
# Swift Coding Style
|
|
7
|
+
|
|
8
|
+
> This file extends [common/coding-style.md](../common/coding-style.md) with Swift specific content.
|
|
9
|
+
|
|
10
|
+
## Formatting
|
|
11
|
+
|
|
12
|
+
- **SwiftFormat** for auto-formatting, **SwiftLint** for style enforcement
|
|
13
|
+
- `swift-format` is bundled with Xcode 16+ as an alternative
|
|
14
|
+
|
|
15
|
+
## Immutability
|
|
16
|
+
|
|
17
|
+
- Prefer `let` over `var` — define everything as `let` and only change to `var` if the compiler requires it
|
|
18
|
+
- Use `struct` with value semantics by default; use `class` only when identity or reference semantics are needed
|
|
19
|
+
|
|
20
|
+
## Naming
|
|
21
|
+
|
|
22
|
+
Follow [Apple API Design Guidelines](https://www.swift.org/documentation/api-design-guidelines/):
|
|
23
|
+
|
|
24
|
+
- Clarity at the point of use — omit needless words
|
|
25
|
+
- Name methods and properties for their roles, not their types
|
|
26
|
+
- Use `static let` for constants over global constants
|
|
27
|
+
|
|
28
|
+
## Error Handling
|
|
29
|
+
|
|
30
|
+
Use typed throws (Swift 6+) and pattern matching:
|
|
31
|
+
|
|
32
|
+
```swift
|
|
33
|
+
func load(id: String) throws(LoadError) -> Item {
|
|
34
|
+
guard let data = try? read(from: path) else {
|
|
35
|
+
throw .fileNotFound(id)
|
|
36
|
+
}
|
|
37
|
+
return try decode(data)
|
|
38
|
+
}
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
## Concurrency
|
|
42
|
+
|
|
43
|
+
Enable Swift 6 strict concurrency checking. Prefer:
|
|
44
|
+
|
|
45
|
+
- `Sendable` value types for data crossing isolation boundaries
|
|
46
|
+
- Actors for shared mutable state
|
|
47
|
+
- Structured concurrency (`async let`, `TaskGroup`) over unstructured `Task {}`
|