Add Contributing guidance for skeleton-based projects and the skeleton itself

Add a Contributing section to the overview covering the tox-driven
development loop, release notes, and releasing, and a separate
skeleton-contrib document for the constraints specific to contributing
to the skeleton itself (squash merges, repo-absolute references).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Author: jaraco

index.md

@@ -9,3 +9,56 @@ See [design](design.md) and [challenges](challenges.md) for more details.
 ## Alternatives
 
 An alternative to maintaining this boilerplate in a shared repo is not to have the boilerplate at all, a concept implemented by the [Coherent System](/coherent-oss/system).
+
+# Contributing
+
+This section provides guidance on contributing to skeleton-based projects. If contributing to the skeleton itself, see the [separate guidance](skeleton-contrib.md).
+
+## Running Checks
+
+The skeleton relies on [tox](https://pypi.org/project/tox) to drive development tasks. See [design](design.md) for the rationale behind the tools referenced below.
+
+Run all checks (tests, formatting, linting, type checks, and coverage) on the default Python with:
+
+```
+tox
+```
+
+To run under a specific Python:
+
+```
+tox -e py314
+```
+
+List the other available environments and what each does with:
+
+```
+tox list
+```
+
+Build the documentation with:
+
+```
+tox -e docs
+```
+
+Disable an individual check for a run by passing `-p no:{plugin}` through to pytest. For example, to skip coverage:
+
+```
+tox -- -p no:cov
+```
+
+The checks only report violations; they never modify your code. Apply formatting and lint fixes with:
+
+```
+ruff format .
+ruff check --fix .
+```
+
+## Adding release notes
+
+Record every user-facing change as a [Towncrier](https://towncrier.readthedocs.io/) news fragment under `newsfragments/`; release notes are assembled from these fragments. Name the file using the issue ID (or pull request ID if no relevant issue) and scope (removal, feature, bugfix). If no issue ID is available, use some unique identifier prefixed by a `+` (i.e. `+1dbf102a.feature.rst`).
+
+## Releasing
+
+When main is stable, cut a release from main using `tox -e finalize`, which will assemble and commit the release notes and tag the commit. Push that commit to release to PyPI using GitHub Actions.

skeleton-contrib.md

@@ -0,0 +1,15 @@
+# Contributing to the Skeleton
+
+This guidance applies to changes to the skeleton project *itself*. Because the skeleton's history is merged into each of its downstream consumers, contributions here carry extra constraints.
+
+## Validation
+
+There are no checks or tests. Consider validating any changes with some downstream project first and then porting (or cherry-picking) the commit to skeleton.
+
+## Squash merge pull requests
+
+Always squash merge pull requests. Every commit on the skeleton's main branch is inherited by every downstream project, so collapsing each change to a single commit keeps that shared history as small and legible as possible.
+
+## Use repo-absolute references
+
+Always use repo-absolute references in commit messages and news fragments — for example `jaraco/skeleton#123`, never a bare `#123`. Because these commits are merged into downstream projects, a bare reference would resolve against the wrong repository and notify unrelated issues. See [Commit Integrations Mismatch](challenges.md) for rationale.