feat: add Learning Paths, examples, and project governance files

### New Content
- Learning Paths section in README (Junior/Senior/Power User/PM tracks)
- examples/ folder with 18 ready-to-use templates:
  - 4 agents (code-reviewer, test-writer, security-auditor, refactoring)
  - 2 skills (TDD workflow, security checklist)
  - 3 commands (commit, review-pr, generate-tests)
  - 4 hooks (bash + PowerShell for security, formatting)
  - 3 config templates (settings, MCP, gitignore)
  - 2 memory templates (project + personal CLAUDE.md)

### Governance
- CHANGELOG.md: Version history (1.0.0 → 1.1.0 → Unreleased)
- CONTRIBUTING.md: Contribution guidelines for community

### Documentation
- llms.txt: Updated structure with new files/folders

This update makes the guide more actionable with concrete templates
and provides clear learning paths for different skill levels.

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
This commit is contained in:
Florian BRUNIAUX 2026-01-10 14:25:22 +01:00
parent a4eed95f47
commit b2acc9b115
24 changed files with 1744 additions and 4 deletions

View file

@ -0,0 +1,68 @@
# Conventional Commit
Generate a conventional commit message for staged changes.
## Instructions
1. Run `git diff --cached` to see staged changes
2. Analyze the nature of changes
3. Generate a commit message following the format below
## Commit Format
```
<type>(<scope>): <subject>
[optional body]
[optional footer]
```
### Types
- `feat`: New feature
- `fix`: Bug fix
- `docs`: Documentation only
- `style`: Formatting, missing semicolons, etc.
- `refactor`: Code change that neither fixes nor adds feature
- `perf`: Performance improvement
- `test`: Adding missing tests
- `chore`: Maintenance tasks
### Rules
- Subject: imperative mood, no period, max 50 chars
- Body: explain WHAT and WHY, not HOW
- Footer: breaking changes, issue references
## Examples
```
feat(auth): add password reset functionality
Implement password reset flow with email verification.
Users can now request a reset link and set new password.
Closes #123
```
```
fix(api): prevent race condition in order processing
Add mutex lock to ensure orders are processed sequentially.
This fixes duplicate charge issues reported by users.
Fixes #456
```
```
refactor(cart): extract pricing logic to separate module
No functional changes. Improves testability and
separates concerns for future discount feature.
```
## Execution
After analyzing staged changes, suggest a commit message.
Ask for confirmation before executing `git commit -m "..."`.
$ARGUMENTS

View file

@ -0,0 +1,88 @@
# Generate Tests
Generate comprehensive tests for specified code.
## Instructions
1. Read the target file(s)
2. Identify testable units (functions, classes, methods)
3. Generate tests following project conventions
4. Ensure high coverage of edge cases
## Test Generation Process
### 1. Analyze Target
- Identify public interfaces
- Understand dependencies
- Note edge cases and boundaries
### 2. Detect Test Framework
Check for:
- `jest.config.js` → Jest
- `vitest.config.ts` → Vitest
- `pytest.ini` → pytest
- `mocha` in package.json → Mocha
### 3. Generate Tests
Follow the detected framework conventions.
## Test Categories
### Happy Path
Normal expected behavior with valid input.
### Edge Cases
- Empty inputs
- Null/undefined values
- Boundary values (0, -1, MAX_INT)
- Single item vs multiple items
### Error Cases
- Invalid input types
- Missing required parameters
- Network/IO failures
- Timeout scenarios
### Integration Points
- Database interactions
- External API calls
- File system operations
## Output Format
```typescript
describe('[ComponentName]', () => {
describe('[methodName]', () => {
// Happy path
it('should [expected behavior] when [condition]', () => {
// Arrange
// Act
// Assert
});
// Edge cases
it('should handle empty input', () => {});
it('should handle null values', () => {});
// Error cases
it('should throw when [invalid condition]', () => {});
});
});
```
## Conventions
- One assertion per test (when practical)
- Descriptive test names
- AAA pattern (Arrange-Act-Assert)
- No test interdependence
- Mock external dependencies
## Usage
```
/generate-tests src/utils/calculator.ts
/generate-tests src/services/
```
$ARGUMENTS

View file

@ -0,0 +1,79 @@
# Review Pull Request
Perform a comprehensive code review of a pull request.
## Instructions
1. Get PR information: `gh pr view $ARGUMENTS --json title,body,files,additions,deletions`
2. Review each changed file
3. Provide structured feedback
## Review Checklist
### Code Quality
- [ ] Code is readable and well-organized
- [ ] Functions are appropriately sized
- [ ] No code duplication
- [ ] Meaningful variable/function names
### Functionality
- [ ] Logic is correct
- [ ] Edge cases handled
- [ ] Error handling is comprehensive
- [ ] No obvious bugs
### Security
- [ ] No hardcoded secrets
- [ ] Input validation present
- [ ] No injection vulnerabilities
- [ ] Authorization checks in place
### Testing
- [ ] Tests added for new code
- [ ] Existing tests still pass
- [ ] Edge cases tested
### Documentation
- [ ] Code is self-documenting or commented
- [ ] README updated if needed
- [ ] API changes documented
## Output Format
```markdown
## PR Review: #[number] - [title]
### Summary
[1-2 sentence overview]
### Approval Status
[ ] Approved
[ ] Approved with suggestions
[ ] Changes requested
### Findings
#### Critical (Must Fix)
- [ ] [Issue description] - `file:line`
#### Suggestions (Should Consider)
- [ ] [Improvement] - `file:line`
#### Nitpicks (Optional)
- [ ] [Minor suggestion] - `file:line`
### Positive Highlights
- [What's done well]
### Questions
- [Clarifications needed]
```
## Usage
```
/review-pr 123
/review-pr https://github.com/owner/repo/pull/123
```
$ARGUMENTS