Issue and PR templates, and a create-ticket skill

.claude/skills/create-ticket/SKILL.md

@@ -0,0 +1,11 @@
+---
+name: create-ticket
+description: Draft and file a GitHub issue (idea, spike, epic, or dev work) on Delphi from its issue templates. Use whenever the user wants to create, file, or log a Delphi ticket, issue, idea, spike, epic, bug, or task.
+---
+
+Follow the shared rules in `software/application-software/workspace-inherit/.claude/skills/create-ticket/SKILL.md`, with these Delphi specifics:
+
+- Repo: Northeastern-Electric-Racing/Delphi (base branch `main`); templates in `.github/ISSUE_TEMPLATE/`.
+- Labels: the template's category and a written-by label; Delphi has no area labels.
+- Vocabulary: `docs/design.md`'s terms (workspace, ws branch, refresh, propose, `workspace-inherit/`).
+- Diagrams: show the branches and folders a change touches (main, `ws/*`, `.delphi/`, CI), before and after.

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: false

.github/ISSUE_TEMPLATE/dev-work.yml

@@ -0,0 +1,47 @@
+name: Dev work
+description: Implementation work of any kind (feature, bug, or task). Set the issue type to match.
+labels: [dev work]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        One template for all implementation work. Set the issue **type** (Feature, Bug, or Task) instead of picking a different template.
+        If this belongs to an epic, add it as a sub-issue of the epic.
+        After filing, add a written-by label (`by: human`, `by: ai`, `by: ai-assisted`).
+  - type: textarea
+    id: what
+    attributes:
+      label: What
+      description: |
+        The change in a few sentences.
+        For a bug: what happens, what should happen, and steps to reproduce.
+    validations:
+      required: true
+  - type: textarea
+    id: diagram
+    attributes:
+      label: Diagram
+      description: Optional. Illustrate the change. Mermaid (in a mermaid code block), ASCII, or an uploaded image.
+  - type: textarea
+    id: requirements
+    attributes:
+      label: Requirements
+      description: What must be true for this to be done. Clear, broad, testable checkboxes. Aim for 3-5; never more than 7.
+      value: "- [ ] "
+    validations:
+      required: true
+  - type: textarea
+    id: notes
+    attributes:
+      label: Notes
+      description: Optional. Anything that helps whoever picks this up, such as links to spikes, PRs or docs, gotchas, and constraints.
+  - type: textarea
+    id: context-transfer
+    attributes:
+      label: Context transfer
+      description: Optional. A dump of context for whoever picks this up (person or agent). Start with a short summary, then the raw context.
+      value: |
+        SUMMARY
+
+        CONTEXT
+      render: text

.github/ISSUE_TEMPLATE/epic.yml

@@ -0,0 +1,62 @@
+name: Epic
+description: A settled idea, broken into dev work tickets.
+type: Feature
+labels: [epic]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        An epic is a finished idea: the approach is decided. Link its dev work tickets as sub-issues.
+        If the idea came through spikes, link the idea below and close it as completed.
+        After filing, add a written-by label (`by: human`, `by: ai`, `by: ai-assisted`).
+  - type: input
+    id: from-idea
+    attributes:
+      label: From idea
+      description: The idea issue this epic came from, if any.
+      placeholder: "#123"
+  - type: textarea
+    id: goal
+    attributes:
+      label: Goal
+      description: What this delivers, and for whom, in a few sentences.
+    validations:
+      required: true
+  - type: textarea
+    id: approach
+    attributes:
+      label: Approach
+      description: The chosen approach, and the spike or decision it came from.
+    validations:
+      required: true
+  - type: textarea
+    id: diagram
+    attributes:
+      label: Diagram
+      description: Illustrate the change, ideally before and after. Mermaid (in a mermaid code block), ASCII, or an uploaded image.
+    validations:
+      required: true
+  - type: textarea
+    id: out-of-scope
+    attributes:
+      label: Out of scope
+      description: What this epic deliberately does not cover.
+      value: "- "
+  - type: textarea
+    id: requirements
+    attributes:
+      label: Requirements
+      description: What must be true for the epic to be done. Clear, broad checkboxes. Aim for 3-5; never more than 7.
+      value: "- [ ] "
+    validations:
+      required: true
+  - type: textarea
+    id: context-transfer
+    attributes:
+      label: Context transfer
+      description: Optional. A dump of context for whoever picks this up (person or agent). Start with a short summary, then the raw context.
+      value: |
+        SUMMARY
+
+        CONTEXT
+      render: text

.github/ISSUE_TEMPLATE/idea.yml

