create-claude-rails 0.1.2 → 0.3.0

package/templates/EXTENSIONS.md

@@ -1,15 +1,15 @@
-# Extension Examples: How Flow Uses Process-in-a-Box
+# Extension Examples: How Flow Uses Claude on Rails
 
-PIB gives you skeletons. Your project fills them in via phase files —
+Claude on Rails (CoR) gives you skeletons. Your project fills them in via phase files —
 replacing defaults with project-specific behavior, adding custom phases
 the skeleton doesn't define. This document shows what that looks like
-in practice, using Flow (PIB's reference implementation) as the example.
+in practice, using Flow (CoR's reference implementation) as the example.
 
 Flow is a cognitive workspace built on Claude Code — a GTD system,
 research thread manager, and course management tool. It has a deployed
 web app (Railway), a local SQLite cache, research threads, an inbox
 pipeline, and 25+ skills. It's what happens when a project grows past
-PIB's defaults while staying on PIB's rails.
+CoR's defaults while staying on CoR's rails.
 
 You and Claude will make different choices for your project. These
 examples show what choices Flow made and why — not what you should do,
@@ -18,22 +18,22 @@ but what's possible.
 
 ## Flow's Phase File Overrides by Skill
 
-For each skeleton skill, the tables show: which PIB phase files Flow
+For each skeleton skill, the tables show: which CoR phase files Flow
 overrides (replacing default behavior with Flow-specific content), and
-which custom phase files Flow adds (concerns PIB doesn't define).
+which custom phase files Flow adds (concerns CoR doesn't define).
 
-Phase file states: **default** = PIB's behavior is fine, no override
+Phase file states: **default** = CoR's behavior is fine, no override
 needed. **override** = Flow writes its own content. **custom** = Flow
-adds a phase PIB doesn't have. **skip** = Flow actively opts out.
+adds a phase CoR doesn't have. **skip** = Flow actively opts out.
 
 ### orient
 
-PIB's orient skeleton loads context, syncs data, scans work, checks
+CoR's orient skeleton loads context, syncs data, scans work, checks
 health, and presents a briefing. Flow's orient is its most complex
 skill — 47 steps managing a deployed app, research threads, an inbox
 pipeline, and multiple always-on perspectives.
 
-| Phase | PIB Default | Flow Override |
+| Phase | CoR Default | Flow Override |
 |---|---|---|
 | `context.md` | Read status files | `system-status.md`, 7 research threads (`thread.yaml` + `CLAUDE.md`), `MEMORY.md` index, active course syllabi |
 | `data-sync.md` | Skip | DB pull from Railway (`sync-db-to-railway.sh --pull`). Report failure but don't block. |
@@ -60,12 +60,12 @@ custom phases as concerns emerge.
 
 ### debrief
 
-PIB's debrief skeleton inventories work, closes items, updates state,
+CoR's debrief skeleton inventories work, closes items, updates state,
 records lessons, and captures loose ends. Flow's debrief is the second
 most complex skill — it resolves feedback comments, runs prep scout and
 articulation sweeps, checks machine-level drift, and enforces QA gates.
 
-| Phase | PIB Default | Flow Override |
+| Phase | CoR Default | Flow Override |
 |---|---|---|
 | `inventory.md` | Scan git log + conversation | Same approach, plus check for uncommitted work, unresolved preview tool sessions |
 | `close-work.md` | Match session work against pib-db actions | Match against Railway API actions. QA perspective gate: actions can't be marked complete if QA report shows failures. Project auto-completion scan. |
@@ -86,16 +86,16 @@ articulation sweeps, checks machine-level drift, and enforces QA gates.
 | `project-completion.md` | Check if any projects have all actions completed, prompt for project close |
 
 **Key pattern:** Flow's debrief has *mandatory perspectives* — historian
-and life-tracker always activate. In PIB's skeleton, perspectives are
+and life-tracker always activate. In CoR's skeleton, perspectives are
 optional (the `perspectives.md` phase can be empty). Flow overrides this
 by listing required perspectives in its close-work and loose-ends phases.
 
 ### validate
 
-PIB's validate skeleton runs validators from a single phase file. Flow
+CoR's validate skeleton runs validators from a single phase file. Flow
 overrides with 8 specific validators.
 
-| Phase | PIB Default | Flow Override |
+| Phase | CoR Default | Flow Override |
 |---|---|---|
 | `validators.md` | Commented-out examples | 8 validators: fid coverage (`validate-fids.sh`), thread structure (`validate-threads.sh`), folder integrity (`validate-folders.sh`), MEMORY.md references, TypeScript (`npx tsc --noEmit`), Vite build (`npx vite build`), ESLint (`npx eslint`), Mantine import check |
 
@@ -104,11 +104,11 @@ does the job. Flow just fills in its specific checks.
 
 ### plan
 
-PIB's plan skeleton researches, checks overlap, drafts with template,
+CoR's plan skeleton researches, checks overlap, drafts with template,
 runs perspective critique, checks completeness, presents, and files work.
 Flow's plan adds a design committee pattern and specific work tracking.
 
-| Phase | PIB Default | Flow Override |
+| Phase | CoR Default | Flow Override |
 |---|---|---|
 | `research.md` | Explore codebase | Same, plus check ecosystem memory (`reference-skill-ecosystem.md`) for prior art |
 | `overlap-check.md` | Query pib-db | Query Railway DB via sqlite3 on local cache. Check open actions + recent completed. |
@@ -126,11 +126,11 @@ Flow's plan adds a design committee pattern and specific work tracking.
 
 ### execute
 
-PIB's execute skeleton loads the plan, activates perspectives, implements
+CoR's execute skeleton loads the plan, activates perspectives, implements
 with checkpoints, validates, and commits. Flow adds QA enforcement and
 design mock verification.
 
-| Phase | PIB Default | Flow Override |
+| Phase | CoR Default | Flow Override |
 |---|---|---|
 | `load-plan.md` | Read plan from conversation or file | Same, plus check for design mocks in action notes (`mock_path`) and `.claude/mocks/` |
 | `perspectives.md` | Activate relevant perspectives | QA always-on. Boundary-conditions always-on. Others per plan's surface area. |
@@ -141,15 +141,15 @@ design mock verification.
 **Key pattern:** Flow's execute enforces a QA gate — the QA perspective
 produces a verification report at checkpoint 3, and debrief won't mark
 actions complete if QA shows failures. This is the "mandatory perspective"
-pattern: a perspective that's advisory in PIB becomes load-bearing in Flow.
+pattern: a perspective that's advisory in CoR becomes load-bearing in Flow.
 
 ### audit
 
-PIB's audit skeleton selects perspectives, runs structural checks, loads
+CoR's audit skeleton selects perspectives, runs structural checks, loads
 triage suppression, spawns perspective agents, and persists findings.
 Flow overrides the data layer and execution model.
 
-| Phase | PIB Default | Flow Override |
+| Phase | CoR Default | Flow Override |
 |---|---|---|
 | `perspective-selection.md` | Discover from SKILL.md files, use groups | Same discovery, but 21 additional domain perspectives available |
 | `structural-checks.md` | Run fast structural scripts | Same validators as `/validate`, run before LLM analysis |
@@ -164,19 +164,19 @@ Flow overrides the data layer and execution model.
 | `triage.md` | Programmatic triage of findings via Railway API PATCH endpoint (approve/reject/defer) |
 | `next-steps.md` | Offer quick-fix, /plan, or bulk triage based on findings after output |
 
-**Why nested agents instead of subprocesses:** PIB's default uses
+**Why nested agents instead of subprocesses:** CoR's default uses
 `claude --print` for parallel perspective execution. Flow found that
 subprocess spawning creates API concurrency errors during active
 sessions. Nested Agent tool calls avoid this. A project without this
-constraint can use PIB's subprocess default.
+constraint can use CoR's subprocess default.
 
 ### pulse
 
-PIB's pulse skeleton checks self-description accuracy, spots dead
+CoR's pulse skeleton checks self-description accuracy, spots dead
 references, and detects staleness. Flow overrides with extensive
 count verification and principle practice checks.
 
-| Phase | PIB Default | Flow Override |
+| Phase | CoR Default | Flow Override |
 |---|---|---|
 | `checks.md` | Count freshness, dead references | Count freshness across 3 files (`project-skills-infrastructure.md`, `system-status.md`, `_context.md`). Dead reference spot-check with rotation tracking (`pulse-state.json`). Skill staleness (last-verified > 30d). Rules enforcement health. Session drift detection. Principle spot-check (samples different principle each run). Memory index auto-fix. |
 | `auto-fix-scope.md` | Closed list of safe fixes | Same closed list: numeric counts, MEMORY.md filenames, system-status moves, `_context.md` perspective lists, last-verified dates |
@@ -190,10 +190,10 @@ project could adopt.
 
 ### triage-audit
 
-PIB's triage skeleton loads findings, presents via UI, and applies
+CoR's triage skeleton loads findings, presents via UI, and applies
 verdicts. Flow overrides the data source and verdict application.
 
-| Phase | PIB Default | Flow Override |
+| Phase | CoR Default | Flow Override |
 |---|---|---|
 | `load-findings.md` | Query pib-db or read JSON files | Fetch from Railway DB via API with severity + perspective ordering |
 | `triage-ui.md` | Start local `triage-server.mjs`, open browser | Same local server, but opened via Chrome MCP tool for reading verdicts |
@@ -218,7 +218,7 @@ project could implement for its own domain.
 | Change-type deployment | `/deploy` | Classifies changes (markdown-only, code, mixed), takes appropriate deploy path (git push vs git push + platform deploy), verifies | Any project with multiple deployment paths depending on what changed. The classify-deploy-verify loop is the pattern. |
 | Area health review | `/quarterly-review` | SQL-driven area-by-area walkthrough: stale actions, recurring cadence health, person context freshness, open loops, supply patterns | Any project with areas of responsibility benefits from periodic health queries. The SQL query templates are reusable. |
 
-These are future extraction candidates. If PIB grows beyond Wave 6, the
+These are future extraction candidates. If CoR grows beyond Wave 6, the
 highest-value patterns to skeleton would be: entity scaffolding (widely
 applicable), prompt refinement (universal for Claude Code projects), and
 command queue processing (needed by any project with an async work queue).
@@ -226,7 +226,7 @@ command queue processing (needed by any project with an async work queue).
 
 ## Writing Domain-Specific Perspectives
 
-PIB ships 14 generic perspectives. Flow has 19 additional domain-specific
+CoR ships 14 generic perspectives. Flow has 19 additional domain-specific
 perspectives. Here are three examples showing how to write your own.
 
 ### Example 1: GTD (encoding domain expertise)
@@ -305,7 +305,7 @@ Eight skills contained reusable patterns (documented in the table above).
 The full analysis is in the methodology essay's Wave 6 findings section.
 
 These are patterns, not extraction candidates — yet. The patterns are
-documented here so PIB users know what's possible. If your project needs
+documented here so CoR users know what's possible. If your project needs
 entity scaffolding or prompt refinement, you'll write your own version.
-If PIB grows a Wave 7, the strongest candidates for skeleton extraction
+If CoR grows a Wave 7, the strongest candidates for skeleton extraction
 are scaffold, refine-prompts, and handle-findings.

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 PIB 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)
 
@@ -106,7 +106,7 @@ execution, audit). Each is a named domain expert encoded in markdown.
 
 | Perspective | Domain | Activation |
 |------------|--------|-----------|
-| `box-health` | PIB adoption health, phase file coverage, configuration drift, anti-bloat | Always-on during audit |
+| `box-health` | CoR adoption health, phase file coverage, configuration drift, anti-bloat | Always-on during audit |
 
 **Infrastructure files (7):**
 
@@ -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 PIB skeletons arrive. Detects current
+  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 PIB", "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
-    role: "Semantic diff against upstream PIB"
+    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 PIB Upgrade
+# /cor-upgrade — Conversational Claude on Rails Upgrade
 
 ## Purpose
 
@@ -34,7 +34,7 @@ nothing breaks. The upgrade path is mechanical — diff, patch, pray. This
 works for code because code has precise semantics. It fails for process
 because process is always adapted to context.
 
-AI-native methodology distributes as conversation. The upstream PIB
+AI-native methodology distributes as conversation. The upstream CoR
 package publishes new skeletons, updated defaults, additional perspectives,
 schema migrations. But the project has already adapted those skeletons —
 customized phase files, tuned perspectives, extended workflows. A
@@ -76,7 +76,7 @@ update, but phase files are NEVER overwritten by upstream changes.**
 
 Skeleton files (SKILL.md) contain the generic orchestration — the workflow
 steps, the phase protocol, the default behaviors. These are authored by
-PIB and may improve over time. When upstream publishes a better skeleton,
+CoR and may improve over time. When upstream publishes a better skeleton,
 the upgrade skill can propose replacing it.
 
 Phase files contain the project's customizations — what specific files to
@@ -95,13 +95,13 @@ between the two.
 ### 1. Detect Current State
 
 Read `phases/detect-current.md` for how to inventory the project's
-current PIB adoption.
+current CoR adoption.
 
-**Default (absent/empty):** Scan the project for PIB artifacts:
-- For each skill in `.claude/skills/`: is it a PIB skeleton? Which
+**Default (absent/empty):** Scan the project for CoR artifacts:
+- For each skill in `.claude/skills/`: is it a CoR skeleton? Which
   phase files are customized vs using defaults vs explicitly skipped?
 - Which perspectives are adopted? Which groups configured?
-- What hooks are installed from PIB?
+- What hooks are installed from CoR?
 - What pib-db schema version is in use (check for known columns)?
 - What's in `memory/patterns/`?
 
@@ -111,7 +111,7 @@ the diff phase.
 ### 2. Diff Against Upstream
 
 Read `phases/diff-upstream.md` for how to compare the project's state
-against the upstream PIB package.
+against the upstream CoR package.
 
 **Default (absent/empty):** Look for `.pib-upstream/` in the project
 root (staged by `npx create-claude-rails upgrade`). For each
@@ -209,15 +209,15 @@ the workflow. Execute them at their declared position.
 ## Proactive Trigger
 
 The upgrade skill doesn't have to wait for the user to invoke it.
-Orient can detect when upstream PIB files are newer than the project's
-adopted copies and surface "PIB updates available" in the briefing.
-This is a hint, not a blocker — the user decides when to run /upgrade.
+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 /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
 
@@ -242,7 +242,7 @@ that erase hard-won customizations.
 
 ### Without Skill (Bad)
 
-New PIB skeletons arrive. The user manually diffs files, trying to
+New CoR skeletons arrive. The user manually diffs files, trying to
 figure out what changed. Some changes are obvious — a new skill directory
 appeared. Others are subtle — a default behavior in an existing skeleton
 shifted. The user copies files they think are updated, accidentally
@@ -253,7 +253,7 @@ spent two sessions tuning is gone, replaced by the upstream default.
 
 ### With Skill (Good)
 
-New PIB 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/apply.md

@@ -71,9 +71,9 @@ Commit after each logical group of changes:
   skeleton changes)
 
 Commit messages should describe what was upgraded:
-"Upgrade orient + debrief skeletons from upstream PIB"
-"Add trigger_condition column (PIB schema migration)"
-"Adopt /validate skill from PIB"
+"Upgrade orient + debrief skeletons from upstream CoR"
+"Add trigger_condition column (CoR schema migration)"
+"Adopt /validate skill from CoR"
 
 ## Summary
 

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

@@ -1,19 +1,19 @@
-# Detect Current — Inventory PIB Adoption State
+# Detect Current — Inventory Claude on Rails Adoption State
 
-Build a structured manifest of the project's current PIB adoption. This
+Build a structured manifest of the project's current CoR adoption. This
 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
-`.claude/skills/`, perspectives, hooks, and database for PIB artifacts.
+`.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.
@@ -30,9 +30,9 @@ back to pure filesystem diffing.
 ### Skills
 
 For each directory in `.claude/skills/`:
-- **Is it a PIB skeleton?** Compare the SKILL.md against the upstream
+- **Is it a CoR skeleton?** Compare the SKILL.md against the upstream
   upstream templates directory. If it matches a known skeleton
-  (by name or by frontmatter `name` field), it's a PIB skill.
+  (by name or by frontmatter `name` field), it's a CoR skill.
 - **Phase file status:** For each phase file the skeleton defines, check
   whether the project's copy is: absent (using default), empty (using
   default), contains `skip: true` (opted out), or contains custom content
@@ -49,13 +49,13 @@ For each directory in `.claude/skills/`:
 ### Hooks
 
 - Read `.claude/settings.json` (or `.claude/settings.local.json`).
-- Identify which hooks were installed as part of PIB adoption vs
+- Identify which hooks were installed as part of CoR adoption vs
   project-specific additions.
 
 ### Database Schema
 
 - If the project uses `pib-db`, check the actual DB schema against
-  known PIB columns. Record which tables and columns exist.
+  known CoR columns. Record which tables and columns exist.
 - Note the effective schema version (inferred from which columns are
   present, not from a version number).
 
@@ -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/{upgrade → cor-upgrade}/phases/diff-upstream.md

@@ -1,7 +1,7 @@
-# Diff Upstream — Compare Project Against PIB Package
+# Diff Upstream — Compare Project Against Claude on Rails Package
 
 Compare the project's current adoption state (from detect-current) against
-the upstream PIB package. Produce a categorized list of changes.
+the upstream CoR package. Produce a categorized list of changes.
 
 When this file is absent or empty, the default behavior is: look for
 `.pib-upstream/` in the project root (staged by `npx create-claude-rails
@@ -59,7 +59,7 @@ new tables, new indexes.
 
 - New hooks in upstream's recommended settings.
 - New rules files in upstream's `.claude/rules/`.
-- Changes to the PIB onboarding or seed skills.
+- Changes to the CoR onboarding or seed skills.
 
 ## Output Format
 

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.