Rename the idea template's "Approaches to explore" to "Areas to explore"

.github/ISSUE_TEMPLATE/idea.yml

@@ -1,13 +1,13 @@
 name: Idea
-description: A feature or direction worth exploring. Ideas are explored through spikes and, once settled, become an epic.
+description: A feature or improvement 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.
+        Don't prescribe a solution. Each area stays open for one or more 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
@@ -25,14 +25,14 @@ body:
     validations:
       required: true
   - type: textarea
-    id: approaches
+    id: areas
     attributes:
-      label: Approaches to explore
+      label: Areas to explore
       description: |
-        The range of possible solutions worth exploring. Each bullet is an area (an open question) and the directions worth trying in it.
-        List areas that need real exploration or design decisions, not questions with quick answers. Each direction should be big enough to become its own spike.
-        Name directions to weigh, not a plan or a recommended pick.
+        The areas to improve or problems to solve, each one for one or more spikes to explore. Each bullet names an area and a few approaches worth trying.
+        Each spike tries one approach to its area. It doesn't have to cover the whole area, and an area can have several spikes, each trying a different approach.
+        List areas that need real exploration or design decisions, not questions with quick answers. Name approaches to weigh, not a plan or a recommended pick.
       value: |
-        - **Area:** direction, direction, or direction.
+        - **Area:** approach, approach, or approach.
     validations:
       required: true

.github/ISSUE_TEMPLATE/spike.yml

@@ -7,13 +7,13 @@ body:
       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. It's done when the lead approves its draft PR.
         Don't prescribe a solution. Describe what to learn and leave the how to whoever picks it up.
-        One direction per spike, not a set to choose between. Title it `<area>: <direction>`, the area shared by its siblings. Prefer filing it under an idea (as a sub-issue), but a spike can stand alone.
+        One approach per spike, not a set to choose between. Title it `<area>: <approach>`, the area shared by its siblings. Prefer filing it under an idea (as a sub-issue), but a spike can stand alone.
         After filing, add a written-by label (`by: human`, `by: ai`, `by: ai-assisted`).
   - type: textarea
     id: exploring
     attributes:
       label: Exploring
-      description: The one direction being tried, broadly. Say what it is, not how to build it or how to run the exploration.
+      description: The one approach being tried, broadly. Say what it is, not how to build it or how to run the exploration.
     validations:
       required: true
   - type: textarea

software/application-software/workspace-inherit/.claude/skills/consolidate-spikes/SKILL.md

@@ -6,8 +6,8 @@ description: Turn finished spikes into implementation tickets: an idea's spikes,
 Drafts and files by the `create-ticket` rules; load it and the project's `ticket-conventions` first. Takes an idea or a standalone spike.
 
 1. **Gather** each spike's findings comment, draft PR, and the PR's reviews; from an idea, its sub-issues too.