@@ -0,0 +1,38 @@
+name: Idea
+description: A feature or direction worth exploring. Ideas are explored through spikes and, once settled, become an epic.
+labels: [idea]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        **Pipeline:** idea → spikes (sub-issues) → epic → dev work.
+        Keep an idea short. If it is small enough to just try, file a spike instead.
+        Don't prescribe a solution. Approaches stay open options for spikes to explore, not a chosen design.
+        After filing, add a written-by label (`by: human`, `by: ai`, `by: ai-assisted`).
+  - type: textarea
+    id: idea
+    attributes:
+      label: Idea
+      description: One or two sentences. What could we build, and for whom? Describe the outcome, not the implementation.
+      placeholder: Let a folder share skills with every workspace below it.
+    validations:
+      required: true
+  - type: textarea
+    id: rationale
+    attributes:
+      label: Rationale
+      description: Why this idea is good and worth exploring. The reasoning behind it, not a history of the problem.
+    validations:
+      required: true
+  - type: textarea
+    id: approaches
+    attributes:
+      label: Approaches to explore
+      description: |
+        The range of possible solutions worth exploring. Each bullet is an area and the options in it.
+        List areas that need real exploration or design decisions, not questions with quick answers. Each one should be big enough to become a spike.
+        Name options to weigh, not a plan or a recommended pick.
+      value: |
+        - **Area:** option, option, or option.
+    validations:
+      required: true

.github/ISSUE_TEMPLATE/spike.yml

@@ -0,0 +1,35 @@
+name: Spike
+description: Explore one approach to an idea, or try a small standalone improvement. Draft PRs welcome.
+labels: [spike]
+body:
+  - type: markdown
+    attributes:
+      value: |
+        A spike lays out what to explore and what we expect. It does **not** hold answers: post findings as comments and link draft PRs.
+        Don't prescribe a solution. Describe what to learn and leave the how to whoever picks it up.
+        Under an idea, each spike is usually a separate implementation of it; add it as a sub-issue of the idea. A small improvement can be a standalone spike.
+        After filing, add a written-by label (`by: human`, `by: ai`, `by: ai-assisted`).
+  - type: textarea
+    id: exploring
+    attributes:
+      label: Exploring
+      description: The approach or implementation being explored, broadly. Say what it is, not how to build it or how to run the exploration.
+    validations:
+      required: true
+  - type: textarea
+    id: hypothesis
+    attributes:
+      label: Hypothesis
+      description: What we expect this approach to prove, in one or two sentences. Reviewers judge the draft PRs and findings against it.
+    validations:
+      required: true
+  - type: textarea
+    id: context-transfer
+    attributes:
+      label: Context transfer
+      description: Optional. A dump of context for whoever picks this up (person or agent). Start with a short summary, then the raw context. Facts only (where code lives, current behavior, constraints, links), not instructions or a proposed solution.
+      value: |
+        SUMMARY
+
+        CONTEXT
+      render: text

.github/pull_request_template.md

@@ -0,0 +1,31 @@
+<!--
+Title: concise and imperative, no ticket number. A change to .delphi/ starts with its version ("Delphi 0.7.0: ...").
+After opening, add a written-by label (by: human, by: ai, by: ai-assisted).
+-->
+
+## Changes
+
+<!-- What landed and the key design choice, in about 50 words. Not a file-by-file list. -->
+
+## Diagram
+
+<!-- Optional. Illustrate the change, ideally before and after. Mermaid, ASCII, or an image. Delete if unused. -->
+
+## Testing
+
+<!-- A short list of what was tested: e2e checks added, dry runs, edge cases. One line each, no step-by-step detail. Leave out the obvious; the checklist covers it. -->
+
+- 
+
+## Notes
+
+<!-- Optional. Tradeoffs, follow-ups, or what was left out and why. -->
+
+## Checklist
+
+- [ ] `ci/check.sh .` and `bash tests/e2e.sh` pass
+- [ ] Version bumped if a `.delphi/manifest.yml` file changed
+- [ ] No merge conflicts
+- [ ] Request reviewers & ping on Slack
+
+Closes #

CLAUDE.md

@@ -37,7 +37,7 @@ source of truth; `docs/goals.md` lists what any change must keep.
   (copied once into a new workspace there). Any folder may add `workspace-inherit/` (written onto the
   `ws/*` root of every workspace below on each refresh, never proposed; `opt-out:` in a
   `workspace.yml` skips a path).
-- `.github/workflows/delphi.yml` (identical to the template's copy), `.github/CODEOWNERS`.
+- `.github/workflows/delphi.yml` (identical to the template's copy), `.github/CODEOWNERS`; issue templates (idea, spike, epic, dev work) and the PR template in `.github/`, filed with the `create-ticket` skill (`.claude/skills/`).
 - `tests/e2e.sh`: end-to-end test in a throwaway sandbox (bare origin, stub `gh` logging to `gh.log`).
 
 ## Rules