mirror of
https://github.com/glittercowboy/get-shit-done
synced 2026-04-25 17:25:23 +02:00
e66f7e889e
Overhaul CONTRIBUTING.md and all GitHub issue/PR templates to enforce a structured, approval-gated contribution process that cuts down on drive-by feature submissions. Changes: - CONTRIBUTING.md: add Types of Contributions section defining Fix, Enhancement, and Feature with escalating requirements and explicit rejection criteria; add Issue-First Rule section making clear that enhancements require approved-enhancement and features require approved-feature label before any code is written; backport gsd-2 testing standards (t.after() per-test cleanup, array join() fixture pattern, Node 24 as primary CI target, test requirements by change type, reviewer standards) - .github/ISSUE_TEMPLATE/enhancement.yml: new template requiring current vs. proposed behavior, reason/benefit narrative, full scope of changes, and breaking changes assessment; cannot be clicked through - .github/ISSUE_TEMPLATE/feature_request.yml: full rewrite requiring solo- developer problem statement, what is being added, full file-level scope, user stories, acceptance criteria, maintenance burden assessment, and alternatives considered; incomplete specs are closed, not revised - .github/pull_request_template.md: converted from general template to a routing page directing contributors to the correct typed template; using the default template for a feature or enhancement is a rejection reason - .github/PULL_REQUEST_TEMPLATE/fix.md: new typed template requiring confirmed-bug label on linked issue and regression test confirmation - .github/PULL_REQUEST_TEMPLATE/enhancement.md: new typed template with hard gate on approved-enhancement label and scope confirmation section - .github/PULL_REQUEST_TEMPLATE/feature.md: new typed template requiring file inventory, spec compliance checklist from the issue, and scope confirmation that nothing beyond the approved spec was added Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
114 lines
3.3 KiB
Markdown
114 lines
3.3 KiB
Markdown
## Feature PR
|
|
|
|
> **Using the wrong template?**
|
|
> — Bug fix: use [fix.md](?template=fix.md)
|
|
> — Enhancement to existing behavior: use [enhancement.md](?template=enhancement.md)
|
|
|
|
---
|
|
|
|
## Linked Issue
|
|
|
|
> **Required.** This PR will be auto-closed if no valid issue link is found.
|
|
> The linked issue **must** have the `approved-feature` label. If it does not, this PR will be closed without review — no exceptions.
|
|
|
|
Closes #
|
|
|
|
> ⛔ **No `approved-feature` label on the issue = immediate close.**
|
|
> Do not open this PR if a maintainer has not yet approved the feature spec.
|
|
> Do not open this PR if you wrote code before the issue was approved.
|
|
|
|
---
|
|
|
|
## Feature summary
|
|
|
|
<!-- One paragraph. What does this feature add? Assume the reviewer has read the issue spec. -->
|
|
|
|
## What changed
|
|
|
|
### New files
|
|
|
|
<!-- List every new file added and its purpose. -->
|
|
|
|
| File | Purpose |
|
|
|------|---------|
|
|
| | |
|
|
|
|
### Modified files
|
|
|
|
<!-- List every existing file modified and what changed in it. -->
|
|
|
|
| File | What changed |
|
|
|------|-------------|
|
|
| | |
|
|
|
|
## Implementation notes
|
|
|
|
<!-- Describe any decisions made during implementation that were not specified in the issue.
|
|
If any part of the implementation differs from the approved spec, explain why. -->
|
|
|
|
## Spec compliance
|
|
|
|
<!-- For each acceptance criterion in the linked issue, confirm it is met. Copy them here and check them off. -->
|
|
|
|
- [ ] <!-- Acceptance criterion 1 from issue -->
|
|
- [ ] <!-- Acceptance criterion 2 from issue -->
|
|
- [ ] <!-- Add all criteria from the issue -->
|
|
|
|
## Testing
|
|
|
|
### Test coverage
|
|
|
|
<!-- Describe what is tested and where. New features require new tests — no exceptions. -->
|
|
|
|
### Platforms tested
|
|
|
|
- [ ] macOS
|
|
- [ ] Windows (including backslash path handling)
|
|
- [ ] Linux
|
|
|
|
### Runtimes tested
|
|
|
|
- [ ] Claude Code
|
|
- [ ] Gemini CLI
|
|
- [ ] OpenCode
|
|
- [ ] Codex
|
|
- [ ] Copilot
|
|
- [ ] Other: ___
|
|
- [ ] N/A — specify which runtimes are supported and why others are excluded
|
|
|
|
---
|
|
|
|
## Scope confirmation
|
|
|
|
- [ ] The implementation matches the scope approved in the linked issue exactly
|
|
- [ ] No additional features, commands, or behaviors were added beyond what was approved
|
|
- [ ] If scope changed during implementation, I updated the issue spec and received re-approval
|
|
|
|
---
|
|
|
|
## Checklist
|
|
|
|
- [ ] Issue linked above with `Closes #NNN` — **PR will be auto-closed if missing**
|
|
- [ ] Linked issue has the `approved-feature` label — **PR will be closed if missing**
|
|
- [ ] All acceptance criteria from the issue are met (listed above)
|
|
- [ ] Implementation scope matches the approved spec exactly
|
|
- [ ] All existing tests pass (`npm test`)
|
|
- [ ] New tests cover the happy path, error cases, and edge cases
|
|
- [ ] CHANGELOG.md updated with a user-facing description of the feature
|
|
- [ ] Documentation updated — commands, workflows, references, README if applicable
|
|
- [ ] No unnecessary external dependencies added
|
|
- [ ] Works on Windows (backslash paths handled)
|
|
|
|
## Breaking changes
|
|
|
|
<!-- Describe any behavior, output format, file schema, or API changes that affect existing users.
|
|
For each breaking change, describe the migration path.
|
|
Write "None" only if you are certain. -->
|
|
|
|
None
|
|
|
|
## Screenshots / recordings
|
|
|
|
<!-- If this feature has any visual output or changes the user experience, include before/after screenshots
|
|
or a short recording. Delete this section if not applicable. -->
|