Separate initiative definition, issue planning and orchestration scope

README.md

@@ -6,7 +6,7 @@ CRW is a community project designed to work with CXC; it is not an official
 OpenAI or Codex product. Its workflow connects child-task delegation, PR review
 resolution, and parent-task verification and integration.
 
-This is an experimental workflow built from a personal setup. It contains six
+This is an experimental workflow built from a personal setup. It contains seven
 skill instruction sets, a symlink installer, and the two Python packages the
 workflow delegates and reports through. CXC and Paperthin remain separate
 dependencies. Having the package source here does not install or activate a
@@ -17,7 +17,8 @@ compatibility.
 |---|---|
 | [crw-focus](skills/crw-focus/SKILL.md) | Make this task a project's fixed management point and restore its recorded link |
 | [crw-next](skills/crw-next/SKILL.md) | Choose one next action when starting or after finishing work, using readchk and nba |
-| [crw-plan](skills/crw-plan/SKILL.md) | Turn product context into canonical Linear documents, milestones, and issues |
+| [crw-define](skills/crw-define/SKILL.md) | Explore intent and define an initiative goal, success evidence, and scope |
+| [crw-plan](skills/crw-plan/SKILL.md) | Decompose an agreed goal into projects, milestones, and one-PR issues |
 | [crw-run](skills/crw-run/SKILL.md) | Delegate ready work to independent Codex tasks and verify CXC execution and delivery |
 | [crw-check](skills/crw-check/SKILL.md) | Verify delivery and return in-scope corrections to managed tasks |
 | [crw-logic](skills/crw-logic/SKILL.md) | Find consequential contradictions using Paperthin checks and minimal counterexamples |
@@ -133,7 +134,7 @@ belongs to the installation you are retiring, move that link to a backup directo
 outside Codex's scanned skill directories. Preserve foreign files, directories,
 and links for their owner to reconcile. Do not infer ownership from the old name,
 and do not move the linked source directory. Run `--check` again; a clean result
-means all six new links point to this checkout and no known old names remain.
+means all current skill links point to this checkout and no known old names remain.
 
 There are no old-name aliases or duplicate skill instruction folders. Refresh the
 client's skill catalog or start a fresh task, then invoke `$crw-run`, for example.
