|
| 1 | +# Contributing |
| 2 | + |
| 3 | +Thanks for contributing to `chalk-skills`. |
| 4 | + |
| 5 | +## Scope |
| 6 | + |
| 7 | +Contribute provider-agnostic, reusable skills and supporting tooling only. Review scope boundaries in `docs/open-source-scope.md`. |
| 8 | + |
| 9 | +## Before Opening a PR |
| 10 | + |
| 11 | +1. Confirm the skill fits the open-source scope. |
| 12 | +2. Follow the skill contract in `docs/skill-contract.md`. |
| 13 | +3. Run validation locally: |
| 14 | + |
| 15 | +```bash |
| 16 | +scripts/validate-skills.sh |
| 17 | +``` |
| 18 | + |
| 19 | +4. Keep behavior changes intentional and bump `version` using SemVer. |
| 20 | + |
| 21 | +## Create a New Skill |
| 22 | + |
| 23 | +Use the scaffold script for consistent initialization: |
| 24 | + |
| 25 | +```bash |
| 26 | +scripts/init-skill.sh <skill-name> --description "what it does and when to use it" --owner chalk |
| 27 | +``` |
| 28 | + |
| 29 | +For project-owned skills in external repos: |
| 30 | + |
| 31 | +```bash |
| 32 | +scripts/init-skill.sh <skill-name> --description "..." --owner project --path .chalk/skills |
| 33 | +``` |
| 34 | + |
| 35 | +## Skill Change Requirements |
| 36 | + |
| 37 | +- Keep `name`, folder name, and index entry aligned. |
| 38 | +- Include required frontmatter keys. |
| 39 | +- Use `owner: chalk` for core repo skills. |
| 40 | +- Do not add provider-specific metadata files. |
| 41 | +- Keep `SKILL.md` concise and practical. |
| 42 | + |
| 43 | +## Pull Request Guidelines |
| 44 | + |
| 45 | +- Explain what changed and why. |
| 46 | +- Include trigger examples for new/updated skills. |
| 47 | +- Call out any compatibility impact. |
| 48 | +- Update `skills/skills-index.yaml` when adding or renaming skills. |
| 49 | +- Update `CHANGELOG.md` for notable user-facing behavior or contract changes. |
| 50 | + |
| 51 | +## Review Criteria |
| 52 | + |
| 53 | +- Contract compliance (`docs/skill-contract.md`) |
| 54 | +- Clear, deterministic workflow steps |
| 55 | +- Safe defaults and guardrails |
| 56 | +- No vendor lock-in in definitions or metadata |
| 57 | + |
| 58 | +Use `docs/review-checklist.md` during review. |
| 59 | + |
| 60 | +## Versioning |
| 61 | + |
| 62 | +Follow `docs/versioning.md` for SemVer bump rules and metadata-version migration policy. |
| 63 | + |
| 64 | +## Maintainers and Review SLA |
| 65 | + |
| 66 | +- Core skill and contract changes require maintainer approval (see `.github/CODEOWNERS`). |
| 67 | +- Target first maintainer response within 3 business days. |
| 68 | +- Target decision (merge/request changes) within 7 business days for complete PRs. |
0 commit comments