-2. **Check it's done.** Every spike is done by `create-ticket`'s Spikes rules (the lead's latest review on its draft PR, from repos/<owner>/<repo>/pulls/<pr>/reviews, is an approval). From an idea, that's every spike under it, and every approach is covered by a spike area. Otherwise list what's missing, offer spikes for uncovered approaches, and stop.
-3. **Choose:** per area (title prefix), propose the direction to build (one spike's, or a mix) with a one-line why, from the findings and the lead's review. The user confirms or changes each.
-4. **Plan** the dev work by `create-ticket`'s Dev work rules: one ticket unless the work is large enough to split into vertical slices, which may cross areas. Each ticket: What, the slice; Notes, links to the spikes and draft PRs it draws on, and the dropped directions with why; context transfer, the findings' facts.
+2. **Check it's done.** Every spike is done by `create-ticket`'s Spikes rules (the lead's latest review on its draft PR, from repos/<owner>/<repo>/pulls/<pr>/reviews, is an approval). From an idea, that's every spike under it, and every one of its areas to explore is covered by a spike area. Otherwise list what's missing, offer spikes for uncovered areas, and stop.
+3. **Choose:** per area (title prefix), propose the approach to build (one spike's, or a mix) with a one-line why, from the findings and the lead's review. The user confirms or changes each.
+4. **Plan** the dev work by `create-ticket`'s Dev work rules: one ticket unless the work is large enough to split into vertical slices, which may cross areas. Each ticket: What, the slice; Notes, links to the spikes and draft PRs it draws on, and the dropped approaches with why; context transfer, the findings' facts.
 5. **Draft** them, and, from an idea or when split, one epic (From: the idea or spike) with the dev work as its sub-issues. Show all, with which slices run in parallel if split; file what the user OKs.
 6. **Close**, each with a one-line comment: the spikes as completed ("Consolidated into #<epic or dev work>"), their draft PRs unless a dev work ticket builds on that branch, and the idea as completed ("Settled in #<epic or dev work>").

software/application-software/workspace-inherit/.claude/skills/create-ticket/SKILL.md

@@ -15,8 +15,8 @@ idea → spikes → epic → dev work, or a standalone spike → dev work
 
 | Ticket | What it is | Issue type | Parent |
 |---|---|---|---|
-| Idea | What could be built and why. Its approaches are areas (open questions), each with directions worth trying. | none | none |
-| Spike | One direction to try in one area of an idea, or a small standalone improvement: what is tried and the hypothesis. Findings go in a comment and a draft PR (`report-spike`), not the ticket. | none | its idea, if any |
+| Idea | What could be built and why. Its areas to explore are things to improve or problems to solve, each with approaches worth trying. | none | none |
+| Spike | One approach to try on one area of an idea (it needn't cover the whole area), or a small standalone improvement: what is tried and the hypothesis. Findings go in a comment and a draft PR (`report-spike`), not the ticket. | none | its idea, if any |
 | Epic | Work too large for one dev work ticket: the goal and whole-epic outcomes, not a walkthrough of each ticket. A new issue linking the idea or spike it came from in "From". | Feature | none |
 | Dev work | Any implementation work: testable requirements, Notes for gotchas and pointers to code. Large work is cut into vertical slices (see Dev work below). | Feature, Bug, or Task | its epic, if any |
 
@@ -43,12 +43,12 @@ How every ticket reads, on any project:
 
 ## Spikes
 
-- One direction, not a set to choose between. If a spike reads "X or Y", it is two spikes.
-- Prefer an idea with a few spikes (often 2-4) under it; a spike can also stand alone, or with siblings, to explore an area.
-- Title it `<area>: <direction>`, with the area a short kebab-case name its siblings share (`graph-saving: Save a graph to a file and re-upload it`). An area may cover more than one of an idea's bullets. A lone small improvement needs no prefix.
-- Sibling spikes share the context transfer's summary and common facts; each adds only the facts particular to its direction.
+- One approach, not a set to choose between. If a spike reads "X or Y", it is two spikes.
+- Prefer an idea with a few spikes (often 2-4) under it; a spike can also stand alone, or with siblings, to explore an area. Several spikes can take on the same area in different ways.
+- Title it `<area>: <approach>`, with the area a short kebab-case name its siblings share (`graph-saving: Save a graph to a file and re-upload it`). An area may cover more than one of an idea's bullets. A lone small improvement needs no prefix.
+- Sibling spikes share the context transfer's summary and common facts; each adds only the facts particular to its approach.
 - An idea needn't get all its spikes at once: file an area's spikes when someone is ready to try them.
-- Done: its findings are posted, review feedback is addressed, and the lead's latest review on its draft PR is an approval (GitHub's Approve), including when the recommendation is to drop the direction. A done spike stays open until `consolidate-spikes` closes it.
+- Done: its findings are posted, review feedback is addressed, and the lead's latest review on its draft PR is an approval (GitHub's Approve), including when the recommendation is to drop the approach. A done spike stays open until `consolidate-spikes` closes it.
 
 ## Draft
 

software/application-software/workspace-inherit/.claude/skills/report-spike/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: report-spike
-description: Post a spike's findings on its ticket, judged against its hypothesis, and ask the lead to review its draft PR. Use when a spike's direction has been tried on an application-software repo (Argos, Nero).
+description: Post a spike's findings on its ticket, judged against its hypothesis, and ask the lead to review its draft PR. Use when a spike's approach has been tried on an application-software repo (Argos, Nero).
 ---
 
 A spike runs like any ticket (branch, commits, a draft PR from `open-pr`); this reports it. Load the project's `pr-conventions` first.