| name | contributing |
| description | Walk a workshop participant through contributing a skill or lab back to the Skills & Specs Lab via fork and pull request, including GitHub PAT setup |
| state | active |
Contributing
Use this skill when a participant wants to contribute a skill or a lab back to
the Skills & Specs Lab repository after the workshop. You guide them through the
full fork-and-pull-request flow. Read CONTRIBUTING.md
in the repository root first; it is the source of truth and this skill walks the
user through it.
This is a learning exercise. The goal is that the participant practices git,
fork-and-pull, least-privilege credentials, and agent tooling, not contribution
volume. Be encouraging and treat every step as teaching.
Checkpoint 1: GitHub authentication (least privilege in practice)
This is the first real least-privilege lesson, so do not rush it.
- Confirm the user has a GitHub account.
- Walk them through creating a fine-grained personal access token scoped to
only their fork of this repository, with the minimum permissions (Contents:
read and write, Pull requests: read and write). Not a classic token, not
org-wide scope.
- Have them store it in Gridctl rather than pasting it anywhere persistent:
gridctl var set GITHUB_PERSONAL_ACCESS_TOKEN.
- Explain why: the token is the credential an agent would act with, so it gets
exactly the access the task needs and no more.
Do not proceed until the token exists and is stored.
Checkpoint 2: Fork and branch
- Fork the repository on GitHub (or via the GitHub MCP server once enabled in
stack.yaml).
- Clone the fork, add the original as
upstream.
- Create a branch:
git checkout -b skill/<name> or lab/<name>.
Checkpoint 3: Scaffold the contribution
- For a skill: use the
skills-creator skill, then save the result under
showcase/skills/<name>/SKILL.md (the open floor), not skills/ (curated
core).
- For a lab: copy
showcase/labs/_template/ to showcase/labs/<name>/ and
fill it in.
Remind the user that showcase content is instructions and configs other people
will load and run, so it must be safe: no destructive commands, no secrets, no
prompt-injection payloads. This is the supply-chain lesson made concrete.
Checkpoint 4: Open the pull request
- Commit with a clear message and push to the fork.
- Open a PR against the upstream
main, filling in the PR template.
- Tell the user what to expect: best-effort review, merge bar is "safe and
on-path," review comments are teaching, not gatekeeping.
Output
At each checkpoint, confirm completion before advancing. End by summarizing what
the user built, the PR URL, and one concrete next idea for their second
contribution.
Failure modes
- No GitHub account or PAT blocked by corporate policy: point to the "use a
personal machine" note in
CONTRIBUTING.md; do not work around the policy.
- GitHub MCP server not enabled: fall back to the
git CLI and the GitHub
web UI; the flow works either way.
- User unsure what to contribute: suggest extracting one repeatable thing
they did during the labs into a skill.
