create-claude-rails 0.2.0 → 0.3.0

package/README.md

@@ -49,7 +49,7 @@ hooks.
 - **`/onboard`** — conversational project interview, re-runnable as the
   project matures.
 - **`/seed`** — detects new tech in your project, proposes expertise.
-- **`/upgrade`** — conversational merge when Claude on Rails updates.
+- **`/cor-upgrade`** — conversational merge when Claude on Rails updates.
 
 ## How It Works
 
@@ -97,7 +97,7 @@ scripts/
 ├── pib-db.js        # work tracking CLI (if installed)
 └── ...              # triage tools (if audit installed)
 
-.pibrc.json          # installation metadata
+.corrc.json          # installation metadata
 ```
 
 ## Upgrading
@@ -106,7 +106,7 @@ scripts/
 npx create-claude-rails            # re-run to add modules
 ```
 
-In Claude Code, run `/upgrade` for conversational merge of upstream
+In Claude Code, run `/cor-upgrade` for conversational merge of upstream
 changes with your customizations.
 
 ## Philosophy

package/lib/cli.js

@@ -22,6 +22,7 @@ const MODULES = {
     description: 'Block destructive git ops (force push, hard reset). Track skill usage via JSONL telemetry.',
     mandatory: false,
     default: true,
+    lean: true,
     templates: ['hooks/git-guardrails.sh', 'hooks/skill-telemetry.sh', 'hooks/skill-tool-telemetry.sh'],
   },
   'work-tracking': {
@@ -29,6 +30,7 @@ const MODULES = {
     description: 'Track work items for orient/debrief. Default: SQLite (pib-db). Also supports markdown (tasks.md) or external systems. Choice made during /onboard.',
     mandatory: false,
     default: true,
+    lean: false,
     templates: ['scripts/pib-db.js', 'scripts/pib-db-schema.sql'],
     needsDb: true,
   },
@@ -37,6 +39,7 @@ const MODULES = {
     description: 'Structured implementation planning with perspective critique and execution checkpoints.',
     mandatory: false,
     default: true,
+    lean: true,
     templates: ['skills/plan', 'skills/execute', 'skills/investigate'],
   },
   'compliance': {
@@ -44,6 +47,7 @@ const MODULES = {
     description: 'Scoped instructions that load by path. Enforcement pipeline for promoting patterns to rules.',
     mandatory: false,
     default: true,
+    lean: false,
     templates: ['rules/enforcement-pipeline.md', 'memory/patterns/_pattern-template.md', 'memory/patterns/pattern-intelligence-first.md'],
   },
   'audit': {
@@ -51,6 +55,7 @@ const MODULES = {
     description: 'Periodic expert-perspective analysis with structured triage. Most compute-intensive module.',
     mandatory: false,
     default: true,
+    lean: true,
     templates: [
       'skills/audit', 'skills/pulse', 'skills/triage-audit',
       'skills/perspectives',
@@ -60,17 +65,19 @@ const MODULES = {
     ],
   },
   'lifecycle': {
-    name: 'Lifecycle (onboard + seed + upgrade)',
-    description: 'Conversational onboarding, capability seeding from tech signals, upgrade merges.',
+    name: 'Lifecycle (onboard + seed + cor-upgrade + link)',
+    description: 'Conversational onboarding, capability seeding, upgrade merges, local dev linking.',
     mandatory: false,
     default: true,
-    templates: ['skills/onboard', 'skills/seed', 'skills/upgrade'],
+    lean: true,
+    templates: ['skills/onboard', 'skills/seed', 'skills/cor-upgrade', 'skills/link', 'skills/unlink', 'skills/publish', 'skills/extract'],
   },
   'validate': {
     name: 'Validate',
     description: 'Structural validation checks with unified summary. Define your own validators.',
     mandatory: false,
     default: true,
+    lean: false,
     templates: ['skills/validate'],
   },
 };
@@ -87,7 +94,7 @@ function detectProjectState(dir) {
   const entries = fs.readdirSync(dir);
   const signals = entries.filter(e => PROJECT_SIGNALS.includes(e));
   const hasClaude = entries.includes('.claude');
-  const hasPibrc = fs.existsSync(path.join(dir, '.pibrc.json'));
+  const hasPibrc = fs.existsSync(path.join(dir, '.corrc.json'));
 
   if (hasPibrc) return 'existing-install';
   if (signals.length > 0) return 'existing-project';
@@ -100,6 +107,7 @@ function parseArgs(argv) {
   const args = argv.slice(2);
   const flags = {
     yes: false,
+    lean: false,
     noDb: false,
     dryRun: false,
     help: false,
@@ -110,6 +118,7 @@ function parseArgs(argv) {
 
   for (const arg of args) {
     if (arg === '--yes' || arg === '-y') flags.yes = true;
+    else if (arg === '--lean') flags.lean = true;
     else if (arg === '--no-db') flags.noDb = true;
     else if (arg === '--dry-run') flags.dryRun = true;
     else if (arg === '--help' || arg === '-h') flags.help = true;
@@ -127,6 +136,7 @@ function printHelp() {
 
   Options:
     --yes, -y     Accept all defaults, no prompts
+    --lean        Install core modules only (no work-tracking, compliance, validate)
     --no-db       Skip work tracking database setup
     --dry-run     Show what would be copied without writing
     --reset       Remove CoR files (uses manifest for safety)
@@ -137,6 +147,7 @@ function printHelp() {
     npx create-claude-rails                 Interactive setup in current dir
     npx create-claude-rails my-project      Set up in ./my-project/
     npx create-claude-rails --yes           Install everything, no questions
+    npx create-claude-rails --lean          Session loop + planning + perspectives
     npx create-claude-rails --yes --no-db   Install everything except DB
     npx create-claude-rails --dry-run       Preview what would be installed
     npx create-claude-rails --reset         Remove CoR files safely
@@ -175,7 +186,7 @@ async function run() {
   if (dirState === 'existing-install') {
     const existing = readMetadata(projectDir);
     console.log(`  Found existing installation (v${existing.version}, installed ${existing.installedAt.split('T')[0]})`);
-    if (!flags.yes) {
+    if (!flags.yes && !flags.lean) {
       const { proceed } = await prompts({
         type: 'confirm',
         name: 'proceed',
@@ -189,7 +200,7 @@ async function run() {
     }
   } else if (dirState === 'existing-project') {
     console.log(`  Detected existing project in ${projectDir}`);
-    if (!flags.yes) {
+    if (!flags.yes && !flags.lean) {
       const { action } = await prompts({
         type: 'select',
         name: 'action',
@@ -233,7 +244,18 @@ async function run() {
   let skippedModules = {};
   let includeDb = !flags.noDb;
 
-  if (flags.yes) {
+  if (flags.lean) {
+    selectedModules = Object.entries(MODULES)
+      .filter(([, mod]) => mod.mandatory || mod.lean)
+      .map(([key]) => key);
+    includeDb = false;
+    const skippedKeys = Object.keys(MODULES).filter(k => !selectedModules.includes(k));
+    for (const k of skippedKeys) {
+      skippedModules[k] = 'Skipped by --lean install';
+    }
+    console.log(`  Lean install: ${selectedModules.length} modules (session-loop, hooks, planning, audit, lifecycle).`);
+    console.log(`  Skipped: ${skippedKeys.join(', ')}.\n`);
+  } else if (flags.yes) {
     selectedModules = Object.keys(MODULES);
     if (flags.noDb) {
       includeDb = false;
@@ -245,16 +267,36 @@ async function run() {
     }
     console.log(`  Installing all ${selectedModules.length} modules.${flags.noDb ? ' (skipping work-tracking DB)' : ''}\n`);
   } else {
-    const { installAll } = await prompts({
-      type: 'confirm',
-      name: 'installAll',
-      message: 'Install everything? (Y skips individual module questions)',
-      initial: true,
+    const { installMode } = await prompts({
+      type: 'select',
+      name: 'installMode',
+      message: 'How much do you want to install?',
+      choices: [
+        { title: 'Everything — all modules, full setup', value: 'full' },
+        { title: 'Lean — session loop + planning + perspectives (no DB, compliance, validate)', value: 'lean' },
+        { title: 'Custom — choose modules individually', value: 'custom' },
+      ],
     });
 
-    if (installAll) {
+    if (!installMode) {
+      console.log('  Cancelled.');
+      return;
+    }
+
+    if (installMode === 'full') {
       selectedModules = Object.keys(MODULES);
       console.log(`\n  Installing all ${selectedModules.length} modules.\n`);
+    } else if (installMode === 'lean') {
+      selectedModules = Object.entries(MODULES)
+        .filter(([, mod]) => mod.mandatory || mod.lean)
+        .map(([key]) => key);
+      includeDb = false;
+      const skippedKeys = Object.keys(MODULES).filter(k => !selectedModules.includes(k));
+      for (const k of skippedKeys) {
+        skippedModules[k] = 'Skipped by lean install';
+      }
+      console.log(`\n  Lean install: ${selectedModules.length} modules.`);
+      console.log(`  Skipped: ${skippedKeys.join(', ')}.\n`);
     } else {
       for (const [key, mod] of Object.entries(MODULES)) {
         if (mod.mandatory) {
@@ -448,7 +490,7 @@ async function run() {
       version: VERSION,
       manifest: allManifest,
     });
-    console.log('  📝 Created .pibrc.json');
+    console.log('  📝 Created .corrc.json');
   }
 
   // --- Summary ---

package/lib/metadata.js

@@ -1,7 +1,7 @@
 const fs = require('fs');
 const path = require('path');
 
-const METADATA_FILE = '.pibrc.json';
+const METADATA_FILE = '.corrc.json';
 
 function metadataPath(projectDir) {
   return path.join(projectDir, METADATA_FILE);

package/lib/reset.js

@@ -49,7 +49,7 @@ async function reset(projectDir, { dryRun = false, force = false } = {}) {
 
   const metadata = readMetadata(projectDir);
   if (!metadata) {
-    console.log('  No .pibrc.json found — nothing to reset.');
+    console.log('  No .corrc.json found — nothing to reset.');
     return;
   }
 
@@ -133,7 +133,7 @@ async function reset(projectDir, { dryRun = false, force = false } = {}) {
     }
   }
 
-  // Remove .pibrc.json last
+  // Remove .corrc.json last
   const pibrcPath = path.join(projectDir, METADATA_FILE);
   if (!dryRun && fs.existsSync(pibrcPath)) {
     fs.unlinkSync(pibrcPath);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-claude-rails",
-  "version": "0.2.0",
+  "version": "0.3.0",
   "description": "Claude on Rails — opinionated process scaffolding for Claude Code projects",
   "bin": {
     "create-claude-rails": "bin/create-claude-rails.js"

package/templates/README.md

@@ -59,7 +59,7 @@ adoption is straightforward: copy what you need into your project's
 | `skills/triage-audit/SKILL.md` | 5 | **Triage skeleton.** Load findings, prepare commentary, present via local web UI or CLI, apply verdicts (fix/defer/reject), create actions for approved findings. 3 phase files. |
 | `skills/onboard/SKILL.md` | 7 | **Onboarding skeleton.** Conversational interview that generates the initial context layer. Re-runnable: first run generates, subsequent runs refine. 6 phase files. |
 | `skills/seed/SKILL.md` | 7 | **Capability seeding skeleton.** Detects technology adoption signals, proposes expertise conversations, builds and maintains perspectives collaboratively. 4 phase files. |
-| `skills/upgrade/SKILL.md` | 7 | **Upgrade skeleton.** Conversational merge when new CoR skeletons arrive. Intelligence is the merge strategy — conversation, not mechanical copy. 4 phase files. |
+| `skills/cor-upgrade/SKILL.md` | 7 | **Upgrade skeleton.** Conversational merge when new CoR skeletons arrive. Intelligence is the merge strategy — conversation, not mechanical copy. 4 phase files. |
 
 ### Scripts (6)
 
@@ -395,7 +395,7 @@ There is no `box.yaml` or template engine. Configuration uses two mechanisms:
   (GTD expertise, Mantine quality, sync health, etc.). EXTENSIONS.md
   includes examples showing how to write your own domain perspectives.
 - **Distribution mechanism** — No npm package, no installer. Copy files.
-  The `/onboard` skill guides adoption. The `/upgrade` skill handles updates.
+  The `/onboard` skill guides adoption. The `/cor-upgrade` skill handles updates.
 
 ## Relationship to Flow
 

package/templates/skills/{upgrade → cor-upgrade}/SKILL.md

@@ -1,27 +1,27 @@
 ---
-name: upgrade
+name: cor-upgrade
 description: |
   Conversational upgrade when new Claude on Rails skeletons arrive. Detects current
   adoption state, diffs against upstream, and for each change walks through
   an intelligent merge — conversation not mechanical copy. Intelligence is
-  the merge strategy. Use when: "upgrade", "update CoR", "new skeletons",
-  "/upgrade".
+  the merge strategy. Use when: "cor-upgrade", "update CoR", "new skeletons",
+  "/cor-upgrade".
 related:
   - type: file
-    path: .claude/skills/upgrade/phases/detect-current.md
+    path: .claude/skills/cor-upgrade/phases/detect-current.md
     role: "Inventory current adoption state"
   - type: file
-    path: .claude/skills/upgrade/phases/diff-upstream.md
+    path: .claude/skills/cor-upgrade/phases/diff-upstream.md
     role: "Semantic diff against upstream CoR"
   - type: file
-    path: .claude/skills/upgrade/phases/merge.md
+    path: .claude/skills/cor-upgrade/phases/merge.md
     role: "Intelligent merge strategy — the core of the skill"
   - type: file
-    path: .claude/skills/upgrade/phases/apply.md
+    path: .claude/skills/cor-upgrade/phases/apply.md
     role: "Apply approved changes"
 ---
 
-# /upgrade — Conversational Claude on Rails Upgrade
+# /cor-upgrade — Conversational Claude on Rails Upgrade
 
 ## Purpose
 
@@ -211,13 +211,13 @@ the workflow. Execute them at their declared position.
 The upgrade skill doesn't have to wait for the user to invoke it.
 Orient can detect when upstream CoR files are newer than the project's
 adopted copies and surface "CoR updates available" in the briefing.
-This is a hint, not a blocker — the user decides when to run /upgrade.
+This is a hint, not a blocker — the user decides when to run /cor-upgrade.
 
 To enable this, a project's orient `phases/health-checks.md` or a
 custom orient phase can compare modification times between upstream
 skeleton SKILL.md files and their adopted counterparts. When drift is
 detected, orient mentions it. When the user is ready, they invoke
-/upgrade and the full conversational merge begins.
+/cor-upgrade and the full conversational merge begins.
 
 ## Extending
 
@@ -253,7 +253,7 @@ spent two sessions tuning is gone, replaced by the upstream default.
 
 ### With Skill (Good)
 
-New CoR skeletons arrive. The user runs `/upgrade`. Claude inventories
+New CoR skeletons arrive. The user runs `/cor-upgrade`. Claude inventories
 what's adopted, diffs against upstream, and walks through each change:
 "The orient skeleton added a calendar-check phase. Your project doesn't
 have calendar integration, so this would be a no-op — skip it for now?"

package/templates/skills/{upgrade → cor-upgrade}/phases/detect-current.md

@@ -5,15 +5,15 @@ manifest is consumed by the diff-upstream phase to determine what has
 changed.
 
 When this file is absent or empty, the default behavior is: read
-`.pibrc.json` for version and module metadata, then scan the project's
+`.corrc.json` for version and module metadata, then scan the project's
 `.claude/skills/`, perspectives, hooks, and database for CoR artifacts.
 To explicitly skip detection, write only `skip: true`.
 
 ## What to Inventory
 
-### Package Metadata (.pibrc.json)
+### Package Metadata (.corrc.json)
 
-Read `.pibrc.json` from the project root. This file is written by the
+Read `.corrc.json` from the project root. This file is written by the
 CLI installer (`npx create-claude-rails`) and contains:
 
 - **`version`** — the installed package version (for diff-upstream comparison)
@@ -22,7 +22,7 @@ CLI installer (`npx create-claude-rails`) and contains:
 - **`skipped`** — modules the user opted out of, with reasons
 - **`upstreamPackage`** — the npm package name (`create-claude-rails`)
 
-If `.pibrc.json` is missing, this is either a pre-npm adoption or a
+If `.corrc.json` is missing, this is either a pre-npm adoption or a
 manual install. Note this in the manifest — the diff-upstream phase
 needs to know whether version comparison is possible or if it must fall
 back to pure filesystem diffing.
@@ -68,9 +68,9 @@ For each directory in `.claude/skills/`:
 ## Output Format
 
 Produce a structured manifest (in conversation, not a file) listing:
-- **Package version** from `.pibrc.json` (or "unknown — no .pibrc.json")
-- **Installed modules** from `.pibrc.json` modules map
-- **Skipped modules** with reasons from `.pibrc.json` skipped map
+- **Package version** from `.corrc.json` (or "unknown — no .corrc.json")
+- **Installed modules** from `.corrc.json` modules map
+- **Skipped modules** with reasons from `.corrc.json` skipped map
 - Each adopted skill with its phase file statuses
 - Each adopted perspective group with member count
 - Hook count and types

package/templates/skills/extract/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: extract
+description: |
+  Analyze non-CoR skills, perspectives, and other artifacts in a consuming
+  project and propose candidates for upstreaming into Claude on Rails as
+  generic templates. Does not perform the extraction — files a proposal
+  that surfaces during orient in the CoR repo. Use when: "extract",
+  "upstream this", "should this be in CoR?", "/extract".
+---
+
+# /extract — Propose Artifacts for Upstreaming to CoR
+
+## Purpose
+
+Consuming projects grow custom skills, perspectives, phase files, and
+other artifacts that solve real problems. Some of those solutions are
+project-specific. Others solve problems that any project would have.
+This skill identifies the latter and proposes upstreaming them into
+Claude on Rails as generic templates.
+
+**This skill proposes. It does not extract.** The actual separation of
+generic orchestration from project-specific context happens in the CoR
+repo after a human reviews and accepts the proposal. The consuming
+project then adopts the CoR version via `/cor-upgrade`.
+
+## Where This Runs
+
+**Consuming projects only.** If run from the CoR source repo
+(`package.json` name is `create-claude-rails`), say: "This skill runs
+from consuming projects. Here, use orient to review incoming proposals."
+
+## Workflow
+
+### 1. Inventory Non-CoR Artifacts
+
+Compare the project's `.claude/` directory against `.corrc.json`'s
+manifest. Anything not in the manifest is project-specific:
+
+- **Custom skills** — `.claude/skills/*/SKILL.md` not in manifest
+- **Custom perspectives** — `.claude/skills/perspectives/*/SKILL.md`
+  not in the standard set
+- **Custom phase files** — phase files in CoR skills that override
+  defaults with substantial logic (not just `skip: true`)
+- **Custom hooks** — hook scripts not installed by CoR
+- **Custom rules** — `.claude/rules/` files beyond the CoR defaults
+- **Patterns** — `.claude/memory/patterns/` entries that encode
+  reusable lessons
+
+### 2. Assess Each Candidate
+
+For each non-CoR artifact, evaluate:
+
+**Generalizability** — Would other projects benefit from this?
+- Does it solve a problem tied to this specific project, or a class
+  of problems?
+- Could the project-specific parts be isolated into phase files?
+- Is the core logic reusable if you strip out hardcoded paths, names,
+  and domain concepts?
+
+**Maturity** — Is this ready to propose?
+- Has it been used enough to know it works? (Check telemetry if
+  available, or ask the user.)
+- Has it been refined, or is it a first draft?
+- Are there known issues or things the user wants to change?
+
+**Category** — What kind of CoR artifact would this become?
+- A new skill template (SKILL.md + default phase behaviors)
+- A new perspective (SKILL.md with scan scope and finding format)
+- A new phase file for an existing skill (e.g., a custom orient check)
+- A new hook or rule template
+- A new pattern worth promoting to the standard set
+
+Rate each candidate: **strong** (clearly generic, proven, ready),
+**possible** (could be generic with work), or **project-specific**
+(not a candidate). Only propose strong and possible candidates.
+
+### 3. Draft Proposals
+
+For each candidate, draft a proposal that includes:
+
+```markdown
+# Extraction Proposal: [artifact name]
+
+## Source
+- Project: [project name/path]
+- Artifact: [path to the artifact]
+- Type: skill | perspective | phase | hook | rule | pattern
+
+## What It Does
+[1-2 paragraphs describing the artifact's purpose and how it works
+in the source project]
+
+## Why It's Generic
+[Why this solves a class of problems, not just this project's problem.
+What other projects would use it for.]
+
+## Suggested Generalized Form
+[How this would look as a CoR template. What becomes the skeleton,
+what becomes phase-file-configurable, what gets dropped as
+project-specific. Include a rough SKILL.md outline if it's a skill
+or perspective.]
+
+## What Stays Project-Specific
+[What parts of the current implementation would remain as phase files
+or project configuration after extraction]
+
+## Assessment
+- Generalizability: strong | possible
+- Maturity: proven | early
+- Complexity: low | medium | high (effort to extract)
+
+## Source Artifact Content
+[Full content of the artifact being proposed, so the CoR repo has
+everything needed to evaluate without access to the source project]
+```
+
+### 4. File Proposals
+
+**If linked** (the CoR package resolves to a local directory — check
+if `node -e "console.log(require.resolve('create-claude-rails'))"`
+points to a local path rather than a `node_modules` path):
+
+- Write each proposal as a markdown file in the CoR repo's
+  `proposals/` directory (create it if needed)
+- Filename: `[source-project]-[artifact-name].md`
+  (e.g., `flow-review-pr.md`)
+- These will surface during orient in the CoR repo
+
+**If not linked** (CoR is installed from npm):
+
+- Open a GitHub issue on the CoR repo for each proposal
+- Title: `Extract proposal: [artifact name] from [project]`
+- Label: `extraction-proposal` (create if needed)
+- Body: the full proposal markdown
+- Requires `gh` CLI to be authenticated
+
+**If neither works** (no link, no gh access):
+
+- Output the proposals to the terminal and tell the user to
+  file them manually or copy them to the CoR repo
+
+### 5. Summary
+
+After filing, summarize:
+- How many artifacts were scanned
+- How many proposals were filed (strong + possible)
+- How many were project-specific (not proposed)
+- Where the proposals went (local files or GitHub issues)
+- Remind: "Review these in the CoR repo. Accepted proposals get
+  built as generic templates, then your project adopts them via
+  /cor-upgrade."
+
+## Running on a Subset
+
+The user can target specific artifacts:
+
+- `/extract` — scan everything
+- `/extract skills/my-skill` — evaluate a specific skill
+- `/extract perspectives` — evaluate all custom perspectives
+
+## What This Does NOT Do
+
+- **Does not modify the consuming project.** No files are changed here.
+- **Does not modify CoR templates.** Proposals are filed, not applied.
+- **Does not decide.** A human reviews each proposal in the CoR repo.
+- **Does not extract phase files from skills.** The separation of
+  skeleton from phases happens during implementation in CoR, not here.
+  The proposal includes a *suggested* separation, not a final one.

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

@@ -168,7 +168,7 @@ Read `phases/work-tracking.md` for how to present work tracking options.
 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 `.pibrc.json` under `workTracking`
+neither. The choice is recorded in `.corrc.json` under `workTracking`
 and feeds into generate-context and generate-session-loop.
 
 ### 4. Options

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

@@ -16,7 +16,7 @@ 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.
 
-Also read `.pibrc.json` if it exists — it records which modules the CLI
+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.
 

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`.
 
@@ -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,48 +124,39 @@ 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
 
@@ -196,7 +180,11 @@ 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 CoR module signals.** When someone describes a pain point that
@@ -204,10 +192,16 @@ onboard's job.
   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."

package/templates/skills/onboard/phases/modularity-menu.md

@@ -6,13 +6,13 @@ opt-in. Progressive adoption means starting with what you need and adding
 modules as the project matures.
 
 When this file is absent or empty, the default behavior is: read
-`.pibrc.json` for module selections made during CLI install, then present
+`.corrc.json` for module selections made during CLI install, then present
 the module hierarchy with that context. To explicitly skip the menu,
 write only `skip: true`.
 
-## Reading CLI Selections (.pibrc.json)
+## Reading CLI Selections (.corrc.json)
 
-If `.pibrc.json` exists in the project root, the CLI has already asked
+If `.corrc.json` exists in the project root, the CLI has already asked
 about module selections. Read the `modules` and `skipped` fields:
 
 - **Installed modules** (`modules` map, value `true`): These are already
@@ -29,7 +29,7 @@ For skipped modules with alternatives, the interview (previous phase)
 should have already asked about the alternative system. Use those answers
 here to confirm the wiring plan.
 
-If `.pibrc.json` doesn't exist (manual install or pre-npm adoption),
+If `.corrc.json` doesn't exist (manual install or pre-npm adoption),
 fall back to presenting the full menu as described below.
 
 ## Module Hierarchy

package/templates/skills/onboard/phases/post-onboard-audit.md

@@ -39,7 +39,7 @@ Compare what the interview revealed against what was generated:
 
 ### 2. Module–Phase Alignment
 
-Cross-reference `.pibrc.json` (installed vs skipped modules) against the
+Cross-reference `.corrc.json` (installed vs skipped modules) against the
 generated phase files:
 
 - **Skipped modules:** No phase file should reference a skipped module's

package/templates/skills/onboard/phases/work-tracking.md

@@ -6,7 +6,7 @@ two built-in options plus bring-your-own. The user chooses one, the other,
 or neither.
 
 When this file is absent or empty, the default behavior is: detect existing
-work tracking, present options, record the choice in `.pibrc.json`. To skip
+work tracking, present options, record the choice in `.corrc.json`. To skip
 work-tracking decisions entirely, write only `skip: true`.
 
 ## When This Phase Activates
@@ -28,7 +28,7 @@ Before presenting options, scan for signs of existing work tracking:
 3. **GitHub Issues** — `gh issue list` returns results (if `gh` CLI is available)
 4. **Custom work-scan phase** — `.claude/skills/orient/phases/work-scan.md`
    with non-default content
-5. **`.pibrc.json` workTracking field** — Previous choice already recorded
+5. **`.corrc.json` workTracking field** — Previous choice already recorded
 
 If something is already set up and working, acknowledge it: "I see you're
 using [X]. Is that working well, or would you like to try something
@@ -161,7 +161,7 @@ Which approach fits your project? You can also skip work tracking for now.
 
 ## Recording the Choice
 
-Record the choice in `.pibrc.json` under a `workTracking` field:
+Record the choice in `.corrc.json` under a `workTracking` field:
 
 ```json
 {
@@ -228,4 +228,4 @@ If a user chose markdown initially and later wants to switch to pib-db:
 2. Early re-run detects markdown tracking
 3. Work-tracking phase asks: "Still using tasks.md? Anything missing?"
 4. If user wants to upgrade: offer to import from markdown into pib-db
-5. Update `.pibrc.json` and regenerate phase files
+5. Update `.corrc.json` and regenerate phase files

package/templates/skills/publish/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: publish
+description: |
+  Publish a new version of Claude on Rails to npm. Analyzes changes since
+  last release, suggests a version bump (patch/minor/major), updates
+  package.json, commits, tags, and publishes. Use when: "publish",
+  "release", "ship it", "/publish".
+---
+
+# /publish — Release to npm
+
+## Purpose
+
+Handle the full publish flow for the `create-claude-rails` package:
+analyze what changed, suggest a version, get confirmation, and ship.
+
+This skill only runs from the CoR source repo (`package.json` has
+`name: "create-claude-rails"`). If run elsewhere, say so and stop.
+
+## Workflow
+
+### 1. Analyze Changes
+
+Run `git log` from the last version tag (e.g., `v0.2.0`) to HEAD.
+Summarize what changed in plain language — group by category:
+
+- **Breaking** — renames, removed features, changed file formats
+- **Features** — new flags, new skills, new modules
+- **Fixes** — bug fixes, UX improvements
+- **Internal** — refactors, template updates that don't change behavior
+
+### 2. Suggest Version
+
+Based on the changes:
+
+- **Patch** (0.x.Y) — fixes only, no new features, no breaking changes
+- **Minor** (0.X.0) — new features, backward-compatible
+- **Major** (X.0.0) — breaking changes (renames, removed APIs, format changes)
+
+Note: while pre-1.0, minor can include breaking changes per semver
+convention. Call this out when recommending.
+
+Present the suggestion with reasoning:
+
+> "Since the last release (v0.2.0), there are N breaking changes
+> (list them), N new features, and N fixes. I'd suggest **0.3.0**
+> because [reason]. Want to go with that, or a different version?"
+
+### 3. Pre-Publish Checks
+
+Before publishing, verify:
+
+- `node -c lib/cli.js` passes (syntax check)
+- Working tree is clean (no uncommitted changes) — if dirty, ask
+  whether to commit first
+- Current branch is main
+- `npm whoami` succeeds (logged in to npm)
+
+### 4. Publish
+
+With user confirmation:
+
+1. Update `version` in `package.json`
+2. Commit: `Bump to <version>`
+3. Tag: `git tag v<version>`
+4. `npm publish`
+5. `git push && git push --tags`
+
+### 5. Post-Publish
+
+- Update `system-status.md` if it exists
+- Report the published version and npm URL

package/templates/skills/unlink/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: unlink
+description: |
+  Remove local development linking for Claude on Rails. Returns the
+  project to using the published npm version. Use when: "unlink",
+  "stop using local CoR", "use published version", "/unlink".
+---
+
+# /unlink — Remove Local Development Link
+
+## Purpose
+
+Disconnect from a local Claude on Rails checkout and return to using
+the published npm version.
+
+## Context Detection
+
+**CoR source repo** (`package.json` has `name: "create-claude-rails"`):
+- Run `npm unlink` to remove the global registration
+- Warn: "This will break the link for all consuming projects that depend
+  on it. They'll need to `npm unlink create-claude-rails` too, or
+  they'll get resolution errors."
+
+**Any other project**:
+- Run `npm unlink create-claude-rails`
+- The project returns to using the published npm version
+- Tell the user: "Unlinked. `npx create-claude-rails` will now pull
+  from npm instead of your local checkout."
+
+## When to Use
+
+- Before testing against the published npm version
+- When done with a local development cycle
+- When the local CoR checkout is moving to a branch you don't want
+  consuming projects to track