From c1a2b330be49c1e75b6bdabb1e5b172f166b07bf Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 17:24:16 +0900 Subject: [PATCH 01/10] Separate Linear goals, project classification, and management identity --- README.md | 9 ++++- skills/crw-focus/SKILL.md | 22 +++++++----- skills/crw-plan/SKILL.md | 14 ++++---- skills/crw-plan/references/integrations.md | 41 +++++++++++++++++++++- 4 files changed, 69 insertions(+), 17 deletions(-) diff --git a/README.md b/README.md index 05b9a34..ea965f1 100644 --- a/README.md +++ b/README.md @@ -219,11 +219,18 @@ 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-plan` creates projects on the user's request and reuses existing items when +updating a plan. 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 diff --git a/skills/crw-focus/SKILL.md b/skills/crw-focus/SKILL.md index b749eda..9564815 100644 --- a/skills/crw-focus/SKILL.md +++ b/skills/crw-focus/SKILL.md @@ -37,15 +37,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,6 +82,11 @@ 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 | diff --git a/skills/crw-plan/SKILL.md b/skills/crw-plan/SKILL.md index 195658d..c8aef48 100644 --- a/skills/crw-plan/SKILL.md +++ b/skills/crw-plan/SKILL.md @@ -23,16 +23,18 @@ Read the user's goal, existing Linear initiative/project/milestones/issues, full Distinguish proposed, implemented, reviewed, merged, deployed, and behaviorally verified work. A Done label or local commit cannot establish every later state. If evidence disagrees, preserve the source links and record the disagreement. -Identify the durable product and finishable outcome. Reuse existing initiative/project IDs and team conventions. Do not infer product identity from a checkout folder name or merge distinct products because their repositories are related. +Identify the goal, product classification, and finishable outcome separately using the shared [Linear operating model](references/integrations.md#linear-operating-model). Reuse existing initiative/project IDs and team conventions. Do not infer product identity from a checkout folder name or merge distinct products because their repositories are related. ## Shape the plan -- **Initiative:** product or longer-term direction, following the workspace convention. -- **Project:** a finishable outcome. Prefer the established `Product · Outcome` naming when the workspace uses it. +- **Initiative:** a goal with an observable completion condition, to which projects contribute. It is not a permanent product container. +- **Project:** a finishable outcome created when the user requests a project. Name the result naturally; do not require a product prefix. A product name can appear when it helps explain the result. - **Milestone:** an observable result or coherent delivery boundary. Follow explicit user grouping, such as one milestone per character or module. - **Issue:** one reviewable delivery, often one PR, with scope, acceptance criteria, canonical document links, dependencies, and meaningful verification. -Use the smallest structure that makes the next action clear. Do not invent dates, owners, status transitions, or a team per product. Record unknowns plainly. +Use the smallest structure within the requested scope. Issue count, repository count, or estimated size does not authorize a new project. Planning or updating issues can reuse a project or keep standalone issues without creating missing upper levels. A project may have no initiative or contribute to several; reuse its ID instead of duplicating the project or its issues. Do not invent dates, owners, status transitions, or a team per product. Record unknowns plainly. + +Apply product-family and related-repository labels under the shared operating model. Reuse existing labels and keep descriptions short. Additional label schemes need discussion with the user; leave views and default screens to the user unless requested. Split by deliverable and shared contract, not file count. Derive order from dependency edges and overlapping edit surfaces. A schema/API contract may precede several apparently independent issues. Avoid dependency cycles and distinguish speculative backlog ideas from approved requirements. @@ -42,9 +44,9 @@ Make criteria observable: user behavior, data/state that must survive, and impor For an existing plan, compute a compact change set: reuse, create, update, or leave unresolved. Match stable IDs and semantic scope before titles. Re-running the same request should converge on the same items. -A request to create or update the Linear plan authorizes the corresponding document/item writes. Prepare concrete changes, apply them within scope, and read back the resulting documents, items, and relations. Do not add a second approval step for routine authorized writes. A draft-only request stays a draft. Deletion, archival, issue closure, messages to others, or a material change to agreed scope need authorization covering that action. +A request to create or update the Linear plan authorizes the corresponding document/item writes within that scope; project creation still requires the user's project request, including an already accepted proposal. Prepare concrete changes, apply them within scope, and read back the resulting documents, items, and relations. Do not add a second approval step for routine authorized writes. A draft-only request stays a draft. Deletion, archival, issue closure, messages to others, or a material change to agreed scope need authorization covering that action. -Preserve unrelated content, labels, history, and human edits. Refresh before updating if another actor may have changed an item. After an uncertain write, look up the existing result before retrying; report partial completion with actual IDs. +Preserve unrelated content, labels, history, and human edits. Refresh before updating if another actor may have changed an item. After an uncertain write, look up the existing result before retrying; report partial completion with actual IDs. If a project was created but its labels or relations failed, repair those fields on that ID. Do not repeat the project create. Resolve same-name candidates by IDs and semantic scope; ask only if the supplied target and current binding cannot distinguish them. Link issues to canonical Linear documents instead of copying the whole specification into every issue. Include the acceptance criteria needed to act. Local drafts remain explicitly unsynced until the Linear write is verified; do not create a parallel permanent planning source. diff --git a/skills/crw-plan/references/integrations.md b/skills/crw-plan/references/integrations.md index 757c16c..604e37b 100644 --- a/skills/crw-plan/references/integrations.md +++ b/skills/crw-plan/references/integrations.md @@ -9,7 +9,11 @@ current assignment and the verified management binding for this task. A temporary question or link for another project does not change the persistent binding; a change to that binding needs an explicit designation or switch. Distinguish Linear project IDs, Codex task/host IDs, Desktop project IDs, and -repository identity. One repository may support several Linear projects. +repository identity. One repository may support several Linear projects, and +one project may involve several repositories. Resolve names to stable project +IDs using the supplied link, verified binding, and semantic scope. If same-name +candidates remain ambiguous, ask before writing or binding; do not pick by +title alone. A rename or changed initiative relation does not change a binding. Use [crw-focus](../../crw-focus/SKILL.md) to designate, record, restore, or switch the fixed management task, including its app title and pin. Refresh @@ -17,6 +21,41 @@ volatile state before acting. An old or copied record locates context but does not transfer another task's ownership or execution permissions. Keep binding setup with `crw-focus` and the requested operation with its existing owner. +## Linear operating model + +Keep goals, product classification, and repository identity separate: + +- An initiative describes a goal and its completion condition, not a permanent + product bucket. A project may have no initiative or contribute to several. + Preserve its stable ID and issues across those relations; do not clone them + or sum shared progress as separate output. Verify connector support and read + back relations before claiming that a requested link exists. +- Create a project when the user requests one, including an accepted proposal. + A planning request, large backlog, or multiple repositories alone is not a + project-creation request. Reuse existing IDs and meaningful scope. Name the + result naturally without a fixed product prefix. Do not rename existing + projects or migrate their relations merely by loading these instructions. +- Product family is a single-choice project label group. Reuse the existing + workspace values; a common project without one owning product may leave it + empty and describe its shared scope. Do not split the project automatically + or treat that empty classification as an error. +- Related repositories use multiple independent project labels, outside a + group. Use `저장소 · repo`, adding the owner when short names collide; keep + the description to the exact repository URL. Verify label identity, parent + group, and resulting assignments. These labels classify related code; they + do not assign all those repositories to every issue or select a checkout. + Non-code work may have no repository label. +- Reuse agreed labels. Discuss any additional label scheme when a need arises + instead of creating it automatically. Preserve unrelated labels; do not copy + all project labels to issues. Keep descriptions brief. Views, filters, and + default screens belong to the user and are configured only when requested. + +For example, a requested “Complete installation and first launch” project can +have one product family and independent core, desktop, and installer repository +labels. An installer fix within it still names only its actual code targets. +A shared planning project can have neither product family nor repository labels. +Neither example requires an initiative or a product prefix in the project name. + ## Linear holds canonical documents Jun keeps product intent, specifications, plans, accepted decisions, and human-readable coordination records in Linear documents linked to the relevant project/issues. Use stable document IDs/URLs and available revision or updated-at evidence. Repositories remain authoritative for source, executable configuration, repository policy, and reproducible implementation evidence. From 829b8de06befd1b415dfa08aedfad71b10ba2671 Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 18:43:18 +0900 Subject: [PATCH 02/10] Plan the full hierarchy with one implementation issue per PR --- README.md | 8 +++++-- skills/crw-plan/SKILL.md | 14 +++++++---- skills/crw-plan/agents/openai.yaml | 4 ++-- skills/crw-plan/references/integrations.md | 28 +++++++++++++++++++--- skills/crw-run/SKILL.md | 7 ++++-- skills/crw-run/references/task-packet.md | 18 +++++++++----- 6 files changed, 60 insertions(+), 19 deletions(-) diff --git a/README.md b/README.md index ea965f1..4ad514e 100644 --- a/README.md +++ b/README.md @@ -225,8 +225,12 @@ 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-plan` creates projects on the user's request and reuses existing items when -updating a plan. Initiatives represent goals; product family and related +`crw-plan` completes a requested full plan from initiatives through projects, +useful milestones, and executable issues in one operation. It reuses existing +items, creates missing ones within that request, and keeps narrow updates scoped. +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). diff --git a/skills/crw-plan/SKILL.md b/skills/crw-plan/SKILL.md index c8aef48..9cda769 100644 --- a/skills/crw-plan/SKILL.md +++ b/skills/crw-plan/SKILL.md @@ -1,12 +1,14 @@ --- name: crw-plan -description: "Turn a product's repository, decisions, and delivery history into canonical Linear planning documents and a roadmap, or reconcile changes into an existing plan. Use for initiative/project setup, milestones, PR-sized issues, and dependencies; use crw-run for dispatch and crw-check for implementation drift. Formerly linear-plan." +description: "Build or reconcile a complete Linear plan from initiatives through projects, milestones, and one-PR implementation issues in one planning operation. Use for product planning, roadmap setup, and scoped plan updates; use crw-run for dispatch and crw-check for implementation drift. Formerly linear-plan." --- # CRW Plan Build a usable product plan from what exists and what the user wants next. Linear holds the canonical product, planning, and decision documents; repositories hold implementation and reproducible evidence. +A full-plan request covers the requested goal through executable issues in one operation: initiative → projects → useful milestones → issues and dependencies. Reuse existing levels and create missing items within that request without requiring a separate invocation at each level. A scoped project/issue update stays scoped; do not invent an initiative or extra projects just to fill the hierarchy. Draft-only and read-only requests keep those limits. + ## Connect the workflow Read [Integrations](references/integrations.md) for Linear access, document authority, CXC ownership, and Paperthin invocation rules. Load relevant installed skills and use their outputs in the plan; naming a skill is not using it. @@ -30,21 +32,23 @@ Identify the goal, product classification, and finishable outcome separately usi - **Initiative:** a goal with an observable completion condition, to which projects contribute. It is not a permanent product container. - **Project:** a finishable outcome created when the user requests a project. Name the result naturally; do not require a product prefix. A product name can appear when it helps explain the result. - **Milestone:** an observable result or coherent delivery boundary. Follow explicit user grouping, such as one milestone per character or module. -- **Issue:** one reviewable delivery, often one PR, with scope, acceptance criteria, canonical document links, dependencies, and meaningful verification. +- **Issue:** one implementation PR, with scope, acceptance criteria, canonical document links, dependencies, and meaningful verification. Apply the shared [issue-to-PR rule](references/integrations.md#issue-to-pr-mapping), including its non-PR work exception. -Use the smallest structure within the requested scope. Issue count, repository count, or estimated size does not authorize a new project. Planning or updating issues can reuse a project or keep standalone issues without creating missing upper levels. A project may have no initiative or contribute to several; reuse its ID instead of duplicating the project or its issues. Do not invent dates, owners, status transitions, or a team per product. Record unknowns plainly. +Use the smallest structure within the requested scope. A full-plan request includes the projects needed for that agreed outcome; issue count, repository count, or estimated size alone does not authorize extra projects. Planning or updating issues can reuse a project or keep standalone issues without creating missing upper levels. A project may have no initiative or contribute to several; reuse its ID instead of duplicating the project or its issues. Do not invent dates, owners, status transitions, or a team per product. Record unknowns plainly. Apply product-family and related-repository labels under the shared operating model. Reuse existing labels and keep descriptions short. Additional label schemes need discussion with the user; leave views and default screens to the user unless requested. Split by deliverable and shared contract, not file count. Derive order from dependency edges and overlapping edit surfaces. A schema/API contract may precede several apparently independent issues. Avoid dependency cycles and distinguish speculative backlog ideas from approved requirements. +If an outcome needs several PRs, plan a separate implementation issue for each and connect prerequisites. Put the combined outcome in the project or milestone. Multiple repositories can belong to one project; code changes needing a PR in each repository require separate issues. Reading a dependency repository alone does not require another issue. + Make criteria observable: user behavior, data/state that must survive, and important failure cases. Do not weaken criteria to match code already written. Reuse completed work as evidence or a prerequisite instead of reopening it as a new implementation task. ## Reconcile and apply For an existing plan, compute a compact change set: reuse, create, update, or leave unresolved. Match stable IDs and semantic scope before titles. Re-running the same request should converge on the same items. -A request to create or update the Linear plan authorizes the corresponding document/item writes within that scope; project creation still requires the user's project request, including an already accepted proposal. Prepare concrete changes, apply them within scope, and read back the resulting documents, items, and relations. Do not add a second approval step for routine authorized writes. A draft-only request stays a draft. Deletion, archival, issue closure, messages to others, or a material change to agreed scope need authorization covering that action. +A full-plan request authorizes its scoped hierarchy and document/item writes, including needed projects; an explicit project request or already accepted proposal also authorizes that project. A narrower update does not authorize unrelated new projects. Prepare concrete changes, apply them within scope, and read back the resulting documents, items, and relations. Do not add a second approval step for routine authorized writes. A draft-only request stays a draft. Deletion, archival, issue closure, messages to others, or a material change to agreed scope need authorization covering that action. Preserve unrelated content, labels, history, and human edits. Refresh before updating if another actor may have changed an item. After an uncertain write, look up the existing result before retrying; report partial completion with actual IDs. If a project was created but its labels or relations failed, repair those fields on that ID. Do not repeat the project create. Resolve same-name candidates by IDs and semantic scope; ask only if the supplied target and current binding cannot distinguish them. @@ -54,4 +58,6 @@ Link issues to canonical Linear documents instead of copying the whole specifica Return Linear document/item links, meaningful changes, unresolved decisions, and the next ready issue or batch with prerequisites. Check requested scope coverage, duplicate work, coherent dependencies, and read-back evidence for reported writes. +For a full plan, do not stop at an initiative, project outline, or the first batch. Cover the entire agreed scope with issue-level criteria, repository/PR boundaries for implementation, dependencies, and verification. When discovery is necessary, define its question, output, and which later work it blocks instead of inventing implementation details. Report any unplanned scope or incomplete writes explicitly; an outline is not a completed plan. Creating the plan does not execute its issues. + Provide a standalone handoff to `crw-run` with source IDs and embedded criteria when worker connector access is unproven. Do not launch work unless execution was requested. diff --git a/skills/crw-plan/agents/openai.yaml b/skills/crw-plan/agents/openai.yaml index 265f912..1fb2318 100644 --- a/skills/crw-plan/agents/openai.yaml +++ b/skills/crw-plan/agents/openai.yaml @@ -1,6 +1,6 @@ interface: display_name: "CRW Plan" - short_description: "제품 현황을 Linear 문서·프로젝트·실행 이슈로 정리" - default_prompt: "$crw-plan 이 제품의 코드와 기존 기획, Linear 현황을 대조해서 문서 정본과 남은 마일스톤·PR 단위 이슈를 정리해줘." + short_description: "목표부터 PR 하나에 대응하는 이슈까지 한 번에 계획" + default_prompt: "$crw-plan 이 제품의 코드·기존 기획·Linear 현황을 대조해서 이니셔티브부터 프로젝트, 필요한 마일스톤, 이슈와 의존성까지 한 번에 계획해줘. 기존 항목을 재사용하고 구현 이슈 하나를 PR 하나에 맞춰 나눠줘." policy: allow_implicit_invocation: true diff --git a/skills/crw-plan/references/integrations.md b/skills/crw-plan/references/integrations.md index 604e37b..02c84ae 100644 --- a/skills/crw-plan/references/integrations.md +++ b/skills/crw-plan/references/integrations.md @@ -30,9 +30,10 @@ Keep goals, product classification, and repository identity separate: Preserve its stable ID and issues across those relations; do not clone them or sum shared progress as separate output. Verify connector support and read back relations before claiming that a requested link exists. -- Create a project when the user requests one, including an accepted proposal. - A planning request, large backlog, or multiple repositories alone is not a - project-creation request. Reuse existing IDs and meaningful scope. Name the +- Create a project when the user requests one, including an accepted proposal + or a full plan from goal through issues. A full-plan request covers the needed + hierarchy in its agreed scope; a narrow plan update, large backlog, or multiple + repositories alone does not authorize extra projects. Reuse existing IDs and meaningful scope. Name the result naturally without a fixed product prefix. Do not rename existing projects or migrate their relations merely by loading these instructions. - Product family is a single-choice project label group. Reuse the existing @@ -56,6 +57,27 @@ labels. An installer fix within it still names only its actual code targets. A shared planning project can have neither product family nor repository labels. Neither example requires an initiative or a product prefix in the project name. +### Issue-to-PR mapping + +One implementation issue corresponds to one PR, and that PR delivers one +implementation issue. Split work requiring several PRs into separate issues +with explicit dependencies, even within one repository. Keep a multi-repository +outcome in one project when appropriate, with one issue per repository PR. +Batches coordinate separate issue/PR pairs; they do not combine issues into one +PR. Referencing a related issue is not claiming to deliver or close it. + +Keep review fixes on the same issue and PR. A necessary replacement PR retains +the superseded link and names the one current delivery PR; it does not create a +second simultaneous delivery for the issue. A new change after that delivery +has merged gets a new issue and PR. Research, design, or operational work with +no repository change uses an explicit non-PR result and verification; do not +create an empty PR merely to fit the rule. + +When existing work breaks this mapping, reconcile its scope and ownership +through `crw-plan` before new dispatch. Preserve active work, IDs, and history; +do not silently split, close, or reassign live issues. Editing these instructions +does not migrate existing work or alter the relay's runtime contracts. + ## Linear holds canonical documents Jun keeps product intent, specifications, plans, accepted decisions, and human-readable coordination records in Linear documents linked to the relevant project/issues. Use stable document IDs/URLs and available revision or updated-at evidence. Repositories remain authoritative for source, executable configuration, repository policy, and reproducible implementation evidence. diff --git a/skills/crw-run/SKILL.md b/skills/crw-run/SKILL.md index ceb644a..afa6e7c 100644 --- a/skills/crw-run/SKILL.md +++ b/skills/crw-run/SKILL.md @@ -147,8 +147,11 @@ Derive batches from both dependency edges and overlapping edit surfaces. Independent issue statuses do not prove independent code changes. Serialize shared schema, persistence, contract, or central UI changes when separation would cost more than it saves. A small project may have only two useful parallel tasks. -Prefer one Linear issue per reviewable delivery when its scope already fits. -Group tightly coupled issues only with an explicit issue-to-delivery mapping. +Apply the shared [issue-to-PR mapping](../crw-plan/references/integrations.md#issue-to-pr-mapping): +one implementation issue per PR, with one issue/PR pair per implementation +packet. A batch retains those separate pairs. If one issue needs several PRs, +or a proposed PR would deliver several issues, reconcile the plan through +`crw-plan` before new dispatch; preserve existing owners and active work. Keep the human-readable coordination record in the project's linked Linear document as part of the management assignment, without a separate recording request. diff --git a/skills/crw-run/references/task-packet.md b/skills/crw-run/references/task-packet.md index 727fbc1..88a6437 100644 --- a/skills/crw-run/references/task-packet.md +++ b/skills/crw-run/references/task-packet.md @@ -15,10 +15,11 @@ Use the real Linear identifier, a concise Korean description of the assigned result, and the agreed execution mode. Use `CXC Loop` when it is the effective workflow; otherwise use the actual mode, such as `구현` or `검증`. The suffix names the assignment, not proof that a loop started. Keep runtime verification separate. -Preserve an explicit user-supplied title. For a grouped delivery, use its primary -issue and retain the full issue mapping in the packet. If no primary issue exists, -use the verified issue identifiers together; if no issue is linked, use the known -project name instead of inventing an issue number. +Preserve an explicit user-supplied title. Each implementation packet names its +one issue and intended PR. A batch retains separate packets and issue/PR pairs; +do not use a primary issue to hide a combined delivery. If no issue is linked, +use the known project name instead of inventing an issue number and reconcile +the mapping through `crw-plan` before new implementation dispatch. The coordinator passes the title through the creation tool's supported title/name field and includes it in the packet. Prompt text alone does not prove the app title @@ -31,13 +32,16 @@ authorized work. Task identity and recovery always use stable IDs, not title mat ## Launch packet -This packet targets a verified independent implementation task for any issue -count or checkout arrangement. Follow [Independent implementation tasks](../SKILL.md#independent-implementation-tasks) +This packet targets a verified independent implementation task for one issue/PR +pair, or an explicitly non-PR result. Follow [Independent implementation tasks](../SKILL.md#independent-implementation-tasks) before dispatch. A packet's wording cannot turn an internal subagent into that task. Record the existing owner and creation/reuse authorization before sending. ```text Task: [bounded result and issue links] +Issue/PR mapping: [one implementation issue ID, target repository, and intended PR scope + or existing PR URL; related issues are dependencies, not additional deliveries. + For non-PR work, state the result and how it will be verified] Title: [issue ID · short task name · agreed workflow, following Child task titles] Workflow: [effective workflow per Default independent execution] @@ -171,6 +175,8 @@ retain private recovery receipts so an interrupted task can still be reconciled. needed to resume: - Coordinator task ID and fixed project/backlog link. +- Each implementation issue's one current PR, repository, and integration target; + retain superseded PR links as history. Record non-PR results separately. - Each task's scope, dependency edges, overlap decisions, and full baseline SHA. - Where a relay holds the assignment: relationship id, current generation, current revision, assignment state, and the synchronisation jobs still owed. From 1e95d0d81cbb712cac898cc4923640f2382ab9b7 Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 18:47:42 +0900 Subject: [PATCH 03/10] Keep advisory planning separate from authorized Linear writes --- README.md | 3 ++- skills/crw-plan/SKILL.md | 6 +++--- skills/crw-plan/agents/openai.yaml | 2 +- skills/crw-plan/references/integrations.md | 7 ++++--- 4 files changed, 10 insertions(+), 8 deletions(-) diff --git a/README.md b/README.md index 4ad514e..2dc1eae 100644 --- a/README.md +++ b/README.md @@ -225,9 +225,10 @@ 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-plan` completes a requested full plan from initiatives through projects, +`crw-plan` completes a request to create or update a full Linear plan from initiatives through projects, useful milestones, and executable issues in one operation. 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 diff --git a/skills/crw-plan/SKILL.md b/skills/crw-plan/SKILL.md index 9cda769..1e51bae 100644 --- a/skills/crw-plan/SKILL.md +++ b/skills/crw-plan/SKILL.md @@ -7,7 +7,7 @@ description: "Build or reconcile a complete Linear plan from initiatives through Build a usable product plan from what exists and what the user wants next. Linear holds the canonical product, planning, and decision documents; repositories hold implementation and reproducible evidence. -A full-plan request covers the requested goal through executable issues in one operation: initiative → projects → useful milestones → issues and dependencies. Reuse existing levels and create missing items within that request without requiring a separate invocation at each level. A scoped project/issue update stays scoped; do not invent an initiative or extra projects just to fill the hierarchy. Draft-only and read-only requests keep those limits. +A request to create or update a full Linear plan covers the requested goal through executable issues in one operation: initiative → projects → useful milestones → issues and dependencies. Reuse existing levels and create missing items within that request without requiring a separate invocation at each level. A scoped project/issue update stays scoped; do not invent an initiative or extra projects just to fill the hierarchy. Consultation, plan-only, draft-only, and read-only requests do not authorize Linear writes; invoking this skill implicitly does not supply write intent. ## Connect the workflow @@ -34,7 +34,7 @@ Identify the goal, product classification, and finishable outcome separately usi - **Milestone:** an observable result or coherent delivery boundary. Follow explicit user grouping, such as one milestone per character or module. - **Issue:** one implementation PR, with scope, acceptance criteria, canonical document links, dependencies, and meaningful verification. Apply the shared [issue-to-PR rule](references/integrations.md#issue-to-pr-mapping), including its non-PR work exception. -Use the smallest structure within the requested scope. A full-plan request includes the projects needed for that agreed outcome; issue count, repository count, or estimated size alone does not authorize extra projects. Planning or updating issues can reuse a project or keep standalone issues without creating missing upper levels. A project may have no initiative or contribute to several; reuse its ID instead of duplicating the project or its issues. Do not invent dates, owners, status transitions, or a team per product. Record unknowns plainly. +Use the smallest structure within the requested scope. An authorized full-plan write includes the projects needed for that agreed outcome; issue count, repository count, or estimated size alone does not authorize extra projects. Planning or updating issues can reuse a project or keep standalone issues without creating missing upper levels. A project may have no initiative or contribute to several; reuse its ID instead of duplicating the project or its issues. Do not invent dates, owners, status transitions, or a team per product. Record unknowns plainly. Apply product-family and related-repository labels under the shared operating model. Reuse existing labels and keep descriptions short. Additional label schemes need discussion with the user; leave views and default screens to the user unless requested. @@ -48,7 +48,7 @@ Make criteria observable: user behavior, data/state that must survive, and impor For an existing plan, compute a compact change set: reuse, create, update, or leave unresolved. Match stable IDs and semantic scope before titles. Re-running the same request should converge on the same items. -A full-plan request authorizes its scoped hierarchy and document/item writes, including needed projects; an explicit project request or already accepted proposal also authorizes that project. A narrower update does not authorize unrelated new projects. Prepare concrete changes, apply them within scope, and read back the resulting documents, items, and relations. Do not add a second approval step for routine authorized writes. A draft-only request stays a draft. Deletion, archival, issue closure, messages to others, or a material change to agreed scope need authorization covering that action. +A request to create, update, or apply the full plan in Linear authorizes its scoped hierarchy and document/item writes, including needed projects; an explicit project request or already accepted proposal also authorizes that project. Resolve write intent from the full conversation and existing authorization, not from the skill name or hierarchy depth. An advisory planning request remains a proposal until an apply/create/update request covers it. A narrower update does not authorize unrelated new projects. Prepare concrete changes, apply them within scope, and read back the resulting documents, items, and relations. Do not add a second approval step for routine authorized writes. A draft-only request stays a draft. Deletion, archival, issue closure, messages to others, or a material change to agreed scope need authorization covering that action. Preserve unrelated content, labels, history, and human edits. Refresh before updating if another actor may have changed an item. After an uncertain write, look up the existing result before retrying; report partial completion with actual IDs. If a project was created but its labels or relations failed, repair those fields on that ID. Do not repeat the project create. Resolve same-name candidates by IDs and semantic scope; ask only if the supplied target and current binding cannot distinguish them. diff --git a/skills/crw-plan/agents/openai.yaml b/skills/crw-plan/agents/openai.yaml index 1fb2318..056541c 100644 --- a/skills/crw-plan/agents/openai.yaml +++ b/skills/crw-plan/agents/openai.yaml @@ -1,6 +1,6 @@ interface: display_name: "CRW Plan" short_description: "목표부터 PR 하나에 대응하는 이슈까지 한 번에 계획" - default_prompt: "$crw-plan 이 제품의 코드·기존 기획·Linear 현황을 대조해서 이니셔티브부터 프로젝트, 필요한 마일스톤, 이슈와 의존성까지 한 번에 계획해줘. 기존 항목을 재사용하고 구현 이슈 하나를 PR 하나에 맞춰 나눠줘." + default_prompt: "$crw-plan 이 제품의 코드·기존 기획·Linear 현황을 대조해서 이니셔티브부터 프로젝트, 필요한 마일스톤, 이슈와 의존성까지 한 번에 계획하고 Linear에 작성·반영해줘. 기존 항목을 재사용하고 구현 이슈 하나를 PR 하나에 맞춰 나눠줘." policy: allow_implicit_invocation: true diff --git a/skills/crw-plan/references/integrations.md b/skills/crw-plan/references/integrations.md index 02c84ae..31a4d7d 100644 --- a/skills/crw-plan/references/integrations.md +++ b/skills/crw-plan/references/integrations.md @@ -31,9 +31,10 @@ Keep goals, product classification, and repository identity separate: or sum shared progress as separate output. Verify connector support and read back relations before claiming that a requested link exists. - Create a project when the user requests one, including an accepted proposal - or a full plan from goal through issues. A full-plan request covers the needed - hierarchy in its agreed scope; a narrow plan update, large backlog, or multiple - repositories alone does not authorize extra projects. Reuse existing IDs and meaningful scope. Name the + or a request to create/update a full Linear plan from goal through issues. + That write request covers the needed hierarchy in its agreed scope; a narrow plan update, large backlog, or multiple + repositories alone does not authorize extra projects. Consultation and + draft-only planning do not authorize Linear writes. Reuse existing IDs and meaningful scope. Name the result naturally without a fixed product prefix. Do not rename existing projects or migrate their relations merely by loading these instructions. - Product family is a single-choice project label group. Reuse the existing From 4e93dd8d23d370a9a044739051775b34ff909bbd Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 19:53:14 +0900 Subject: [PATCH 04/10] Split initiative definition from planning and bind orchestration scope --- README.md | 19 +++--- scripts/ci/tests/test_install.py | 2 +- skills/crw-define/SKILL.md | 72 ++++++++++++++++++++++ skills/crw-define/agents/openai.yaml | 6 ++ skills/crw-focus/SKILL.md | 5 +- skills/crw-next/SKILL.md | 3 +- skills/crw-plan/SKILL.md | 8 ++- skills/crw-plan/agents/openai.yaml | 4 +- skills/crw-plan/references/integrations.md | 23 ++++++- skills/crw-run/SKILL.md | 6 +- skills/crw-run/references/task-packet.md | 7 ++- 11 files changed, 134 insertions(+), 21 deletions(-) create mode 100644 skills/crw-define/SKILL.md create mode 100644 skills/crw-define/agents/openai.yaml diff --git a/README.md b/README.md index 2dc1eae..49f84b4 100644 --- a/README.md +++ b/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. @@ -225,8 +228,10 @@ 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-plan` completes a request to create or update a full Linear plan from initiatives through projects, -useful milestones, and executable issues in one operation. It reuses existing +`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 diff --git a/scripts/ci/tests/test_install.py b/scripts/ci/tests/test_install.py index 9e06235..716794b 100644 --- a/scripts/ci/tests/test_install.py +++ b/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] diff --git a/skills/crw-define/SKILL.md b/skills/crw-define/SKILL.md new file mode 100644 index 0000000..d69142e --- /dev/null +++ b/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. diff --git a/skills/crw-define/agents/openai.yaml b/skills/crw-define/agents/openai.yaml new file mode 100644 index 0000000..653545d --- /dev/null +++ b/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 diff --git a/skills/crw-focus/SKILL.md b/skills/crw-focus/SKILL.md index 9564815..00747bf 100644 --- a/skills/crw-focus/SKILL.md +++ b/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. @@ -92,6 +94,7 @@ 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) | diff --git a/skills/crw-next/SKILL.md b/skills/crw-next/SKILL.md index ac3d7dc..b3c33d4 100644 --- a/skills/crw-next/SKILL.md +++ b/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 diff --git a/skills/crw-plan/SKILL.md b/skills/crw-plan/SKILL.md index 1e51bae..a501658 100644 --- a/skills/crw-plan/SKILL.md +++ b/skills/crw-plan/SKILL.md @@ -1,13 +1,13 @@ --- name: crw-plan -description: "Build or reconcile a complete Linear plan from initiatives through projects, milestones, and one-PR implementation issues in one planning operation. Use for product planning, roadmap setup, and scoped plan updates; use crw-run for dispatch and crw-check for implementation drift. Formerly linear-plan." +description: "Decompose an agreed goal into Linear projects, useful milestones, and one-PR implementation issues in one planning operation. Use crw-define for initiative definition and intent exploration. Use for product planning, roadmap setup, and scoped plan updates; use crw-run for dispatch and crw-check for implementation drift. Formerly linear-plan." --- # CRW Plan Build a usable product plan from what exists and what the user wants next. Linear holds the canonical product, planning, and decision documents; repositories hold implementation and reproducible evidence. -A request to create or update a full Linear plan covers the requested goal through executable issues in one operation: initiative → projects → useful milestones → issues and dependencies. Reuse existing levels and create missing items within that request without requiring a separate invocation at each level. A scoped project/issue update stays scoped; do not invent an initiative or extra projects just to fill the hierarchy. Consultation, plan-only, draft-only, and read-only requests do not authorize Linear writes; invoking this skill implicitly does not supply write intent. +Use an agreed initiative definition as input, then cover its requested scope through executable issues in one operation: projects → useful milestones → issues and dependencies. If the goal itself needs definition, use [crw-define](../crw-define/SKILL.md); a request for both definition and planning chains the two without another invocation. An existing project or standalone issue can supply the agreed goal without an initiative. Reuse existing levels and create missing items within that request without requiring a separate invocation at each level. A scoped project/issue update stays scoped; do not invent an initiative or extra projects just to fill the hierarchy. Consultation, plan-only, draft-only, and read-only requests do not authorize Linear writes; invoking this skill implicitly does not supply write intent. ## Connect the workflow @@ -29,7 +29,7 @@ Identify the goal, product classification, and finishable outcome separately usi ## Shape the plan -- **Initiative:** a goal with an observable completion condition, to which projects contribute. It is not a permanent product container. +- **Initiative input:** the agreed goal, finish condition, scope and open decisions from `crw-define` or an existing accepted definition. Preserve its identity and link contributing projects; return material goal changes to definition within the request’s scope. - **Project:** a finishable outcome created when the user requests a project. Name the result naturally; do not require a product prefix. A product name can appear when it helps explain the result. - **Milestone:** an observable result or coherent delivery boundary. Follow explicit user grouping, such as one milestone per character or module. - **Issue:** one implementation PR, with scope, acceptance criteria, canonical document links, dependencies, and meaningful verification. Apply the shared [issue-to-PR rule](references/integrations.md#issue-to-pr-mapping), including its non-PR work exception. @@ -38,6 +38,8 @@ Use the smallest structure within the requested scope. An authorized full-plan w Apply product-family and related-repository labels under the shared operating model. Reuse existing labels and keep descriptions short. Additional label schemes need discussion with the user; leave views and default screens to the user unless requested. +Carry the definition’s accepted direction and unresolved decisions into the plan. Develop project-specific design detail when needed; Strategy/Scope/Structure/Skeleton/Surface are document lenses, never required initiative/project/milestone/issue levels. + Split by deliverable and shared contract, not file count. Derive order from dependency edges and overlapping edit surfaces. A schema/API contract may precede several apparently independent issues. Avoid dependency cycles and distinguish speculative backlog ideas from approved requirements. If an outcome needs several PRs, plan a separate implementation issue for each and connect prerequisites. Put the combined outcome in the project or milestone. Multiple repositories can belong to one project; code changes needing a PR in each repository require separate issues. Reading a dependency repository alone does not require another issue. diff --git a/skills/crw-plan/agents/openai.yaml b/skills/crw-plan/agents/openai.yaml index 056541c..3af5397 100644 --- a/skills/crw-plan/agents/openai.yaml +++ b/skills/crw-plan/agents/openai.yaml @@ -1,6 +1,6 @@ interface: display_name: "CRW Plan" - short_description: "목표부터 PR 하나에 대응하는 이슈까지 한 번에 계획" - default_prompt: "$crw-plan 이 제품의 코드·기존 기획·Linear 현황을 대조해서 이니셔티브부터 프로젝트, 필요한 마일스톤, 이슈와 의존성까지 한 번에 계획하고 Linear에 작성·반영해줘. 기존 항목을 재사용하고 구현 이슈 하나를 PR 하나에 맞춰 나눠줘." + short_description: "정의된 목표를 프로젝트와 PR 단위 이슈로 한 번에 구체화" + default_prompt: "$crw-plan 정의된 목표와 코드·기존 기획·Linear 현황을 대조해서 프로젝트, 필요한 마일스톤, 이슈와 의존성까지 한 번에 계획하고 Linear에 작성·반영해줘. 기존 항목을 재사용하고 구현 이슈 하나를 PR 하나에 맞춰 나눠줘." policy: allow_implicit_invocation: true diff --git a/skills/crw-plan/references/integrations.md b/skills/crw-plan/references/integrations.md index 31a4d7d..0b0418b 100644 --- a/skills/crw-plan/references/integrations.md +++ b/skills/crw-plan/references/integrations.md @@ -1,6 +1,6 @@ # Linear, CXC, and Paperthin integration -Shared guidance and Jun's workflow defaults for `crw-focus`, `crw-next`, `crw-plan`, `crw-run`, `crw-check`, and `crw-logic`. Read the operation-specific skill for scope. Apply these defaults within the user's assignment and current host permissions. +Shared guidance and Jun's workflow defaults for `crw-define`, `crw-focus`, `crw-next`, `crw-plan`, `crw-run`, `crw-check`, and `crw-logic`. Read the operation-specific skill for scope. Apply these defaults within the user's assignment and current host permissions. ## Resolve the project target @@ -79,6 +79,25 @@ through `crw-plan` before new dispatch. Preserve active work, IDs, and history; do not silently split, close, or reassign live issues. Editing these instructions does not migrate existing work or alter the relay's runtime contracts. +### Parent and child scope + +One parent Codex task orchestrates one Linear project: issue dependencies, +sequencing, parallel children, delivery verification and project integration. +One child Codex task orchestrates one Linear issue: implementation, tests, its +PR and review fixes, with internal helpers as needed. A ready batch means +several separate children, not several issues assigned to one child. Internal +helpers do not acquire project or issue ownership by receiving a subtask. + +Bind the parent by stable project ID and each child by its issue ID. An initiative +spanning projects is a planning scope, not a combined execution-parent binding. +Preserve other project coordinators and route cross-project prerequisites by +relation; do not absorb their issues. Standalone issues may remain projectless +and run in an issue-scoped task without inventing a project or a project parent. +An explicit current-task implementation request keeps that mode and issue scope; +it is not evidence that an independent child was created. Reuse the responsible +child for the same issue’s follow-ups, not for a new issue. Explicit project-focus +switches preserve old bindings and active ownership before establishing the new one. + ## Linear holds canonical documents Jun keeps product intent, specifications, plans, accepted decisions, and human-readable coordination records in Linear documents linked to the relevant project/issues. Use stable document IDs/URLs and available revision or updated-at evidence. Repositories remain authoritative for source, executable configuration, repository policy, and reproducible implementation evidence. @@ -103,7 +122,7 @@ Resolve installed paths from the current catalog. Read `cxc-dev` for development The effective Loop workflow loads `cxc-loop` and `cxc-pabcd` and follows their current goal, session, phase, and evidence requirements in the owning task. A plan or audit alone does not activate them. Delegated agents use the current CXC dispatch protocol and host-permitted tools/settings. Task creation, model configuration, and loop activation each need their own evidence. -Only one owner controls an operation. `crw-next` selects the next action, `crw-plan` defines work, `crw-run` coordinates execution, `crw-check` compares delivery with intent, and `crw-logic` investigates contradictions. A focused audit returns findings to its caller; it does not become another coordinator or recursively dispatch the caller. +Only one owner controls an operation. `crw-define` defines initiative intent, `crw-next` selects the next action, `crw-plan` decomposes agreed goals into projects and issues, `crw-run` coordinates execution, `crw-check` compares delivery with intent, and `crw-logic` investigates contradictions. A focused audit returns findings to its caller; it does not become another coordinator or recursively dispatch the caller. ### Completion follow-up in an existing execution workflow diff --git a/skills/crw-run/SKILL.md b/skills/crw-run/SKILL.md index afa6e7c..8c6cbdb 100644 --- a/skills/crw-run/SKILL.md +++ b/skills/crw-run/SKILL.md @@ -6,7 +6,9 @@ description: "Coordinate one Linear issue or a ready batch through independent c # CRW Run Use the selected Linear project as the planning source and keep this Codex task -as its coordinator. Each implementation task owns its +as its coordinator: one parent per project, one child per issue. Follow the shared +[parent and child scope](../crw-plan/references/integrations.md#parent-and-child-scope), +including standalone issues and explicit current-task work. Each child owns its checkout and execution; this task owns scope, dependencies, dispatch receipts, review, and the decision to release the next work. @@ -65,7 +67,7 @@ implementation worker. Read the coordination record and inspect the existing responsible task and any current writer before creating or assigning work. Verify its actual task/host ID, issue scope, current turn, checkout ownership, and execution settings. Reuse -that task for compatible follow-up work under the existing assignment. A busy +that task for compatible follow-up work on the same issue under the existing assignment. A busy task, an uncertain send, or an inaccessible record is not evidence that no writer exists; reconcile before retrying or considering a replacement. diff --git a/skills/crw-run/references/task-packet.md b/skills/crw-run/references/task-packet.md index 88a6437..aef1e7d 100644 --- a/skills/crw-run/references/task-packet.md +++ b/skills/crw-run/references/task-packet.md @@ -38,7 +38,9 @@ before dispatch. A packet's wording cannot turn an internal subagent into that task. Record the existing owner and creation/reuse authorization before sending. ```text -Task: [bounded result and issue links] +Task: [one issue ID and bounded result] +Parent: [one Linear project ID and verified coordinator task ID, or no project + for a standalone issue; initiative membership does not assign another project] Issue/PR mapping: [one implementation issue ID, target repository, and intended PR scope or existing PR URL; related issues are dependencies, not additional deliveries. For non-PR work, state the result and how it will be verified] @@ -79,7 +81,8 @@ Outcome and scope: Execution: - Read applicable project instructions and relevant source. -- You are the independent implementation task; the parent owns coordination, +- You orchestrate this one issue and its internal helpers. Do not absorb another + issue into this task or PR. The parent orchestrates one project and owns coordination, delivery validation, and authorized integration. Do not adopt the parent's CXC binding. - Where the assignment covers publication and you can push, own the delivery end to end: implement, test, commit, push, open the pull request, then triage, fix, reply From f3b28e897b2be778cb13020ec471cd67a142c551 Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 19:57:25 +0900 Subject: [PATCH 05/10] Keep standalone issue execution and recovery projectless --- skills/crw-run/SKILL.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/skills/crw-run/SKILL.md b/skills/crw-run/SKILL.md index 8c6cbdb..92e61c7 100644 --- a/skills/crw-run/SKILL.md +++ b/skills/crw-run/SKILL.md @@ -141,6 +141,13 @@ milestone percentage, issue status, merged PR, and deployed behavior can disagre record the discrepancy rather than silently treating them as equivalent. Missing connector access is a concrete limitation, not permission to invent issue details. +For a standalone issue, read that issue, its linked canonical documents and +blocking relations directly; project and milestone reads are inapplicable. Keep +its issue-scoped ownership and the existing management binding unchanged. Do not +create a project or call `crw-focus` to satisfy this baseline. If a transport +requires a project binding, use a permitted projectless execution path or report +that capability gap; never invent a project ID for a receipt. + Compare local and remote commit ancestry. Preserve local-only commits and dirty work. Record a full baseline commit for each task and decide how any prerequisite changes will reach it. Do not push shared baseline commits through every task. @@ -157,6 +164,10 @@ or a proposed PR would deliver several issues, reconcile the plan through Keep the human-readable coordination record in the project's linked Linear document as part of the management assignment, without a separate recording request. +For a standalone issue, use its existing linked coordination document or a compact +owned section in the issue within the authorized recording scope. Keep private +recovery receipts keyed by the issue and actual task IDs; no project record or +parent binding is required. Preserve unrelated issue content on each update. For explicit read-only scope or unavailable access, return the unsynced update and retain the task's private recovery receipt. Keep raw launch receipts and sensitive evidence in an appropriate private location; local From 8999311d189bb88a20dd0e1b13121532ce55412c Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 19:58:29 +0900 Subject: [PATCH 06/10] Include initiative definition in operational installation examples --- .../crw-run/references/operations/installation-plan.example.md | 2 +- skills/crw-run/references/operations/scenarios.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/skills/crw-run/references/operations/installation-plan.example.md b/skills/crw-run/references/operations/installation-plan.example.md index e299fde..d5fb5ff 100644 --- a/skills/crw-run/references/operations/installation-plan.example.md +++ b/skills/crw-run/references/operations/installation-plan.example.md @@ -11,7 +11,7 @@ assumptions force rather than a report about a machine. ## Situation -A host already has the six skills linked, an MCP server registered for the bridge, and a relay +A host already has the seven current skills (including `crw-define`) linked, an MCP server registered for the bridge, and a relay console script on `PATH`. The operator wants to confirm the combination is the verified one before starting a daemon for a new assignment. diff --git a/skills/crw-run/references/operations/scenarios.md b/skills/crw-run/references/operations/scenarios.md index a7f94cf..42edf06 100644 --- a/skills/crw-run/references/operations/scenarios.md +++ b/skills/crw-run/references/operations/scenarios.md @@ -8,7 +8,7 @@ one of them. ## S1 New installation on a host that has nothing -Observed: no relay console script, no MCP registration, no state directory, and the six skills not +Observed: no relay console script, no MCP registration, no state directory, and the seven current skills (including `crw-define`) not yet linked. Clauses: OPS-2.3 for the skill links, OPS-1.1 and OPS-1.3 for the combination, OPS-2.4 for the From ba82ec8aed20f2aac883e2fd0f9c83e462a7a144 Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 20:01:12 +0900 Subject: [PATCH 07/10] Carry projectless routing and non-PR evidence through execution --- skills/crw-run/SKILL.md | 27 +++++++++++++++++------- skills/crw-run/references/task-packet.md | 16 ++++++++++---- 2 files changed, 31 insertions(+), 12 deletions(-) diff --git a/skills/crw-run/SKILL.md b/skills/crw-run/SKILL.md index 92e61c7..be12f6e 100644 --- a/skills/crw-run/SKILL.md +++ b/skills/crw-run/SKILL.md @@ -148,7 +148,7 @@ create a project or call `crw-focus` to satisfy this baseline. If a transport requires a project binding, use a permitted projectless execution path or report that capability gap; never invent a project ID for a receipt. -Compare local and remote commit ancestry. Preserve local-only commits and dirty +For repository-changing work, compare local and remote commit ancestry. Preserve local-only commits and dirty work. Record a full baseline commit for each task and decide how any prerequisite changes will reach it. Do not push shared baseline commits through every task. @@ -167,7 +167,9 @@ document as part of the management assignment, without a separate recording requ For a standalone issue, use its existing linked coordination document or a compact owned section in the issue within the authorized recording scope. Keep private recovery receipts keyed by the issue and actual task IDs; no project record or -parent binding is required. Preserve unrelated issue content on each update. +project-level parent binding is required. If delegation or a relay is used, retain +the real coordinator task ID and routing identity; projectless does not mean +coordinatorless. Preserve unrelated issue content on each update. For explicit read-only scope or unavailable access, return the unsynced update and retain the task's private recovery receipt. Keep raw launch receipts and sensitive evidence in an appropriate private location; local @@ -178,9 +180,15 @@ Do not store project state or credentials inside this installed skill. Read [Task packet](references/task-packet.md) when preparing prompts. Each packet must stand alone in a fresh context and name its prerequisites, scope, baseline, -acceptance criteria, verification, and return artifacts. - -Every packet carries the current delivery contract, and where the template's older +acceptance criteria, verification, and return artifacts. For non-PR work without +repository changes, use the source document/data revision as the baseline and +return the verified result with its stable link or artifact digest. Omit Git +ancestry, worktree/branch/commit, push/PR/review/merge requirements and their OPS +clauses when they do not apply; do not create a repository or empty PR. Keep task +ownership, access, settings, criteria and recovery evidence. This non-PR path +applies throughout dispatch, observation and completion below. + +For repository-changing work, every packet carries the current delivery contract, and where the template's older delivery menu disagrees the contract wins. Name in the packet that the child owns its commits, push, the pull request and the review on that same pull request through to the applicable gates, and that the coordinator performs the merge while release and @@ -203,7 +211,8 @@ creation field, verify the actual title by task ID, and correct it on the same managed task when supported. The packet's title alone is not app-state evidence. Apply [Independent implementation tasks](#independent-implementation-tasks) even -when no new branch or worktree is needed. Reuse a checkout whose ownership is +when no new branch or worktree is needed. Non-PR work uses its permitted working +directory and artifact access without Git metadata. For code work, reuse a checkout whose ownership is verified for the responsible child; a coordinator may prepare it before handoff. Otherwise follow the project/user placement convention. Record the actual path, branch, and owner; do not create a second checkout just to prove task separation. @@ -285,7 +294,7 @@ Describe evidence separately: | Prompt dispatched | Accepted turn ID and matching user message | | Requested settings applied | Actual returned settings, not prompt text | | CXC Loop active | Child's active goal and current goalplan/FSM evidence | -| Work delivered | Completed turn plus actual commit/diff and check artifacts | +| Work delivered | Completed turn plus actual commit/diff and checks for code; verified result and source revision or artifact digest for non-PR work | | Pull request review handled by the child | Per-finding trail on that PR: the finding, the commit that addressed it, and the recheck | | Child reports normal completion | Required checks and reviews finished on the current head, blocking findings resolved; a missing mandatory review or check is blocked, not complete | | Verified for integration | Coordinator reviewed the exact revision and acceptance criteria | @@ -298,7 +307,9 @@ Describe evidence separately: Do not assume a worktree/task returned by a backend appears in the app's project. Check the Desktop listing separately when the user needs that association. -After delivery, identify the final commit or frozen hashed diff/file bundle, then +After non-PR delivery, verify the result against its source revision and acceptance +criteria, with no commit or merge requirement. After code delivery, identify the +final commit or frozen hashed diff/file bundle, then check the prerequisite ancestry, scoped diff, acceptance criteria, meaningful negative cases, and relevant user-visible behavior. Reuse valid proof for the same revision and criteria; run missing checks or checks invalidated by diff --git a/skills/crw-run/references/task-packet.md b/skills/crw-run/references/task-packet.md index aef1e7d..754f6bc 100644 --- a/skills/crw-run/references/task-packet.md +++ b/skills/crw-run/references/task-packet.md @@ -36,11 +36,15 @@ This packet targets a verified independent implementation task for one issue/PR pair, or an explicitly non-PR result. Follow [Independent implementation tasks](../SKILL.md#independent-implementation-tasks) before dispatch. A packet's wording cannot turn an internal subagent into that task. Record the existing owner and creation/reuse authorization before sending. +For non-PR work, remove inapplicable Git/worktree/PR/OPS delivery fields and steps +below. Carry the actual source revision, result link or artifact digest and +verification instead. Retain task identity, permissions and recovery information. ```text Task: [one issue ID and bounded result] Parent: [one Linear project ID and verified coordinator task ID, or no project - for a standalone issue; initiative membership does not assign another project] + for a standalone issue; retain the real coordinator task ID if delegated. + Initiative membership does not assign another project] Issue/PR mapping: [one implementation issue ID, target repository, and intended PR scope or existing PR URL; related issues are dependencies, not additional deliveries. For non-PR work, state the result and how it will be verified] @@ -172,15 +176,19 @@ Stop after this assigned result; do not auto-start another issue. ## Coordination record Use the project's linked canonical Linear coordination document as part of the -management assignment, following [Integrations](../../crw-plan/references/integrations.md#completion-follow-up-in-an-existing-execution-workflow). +management assignment. For a standalone issue, use its existing linked document +or an owned section in that issue and private issue/task recovery receipts. A +project binding is optional; the actual coordinator identity remains required +when delegating or routing relay delivery. Follow [Integrations](../../crw-plan/references/integrations.md#completion-follow-up-in-an-existing-execution-workflow). For explicit read-only scope or unavailable access, return an unsynced update; retain private recovery receipts so an interrupted task can still be reconciled. Record only what is needed to resume: -- Coordinator task ID and fixed project/backlog link. +- Coordinator task ID and fixed project or standalone issue link. - Each implementation issue's one current PR, repository, and integration target; retain superseded PR links as history. Record non-PR results separately. -- Each task's scope, dependency edges, overlap decisions, and full baseline SHA. +- Each task's scope, dependency edges, overlap decisions, and code baseline SHA + or non-PR source revision. - Where a relay holds the assignment: relationship id, current generation, current revision, assignment state, and the synchronisation jobs still owed. - Actual worktree/branch ownership and how local-only prerequisites are preserved. From 822bf82683484eef1061d1ffb658edd71572264b Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 20:05:40 +0900 Subject: [PATCH 08/10] Pin non-PR outputs and document standalone relay scope --- skills/crw-run/SKILL.md | 11 ++++++---- skills/crw-run/references/operations.md | 17 +++++++++----- skills/crw-run/references/relay.md | 6 ++++- skills/crw-run/references/task-packet.md | 28 ++++++++++++++++++++++-- 4 files changed, 50 insertions(+), 12 deletions(-) diff --git a/skills/crw-run/SKILL.md b/skills/crw-run/SKILL.md index be12f6e..db45702 100644 --- a/skills/crw-run/SKILL.md +++ b/skills/crw-run/SKILL.md @@ -182,7 +182,9 @@ Read [Task packet](references/task-packet.md) when preparing prompts. Each packe must stand alone in a fresh context and name its prerequisites, scope, baseline, acceptance criteria, verification, and return artifacts. For non-PR work without repository changes, use the source document/data revision as the baseline and -return the verified result with its stable link or artifact digest. Omit Git +return both that input baseline and the verified output identity: a stable result +link plus delivered revision/updated-at evidence, or a durable file locator plus +its digest. Snapshot the verified output when the source cannot recover old revisions. Omit Git ancestry, worktree/branch/commit, push/PR/review/merge requirements and their OPS clauses when they do not apply; do not create a repository or empty PR. Keep task ownership, access, settings, criteria and recovery evidence. This non-PR path @@ -294,7 +296,7 @@ Describe evidence separately: | Prompt dispatched | Accepted turn ID and matching user message | | Requested settings applied | Actual returned settings, not prompt text | | CXC Loop active | Child's active goal and current goalplan/FSM evidence | -| Work delivered | Completed turn plus actual commit/diff and checks for code; verified result and source revision or artifact digest for non-PR work | +| Work delivered | Completed turn plus actual commit/diff and checks for code; verified result with both input baseline and delivered output revision/digest for non-PR work | | Pull request review handled by the child | Per-finding trail on that PR: the finding, the commit that addressed it, and the recheck | | Child reports normal completion | Required checks and reviews finished on the current head, blocking findings resolved; a missing mandatory review or check is blocked, not complete | | Verified for integration | Coordinator reviewed the exact revision and acceptance criteria | @@ -307,8 +309,9 @@ Describe evidence separately: Do not assume a worktree/task returned by a backend appears in the app's project. Check the Desktop listing separately when the user needs that association. -After non-PR delivery, verify the result against its source revision and acceptance -criteria, with no commit or merge requirement. After code delivery, identify the +After non-PR delivery, verify the delivered output revision/digest against its +input baseline and acceptance criteria. A later edit at the same URL invalidates +reused verification; it is not the same output. No commit or merge is required. After code delivery, identify the final commit or frozen hashed diff/file bundle, then check the prerequisite ancestry, scoped diff, acceptance criteria, meaningful negative cases, and relevant user-visible behavior. Reuse valid proof diff --git a/skills/crw-run/references/operations.md b/skills/crw-run/references/operations.md index 5737cfc..b6284d9 100644 --- a/skills/crw-run/references/operations.md +++ b/skills/crw-run/references/operations.md @@ -591,15 +591,22 @@ and something can be merged that this field never covered, so neither is read fr Because one service carries assignments belonging to several parents, several repositories and several Linear projects, each assignment binds a full identity and routing uses nothing outside it. -The binding is the stable Linear workspace, project and issue identifiers; the host; the native -parent and child task identifiers; the execution generation; the repository, worktree, branch and -owner; the artifact roots; and the allowed recipients. +The binding is the stable Linear workspace and issue identifiers, plus the project identifier +when one exists; the host; the native coordinator and child task identifiers; the execution +generation; the repository, worktree and branch for code work; the owner, artifact roots and +allowed recipients. A standalone issue records no project, but delegated delivery still names +its actual coordinator. Non-PR work retains its permitted artifact roots and result identity +without inventing Git metadata. A displayed issue key is a label, not an identifier. It is unique inside one workspace and nowhere else, so two workspaces can both hold the same key, and a registration or a lookup carrying only that key can match the wrong assignment and refuse a legitimate second child as a duplicate. Every -registration therefore carries the stable workspace and project identifiers alongside it, and any -command that accepts a key is given enough identity to resolve it unambiguously. +registration therefore uses a globally stable issue identity and records its workspace and, +when present, project in the canonical scope reference. For a projectless issue, use a +workspace-qualified issue document or issue record as that reference. The bundled relay keeps +`--scope-ref` as descriptive context and routes on the exact `--issue` string and task IDs; +it does not validate Linear membership. Any command accepting a display key needs enough +identity to resolve it unambiguously before registration. See [relay registration](relay.md#register-the-assignment). ### OPS-7.2 Never route on a display name or a working directory diff --git a/skills/crw-run/references/relay.md b/skills/crw-run/references/relay.md index 6bdf1c8..8c1d1ac 100644 --- a/skills/crw-run/references/relay.md +++ b/skills/crw-run/references/relay.md @@ -108,7 +108,11 @@ the two task ids. A displayed key like `JUN-00` is unique inside one workspace a so one store serving two workspaces would conflate them and refuse the second legitimate child. Pass an identifier that is stable and unique across every workspace the store serves, and record the workspace or project it belongs to in `--scope-ref`, which the relationship keeps and reports. -Use that same string everywhere afterwards, including in the packet the child is given: a lookup +For a standalone issue, the scope reference names its workspace and stable issue/document +URL instead of a project. Project membership is absent, not fabricated; the real coordinator +and child IDs and both allowed recipients remain required. `--scope-ref` is descriptive +context, not a checked Linear project binding. +Use that same issue string everywhere afterwards, including in the packet the child is given: a lookup by a different spelling of the same issue finds nothing, and a child that follows it reports a perfectly good completion as UNEMITTED. diff --git a/skills/crw-run/references/task-packet.md b/skills/crw-run/references/task-packet.md index 754f6bc..c430cc8 100644 --- a/skills/crw-run/references/task-packet.md +++ b/skills/crw-run/references/task-packet.md @@ -37,8 +37,9 @@ pair, or an explicitly non-PR result. Follow [Independent implementation tasks]( before dispatch. A packet's wording cannot turn an internal subagent into that task. Record the existing owner and creation/reuse authorization before sending. For non-PR work, remove inapplicable Git/worktree/PR/OPS delivery fields and steps -below. Carry the actual source revision, result link or artifact digest and -verification instead. Retain task identity, permissions and recovery information. +below. Carry the input baseline and delivered output identity separately: stable +link plus output revision/updated-at evidence, or durable file locator plus digest. +Retain a verified snapshot when old linked revisions cannot be recovered. Retain task identity, permissions and recovery information. ```text Task: [one issue ID and bounded result] @@ -173,6 +174,29 @@ Return: Stop after this assigned result; do not auto-start another issue. ``` +## Non-PR packet + +Use this reduced shape for research, design or verification without repository changes. +Keep the shared authorization, task settings and recovery rules above; omit code-only +fields and OPS publication clauses. Relay-specific fields apply only when used. + +```text +Task: [one stable issue ID, bounded result, existing owner] +Coordinator: [actual task/host IDs if delegated; project ID only if one exists] +Scope: [accepted question/outcome, exclusions, dependencies and write authority] +Input baseline: [source IDs, revisions/updated-at evidence and known gaps] +Workflow/settings: [effective workflow, model/effort and actual permission profile] +Working location: [permitted cwd/artifact roots; no invented Git repository] +Verification: [observable acceptance criteria and independent evidence needed] +Return: [actual task ID, result link plus delivered revision/updated-at evidence, + or durable artifact locator plus digest; verified output snapshot if needed; + criterion evidence, unresolved limitations and next handoff] +Recovery: [issue-linked record or private receipt, dispatch/turn IDs and actual owner] +Relay, if used: [exact issue identity, scope reference, real coordinator/child IDs, + state directory and authorized recipients; current generation/receipt outcome] +Stop after this issue; do not start another issue or create an empty PR. +``` + ## Coordination record Use the project's linked canonical Linear coordination document as part of the From dc3ef47de628912a7c4498eeaf177b72a9df35a1 Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 20:10:23 +0900 Subject: [PATCH 09/10] Define non-Git workspace and relay artifact requirements --- skills/crw-plan/references/integrations.md | 2 ++ skills/crw-run/references/operations.md | 15 +++++++++++++++ skills/crw-run/references/relay.md | 5 +++++ skills/crw-run/references/task-packet.md | 7 +++++-- 4 files changed, 27 insertions(+), 2 deletions(-) diff --git a/skills/crw-plan/references/integrations.md b/skills/crw-plan/references/integrations.md index 0b0418b..6e75c8d 100644 --- a/skills/crw-plan/references/integrations.md +++ b/skills/crw-plan/references/integrations.md @@ -140,6 +140,8 @@ Unless the request chooses otherwise, an independent child task that `crw-run` c This default binds only `crw-run`'s independent children. The coordinator task, other products' global configuration, and CXC internal helper role routing keep their own settings. +Non-PR work without repository changes uses the working directory, source/result access and durable evidence defined in OPS-5.1 of the [Operations contract](../../crw-run/references/operations.md#ops-51-placement); it does not need Git or PR capability. + A new independent child is also created with enough capability to finish its delivery: file access for its checkout and evidence, git metadata access for its branch and commits, and the network access its push, pull request, and checks require. Broad local capability is the normal case. Worktrees, branches, scope, and recorded ownership separate concurrent work; the effective sandbox and permission profile define the enforced access boundary. The default covers a trusted implementation task inside the operating scope that creates it; an explicit narrower policy for the scope or the assignment governs over it, the effective profile is read back from the creation receipt, and the sandbox itself is never bypassed. Changing the default is a recorded decision rather than something a review performs. Apply the settings through the creation tool's real arguments and verify the returned profile. Tasks already running keep the settings they were created with; this is not authority to widen a live task or bypass a sandbox. See [Operations contract](../../crw-run/references/operations.md) for the owning rules. The coordinator applies the effective settings through the creation tool's real arguments, sends the bounded issue packet in the initial work prompt, and verifies the returned settings. When CXC Loop is the effective workflow, that prompt invokes the installed `cxc-loop` skill; an explicit non-Loop or no-goal alternative omits that invocation and names the agreed workflow instead. Loop mechanics belong to the child and its `cxc-loop`/`cxc-pabcd` skills; see [Prepare and dispatch](../../crw-run/SKILL.md#prepare-and-dispatch). diff --git a/skills/crw-run/references/operations.md b/skills/crw-run/references/operations.md index b6284d9..6ffa0e9 100644 --- a/skills/crw-run/references/operations.md +++ b/skills/crw-run/references/operations.md @@ -415,6 +415,21 @@ migration deliberately rather than as a side effect of an install. ### OPS-5.1 Placement +The checkout, branch, Git ownership and commit/PR capability rules in OPS-5 apply +to repository-changing implementation. Non-PR research, design and verification +use a permitted task working directory and durable private evidence root under +the applicable user/project placement convention. Record its creator, editing owner, +retention owner and cleanup authority; Git metadata ownership is inapplicable. +Do not create a repository, branch or PR to satisfy this contract. Grant the access +needed for the actual sources and result; explicit narrower scope and existing +permission limits still win, with returned settings verified under OPS-5.5. + +A non-PR assignment using the relay must freeze its delivered result and evidence +in at least one file under an authorized artifact root. Emit that artifact so the +ready receipt has a nonempty manifest; a document URL alone cannot be relayed. +For a mutable linked result, include its stable ID/link, delivered revision or +updated-at evidence and verified output snapshot. Keep the input baseline separate. + An implementation task works in `/home/jun/code-worktrees//`, where the project segment comes from the original repository's project name rather than the directory name of whatever checkout is currently open, and the task segment is short kebab-case. The branch is diff --git a/skills/crw-run/references/relay.md b/skills/crw-run/references/relay.md index 8c1d1ac..db51711 100644 --- a/skills/crw-run/references/relay.md +++ b/skills/crw-run/references/relay.md @@ -162,6 +162,11 @@ against no criteria. `criteria-show --relationship ` returns the set and it --outcome ready_for_review --turn-thread --turn-id \ --artifact /abs/path [--supersedes-revision ] +For non-PR work, `--artifact` is still required. Freeze the result and verification +evidence under an authorized artifact root, including any source and delivered +document identities. A linked document alone has no manifest and cannot produce +a `ready_for_review` receipt. Keep the snapshot private when its source is private. + Without `--socket` the receipt is STAGED: recorded and visible, deliverable only once an independent observation sees that turn end normally. Staged is real progress; it is not delivery and a report must not call it one. diff --git a/skills/crw-run/references/task-packet.md b/skills/crw-run/references/task-packet.md index c430cc8..44e1316 100644 --- a/skills/crw-run/references/task-packet.md +++ b/skills/crw-run/references/task-packet.md @@ -178,7 +178,9 @@ Stop after this assigned result; do not auto-start another issue. Use this reduced shape for research, design or verification without repository changes. Keep the shared authorization, task settings and recovery rules above; omit code-only -fields and OPS publication clauses. Relay-specific fields apply only when used. +fields and OPS publication clauses. Relay-specific fields apply only when used. When using the relay, freeze the result +and its verification evidence in a file under an authorized artifact root and emit +that file; link-only completion has no manifest and is not a valid ready receipt. ```text Task: [one stable issue ID, bounded result, existing owner] @@ -193,7 +195,8 @@ Return: [actual task ID, result link plus delivered revision/updated-at evidence criterion evidence, unresolved limitations and next handoff] Recovery: [issue-linked record or private receipt, dispatch/turn IDs and actual owner] Relay, if used: [exact issue identity, scope reference, real coordinator/child IDs, - state directory and authorized recipients; current generation/receipt outcome] + state directory and authorized recipients; frozen result/evidence artifact path + and digest under an authorized root; current generation/receipt outcome] Stop after this issue; do not start another issue or create an empty PR. ``` From 2c941643afd97608db4fea7ccaa7ba563ded4bae Mon Sep 17 00:00:00 2001 From: thisisjun786 <259586770+thisisjun786@users.noreply.github.com> Date: Wed, 16 Sep 2026 20:14:08 +0900 Subject: [PATCH 10/10] Record non-PR launch inputs without Git metadata --- skills/crw-run/SKILL.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/skills/crw-run/SKILL.md b/skills/crw-run/SKILL.md index db45702..f13843a 100644 --- a/skills/crw-run/SKILL.md +++ b/skills/crw-run/SKILL.md @@ -249,8 +249,10 @@ model” is not a configuration override. A catalog entry is not proof of the mo that served the request. Settle a setting the creation path cannot apply before creating the task rather than downgrading it. -Record request ID, task ID, host ID when supplied, turn ID, checkout, full -baseline SHA, requested/actual title and settings, and launch outcome. Do not put raw +Record request ID, task ID, host ID when supplied, turn ID, requested/actual title +and settings, and launch outcome. For code work include the checkout and full Git +baseline SHA. For non-PR work include the permitted working location and input +source revision; add the delivered output identity when the result exists. Do not put raw credentials or full private prompts in public project records. Where a relay holds the assignment, register the relationship with its authorized