Add issue templates and standard labels #4

Summary

Repo hygiene for consistent issue filing across worktrees-hives. Standard labels and optional GitHub issue templates make multi-agent work discoverable, filterable, and consistent with the epic’s milestone taxonomy (scaffold / core / orchestrator / safety / platform / docs).

Problem / context

Today the repo already has custom labels (epic, core, orchestrator, docs, platform, safety) plus GitHub defaults, but:

• Label meanings are not documented for humans or agents that file follow-ups.
• There are no issue templates, so new issues tend to be thin (summary + short acceptance only), which slows planning and PR handoff.
• The skill will spawn workers that create and claim issues; templates reduce ambiguity and keep Linear↔GitHub footers consistent.
• Milestone A3 (scaffold) depends on this being done before core hive-loop work is treated as “production quality” process.

This issue is documentation and GitHub repo configuration only — not skill runtime code.

Goals

• Establish a canonical label set with short, operator-facing definitions.
• Provide optional issue templates (feature / bug / chore) that nudge authors toward problem, acceptance criteria, and the Linear footer pattern already used (Linear: … (\RM-N`)`).
• Document labels in README and/or a short CONTRIBUTING snippet so agents and humans share one source of truth.
• Align template fields with how workers will later parse issues (title, summary, acceptance checkboxes).

Non-goals

• Building runtime label enforcement in the skill (discover filters, auto-labeling logic) — that belongs in later core issues.
• Replacing Linear as the planning system of record; GitHub remains the execution surface, Linear stays linked via footer.
• Migrating or closing existing issues; re-labeling historical issues is optional cleanup, not required for Done.
• Designing full product PR templates or CODEOWNERS (out of scope for A3).
• Implementing the skill’s discover / claim / orchestrator behavior (see Discover open issues/PRs for allowed owners #5–Issue → PR workflow (never auto-merge) #8).

Detailed acceptance criteria

• Labels present and usable on rmems/worktrees-hives:
  • epic — multi-issue umbrella / milestone grouping
  • core — skill loop primitives (discover, claim, PR, babysit, state)
  • orchestrator — multi-subagent scheduling, caps, join/report
  • docs — README, SKILL.md, templates, operator docs
  • platform — install paths, multi-agent-host packaging, validation on second host
  • safety — never-merge, force-with-lease, fix caps, owner allowlist, hang recovery
• Each of the six labels has a non-empty description in GitHub (and the same text appears in docs).
• Optional issue templates under .github/ISSUE_TEMPLATE/ (or GitHub form YAML):
  • Feature (default for new skill capability)
  • Bug (unexpected skill/CI/process failure)
  • Chore (hygiene, packaging, docs-only)
• Templates include at least: Summary, Problem / context (or repro), Acceptance criteria (checkboxes), and a Linear footer placeholder matching existing style.
• README (and/or CONTRIBUTING snippet) documents label meanings and when to use which template.
• No change required to skill runtime code for this issue to close.
• Linear footer preserved/updated: link to RM-4.

Design options

Recommendation: A or B (prefer B if maintainers want required fields; A is fine for agent-heavy workflows that paste markdown). Labels already exist — task is descriptions + docs, not inventing new names unless gaps appear.

Suggested label colors (keep existing if already set): epic red, core blue, orchestrator purple, docs blue-gray, platform green, safety orange/red.

Dependencies

Blocks: nothing hard. Blocked by: nothing hard (can ship anytime in scaffold phase).

Risks

• Label sprawl if agents invent new labels ad hoc — mitigate with “use only documented labels unless epic expands taxonomy.”
• Template fatigue — keep templates short; avoid 20 required fields.
• Drift between Linear issue shape and GitHub templates — keep Linear link footer as the only mandatory cross-link field.
• Duplicate defaults (documentation vs docs) — document that skill issues use docs, leave GitHub defaults alone or note which to prefer.

Suggested plan

1. Inventory current labels via gh label list; fill empty descriptions for the six standard labels.
2. Add LABELS.md section to README or short CONTRIBUTING: name → meaning → typical milestones.
3. Add issue templates (feature / bug / chore) with shared footer pattern:
   Linear: <url> (\RM-N`)`
4. Optionally add config.yml with contact links / disable blank issues if desired.
5. Smoke: open a draft issue from each template; confirm labels apply cleanly.
6. Cross-link from Expand README: install, commands, architecture #3 README expansion if that lands later (avoid duplicating long prose).

Prior art / references

• Repo purpose: multi-subagent hive — issues→PRs + PR babysit under isolated git worktrees; owners rmems, Limen-Neural; never merge.
• Prior art skill: pr-babysit (~/.agents/skills/pr-babysit/SKILL.md) — owner allowlist and safety tone this repo should match in docs.
• Epic milestones: A scaffold (this issue = A3).

Hybrid layer

Primary implementation layer: docs

This issue remains valid under the Python/Rust hybrid architecture (epic #21). Rust owns worktrees, state, process supervision, and hard safety; Python owns orchestration/policy; agent skills document how Grok drives both.

Linear: https://linear.app/rpd-34/issue/RM-4/worktrees-hives-gh4-add-issue-templates-and-standard-labels (RM-4)