[sabind]

Why

Part of open sourcing the codebase. Contributors need a consistent way to get up to speed, to collaborate, and to file issues that carry the right information for reviewing and decision making. Issue #8.

Closes #8

What

The repository gains a contributing guide, three issue forms with a chooser that routes questions, ideas and vulnerabilities elsewhere, and the standard community files. The pr skill accepts a ticket in any form and defers to a repository's own pull request template, so this repository's template can carry the Closes #<number> convention.

Changes

• Add .github/CONTRIBUTING.md, LICENSE (MIT), .github/SECURITY.md and .github/CODE_OF_CONDUCT.md; the README now points at the guide instead of carrying the setup and eval rules itself; the plugin manifest gains a license field and goes to 0.5.1. Necessary to let people contribute consistently, get up to speed and understand how to collaborate. The README defers to the sources of truth to avoid multiple sources of truth. The license and security policy are boilerplate that open source projects need.
• Add three issue forms (misbehaving skill or agent, proposal, new eval case), each labelled triage and typed, and a chooser that disables blank issues and sends questions and ideas to Discussions and vulnerabilities to the security policy. Coordinating new features needs the right information captured in tickets, and consistency helps reviewing and decision making.
• The pr skill accepts a ticket as an issue number, URL or tracker key, prefers a repository's own pull request template over its default, and its default template moves to skills/pr/pull_request_template.md; this repository's own template asks for Closes #<number>, shows the shape of a Changes bullet, and asks for the eval table when a skill, agent, rule or hook changed. The pr skill is repository-agnostic and meant for use anywhere; the local template is an example of a repository's own template, which the skill will use.
• Add checks/test_issue_forms.py, a free check under make validate that reads the component dropdown of every issue form and asserts it lists exactly the skills, agents, rules and hook events on disk, ends in the catch-all, and is identical across the three forms. Issue forms cannot share YAML, so the dropdown is duplicated; the check confirms the dropdowns stay aligned with the code.
• Add the spec under .claude/specs/contributing-guide/, with tasks 1 and 2.4 ticked. Specs are part of the docs as historical references: they freeze after the change and are markers rather than living docs.

Testing

make validate: 9 unit tests OK (6 existing plus the 3 new issue-form checks), both validators passed. The new check was also shown to fail when a form drops a component and when a skill folder is added without a dropdown entry, with those edits reverted afterwards.

make eval-skill-pr (3 runs per case):

CASE	SCORE	PASS%	RUNS	COST
opens-pr-with-stub-gh	1.00	100%	3	$0.57
stops-at-starting-checks	1.00	100%	3	$0.50

2 cases, 100s, $1.07. A kept run of opens-pr-with-stub-gh (1 run, $0.18) scored 1.00; its trace shows the Read of skills/pr/pull_request_template.md and a gh pr create body with the six headings, which the graders cannot see.

Task 2.4, the manual check of the pr skill with an issue number as the ticket, is this pull request: the title begins [#8], Why names #8 and ends with Closes #8, and the description carries this repository's six headings. The issue was given up front, so the ticket question and its "any form works" wording were not exercised.

Risk and rollout

No rollout risk beyond regressions to the skills, which the evals guard. The forms, chooser and community files take effect only once merged to main.

Notes for reviewers

Focus on the Markdown docs and the changes to the pr skill under skills/pr/. No rule changed.

Tasks 6.2 and 6.3 in the spec, checking the forms, the chooser and the community profile on GitHub, can only run after the merge and will be recorded afterwards.

🤖 Generated with Claude Code

[dansabin]

No need to explain the upcoming section here.

[dansabin]

We don't really have milestones yet. are we getting ahead of ourselves?