feat(contributing): make filing a good issue the default path before a PR #1834

CONTRIBUTING.md now asks every change to start with an issue or a discussion. That only works if filing one is the path of least resistance. Today it isn't — and most of the pieces already exist, unwired.

Two people show up, and we serve neither

A user hits a bug while using OpenSpec in their own project. They have openspec installed and an agent open. Best case: they say "file that as an issue" and it happens. Today openspec feedback "..." posts a free-form ## Summary / ## Details body with a Feedback: prefix — no repro, no expected-vs-actual, no agent/model. And openspec/specs/cli-feedback/spec.md specifies a /feedback skill that drafts and submits this properly; the template is written (src/core/templates/workflows/feedback.ts) but feedback was never added to ALL_WORKFLOWS in src/core/profiles.ts, so it has never been generated or installed by anyone.

A contributor clones this repo and opens a PR. They never ran openspec init, so no skill will ever reach them. They find no .github/ISSUE_TEMPLATE/ and no PR template — just a blank box and, later, a review comment asking them to go file the issue they didn't know they needed. That is the contributor we are most likely to lose, and the current plan has nothing for them.

The fix: catch both, ask for almost nothing

1. .github/ for the drive-by contributor.

• ISSUE_TEMPLATE/bug_report.yml — expected, actual, minimal repro, openspec --version, agent/model.
• ISSUE_TEMPLATE/feature_request.yml — the problem in one sentence, who it affects, what you tried.
• ISSUE_TEMPLATE/config.yml — route core-design topics to Discussions, per CONTRIBUTING step 1.
• PULL_REQUEST_TEMPLATE.md — Closes # on the first line, and directly under it: "No issue yet? Run openspec feedback "..." or open one here." This is the piece that catches the PR-first contributor at the exact moment they need it, with no bot and no CI.

2. Ship the feedback skill that already exists. Register feedback as a workflow so init/update install it. Its job is to draft, not interrogate: it already has the conversation, the failing command, the version and the platform, so it fills those in itself, asks only for what it genuinely cannot infer, shows one complete draft, and submits on a single confirmation. Same fields as the bug form.

3. Point the CLI at the form. openspec feedback --type bug|feature|feedback emits the matching body and a label that exists (bug, enhancement — note the feedback label still does not exist in this repo, so every submission currently falls back to unlabeled). The manual-fallback URL in generateManualSubmissionUrl() must gain ?template=bug_report.yml and prefill the form's field ids — today it passes bare title/body, which lands on the blank form and quietly undoes step 1 for every user without gh.

The test: a contributor who has never read CONTRIBUTING.md still ends up with a well-formed issue linked to their PR, without being asked to read anything.

Not in scope

CI enforcement of "every PR links an issue." Worth doing later, but a gate only punishes people the easy path hasn't reached yet. The PR template above should make it mostly unnecessary — if it doesn't, we will have real data on how often.

One open decision

Keep the workflow id feedback (already a CLI verb, already spec'd) or rename it to report? Reusing feedback is the lower-churn option.

Notes for whoever picks this up

• Step 1 is .github/-only and can ship on its own, today, with no proposal.
• Steps 2 and 3 add a workflow and a CLI flag, so per CONTRIBUTING step 2 they want a change proposal PR first. Spec to delta: openspec/specs/cli-feedback/spec.md (its "Feedback skill for agents" requirement is currently unimplemented).
• Adding a workflow id touches more than profiles.ts: shared/skill-generation.ts (skill + command entries), init.ts, profile-sync-drift.ts, utils/command-references.ts, shared/tool-detection.ts, WORKFLOW_PROMPT_META in commands/config.ts, plus the skills/ mirror and its parity hashes.