create-claude-rails 0.1.2 → 0.3.0

package/templates/skills/link/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: link
+description: |
+  Set up local development linking for Claude on Rails. Detects whether
+  you're in the CoR source repo or a consuming project and runs the
+  appropriate npm link command. Use when: "link", "local dev", "use local
+  CoR", "/link".
+---
+
+# /link — Local Development Linking
+
+## Purpose
+
+Connect a consuming project to a local checkout of Claude on Rails so
+template changes are immediately available without publishing to npm.
+
+## Context Detection
+
+Before doing anything, determine where you are:
+
+**CoR source repo** (`package.json` has `name: "create-claude-rails"`):
+- Run `npm link` to register the package globally
+- This makes the local checkout available to any project that links to it
+- Tell the user: "Registered locally. In your other projects, run `/link`
+  to connect them to this checkout."
+
+**Any other project** (anything that isn't the CoR source repo):
+- Run `npm link create-claude-rails` to point to the local CoR checkout
+- Verify it worked: check that `npx create-claude-rails --help` resolves
+  to the local version
+- If CoR is already installed (`.corrc.json` exists): "Linked to local
+  CoR. Run `/cor-upgrade` to pull template changes into your installed
+  skills."
+- If CoR is not yet installed: "Linked to local CoR. Run
+  `npx create-claude-rails` to install."
+
+## Prerequisites
+
+The CoR source repo must have been linked first (`npm link` from the CoR
+directory). If a consuming project tries to link and the global link
+doesn't exist, npm will error. In that case, tell the user to run `/link`
+in their CoR checkout first.
+
+## What This Encodes
+
+- `npm link` (in source) registers a global symlink to the package
+- `npm link create-claude-rails` (in consumer) creates a local symlink
+  to the globally registered package
+- The link survives across terminal sessions
+- The link uses whatever is on disk — no version pinning, no caching
+- After linking, `npx create-claude-rails` and `/cor-upgrade` both
+  resolve to the local checkout

package/templates/skills/onboard/SKILL.md

@@ -2,16 +2,22 @@
 name: onboard
 description: |
   Conversational interview that generates the initial context layer for a
-  project adopting PIB. Re-runnable at different maturity stages — each run
+  project adopting Claude on Rails. Re-runnable at different maturity stages — each run
   refines based on what the project has learned. Use when: "onboard",
-  "set up PIB", "bootstrap", "/onboard".
+  "set up CoR", "bootstrap", "/onboard".
 related:
   - type: file
     path: .claude/skills/onboard/phases/detect-state.md
-    role: "Detect existing PIB artifacts and determine run mode"
+    role: "Detect existing CoR artifacts and determine run mode"
   - type: file
     path: .claude/skills/onboard/phases/interview.md
     role: "Conversational interview questions"
+  - type: file
+    path: .claude/skills/onboard/phases/work-tracking.md
+    role: "Choose work tracking system (SQLite vs markdown vs external)"
+  - type: file
+    path: .claude/skills/onboard/phases/options.md
+    role: "Structured decision points before generation"
   - type: file
     path: .claude/skills/onboard/phases/generate-context.md
     role: "Generate or update context files"
@@ -33,7 +39,7 @@ related:
 
 ## Purpose
 
-Generate the context layer that makes every other PIB skill work. Without
+Generate the context layer that makes every other CoR skill work. Without
 context — what is this project, what stack does it use, what breaks, who
 works on it — the session loop runs blind. Orient reads files that don't
 exist yet. Debrief records lessons into a structure that hasn't been
@@ -69,7 +75,7 @@ Onboard is re-runnable. What it does depends on what already exists:
 
 ### 1. First Run (no _context.md)
 
-No PIB context layer exists yet. This is the full interview: who are you,
+No CoR context layer exists yet. This is the full interview: who are you,
 what is this, what breaks, what do you need. Generates the complete
 initial context layer — `_context.md`, CLAUDE.md additions, system-status.md,
 and session loop wiring. The goal is a working session loop by the end of
@@ -77,7 +83,7 @@ the conversation.
 
 ### 2. Early Re-Run (sparse artifacts)
 
-Some PIB artifacts exist but the project is young. The session loop has
+Some CoR artifacts exist but the project is young. The session loop has
 run a few times and the user has learned what works and what doesn't.
 The interview shifts to refinement: What has the session loop taught you
 that CLAUDE.md doesn't reflect? What friction have you hit? What context
@@ -86,7 +92,7 @@ existing files rather than creating new ones.
 
 ### 3. Mature Re-Run (rich context)
 
-The project has been using PIB for a while. Context files are populated,
+The project has been using CoR for a while. Context files are populated,
 multiple modules are active, patterns have accumulated. The interview
 becomes a health check: Which modules are you actually using? Is anything
 ready to retire? What gaps have you noticed? Are there new areas the
@@ -98,7 +104,7 @@ doesn't have to declare it.
 
 ## Why This Matters
 
-Every PIB skill reads from the context layer. Orient reads `_context.md`
+Every CoR skill reads from the context layer. Orient reads `_context.md`
 to know what files to check. Plan reads it to know where work items live.
 Perspectives read it to know where to look. If the context layer is empty
 or wrong, every skill downstream is degraded. Onboard is the foundation
@@ -113,9 +119,9 @@ the periodic recalibration that keeps the context layer honest.
 
 ### 1. Detect State
 
-Read `phases/detect-state.md` for how to scan existing PIB artifacts.
+Read `phases/detect-state.md` for how to scan existing CoR artifacts.
 
-**Default (absent/empty):** Scan for the standard PIB artifact set:
+**Default (absent/empty):** Scan for the standard CoR artifact set:
 `_context.md`, `system-status.md`, `orient/phases/`, `debrief/phases/`,
 `pib.db`, `_groups.yaml`, `memory/patterns/`. Count what exists, classify
 its richness (empty file vs populated), and determine the run mode. Report
@@ -149,12 +155,37 @@ by now?
 
 This is a conversation, not a form. Ask 2-3 questions at a time, not all
 at once. Follow up on answers — if the user mentions a pain point, dig
-into it. If something sounds like it maps to a specific PIB module, note
+into it. If something sounds like it maps to a specific CoR module, note
 it for the modularity menu phase. The interview is the most valuable
 phase because it captures knowledge that no amount of file scanning can
 surface.
 
-### 3. Generate Context
+### 3. Work Tracking
+
+Read `phases/work-tracking.md` for how to present work tracking options.
+
+**Default (absent/empty):** Detect existing work tracking (pib.db,
+tasks.md, GitHub Issues, custom phase files). Present two built-in
+options — SQLite database (pib-db) or markdown file (tasks.md) — plus
+bring-your-own for external systems. User picks one, the other, or
+neither. The choice is recorded in `.corrc.json` under `workTracking`
+and feeds into generate-context and generate-session-loop.
+
+### 4. Options
+
+Read `phases/options.md` for how to present structured decision points.
+
+**Default (absent/empty):** If the interview revealed open decisions
+(tech stack undecided, architecture unclear, "what would you recommend?"),
+present 2-3 options per decision with trade-offs. Uses architecture and
+boundary-conditions perspectives internally to evaluate each option.
+Skips automatically when the user already has clear opinions or this is
+a re-run.
+
+The user's choices feed into generate-context. Deferred decisions are
+noted as open questions in `_context.md`.
+
+### 5. Generate Context
 
 Read `phases/generate-context.md` for how to create or update the context
 layer from interview answers.
@@ -173,7 +204,7 @@ would change as diffs — never overwrite without showing the delta. Let
 the user approve, modify, or reject each change. The user owns their
 context files; onboard proposes, never imposes.
 
-### 4. Generate Session Loop
+### 6. Generate Session Loop
 
 Read `phases/generate-session-loop.md` for how to wire orient and debrief
 phase files.
@@ -196,9 +227,9 @@ In re-run mode, examine existing phase files and propose refinements based
 on what the interview surfaced. If the user said "orient never shows me X,"
 that's a signal to update the work-scan or health-checks phase.
 
-### 5. Modularity Menu
+### 7. Modularity Menu
 
-Read `phases/modularity-menu.md` for which PIB modules to present.
+Read `phases/modularity-menu.md` for which CoR modules to present.
 
 **Default (absent/empty):** Present the module hierarchy with adoption
 recommendations based on the interview. The session loop is always set up.
@@ -209,7 +240,7 @@ they can always add more later.
 In re-run mode, show what's adopted alongside what's available. Surface
 retirement candidates — modules that were adopted but aren't being used.
 
-### 6. Summary
+### 8. Summary
 
 Read `phases/summary.md` for how to present results.
 
@@ -221,7 +252,7 @@ through use as orient and debrief reveal what's missing.
 In re-run mode, present a before/after view: what the context layer
 looked like before, what changed, and why.
 
-### 7. Post-Onboard Audit
+### 9. Post-Onboard Audit
 
 Read `phases/post-onboard-audit.md` for the configuration sanity check.
 
@@ -240,8 +271,10 @@ pre-flight check, not a deferred finding.
 
 | Phase | Absent = | What it customizes |
 |-------|----------|-------------------|
-| `detect-state.md` | Default: scan standard PIB artifacts | What artifacts to scan and how to determine mode |
+| `detect-state.md` | Default: scan standard CoR artifacts | What artifacts to scan and how to determine mode |
 | `interview.md` | Default: mode-adapted questions | What to ask and how to follow up |
+| `work-tracking.md` | Default: detect & present choices | What work tracking system to use (pib-db, markdown, or external) |
+| `options.md` | Default: present decisions with trade-offs | What decisions to surface and how to frame options |
 | `generate-context.md` | Default: create/update _context.md, CLAUDE.md, system-status.md | What files to generate and how |
 | `generate-session-loop.md` | Default: wire orient/debrief phases | How to set up the session loop |
 | `modularity-menu.md` | Default: present module hierarchy | Which modules to present and how |
@@ -254,7 +287,7 @@ Onboard is a companion, not a configurator. The framing is "let's figure
 out what your project needs" — not "I'll set up your system now." The
 interview is genuine curiosity about the project, not a checklist to get
 through. When the user describes a pain point, the right response is to
-understand it, not to immediately map it to a PIB module.
+understand it, not to immediately map it to a CoR module.
 
 This matters because the quality of the context layer depends on the
 quality of the conversation. A mechanical interview produces mechanical
@@ -284,13 +317,13 @@ Examples of phases mature adopters add:
 
 ## Calibration
 
-**Core failure this targets:** Starting PIB adoption with empty context
+**Core failure this targets:** Starting CoR adoption with empty context
 files, causing the session loop to run without knowing anything about the
 project it's supposed to help.
 
 ### Without Skill (Bad)
 
-A project adopts PIB. They copy the skeleton files, run `/orient` — it
+A project adopts CoR. They copy the skeleton files, run `/orient` — it
 reads a blank `_context.md` and an empty `system-status.md`, reports
 nothing useful. They run `/debrief` — it tries to close work items but
 doesn't know where work is tracked. They create a plan — perspectives
@@ -305,7 +338,7 @@ discovering context gaps one at a time.
 
 ### With Skill (Good)
 
-A project adopts PIB and runs `/onboard`. The interview asks what the
+A project adopts CoR and runs `/onboard`. The interview asks what the
 project is, what stack it uses, what hurts. The user mentions they have a
 Rails app with a PostgreSQL database, three developers, and a recurring
 problem with stale feature flags. From the conversation, onboard generates

package/templates/skills/onboard/phases/detect-state.md

@@ -1,76 +1,58 @@
-# Detect State — Scan PIB Artifacts and Determine Mode
+# Detect State — Scan Claude on Rails Artifacts and Determine Mode
 
-Scan the project for existing PIB artifacts to determine whether this is
+Scan the project for existing CoR artifacts to determine whether this is
 a first run, early re-run, or mature re-run. The mode determination
 drives how every subsequent phase behaves.
 
 When this file is absent or empty, the default behavior is: scan for the
-standard PIB artifact set, classify each artifact's richness, and
+standard CoR artifact set, classify each artifact's richness, and
 determine the mode. To explicitly skip state detection (force first-run
 mode), write only `skip: true`.
 
-## Pre-Check: CLI Metadata
+## Fast Path
 
-Before scanning artifacts, read `.pibrc.json` at the project root. This
-file is created by `npx create-claude-rails` and records which modules
-were installed, which were skipped (with reasons), and the package version.
+Check for `_context.md` (or `.claude/skills/perspectives/_context.md`).
+If it doesn't exist, the mode is **first-run** — skip the full scan and
+move to the interview immediately. No need to check 10 artifact types
+when the primary signal is absent.
 
-If `.pibrc.json` is absent, this skill was installed manually (not via
-the CLI). That's fine — proceed with the artifact scan. The interview
-and modularity menu will handle module decisions.
+Also read `.corrc.json` if it exists — it records which modules the CLI
+installed and which were skipped (with reasons). The interview phase uses
+this to skip redundant questions.
 
-If `.pibrc.json` exists, note the installed and skipped modules. The
-interview phase uses this to skip redundant questions and the modularity
-menu uses `skipped` reasons to ask about alternatives.
+## Full Scan (re-runs only)
 
-## What to Scan
-
-Check for these artifacts and classify each as absent, empty, or populated:
+Only when `_context.md` exists, scan these artifacts to distinguish
+early vs mature re-run:
 
 | Artifact | Path Pattern | Indicates |
 |----------|-------------|-----------|
-| Project context | `_context.md` or `.claude/skills/perspectives/_context.md` | Context layer exists |
 | System status | `system-status.md` | State tracking exists |
 | Orient phases | `.claude/skills/orient/phases/*.md` | Session loop is wired |
 | Debrief phases | `.claude/skills/debrief/phases/*.md` | Session loop is wired |
 | Work tracking DB | `pib.db` | Work tracking is active |
 | Perspective groups | `_groups.yaml` or `.claude/skills/perspectives/_groups.yaml` | Audit system configured |
-| Memory patterns | `memory/patterns/*.md` | Feedback loop is active |
+| Memory patterns | `memory/patterns/*.md` or `.claude/memory/patterns/*.md` | Feedback loop is active |
 | CLAUDE.md | Root `CLAUDE.md` | Project instructions exist |
 | Rules files | `.claude/rules/*.md` | Scoped instructions exist |
 | Hook config | `.claude/settings.json` or `.claude/settings.local.json` | Enforcement hooks exist |
 
-## Mode Determination
-
-**First run:** `_context.md` does not exist. No PIB context layer has been
-generated yet. Even if other artifacts exist (e.g., a CLAUDE.md written
-by hand), the absence of the generated context file means onboard hasn't
-run before.
-
-**Early re-run:** `_context.md` exists but the artifact set is sparse.
-Fewer than 5 of the scanned artifacts are populated. The session loop
-may be wired but modules like work tracking, audit, and enforcement are
-not yet active. The project is young — it has been through a few sessions
-but hasn't accumulated rich process infrastructure.
-
-**Mature re-run:** `_context.md` exists and 5 or more scanned artifacts
-are populated. The project has a working session loop, some form of work
-tracking, and at least one additional module (audit, enforcement, or
-memory). The context layer has had time to accumulate gaps and drift.
+**Early re-run:** Fewer than 5 of the above are populated.
+**Mature re-run:** 5 or more are populated.
 
 ## Output
 
-Report findings as a structured summary that subsequent phases can
+For first-run: `Mode: first-run` — that's it. Move on.
+
+For re-runs, report a structured summary that subsequent phases can
 reference:
 
 ```
-Mode: first-run | early-rerun | mature-rerun
+Mode: early-rerun | mature-rerun
 
 Artifacts found:
-  - _context.md: populated (last modified 2026-03-15)
   - system-status.md: populated
   - orient phases: 3 files (context.md, work-scan.md, health-checks.md)
-  - debrief phases: 2 files (inventory.md, update-state.md)
   - pib.db: absent
   - memory patterns: 4 files
   ...

package/templates/skills/onboard/phases/generate-context.md

@@ -1,6 +1,6 @@
 # Generate Context — Create or Update Context Files
 
-Transform interview answers into the files that make the rest of PIB
+Transform interview answers into the files that make the rest of Claude on Rails
 functional. This is where conversation becomes infrastructure — but it
 is always a proposal, never an imposition.
 

package/templates/skills/onboard/phases/interview.md

@@ -5,7 +5,7 @@ listen to answers, follow up on what's interesting or unclear. The quality
 of the context layer depends directly on the quality of this conversation.
 
 When this file is absent or empty, the default behavior is: ask mode-
-adapted questions as described below, 2-3 at a time, with follow-ups.
+adapted questions as described below, one at a time, with follow-ups.
 To explicitly skip the interview (e.g., when generating context from
 existing documentation), write only `skip: true`.
 
@@ -60,7 +60,7 @@ are valid starting points.
 
 ## First-Run Questions
 
-The detect-state phase identified this as a first run (no PIB context
+The detect-state phase identified this as a first run (no CoR context
 layer exists). But "first run" covers two very different situations:
 
 ### Greenfield (no project yet, or near-empty directory)
@@ -69,21 +69,17 @@ The user just ran the CLI in an empty or near-empty directory. There's
 nothing to scan, no workflow to reflect on yet. Questions must be
 **forward-looking** — about intentions, not retrospection.
 
-**Round 1 — What and why:**
-- What are you trying to build?
-- What will you be using Claude Code for on this project?
-
-**Round 2 — How you work (adapt based on Round 1):**
-- How do you usually keep track of what needs to be done? (A list
-  somewhere, a tool, your head?)
-- Will anyone else be working on this with you?
-- Have you struggled with anything on past projects that you'd want
-  to get ahead of this time?
-
-**Round 3 — Scope and shape (adapt based on Rounds 1-2):**
-- How big is this? A weekend project, something you'll be working on
-  for months?
-- What does done look like, roughly?
+**Questions (ask one at a time, in order — skip or reorder based on
+what the conversation reveals):**
+1. What are you trying to build?
+2. What will you be using Claude Code for on this project?
+3. How do you usually keep track of what needs to be done?
+4. Will anyone else be working on this with you?
+5. Have you struggled with anything on past projects that you'd want
+   to get ahead of this time?
+6. How big is this? A weekend project, something you'll be working on
+   for months?
+7. What does done look like, roughly?
 
 **Follow-up instincts:**
 - If they describe something ambitious, ask what the first milestone is
@@ -98,26 +94,23 @@ The user ran the CLI in a project that already has substance. There are
 files to scan — use them for tech detection instead of asking. Focus the
 conversation on **work and pain**, not tooling.
 
-**Before Round 1:** Scan the project for tech signals (package.json,
+**Before asking:** Scan the project for tech signals (package.json,
 Cargo.toml, requirements.txt, Dockerfile, .github/, etc.). Note what
 you find — it informs your follow-ups but doesn't replace the
 conversation. Don't announce what you found; weave it in naturally.
 
-**Round 1 — Identity:**
-- Tell me about this project. What does it do, who is it for?
-- What are you mainly working on right now?
-
-**Round 2 — Pain (adapt based on Round 1):**
-- What tends to break or get forgotten?
-- What do you wish Claude knew about this project from the very start
-  of every session?
-- Is there anything that fails silently — things that go wrong without
-  anyone noticing until it's too late?
-
-**Round 3 — Operations (adapt based on Rounds 1-2):**
-- How do you currently keep track of what needs to be done?
-- What does a typical working session on this project look like?
-- Is there a deploy pipeline or remote environment?
+**Questions (ask one at a time, in order — skip or reorder based on
+what the conversation reveals):**
+1. Tell me about this project. What does it do?
+2. What are you mainly working on right now?
+3. What tends to break or get forgotten?
+4. What do you wish Claude knew about this project from the very start
+   of every session?
+5. Is there anything that fails silently — things that go wrong without
+   anyone noticing until it's too late?
+6. How do you currently keep track of what needs to be done?
+7. What does a typical working session on this project look like?
+8. Is there a deploy pipeline or remote environment?
 
 **Follow-up instincts:**
 - If someone mentions a pain point, ask *why* it happens and how often
@@ -131,63 +124,84 @@ conversation. Don't announce what you found; weave it in naturally.
 The session loop has been running. Shift from "what is this" to "what
 have you learned."
 
-**Round 1 — Session Loop Feedback:**
-- What has the session loop taught you that the context files don't
-  currently capture?
-- Does orient give you what you need at session start? What's missing?
-- Does debrief close the right loops? What falls through?
-
-**Round 2 — Friction (adapt based on Round 1):**
-- Where have you hit friction with the current setup?
-- Are there things you keep having to tell Claude that should already be
-  in the context?
-- Any phase files that aren't pulling their weight?
-
-**Round 3 — Growth (adapt based on Rounds 1-2):**
-- Has the project changed since the initial onboard? New components,
-  shifted priorities, different pain points?
-- Are you ready for any of the modules you skipped last time?
-- Anything you've been doing manually that should be automated?
+**Questions (ask one at a time, in order — skip or reorder based on
+what the conversation reveals):**
+1. What has the session loop taught you that the context files don't
+   currently capture?
+2. Does orient give you what you need at session start? What's missing?
+3. Does debrief close the right loops? What falls through?
+4. Where have you hit friction with the current setup?
+5. Are there things you keep having to tell Claude that should already be
+   in the context?
+6. Any phase files that aren't pulling their weight?
+7. Has the project changed since the initial onboard?
+8. Are you ready for any of the modules you skipped last time?
+9. Anything you've been doing manually that should be automated?
 
 ## Mature Re-Run Questions
 
 The system has been running long enough to accumulate both value and
 cruft. This is a health check.
 
-**Round 1 — Usage Reality:**
-- Which modules are you actually using regularly?
-- Anything that felt useful at first but you've stopped relying on?
-- Are there modules you adopted but never really configured properly?
-
-**Round 2 — Gaps and Drift:**
-- What gaps have you noticed in coverage? Things the system should catch
-  but doesn't.
-- Has the project's architecture or priorities shifted since the last
-  onboard run? Does the context layer reflect the current reality?
-- Any new pain points that weren't there before?
-
-**Round 3 — Simplification:**
-- Is anything ready to retire? Phase files, perspectives, health checks
-  that check for problems you no longer have?
-- Could any of your custom phase files be simplified now that you know
-  what you actually need?
-- Are there patterns in your memory/feedback that suggest a structural
-  change rather than another rule?
+**Questions (ask one at a time, in order — skip or reorder based on
+what the conversation reveals):**
+1. Which modules are you actually using regularly?
+2. Anything that felt useful at first but you've stopped relying on?
+3. Are there modules you adopted but never really configured properly?
+4. What gaps have you noticed? Things the system should catch but doesn't.
+5. Has the project's architecture or priorities shifted since the last
+   onboard run?
+6. Any new pain points that weren't there before?
+7. Is anything ready to retire?
+8. Could any of your custom phase files be simplified now that you know
+   what you actually need?
+9. Are there patterns in your memory/feedback that suggest a structural
+   change rather than another rule?
+
+## Scope Boundary
+
+You are configuring the **process layer** — what Claude should know about
+this project, how sessions start and end, what to track and check. You
+are NOT:
+
+- Recommending tech stacks, frameworks, or architecture
+- Advising on what to build or how to build it
+- Making product decisions
+
+If the user asks "what should I use?" or "what do you recommend?" for
+their actual project, redirect: "That's a great question for your first
+working session after we finish setup. Right now I'm just learning about
+your project so the session loop knows what to look for. What do you
+know so far about what you'll be building?"
+
+Record what they tell you about their intentions and tools — that goes
+into `_context.md`. But choosing those tools is their decision, not
+onboard's job.
 
 ## Conversation Guidelines
 
-- **2-3 questions per round.** Let the user respond before asking more.
+- **One question at a time.** Ask a single question, wait for the answer,
+  then ask the next one. Never stack multiple questions in one message.
+  The rounds below are a *sequence*, not a batch — each bullet is its own
+  turn. Follow-ups based on the answer take priority over the next
+  planned question.
 - **Follow up on substance.** If an answer reveals something important,
   dig into it before moving on to the next topic.
-- **Note PIB module signals.** When someone describes a pain point that
+- **Note CoR module signals.** When someone describes a pain point that
   maps to a specific module, note it internally for the modularity menu
   phase — but don't interrupt the conversation to pitch the module.
 - **Don't assume answers.** Even if you can see the project's files, ask
   about things like pain points and priorities that only the user knows.
+- **Earn the right to ask about specifics.** Don't ask about tech stack,
+  deployment pipelines, or architecture until the conversation has shown
+  the user has context to give a meaningful answer. Lead with open
+  questions ("tell me about this project") and let specifics emerge
+  naturally. If the user is non-technical or early in their thinking,
+  those questions may never be appropriate — and that's fine.
 - **Summarize before generating.** After the interview, reflect back what
   you heard: "Here's what I'm taking away from this conversation..." Let
   the user correct before generating files.
-- **For skipped modules (.pibrc.json):** If the CLI's `skipped` field
+- **For skipped modules (.corrc.json):** If the CLI's `skipped` field
   shows a module was opted out with a reason, weave that into the
   conversation naturally. "I see you're tracking work somewhere else —
   tell me about that" rather than "Module work-tracking was skipped."