scriptoriumadmin/awesome-claude-skills
1
0
Fork 0
mirror of https://github.com/ComposioHQ/awesome-claude-skills.git synced 2026-10-10 03:28:07 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge b148c87acc into 0e304eadb3

Browse source
This commit is contained in:
Ronan Takizawa 2026-04-23 06:44:43 +00:00 • committed by GitHub
commit 7cf15e1e4e
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
12 changed files with 1207 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
README.md
View file

@ -121,6 +121,7 @@ Claude Skills are customizable workflows that teach Claude how to perform specif
- [LangSmith Fetch](./langsmith-fetch/) - Debug LangChain and LangGraph agents by automatically fetching and analyzing execution traces from LangSmith Studio. First AI observability skill for Claude Code. *By [@OthmanAdi](https://github.com/OthmanAdi)*
- [MCP Builder](./mcp-builder/) - Guides creation of high-quality MCP (Model Context Protocol) servers for integrating external APIs and services with LLMs using Python or TypeScript.
- [move-code-quality-skill](https://github.com/1NickPappas/move-code-quality-skill) - Analyzes Move language packages against the official Move Book Code Quality Checklist for Move 2024 Edition compliance and best practices.
- [Open Source Contribution](./open-source-contribution/) - Guides developers through open source contributions including finding projects, writing PRs, conventional commits, and communicating with maintainers. Covers enterprise standards (Linux Kernel, Apache) and security disclosure. *By [@ronantakizawa](https://github.com/ronantakizawa)*
- [Playwright Browser Automation](https://github.com/lackeyjb/playwright-skill) - Model-invoked Playwright automation for testing and validating web applications. *By [@lackeyjb](https://github.com/lackeyjb)*
- [prompt-engineering](https://github.com/NeoLabHQ/context-engineering-kit/tree/master/plugins/customaize-agent/skills/prompt-engineering) - Teaches well-known prompt engineering techniques and patterns, including Anthropic best practices and agent persuasion principles.
- [pypict-claude-skill](https://github.com/omkamal/pypict-claude-skill) - Design comprehensive test cases using PICT (Pairwise Independent Combinatorial Testing) for requirements or code, generating optimized test suites with pairwise coverage.

21
open-source-contribution/LICENSE Normal file
View file

@ -0,0 +1,21 @@
MIT License
Copyright (c) 2026 Ronan Takizawa
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

48
open-source-contribution/README.md Normal file
View file

@ -0,0 +1,48 @@
# Open Source Contribution Skill
A Claude Code skill that guides developers through open source contributions.
This skill has been tested and shows signs of improved commitment message consistency and easy issue discovery.
This skill was built using references from GitHub and Google's open source guide and conventional commits.
## What It Does
- **Finding Projects**: Resources and labels for finding beginner-friendly issues
- **Understanding Codebases**: Step-by-step approach to navigating large projects
- **Writing PRs**: Forking workflow, branch strategy, conventional commits, PR descriptions
- **Code Review**: How to respond to feedback professionally
- **Communicating with Maintainers**: Bug reports, feature requests, best practices
- **Enterprise Standards**: Linux Kernel patch format, Apache contributor ladder
- **Security Disclosure**: Coordinated vulnerability reporting
## Installation
### Using npx add-skill
```bash
npx add-skill ronantakizawa/open-source-contribution
```
### Using npx skills
```bash
npx skills add ronantakizawa/open-source-contribution
```
### Manual Installation
```bash
# Clone to your skills directory
git clone https://github.com/ronantakizawa/open-source-contribution ~/.claude/skills/open-source-contribution
```
### References
- [GitHub Open Source Guide](https://opensource.guide/how-to-contribute/)
- [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)
- [Google Engineering Practices](https://google.github.io/eng-practices/review/)
- [Good First Issue](https://goodfirstissue.dev/)
- [First Timers Only](https://www.firsttimersonly.com/)
- [Up For Grabs](https://up-for-grabs.net/)
- [CodeTriage](https://www.codetriage.com/)
- [7 Common Mistakes New Contributors Make](https://dev.to/codergirl1991/7-common-mistakes-new-contributors-make-in-open-source-software-2noo)
- [Lessons from Reviewing 200+ PRs](https://bhupesh.me/hacktoberfest-pr-review/)
- [Nadia Eghbal - Working in Public](https://press.stripe.com/working-in-public)

445
open-source-contribution/SKILL.md Normal file
View file

@ -0,0 +1,445 @@
---
name: open-source-contribution
description: Guides developers through open source contributions including finding projects, writing PRs, conventional commits, and communicating with maintainers. Covers enterprise standards (Linux Kernel, Apache) and security disclosure. Use when contributing to GitHub/GitLab projects, writing commit messages, responding to code review, or reporting vulnerabilities.
---
# Contributing to Open Source
## Quick Navigation
| Topic | Description |
|-------|-------------|
| [Finding Projects](#finding-projects) | Resources and labels for finding issues |
| [Understanding Codebases](#understanding-large-codebases) | How to navigate unfamiliar code |
| [Writing PRs](#writing-effective-pull-requests) | Branch strategy, commits, descriptions |
| [Code Review](#responding-to-code-review) | How to handle feedback |
| [Communicating with Maintainers](#communicating-with-maintainers) | Principles and templates |
| [Maintainer Perspective](#understanding-maintainer-perspective) | What maintainers want |
| [Common Mistakes](#common-mistakes-to-avoid) | Anti-patterns to avoid |
| [What Counts as Meaningful](#what-counts-as-meaningful) | High-value contributions |
**Reference Files:**
- [Conventional Commits](reference/conventional-commits.md) - Complete commit message guide
- [Enterprise Practices](reference/enterprise-practices.md) - Linux Kernel, Apache standards
- [Security Disclosure](reference/security-disclosure.md) - Reporting vulnerabilities
**Templates:**
- [Pull Request Template](templates/pull-request.md)
- [Bug Report Template](templates/bug-report.md)
- [Feature Request Template](templates/feature-request.md)
- [Commit Messages Reference](templates/commit-messages.md)
---
## Finding Projects
### Resources
- **GitHub Contribute Page**: `github.com/<owner>/<repo>/contribute`
- [Good First Issue](https://goodfirstissue.dev/)
- [Up For Grabs](https://up-for-grabs.net/)
- [First Timers Only](https://www.firsttimersonly.com/)
- **GitHub Search**: `label:"good first issue" language:<your-language>`
### Labels to Look For
| Label | Meaning |
|-------|---------|
| `good first issue` | GitHub's official beginner label |
| `first-timers-only` | Reserved for first-time contributors |
| `help wanted` | Maintainers actively seeking help |
| `documentation` | Often good entry points |
### Evaluating a Project
Before contributing, verify:
- Has an OSI-approved open source license
- Recent commits (within last 3 months)
- Maintainers respond to issues/PRs
- Has CONTRIBUTING.md or contribution guidelines
- Automated tests (CI/CD) exist
---
## Understanding Large Codebases
### Step 1: Documentation First
Read in order: README.md → CONTRIBUTING.md → Architecture docs → API docs
### Step 2: Build and Run Locally
```bash
git clone https://github.com/<owner>/<repo>.git
cd <repo>
# Follow setup instructions, run tests
```
### Step 3: Explore Strategically
**Find important files**:
```bash
git log --pretty=format: --name-only | sort | uniq -c | sort -rg | head -20
```
**Understand entry points**: Look for `main`, `index`, `app`, or `server` files.
**Read tests**: They document expected behavior and show component usage.
### Step 4: Focus on Your Target
Don't try to understand everything:
1. Identify the module related to your issue
2. Read that module thoroughly
3. Trace dependencies one level up and down
4. Treat unrelated code as "black boxes"
### Step 5: Use Git as Documentation
```bash
git log --oneline <file> # File history
git log --grep="<keyword>" # Find relevant PRs
git blame <file> # Who to ask
```
---
## Writing Effective Pull Requests
### Before You Start
1. **Claim the issue**: Comment to let maintainers know you're working on it
2. **Ask questions**: If requirements are unclear, ask before coding
3. **Check for duplicates**: Search existing PRs
### Forking Workflow
For projects where you don't have write access:
```bash
# 1. Fork on GitHub, then clone your fork
git clone https://github.com/YOUR-USERNAME/<repo>.git
cd <repo>
# 2. Add upstream remote
git remote add upstream https://github.com/ORIGINAL-OWNER/<repo>.git
# 3. Keep fork updated
git fetch upstream
git checkout main
git merge upstream/main
# 4. Create feature branch and work
git checkout -b fix/your-fix
# ... make changes ...
git push origin fix/your-fix
# 5. Open PR from your fork to upstream
```
### Branch Strategy
```bash
git checkout -b <type>/<short-description>
# Examples:
git checkout -b fix/null-pointer-exception
git checkout -b feat/add-dark-mode
git checkout -b docs/update-readme
```
### Commit Messages
Follow [Conventional Commits](https://www.conventionalcommits.org/):
```
<type>[scope]: <description>
[optional body]
[optional footer]
```
**Quick reference**:
| Type | Use For |
|------|---------|
| `feat` | New feature |
| `fix` | Bug fix |
| `docs` | Documentation |
| `refactor` | Code restructure |
| `test` | Tests |
| `chore` | Maintenance |
**Example**:
```
fix(auth): resolve token refresh race condition
Fixes #123
```
For complete guide: See [reference/conventional-commits.md](reference/conventional-commits.md)
### PR Description Template
```markdown
## Summary
Brief description of what this PR does and why.
## Changes
- Change 1
- Change 2
## Related Issues
Fixes #123
## Testing
- [ ] Existing tests pass
- [ ] Added new tests
- [ ] Manually tested
```
### PR Sizing Best Practices
Research shows smaller PRs get better reviews:
| Size | Lines Changed | Review Quality |
|------|---------------|----------------|
| Ideal | ~50 lines | Thorough review |
| Good | <200 lines | Good feedback |
| Acceptable | <400 lines | Adequate review |
| Too Large | 400+ lines | Likely to miss issues |
### PR Best Practices
- **One concern per PR**: Don't mix features, fixes, and refactors
- **Self-review first**: Read your own diff before requesting review
- **Use draft PRs**: Open early for feedback on approach
- **Include tests**: Maintainers rarely merge untested code
- **Respond promptly**: Don't let PRs go stale
### What NOT to Include in PRs
Remove before committing:
- `.env`, `.env.local`, credentials, API keys
- IDE/editor configs (`.idea/`, `.vscode/` unless project-standard)
- Personal notes, TODOs, planning files
- Debug code, console.logs, print statements
- Unrelated formatting changes
- Large binary files, screenshots (unless required)
**Check for secrets before pushing:**
```bash
# Search for common secret patterns
git diff --cached | grep -iE "(api_key|password|secret|token).*="
```
### GitHub CLI Essentials
```bash
# Create PR interactively
gh pr create
# Create PR with title and body
gh pr create --title "Fix: resolve null pointer" --body "Fixes #123"
# Create draft PR
gh pr create --draft
# Check PR status
gh pr status
# View PR in browser
gh pr view --web
```
---
## Responding to Code Review
### Mindset
Code review is collaborative, not adversarial. Reviewers want to help improve the code.
### Response Templates
**When you agree**:
```
Good catch! Fixed in [commit hash].
```
**When you need clarification**:
```
I want to make sure I understand—are you suggesting [X] because of [Y]?
```
**When you disagree**:
```
I went with [current approach] because:
- [Reason 1]
- [Reason 2]
Open to changing if you think [alternative] better serves the project.
```
**When asked for big changes**:
```
Great suggestion. Would it make sense to address this in a follow-up PR?
```
### Guidelines
- Address all comments
- Stay calm—step away if frustrated
- Re-request review after addressing feedback
---
## Communicating with Maintainers
### Principles
- Keep communication public (others benefit)
- Be concise (maintainers have limited time)
- Do homework first (search existing issues)
- Be patient (follow up after one week, politely)
### Bug Report Template
```markdown
## Description
Clear description of the bug.
## Steps to Reproduce
1. Step 1
2. Step 2
3. See error
## Expected vs Actual Behavior
Expected: X
Actual: Y
## Environment
- OS: [e.g., macOS 14.0]
- Version: [e.g., v2.1.0]
```
### Feature Request Template
```markdown
## Summary
What you're proposing.
## Problem
What problem this solves.
## Proposed Solution
How you envision it working.
## Alternatives Considered
Other approaches you considered.
```
---
## Understanding Maintainer Perspective
### What Maintainers Deal With
- **Overwhelm**: Popular projects receive hundreds of issues/PRs
- **Volunteer work**: Most maintainers aren't paid
- **Burnout**: Endless notifications and demanding users
- **Quality gates**: Must protect codebase from bugs and technical debt
### What Maintainers Want
1. Contributors who read the docs first
2. Well-tested code
3. Clear communication about what and why
4. Patience (days or weeks to respond is normal)
5. Follow-through (don't abandon PRs mid-review)
### Quotes from Experienced Maintainers
> "The best good first issue is the one you created yourself. Try going through the product, and in the process of testing and understanding it, you'll find your good first issue."
> "All the projects I've contributed to are things I've used in some way. I never saw the point of just 'showing up' to a project."
---
## Common Mistakes to Avoid
### Before Starting
1. **Skipping CONTRIBUTING.md**: Always read contribution guidelines first
2. **Not checking existing work**: Search PRs/issues for duplicates
3. **Working on assigned issues**: Check if someone is already on it
4. **Building unsolicited features**: Propose in an issue first, wait for approval
5. **Not understanding the project**: Use it before contributing to it
### During Development
6. **Working on main branch**: Always use feature branches
7. **Giant PRs**: Break into smaller, focused PRs (<200 lines ideal)
8. **No tests**: Maintainers rarely merge untested code
9. **Including secrets**: Check for API keys, passwords, tokens
10. **Committing debug code**: Remove console.logs and print statements
### When Submitting
11. **Vague PR titles**: Be specific (not "Fixed bug" but "Fix null pointer in auth handler")
12. **Ignoring templates**: Use provided issue/PR templates
13. **Ignoring CI failures**: Fix all failing checks before requesting review
14. **No description**: Explain what, why, and how to test
### After Submitting
15. **Going silent**: Respond to feedback within 48 hours
16. **Arguing in reviews**: Stay collaborative, assume good intent
### Low-Value Contributions
- Adding your name to README files
- Trivial changes (typo fixes in comments nobody reads)
- "Drive-by" contributions with no intention to follow through
- Opening issues that are already documented
---
## What Counts as Meaningful
### High-Value
- Bug fixes with tests
- Documentation that helps new users
- Test coverage for untested code paths
- Performance improvements with benchmarks
- Security fixes (reported responsibly)
- Triaging issues: Reproducing bugs, closing duplicates
### Best Strategy
1. **Use the project first**: Become a real user before contributing
2. **Solve your own problems**: Fix bugs you encounter
3. **Think long-term**: Build relationships, not just contribution counts
4. **Quality over quantity**: One thoughtful PR beats ten trivial ones
---
## External References
### Official Guides
- [GitHub Open Source Guide](https://opensource.guide/how-to-contribute/)
- [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)
- [Google Engineering Practices](https://google.github.io/eng-practices/review/)
### Finding Projects
- [Good First Issue](https://goodfirstissue.dev/)
- [First Timers Only](https://www.firsttimersonly.com/)
- [Up For Grabs](https://up-for-grabs.net/)
- [CodeTriage](https://www.codetriage.com/)
### Community Insights
- [7 Common Mistakes New Contributors Make](https://dev.to/codergirl1991/7-common-mistakes-new-contributors-make-in-open-source-software-2noo)
- [Lessons from Reviewing 200+ PRs](https://bhupesh.me/hacktoberfest-pr-review/)
- [Nadia Eghbal - Working in Public](https://press.stripe.com/working-in-public)

27
open-source-contribution/marketplace.json Normal file
View file

@ -0,0 +1,27 @@
{
"name": "open-source-contribution",
"version": "1.0.0",
"description": "Guides developers through open source contributions including finding projects, writing PRs, conventional commits, and communicating with maintainers. Covers enterprise standards (Linux Kernel, Apache) and security disclosure.",
"author": "ronantakizawa",
"repository": "https://github.com/ronantakizawa/open-source-contribution",
"license": "MIT",
"keywords": [
"open-source",
"github",
"pull-request",
"conventional-commits",
"code-review",
"contributing",
"git"
],
"categories": [
"developer-tools",
"workflow",
"documentation"
],
"compatibility": [
"claude-code",
"codex-cli",
"cursor"
]
}

142
open-source-contribution/reference/conventional-commits.md Normal file
View file

@ -0,0 +1,142 @@
# Conventional Commits Reference
Complete guide to the [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/) specification.
## Format
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
## Types
| Type | Description | SemVer Impact |
|------|-------------|---------------|
| `feat` | Add, adjust, or remove a feature | **MINOR** bump |
| `fix` | Fix a bug | **PATCH** bump |
| `docs` | Documentation only changes | None |
| `style` | Code style (whitespace, formatting, semicolons) | None |
| `refactor` | Restructure code without changing behavior | None |
| `perf` | Performance improvements | None |
| `test` | Add or correct tests | None |
| `build` | Build tools, dependencies, project version | None |
| `ci` | CI/CD configuration changes | None |
| `chore` | Maintenance (e.g., .gitignore updates) | None |
| `revert` | Revert a previous commit | Depends |
## Scope
Provides context about what section of the codebase is affected:
```
feat(parser): add ability to parse arrays
fix(auth): resolve token refresh race condition
```
**Rules**: Optional, noun describing the section (e.g., `api`, `auth`, `parser`), don't use issue identifiers.
## Description
- **Required** - immediately follows colon and space
- **Imperative, present tense**: "add" not "added"
- **No capitalization** of first letter
- **No period** at end
- **Under 50 characters**
## Body
- **Optional** - separated by blank line
- Explain **what** and **why**, not how
- Wrap at **72 characters**
## Footer
| Token | Purpose | Example |
|-------|---------|---------|
| `Fixes` | Closes issue when merged | `Fixes #123` |
| `Closes` | Closes issue when merged | `Closes #456` |
| `Resolves` | Closes issue when merged | `Resolves #789` |
| `Related to` | Links without closing | `Related to #101` |
| `Reviewed-by` | Credit reviewers | `Reviewed-by: Name` |
| `BREAKING CHANGE` | Documents breaking change | See below |
## Breaking Changes
Triggers **MAJOR** version bump. Two ways to indicate:
**1. Exclamation mark**:
```
feat!: remove deprecated endpoints
feat(api)!: change authentication flow
```
**2. Footer notation**:
```
feat(api): change response format
BREAKING CHANGE: Response now returns nested object.
```
## Examples
**Simple fix**:
```
fix: prevent null pointer when config is missing
```
**Feature with scope**:
```
feat(auth): add OAuth2 login with Google provider
```
**With body and footer**:
```
fix(parser): handle deeply nested arrays
The previous implementation failed with stack overflow
when arrays exceeded 10 levels of nesting.
Fixes #892
```
**Breaking change**:
```
feat(api)!: migrate to v2 authentication
Replaced session-based auth with JWT tokens.
BREAKING CHANGE: Requires Bearer token in Authorization header.
Session cookies no longer supported.
Fixes #234
```
**Revert**:
```
revert: feat(auth): add OAuth2 login
This reverts commit abc1234.
Reason: Causing issues with SSO customers.
```
## Common Mistakes
```
fix: fix bug # Too vague
feat: added new feature # Past tense (use "add")
Fix: Handle null input # Capitalized after colon
docs: update readme. # Period at end
update readme # Missing type
feat: add login and fix header # Mixing concerns
```
## Tooling
- [commitlint](https://commitlint.js.org/) - Lint commit messages
- [commitizen](https://commitizen-tools.github.io/commitizen/) - Interactive CLI
- [husky](https://typicode.github.io/husky/) - Git hooks
- [semantic-release](https://semantic-release.gitbook.io/) - Automated versioning

74
open-source-contribution/reference/enterprise-practices.md Normal file
View file

@ -0,0 +1,74 @@
# Enterprise-Level Contribution Practices
Large foundations have rigorous standards that make you a better contributor everywhere.
## Linux Kernel
The most demanding contribution standards in open source.
### Patch Format
```
[PATCH] subsystem: summary phrase (max 70-75 chars)
Detailed explanation of what the patch does and why.
Wrap at 75 characters.
Signed-off-by: Your Name <email@example.com>
```
### Key Requirements
- **Signed-off-by required**: Certifies you have the right to submit (Developer Certificate of Origin)
- **Plain text only**: "No MIME, no links, no compression, no attachments"
- **Use `git send-email`**: Patches submitted via email, not pull requests
- **One logical change per patch**: Kernel must build and run after each patch
- **Run `scripts/checkpatch.pl`**: Style-check before submission
### Tags
| Tag | Meaning |
|-----|---------|
| `Acked-by:` | Developer agrees the patch is appropriate |
| `Reviewed-by:` | Developer has reviewed for correctness |
| `Tested-by:` | Person has tested and verified it works |
| `Reported-by:` | Credits the bug reporter |
| `Fixes:` | References the commit that introduced the bug |
### Finding Maintainers
```bash
scripts/get_maintainer.pl <patch-file>
```
### Review Process
- Wait 1-2 weeks before following up
- Use inline replies (not top-posting)
- Remove Acked-by/Tested-by tags if patch changes substantially
- Include changelog between patch versions
## Apache Software Foundation
### Progression Path
```
User → Contributor → Committer → PMC Member
```
### Key Requirements
- **Contributor License Agreement (CLA)**: Required before contributions accepted
- **Mailing list communication**: Use `dev@project.apache.org` for discussions
- **Apache License 2.0**: All contributions fall under this license
### What Apache Values
- Contributions beyond code: documentation, design, event coordination
- Long-term commitment over one-off patches
- Consistent, quality contributions lead to committer invitations
## References
- [Linux Kernel - Submitting Patches](https://docs.kernel.org/process/submitting-patches.html)
- [Apache - Get Involved](https://www.apache.org/foundation/getinvolved.html)

63
open-source-contribution/reference/security-disclosure.md Normal file
View file

@ -0,0 +1,63 @@
# Reporting Security Vulnerabilities
Security issues require special handling—never open public issues for vulnerabilities.
## Finding the Security Policy
Look for `SECURITY.md` in the repository root, `docs/`, or `.github/` folder.
## Coordinated Disclosure Process
1. **Report privately**: Use project's security contact or GitHub's private vulnerability reporting
2. **Provide details**: Reproduction steps, affected versions, potential impact
3. **Wait for acknowledgment**: Projects typically respond within a few days
4. **Coordinate on timeline**: Standard disclosure window is 90 days
5. **Help with the fix**: Offer to review patches or test fixes
6. **Public disclosure**: After patch is released, details can be published
## Timeline Expectations
| Situation | Timeline |
|-----------|----------|
| Standard vulnerability | 90 days to patch + disclose |
| Actively exploited | Shorter—urgent patching needed |
| Complex fix required | May extend beyond 90 days |
## Vulnerability Report Template
```markdown
## Vulnerability Report
**Affected Component**: [module/package name]
**Affected Versions**: [version range]
**Severity**: [Critical/High/Medium/Low]
## Description
[Clear explanation of the vulnerability]
## Steps to Reproduce
1. [Step 1]
2. [Step 2]
3. [Observe vulnerability]
## Impact
[What an attacker could do]
## Suggested Fix (optional)
[If you have ideas for remediation]
## Environment
- OS: [e.g., Ubuntu 22.04]
- Version: [e.g., v2.1.0]
```
## After Disclosure
- You may receive credit in the CVE and release notes
- Some projects have bug bounty programs
- Never disclose publicly before the patch is available
## References
- [Google OSS Vulnerability Guide](https://github.com/google/oss-vulnerability-guide)
- [OWASP Vulnerability Disclosure Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerability_Disclosure_Cheat_Sheet.html)

53
open-source-contribution/templates/bug-report.md Normal file
View file

@ -0,0 +1,53 @@
# Bug Report Template
Use this template when reporting bugs to open source projects.
---
## Bug Description
<!-- A clear and concise description of what the bug is -->
## Steps to Reproduce
1. Go to '...'
2. Click on '...'
3. Scroll down to '...'
4. See error
## Expected Behavior
<!-- What you expected to happen -->
## Actual Behavior
<!-- What actually happened -->
## Screenshots / Logs
<!-- If applicable, add screenshots or error logs to help explain the problem -->
```
Paste error logs here
```
## Environment
- **OS**: [e.g., macOS 14.0, Windows 11, Ubuntu 22.04]
- **Version**: [e.g., v2.1.0]
- **Runtime**: [e.g., Node 18.0, Python 3.11]
- **Browser** (if applicable): [e.g., Chrome 120, Firefox 121]
## Possible Solution
<!-- Optional: If you have an idea of what might be causing this or how to fix it -->
## Additional Context
<!-- Add any other context about the problem here -->
## Checklist
- [ ] I have searched existing issues to ensure this is not a duplicate
- [ ] I have included all relevant environment information
- [ ] I can reliably reproduce this issue

196
open-source-contribution/templates/commit-messages.md Normal file
View file

@ -0,0 +1,196 @@
# Commit Message Reference
Quick reference for writing conventional commit messages based on [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/).
## Format
```
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
```
## Types
| Type | Description | SemVer Bump |
|------------|--------------------------------------------------|-------------|
| `feat` | Add, adjust, or remove a feature | **MINOR** |
| `fix` | Fix a bug | **PATCH** |
| `docs` | Documentation only changes | None |
| `style` | Formatting, whitespace (no code change) | None |
| `refactor` | Restructure code without changing behavior | None |
| `perf` | Performance improvements | None |
| `test` | Add or correct tests | None |
| `build` | Build system or external dependencies | None |
| `ci` | CI/CD configuration | None |
| `ops` | Infrastructure, deployment, monitoring | None |
| `chore` | Maintenance tasks (e.g., .gitignore) | None |
| `revert` | Revert a previous commit | Depends |
## Rules
1. **Imperative mood**: "add" not "added" or "adds"
2. **Lowercase**: Start description with lowercase (after colon)
3. **No period**: Don't end description with a period
4. **50/72 rule**: Subject line ≤50 chars, body wrapped at 72 chars
5. **Blank line**: Separate subject from body with blank line
## Scope
Scope provides context about what section of the codebase is affected:
```
feat(parser): add ability to parse arrays
fix(auth): resolve token refresh race condition
```
**Common scopes** (project-specific):
- Component names: `auth`, `parser`, `api`, `ui`
- Modules: `core`, `utils`, `config`
- Features: `login`, `search`, `export`
**Rules**:
- Optional but recommended for larger projects
- Should be a noun describing the section
- Don't use issue identifiers as scopes
## Breaking Changes
Breaking changes trigger a **MAJOR** version bump.
**Two ways to indicate breaking changes**:
### 1. Exclamation mark notation
```
feat!: remove deprecated endpoints
feat(api)!: change authentication flow
```
### 2. Footer notation
```
feat(api): change response format
BREAKING CHANGE: Response now returns nested object.
Previously { name, email }. Now { user: { name, email } }.
```
**BREAKING CHANGE rules**:
- Must be uppercase
- `BREAKING-CHANGE` (with hyphen) is also valid
- Can be combined with `!` notation
- Can span multiple lines
## Examples
### Simple fix
```
fix: prevent crash when input is empty
```
### Feature with scope
```
feat(auth): add OAuth2 login support
```
### With body
```
fix(parser): handle nested arrays correctly
The previous implementation failed when arrays contained
more than 3 levels of nesting. This fix recursively
processes all nesting levels.
```
### With issue reference
```
fix(api): return 404 for missing resources
Previously returned 500 which confused error handling
on the client side.
Fixes #123
```
### Breaking change (exclamation)
```
feat(api)!: change authentication endpoint
The /auth endpoint now requires a JSON body instead of
form data.
BREAKING CHANGE: Update all clients to send
Content-Type: application/json header.
Closes #456
```
### Multiple issues
```
fix(validation): improve email regex pattern
- Added support for plus addressing (user+tag@domain.com)
- Fixed false positives for domains with hyphens
- Added comprehensive test cases
Fixes #101
Fixes #102
Related to #99
```
### Revert
```
revert: feat(auth): add OAuth2 login with Google
This reverts commit abc1234def5678.
Reason: Causing issues with existing SSO customers.
```
## Footer Keywords
| Keyword | Effect |
|--------------------|-------------------------------------|
| `Fixes #N` | Closes issue N when PR is merged |
| `Closes #N` | Closes issue N when PR is merged |
| `Resolves #N` | Closes issue N when PR is merged |
| `Related to #N` | Links to issue without closing |
| `Reviewed-by` | Credit reviewers |
| `Refs` | Reference commits/issues |
| `BREAKING CHANGE:` | Marks as breaking (**MAJOR** bump) |
## Anti-Patterns
Avoid these common mistakes:
```
# Too vague
fix: fix bug # What bug?
# Past tense (should be imperative)
feat: added new feature # Use "add"
# Capitalized (should be lowercase)
Fix: Handle null input # Lowercase after colon
# With period
fix: resolve issue. # Remove the period
# Too long (>50 chars in subject)
feat(authentication-system): add comprehensive OAuth2 support with refresh tokens
# No type
update readme with new instructions # Add type: "docs: ..."
# Mixing concerns (one commit = one change)
feat: add login and fix header and update docs
```
## Tooling
- **[commitlint](https://commitlint.js.org/)**: Lint commit messages
- **[commitizen](https://commitizen-tools.github.io/commitizen/)**: Interactive CLI
- **[husky](https://typicode.github.io/husky/)**: Git hooks
- **[semantic-release](https://semantic-release.gitbook.io/)**: Automate versioning

73
open-source-contribution/templates/feature-request.md Normal file
View file

@ -0,0 +1,73 @@
# Feature Request Template
Use this template when proposing new features to open source projects.
---
## Feature Summary
<!-- A clear and concise description of the feature you're proposing -->
## Problem Statement
<!-- What problem does this feature solve? Why is it needed? -->
Is your feature request related to a problem? Please describe:
<!-- e.g., "I'm always frustrated when..." -->
## Proposed Solution
<!-- Describe how you envision this feature working -->
### User Experience
<!-- How would users interact with this feature? -->
### Technical Approach (if known)
<!-- Optional: High-level technical implementation ideas -->
## Alternatives Considered
<!-- Describe any alternative solutions or features you've considered -->
1. **Alternative A**:
- Pros:
- Cons:
2. **Alternative B**:
- Pros:
- Cons:
## Use Cases
<!-- Provide specific examples of when this feature would be useful -->
1.
2.
3.
## Mockups / Examples
<!-- If applicable, add mockups, diagrams, or examples from other projects -->
## Implementation Considerations
- **Breaking Changes**: Will this require breaking changes?
- **Dependencies**: Are new dependencies required?
- **Scope**: Is this a small, medium, or large effort?
## Willingness to Contribute
<!-- Let maintainers know if you're willing to help implement -->
- [ ] I am willing to submit a PR to implement this feature
- [ ] I can help with testing
- [ ] I can help with documentation
## Additional Context
<!-- Add any other context, screenshots, or references about the feature request -->
## Checklist
- [ ] I have searched existing issues/discussions to ensure this is not a duplicate
- [ ] I have clearly described the problem this feature solves
- [ ] I have considered backward compatibility

64
open-source-contribution/templates/pull-request.md Normal file
View file

@ -0,0 +1,64 @@
# Pull Request Template
Use this template when opening pull requests to open source projects.
---
## Summary
<!-- Brief description of what this PR does and why -->
## Changes
<!-- List specific changes made -->
-
-
-
## Related Issues
<!-- Link to related issues using keywords -->
Fixes #
Related to #
## Type of Change
<!-- Mark the relevant option with an "x" -->
- [ ] Bug fix (non-breaking change that fixes an issue)
- [ ] New feature (non-breaking change that adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [ ] Documentation update
- [ ] Refactoring (no functional changes)
- [ ] Performance improvement
- [ ] Test addition or correction
## Testing
<!-- Describe how you tested your changes -->
- [ ] Existing tests pass
- [ ] Added new tests for changes
- [ ] Manually tested locally
### Test Instructions
<!-- How can reviewers test this change? -->
## Screenshots (if applicable)
<!-- Add before/after screenshots for UI changes -->
| Before | After |
|--------|-------|
| | |
## Checklist
- [ ] My code follows the project's style guidelines
- [ ] I have performed a self-review of my code
- [ ] I have commented my code where necessary (particularly complex areas)
- [ ] I have updated the documentation (if applicable)
- [ ] My changes generate no new warnings
- [ ] Any dependent changes have been merged and published
## Additional Notes
<!-- Any additional context, concerns, or questions for reviewers -->