@@ -179,7 +180,8 @@ The bundled validator has its own dependencies. It checks skill structure, not t
 ```text
 $crw-focus [Linear project] 이 작업을 이 프로젝트의 고정 진행 관리 창구로 지정하고 연결을 기록해줘.
 $crw-next [Linear project or product repository] 다음에 뭐 하지? 시작할 단계인지 끝난 뒤인지 확인하고 다음 행동 하나를 골라줘.
-$crw-plan [Linear project or product repository] 정본 문서와 남은 실행 이슈를 정리해줘.
+$crw-define [idea or initiative] 목표·완료 기준·범위를 정의해 Linear에 반영해줘.
+$crw-plan [defined initiative or existing project] 프로젝트·마일스톤·이슈와 의존성을 계획해 Linear에 반영해줘.
 $crw-run [Linear project] 준비된 첫 묶음을 기존 담당 하위 Codex 작업에 맡기고, 없으면 새 독립 하위 Codex 작업을 생성해 CXC Loop로 실행·검증해줘.
 $crw-check [Linear project or issue] 기획대로 구현됐는지 확인해줘.
 $crw-logic [Linear document or project] 설계와 계산 규칙의 모순을 찾아줘.
@@ -188,7 +190,8 @@ $crw-logic [Linear document or project] 설계와 계산 규칙의 모순을 찾
 These are invocation examples, not requests to execute while reading this file.
 
 `crw-run` keeps implementation in the responsible independent child task for
-one issue, an existing worktree, or a PR repair. The coordinator selects scope,
+one issue, including that issue’s worktree and PR repairs. Each parent orchestrates
+one project and each child one issue. The coordinator selects scope,
 reviews results, checks CI, and performs authorized integration. Internal
 subagents assist within those tasks and do not replace the independent child.
 
@@ -219,11 +222,25 @@ apply. See [Independent implementation tasks](skills/crw-run/SKILL.md#independen
 
 `crw-focus` records the project and current task IDs in a linked Linear
 document, sets the task title and sidebar pin when supported, and restores that
-context for later requests. Management titles use `Initiative name - Project summary`.
+context for later requests. Management titles use a concise project summary;
+the binding uses the stable project ID regardless of names or initiative membership.
 It routes each request to its existing operation
 owner. Designating the management task alone does not start project execution;
 an accompanying execution request continues within its authorized scope.
 
+`crw-define` explores intent and defines the initiative’s goal, finish condition
+and scope. `crw-plan` then decomposes the agreed goal into projects, useful
+milestones, and executable issues in one operation. A request for both chains
+them; definition-only stops before project and issue creation. It reuses existing
+items, creates missing ones within that request, and keeps narrow updates scoped.
+Consultation and draft-only planning do not write to Linear.
+Each implementation issue maps to one PR; work requiring several PRs is split
+into dependent issues. Non-PR research or design keeps a verified result instead.
+Initiatives represent goals; product family and related
+repositories are separate project labels. Project names need no product prefix,
+and views remain the user's choice. See the shared
+[Linear operating model](skills/crw-plan/references/integrations.md#linear-operating-model).
+
 `crw-next` distinguishes choosing a first step from choosing what follows a
 delivery. It uses `readchk` to resolve ambiguous intent and `nba` to pick one
 evidence-backed action with a clear completion condition. Standalone advice does

scripts/ci/tests/test_install.py

@@ -7,7 +7,7 @@
 
 ROOT = Path(__file__).resolve().parents[3]
 SCRIPT = ROOT / "scripts/install.py"
-NAMES = ("crw-check", "crw-focus", "crw-logic", "crw-next", "crw-plan", "crw-run")
+NAMES = ("crw-check", "crw-define", "crw-focus", "crw-logic", "crw-next", "crw-plan", "crw-run")
 SOURCES = [ROOT / "skills" / name for name in NAMES]
 
 

skills/crw-define/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: crw-define
+description: "Explore an idea and define a goal-based Linear initiative: purpose, desired change, success evidence, scope, and open decisions. Use when intent or an initiative needs definition; hand an agreed goal to crw-plan for projects and issues. Definition alone does not create an execution plan."
+---
+
+# CRW Define
+
+Make the intended change clear enough to decide whether and what to plan.
+An initiative is a goal with an observable finish, not a permanent product bucket.
+Read the shared [Integrations](../crw-plan/references/integrations.md) for source
+of truth, write authority, classification, and tool access.
+
+## Recover the intent
+
+Read the request, accepted decisions, and existing initiative and linked documents.
+Reuse stable IDs and distinguish the user's words, accepted choices, suggestions,
+and unresolved assumptions. Inspect relevant product or repository evidence only
+where it can change the definition. Do not replace the user's goal with a guessed
+“real problem.” Use installed `cxc-recall` for missing history, not as live proof.
+
+When an answer could materially change the goal or design, ask one useful question
+at a time. Prefer the consequential hidden premise or missing perspective over a
+fixed questionnaire. A clear intent needs no ceremonial interview. Do not force
+clever questions, preset binary choices, recommendations, or exhaustive branches.
+Accept an unexpected answer, “I don't know,” a correction, or a stop request;
+update the working understanding instead of steering back to a preferred answer.
+Continue independent work while a question is pending where the host permits it.
+
+## Define the goal
+
+Keep a compact definition with:
+
+- The original idea, problem or opportunity, and why it matters.
+- The desired change and who benefits.
+- Observable success evidence and the condition for finishing the initiative.
+- Included scope, explicit exclusions, accepted direction and reasons.
+- Considered perspectives, deferred choices and unresolved questions that affect planning.
+
+Do not invent dates, owners, numerical targets, validated demand, or user answers.
+Distinguish evidence from assumptions. Record unknowns as unknowns rather than
+filling later design stages with plausible detail. Reuse an existing initiative
+when the goal matches; related products or repositories alone do not establish it.
+A narrow project or standalone issue does not require a new initiative.
+
+## Carry design forward
+
+When design documentation is requested, keep one linked canonical document using
+Strategy → Scope → Structure → Skeleton → Surface as lenses, not as Linear levels.
+The initiative definition usually supplies Strategy and high-level Scope. Let
+project planning develop project-specific Structure, Skeleton and Surface when
+they become knowable; CLI/API work need not invent screens. Mark unsupported
+stages open. Preserve the original idea, newly considered perspective, chosen
+direction and why, deferred alternatives, and material open questions.
+
+A material contradiction returns to the relevant question; it does not trigger
+an automatic interview restart. Do not claim that a simulated conversation proves
+real question quality or product demand. Real-use evaluation remains separate.
+
+## Apply and hand off
+
+Advice, exploration and draft-only requests produce a proposal without Linear
+writes. A request to define/create/update the initiative in Linear covers that
+initiative and its canonical definition document, not automatic projects or issues.
+Respect an already accepted broader write request without asking at every level.
+Read current state before writing, preserve unrelated content and history, and
+read back IDs, content and links. Reconcile uncertain writes before retrying.
+
+Return the agreed goal, success evidence, scope, open decisions and source links.
+If both definition and a full plan were requested, continue to
+[crw-plan](../crw-plan/SKILL.md) in the same operation with that definition and its
+write scope. Definition-only ends here. If scope is advisory, the downstream plan
+also remains a proposal. Creating either artifact does not launch execution tasks.

skills/crw-define/agents/openai.yaml

@@ -0,0 +1,6 @@
+interface:
+  display_name: "CRW Define"
+  short_description: "의도를 탐색하고 완료 기준이 있는 이니셔티브 목표 정의"
+  default_prompt: "$crw-define 이 아이디어의 의도와 중요한 전제를 확인하고, 목표·완료 기준·범위·미결정을 정리해 Linear 이니셔티브와 정본 문서에 반영해줘. 프로젝트와 이슈 분해는 아직 하지 마."
+policy:
+  allow_implicit_invocation: true

skills/crw-focus/SKILL.md

@@ -6,7 +6,9 @@ description: "Designate, restore, or switch the current Codex task as a Linear p
 # CRW Focus
 
 Make this Codex task the continuing management point for one Linear project.
-Preserve that target across follow-up requests and context recovery.
+Preserve that target across follow-up requests and context recovery. This parent
+orchestrates one project; its independent children each orchestrate one issue
+under the shared [parent and child scope](../crw-plan/references/integrations.md#parent-and-child-scope).
 
 Read [Integrations](../crw-plan/references/integrations.md) for shared target
 resolution, document authority, access, and inherited authorization.
@@ -37,15 +39,14 @@ A request to make this the fixed management task covers its matching title,
 sidebar pin, and a compact Linear management record. Respect an explicit title,
 no-rename, unpinned, or read-only constraint.
 
-Use the actual linked initiative name followed by a concise project summary:
-`Initiative name - Project summary`. Read the project's initiative relation;
-do not infer it from the repository or duplicate the initiative prefix in the
-project summary. Preserve an explicit user title. If there is no initiative,
-use the project summary alone; if multiple initiative relations make the choice
-unclear, ask one focused question before renaming. Do not change the
-initiative/project names themselves. Continue independent binding preparation
-while the title choice is unresolved. This convention names the management
-task; execution-task titles follow [Child task titles](../crw-run/references/task-packet.md#child-task-titles).
+Use a concise project summary as the management task title. Preserve an explicit
+user title. Product family and initiative membership are context, not required
+title prefixes; no initiative or multiple initiatives needs no title-choice
+question. Resolve same-name projects by stable ID under the shared target rules
+before binding. If their management titles would be indistinguishable, append a
+short project-ID suffix. Do not rename the initiative or project itself. This
+convention names the management task; execution-task titles follow
+[Child task titles](../crw-run/references/task-packet.md#child-task-titles).
 
 Discover the supported task rename and sidebar tools and their current schemas.
 Apply changes only to the verified current task, and check its resulting title
@@ -83,11 +84,17 @@ and scoped recall to find a lost record. A copied binding for another task does
 not assign ownership here. Follow the shared target-resolution rules for
 explicit one-off targets and changes to the persistent link.
 
+Keep the recorded project ID when its name, product labels, or initiative
+relations change. Existing titles with an initiative prefix are presentation,
+not a reason to rebind or rename during recovery. Refresh the title only within
+an authorized presentation change; do not migrate existing bindings implicitly.
+
 Load the existing owner for the requested operation:
 
 | Request | Owner |
 |---|---|
 | Where to start or what to do next | [crw-next](../crw-next/SKILL.md) |
+| Define initiative intent or goal | [crw-define](../crw-define/SKILL.md) |
 | Plan, roadmap, milestones, or issue scope | [crw-plan](../crw-plan/SKILL.md) |
 | Run work, coordinate progress, or follow up on delivery | [crw-run](../crw-run/SKILL.md) |
 | Compare delivery with accepted requirements | [crw-check](../crw-check/SKILL.md) |

skills/crw-next/SKILL.md

@@ -38,7 +38,8 @@ open work before proposing a new project or duplicate issue.
 
 If the outcome is unclear, choose the smallest discovery step that would change
 the decision: a focused user question, an external observation, or a bounded
-experiment. If it is clear, choose the smallest useful first delivery with ready
+experiment. Use [crw-define](../crw-define/SKILL.md) when the initiative goal
+itself needs definition. If it is clear, choose the smallest useful first delivery with ready
 prerequisites. Missing documents alone do not justify a full planning exercise;
 use [crw-plan](../crw-plan/SKILL.md) when missing scope or dependencies
 actually prevent execution. Prefer a step that produces evidence or user value