@moreih29/nexus-core 0.17.0 → 0.18.2

package/assets/skills/nx-plan/body.md

@@ -1,361 +0,0 @@
----
-name: nx-plan
-description: Structured multi-perspective analysis to decompose issues, align on
-  decisions, and produce an enriched plan before execution. Plan only — does not
-  execute.
-summary: "Structured planning — subagent-based analysis, deliberate decisions, produce execution plan"
-triggers:
-  - plan
-harness_docs_refs:
-  - resume_invocation
-id: nx-plan
----
-
-## Role
-
-Facilitate structured multi-perspective analysis using subagents to decompose issues, deliberate on options, and align on decisions. Lead acts as synthesizer AND active participant — orchestrates subagent research/analysis AND contributes its own position. Does not execute — planning only. Transition to execution is the user's decision.
-
-## Constraints
-
-- NEVER execute — this skill is planning only; transition to execution is the user's decision
-- NEVER call `nx_plan_start` before research is complete (research_summary is required)
-- NEVER present multiple issues at once — one issue at a time only
-- NEVER ask groundless questions — always research code/knowledge/decisions first
-- NEVER use the harness's team creation primitive. Inter-agent messaging for resume is permitted ONLY for resuming completed subagents whose `resume_tier` is `persistent` or `bounded`, and ONLY within the constraints of the Resume Policy section below. Direct inter-agent communication to running teammates remains forbidden in plan sessions.
-- MUST record all decisions with `[d]` tag so they are not scattered across turns
-- MUST call `nx_plan_decide` when recording `[d]`
-- MUST check for existing plan.json before starting a new session
-- `[d]` without an active plan.json is BLOCKED — "[d]는 plan 세션 안에서만 유효합니다."
-- MUST present a comparison table before asking for a decision — never present options as prose only. Format:
-
-```
-| | A: {title} | B: {title} |
-|---|---|---|
-| Pros | ... | ... |
-| Cons | ... | ... |
-| Pick | | **(Recommended)** |
-```
-
-## Guidelines
-
-## Trigger
-
-- Explicit tag: `[plan]` — continue existing session if plan.json exists, otherwise start new
-- Additional analysis needed mid-session: spawn HOW subagents independently via the harness's subagent spawn primitive
-- Continuing conversation without a tag → continue existing session
-
----
-
-## Auto Mode (`[plan:auto]`)
-
-When triggered with `[plan:auto]` or invoked via `{{skill_activation skill=nx-plan mode=auto}}`, run the full planning process **without user interaction**:
-
-1. **Research** — spawn researcher+Explore subagents (same as interactive)
-2. **Issue derivation** — Lead identifies issues from research
-3. **Auto-decide** — for each issue, Lead selects the recommended option without presenting choices. Each `nx_plan_decide(summary)` MUST include: selected approach + reason, AND rejected alternatives + why they were dismissed. No comparison table needed, but internal deliberation is mandatory.
-4. **Decision briefing** — output a concise summary of all decisions before generating tasks:
-   ```
-   [auto-plan complete] N issues, N decisions:
-   - #1: {selected} ({rejected alternative} — reason)
-   - #2: ...
-   ```
-   Do not wait for user response — proceed immediately to task generation.
-5. **Plan document** — generate tasks.json following Step 7 rules (including HOW-assisted decomposition if `how_agents` present in plan.json issues). Apply owner table and verification auto-pairing.
-
-Key differences from interactive mode:
-- No user prompts or comparison tables — Lead decides autonomously
-- No dynamic agenda proposals — Lead handles all derived issues internally
-- Output: tasks.json ready for `[run]` execution
-
-**Scope by invocation context:**
-- `[plan:auto]` standalone → auto-plan + briefing + tasks.json generation. Stops here.
-- Invoked by `[run]` (tasks.json absent) → auto-plan + briefing + tasks.json generation + seamless execution transition. No pause between plan and run.
-
-This mode is invoked internally by `[run]` when no tasks.json exists, or explicitly by the user with `[plan:auto]`.
-
----
-
-## Procedure (Interactive Mode)
-
-### Step 1: Intent Discovery
-
-Determine planning depth and identify which HOW subagents to delegate analysis to, based on Progressive Depth.
-
-| Level | Signal | Exploration Scope |
-|-------|--------|-------------------|
-| **Specific** | File path, function name, error message, or concrete target named | Focused on the relevant file/module |
-| **Direction-setting** | Open-ended question, "it would be nice if ~", choice needed among approaches | Related area + external case research |
-| **Abstract** | "I don't know how to approach this", goal itself unclear, fundamental direction | Full codebase + external research + comparable project comparison |
-
-- Specific request → confirm intent with 1–2 questions, derive issues immediately
-- Direction-setting → use hypothesis-based questions to understand intent
-- Abstract/fundamental → actively interview to uncover root goals the user hasn't clarified
-
-**HOW subagent selection rule:**
-- User explicitly names agents → use as-is, propose additions if gaps detected
-- User does not name agents → Lead proposes based on issue scope, confirm with user
-- Additional HOW subagents can be spawned at any time during analysis (Lead's or user's discretion)
-
-### Step 2: Research
-
-Understand code, core knowledge, and prior decisions before forming a planning agenda.
-
-**Start by checking existing knowledge**: before spawning any subagent, use file pattern search and file reading to scan `.nexus/memory/` and `.nexus/context/` for relevant memos and context files, and use `nx_history_search` to check for prior decisions on this topic. If the needed information is already there, use it directly and skip or narrow the subagent spawn. Only spawn subagents to fill gaps not covered by existing knowledge.
-
-**Approach selection:**
-
-| Scenario | Approach |
-|----------|----------|
-| Codebase orientation | `{{subagent_spawn target_role=explore prompt="<file/code search task>"}}` for codebase exploration |
-| External research needed | `{{subagent_spawn target_role=researcher prompt="<research question>"}}` for web search |
-| Both codebase and external | Spawn Explore + Researcher in parallel |
-
-- NEVER call `nx_plan_start` before research is complete.
-- `research_summary` parameter in `nx_plan_start` is required — forces research completion before session creation.
-- Researcher subagents are spawned via the harness's subagent spawn primitive and return findings to Lead. They do not join the plan session.
-
-**Existing session (plan.json present):**
-- Check current state with `nx_plan_status`.
-- If new topic or additional research needed → spawn researcher subagent accordingly.
-- Do not proceed to next issue before research is complete.
-
-### Step 3: Session Setup
-
-Register the planning session.
-
-1. **`nx_plan_start(topic, issues, research_summary)`** — register plan in plan.json; auto-archives any existing plan.json.
-2. Show the issue list to the user and confirm before proceeding.
-
-### Step 4: Analysis
-
-**Always proceed one issue at a time.** Never present multiple issues simultaneously.
-
-For each issue:
-
-1. **Current State Analysis** — Lead summarizes the current state and problems, drawing on research.
-2. **Subagent Analysis** — for complex issues, spawn HOW subagents (architect, strategist, etc.) in parallel via the harness's subagent spawn primitive. Each subagent independently analyzes the issue and returns findings.
-   - **Domain-Agent mapping** — match issue keywords to recommended HOW subagents:
-
-   | Domain keywords | Recommended HOW |
-   |----------------|-----------------|
-   | UI, UX, 디자인, 인터페이스, 사용자 경험, 레이아웃 | Designer |
-   | 아키텍처, 시스템 설계, 성능, 구조 변경, API, 스키마 | Architect |
-   | 비즈니스, 시장, 전략, 포지셔닝, 경쟁, 수익 | Strategist |
-   | 연구 방법론, 근거 평가, 문헌, 실험 설계 | Postdoc |
-
-   - **Opt-out default**: if the issue matches a domain in the mapping, spawning is the default. Multiple matches → multiple spawns. To skip, state "{Agent} not needed — reason: ..." in the analysis text.
-   - **No mapping match**: if no domain matches, Lead analyzes directly. When uncertain, spawn — the cost of an unnecessary spawn is lower than the cost of a shallow analysis.
-   - **Record HOW findings**: after HOW subagents return, include their agent names and key findings when recording the decision via `nx_plan_decide(how_agents=[...], how_summary={...})`. This data is stored in plan.json for Step 7 task generation.
-3. **Present Options** — after synthesis, Lead presents a comparison:
-
-```
-| Item | A: {title} | B: {title} | C: {title} |
-|------|-----------|-----------|-----------|
-| Pros | ... | ... | ... |
-| Cons | ... | ... | ... |
-| Trade-offs | ... | ... | ... |
-| Best for | ... | ... | ... |
-
-**Recommendation: {X} ({title})**
-
-- Option A falls short because {reason}
-- Option B falls short because {reason}
-- Option X overcomes {A/B limitations} → {core benefit}
-```
-
-4. **Await user response** — receive free-form responses. Users may combine options, push back, or ask follow-up questions.
-
-## Resume Policy
-
-When the harness's resume mechanism is unavailable, ALL resume paths are disabled — force fresh spawn. Otherwise:
-
-| resume_tier | Same-issue default | Cross-issue | Disqualifiers |
-|---|---|---|---|
-| persistent | resume by default | Lead opt-in only | counter-evidence / reversal / re-review issue → fresh |
-| bounded | conditional (same artifact only) | forbidden | loop 3x / feedback cycle (REVISION_REQUIRED) → fresh |
-| ephemeral | forbidden | forbidden | N/A (always fresh) |
-
-Before resuming a `bounded` agent: include a "re-read target files before any modification" instruction in the prompt. Bounded resume without re-read is BLOCKED.
-
-`resume_tier` is read from each agent's frontmatter (`agents/*.md`). If absent, treat as `ephemeral` (most conservative).
-
-### Step 5: Record Decision
-
-When the user decides, record with the `[d]` tag.
-
-- gate.ts detects `[d]` and routes to `nx_plan_decide`.
-- `nx_plan_decide(issue_id, summary)` — marks issue as `decided`, writes `decision` inline in plan.json.
-- Decisions are NOT written to decisions.json — plan.json is the single source of truth.
-- `[d]` without plan.json is blocked.
-- **Progress anchoring**: immediately after recording, output one line: "Issue #N decided (M of K complete). Next: #X — {title}." This keeps the user oriented in multi-issue sessions.
-
-**Immediately after each decision**, Lead checks: "Does this decision create follow-up questions or new issues?" If yes, propose adding via `nx_plan_update(action='add')` before moving to the next issue.
-
-**Decision reversal**: if the user wants to reconsider a prior decision ("아까 결정 다시 생각해보자", "issue #N 번복"), Lead calls `nx_plan_update(action='reopen', issue_id=N)` to reopen the issue and returns to Step 4 analysis for that issue.
-
-### Step 6: Dynamic Agenda + Wrap-up
-
-After each decision, Lead automatically checks for derived issues.
-
-- **Dynamic agenda proposal**: after a decision is recorded, Lead examines whether the decision implies follow-on questions or unresolved sub-issues. If found, propose adding them with `nx_plan_update(action='add', ...)` and confirm with the user before adding.
-- Pending issues remain → naturally transition to the next issue.
-- All issues decided → **Gap check**: compare original question/topic against the issue list.
-  - Gap found → register additional issues with `nx_plan_update(action='add', ...)`, return to Step 4.
-  - No gap → signal planning complete.
-- Wrap-up: confirm all analysis threads have reported conclusions to Lead.
-- Proceed to Step 7 automatically — do not ask whether to generate the plan document.
-
-### Step 7: Plan Document Generation
-
-All issues decided → generate the plan document (tasks.json) immediately:
-
-1. **Collect decisions** — gather all `decided` issues from plan.json
-2. **Derive tasks** — decompose decisions into concrete, actionable tasks
-
-   **HOW-assisted task decomposition**: check plan.json issues for `how_agents` field.
-   - If HOW agents participated in analysis → re-spawn those HOWs with the decided approach + their prior `how_summary` as context. Ask them to propose task decomposition and owner assignment for their domain.
-   - If no HOW agents participated → Lead decomposes alone using the owner table and auto-pairing rules above.
-   - This ensures task generation depth is proportional to plan analysis depth.
-
-3. **Enrich each task** with:
-   - `approach` — implementation strategy derived from the decision rationale
-   - `acceptance` — definition of done, verifiable criteria
-   - `risk` — known risks or caveats from the analysis
-   - `deps` — task dependencies based on execution order
-   - `owner` — assign based on delegation analysis:
-
-   | Work type | owner | Criteria |
-   |-----------|-------|----------|
-   | Single file, small change | **lead** | Subagent overhead > task effort |
-   | Code implementation (.ts, .js, .py, etc.) | **engineer** | Source code creation/modification |
-   | Documentation/content (.md, non-code) | **writer** | .md files, README, docs, non-code content |
-   | Web research / external investigation | **researcher** | External information gathering needed |
-   | Design analysis / review | **architect** etc. HOW | Technical trade-off judgment |
-   | Sequential edits to same file | **lead** | Parallel subagents risk conflict |
-
-   **Primary metric — artifact-coherence**: a well-scoped task targets a single artifact or a tightly coupled artifact cluster and makes a single coherent change. A change is coherent when (a) it can be described in one sentence, (b) reverting it leaves all other artifacts consistent, and (c) its acceptance can be verified by inspecting its outputs alone.
-
-   **Verification auto-pairing (conditional)** — create a CHECK task only when the DO task's acceptance includes the appropriate verification trigger:
-   - `owner: "engineer"` + acceptance contains a runtime-behavior criterion → pair a **tester** task.
-   - `owner: "writer"` + acceptance contains a verifiable deliverable criterion → pair a **reviewer** task.
-   - Exclusions: pure refactor (behavior-preserving), type-only changes, docs-adjacent tasks (.md or frontmatter-only, classified under `docs_only` entries in `vocabulary/task-exceptions.yml`), and researcher tasks. Researcher tasks never receive an auto-paired CHECK — research outputs feed Lead or HOW agents directly, not tester or reviewer.
-   - Paired verification tasks are linked via `deps` to the original task.
-
-   **Exception catalog**: task decomposition exceptions are defined in `vocabulary/task-exceptions.yml` (`docs_only.coherent`, `docs_only.independent`, `same_file_bundle`, `generated_artifacts`). When an exception applies to a task, record its id in the task's `context` field so downstream tooling can trace the classification.
-
-   **Dedup Layer 1 (plan-time static merge)**: before finalizing the task list, scan draft tasks for overlapping target_files. Overlapping tasks are merged into a single owner task via the `same_file_bundle` exception from `vocabulary/task-exceptions.yml` to prevent parallel write conflicts during execution.
-
-   **DO/CHECK decomposition principle**: DO agents (engineer, writer, researcher) and CHECK agents (tester, reviewer) accumulate less per-task context than HOW agents. When a task involves multiple independent artifacts, decompose across multiple parallel DO/CHECK subagents rather than bundling. HOW agents benefit from consolidated context and should generally remain as single sessions. Parallel decomposition is worthwhile when there are at least three independent artifacts; below that, bundling under one owner is preferable to avoid parallelization overhead.
-
-   **HOW decomposition rule**: split HOW analysis across multiple subagents only when the issue crosses different rows of the domain-agent mapping table (architect vs designer vs strategist vs postdoc). Sub-concerns within a single domain row belong in one HOW session.
-
-4. **Populate tasks.json** via `nx_task_add`:
-   - Set `goal` from the plan topic
-   - Set `decisions` from plan.json decided summaries
-   - Call `nx_task_add(plan_issue=N, approach, acceptance, risk, owner)` for each task
-   - If any decisions involve design or architecture changes, include a task (owner: `writer` or `lead`) to update the relevant files in `.nexus/context/` to reflect those decisions
-5. **Present plan document** — show the user the generated tasks.json summary for review
-6. **Present transition**: "Proceed with `[run]` to execute."
-
-**Incremental mode**: if tasks.json already exists (e.g., after adding follow-up issues), only add tasks for new decisions. Check `plan_issue` field to avoid duplicating tasks for already-covered issues.
-
----
-
-## plan → run Transition
-
-tasks.json is already generated in Step 7. Plan's role ends here.
-Proceed with `[run]` to execute.
-
----
-
-## Principles
-
-1. **Active intent discovery** — actively uncover what the user hasn't clarified. Use interviewing to surface the root goal behind the words.
-2. **Lead as synthesizer AND participant** — Lead does not merely relay subagent findings. Lead forms its own position, makes recommendations, and pushes back with evidence. Not a yes-man.
-3. **Exploration first + proactive expansion** — research code/knowledge/external sources before planning starts. Never ask groundless questions.
-4. **Hypothesis-based questions** — instead of empty questions, form hypotheses grounded in research and confirm with the user.
-5. **Progressive Depth** — automatically adjust planning depth and HOW subagent composition based on request complexity.
-6. **One at a time** — never present multiple issues at once. Reduce the user's cognitive load.
-7. **Options must include pros/cons/trade-offs/recommendation** — when recommending, explain why other options fall short.
-8. **Objective pushback** — even when the user arrives with strong conviction, Lead MUST independently analyze all viable options and present trade-offs the user may not have considered. The comparison table exists to surface what the user doesn't know, not to confirm what they already believe. Counter with evidence when better alternatives exist.
-9. **Prose conversation by default** — free-form user responses (combinations, pushback, follow-up questions) are the core of planning quality.
-10. **Dynamic agenda** — decisions create new questions. Lead proactively surfaces derived issues rather than waiting for the user to notice gaps.
-
----
-
-## State Management
-
-### plan.json
-
-`.nexus/state/plan.json` — managed via MCP tools.
-
-```json
-{
-  "id": 1,
-  "topic": "topic name",
-  "issues": [
-    {
-      "id": 1,
-      "title": "issue title",
-      "status": "pending"
-    },
-    {
-      "id": 2,
-      "title": "issue title",
-      "status": "decided",
-      "decision": "decision summary",
-      "how_agents": ["architect", "designer"],
-      "how_summary": {
-        "architect": "key findings...",
-        "designer": "key findings..."
-      }
-    }
-  ],
-  "research_summary": "...",
-  "created_at": "2026-01-01T00:00:00Z"
-}
-```
-
-- **Create**: `nx_plan_start(topic, issues, research_summary)` — called in Step 3; auto-archives any existing plan.json
-- **Status**: `nx_plan_status()` — check current issue state + decisions
-- **Update**: `nx_plan_update(action, ...)` — add/remove/modify/reopen issues
-- **Decide**: `nx_plan_decide(issue_id, summary)` — marks issue as `decided`, writes decision inline
-- **File presence = session in progress**
-
-### Topic Switching
-
-- `[plan]` → continue existing plan.json if present; start new session if not
-- Continue conversation without tag → continue existing session
-- New `nx_plan_start` call → auto-archives current plan.json before creating new one
-
-### Session Abort
-
-To abort a session, archive current state via `nx_task_close`. Incomplete issues/tasks are recorded in history.json for future reference.
-
----
-
-## Self-Reinforcing Loop
-
-```
-[plan] start → check/continue existing plan.json (start new if none)
-  ↓
-Intent discovery → research (parallel subagents) → nx_plan_start (register issues)
-  ↓
-Per-issue: HOW subagent analysis (parallel, independent) → Lead synthesis
-  → options comparison → [d] → nx_plan_decide
-  → dynamic agenda check → propose derived issues if found
-  ↓
-Next issue → ... → gap check → planning complete
-  ↓
-Proceed with `[run]` to execute.
-  ↓
-[run]: execution skill handles the full pipeline
-  ↓
-All done → nx_task_close (handled by run skill)
-```
-
-gate.ts detects `[d]` and routes to `nx_plan_decide` if plan.json exists; blocks otherwise.
-
-## Deactivation
-
-When transitioning to `[run]`, Plan's role ends. Execution is handled by the run skill.

package/assets/skills/nx-run/body.ko.md

@@ -1,161 +0,0 @@
----
-name: nx-run
-description: Execution — user-directed agent composition.
-summary: "Execution — user-directed agent composition"
-triggers:
-  - run
-harness_docs_refs:
-  - resume_invocation
-id: nx-run
----
-
-## Role
-
-사용자가 [run] 태그를 호출할 때 Lead가 따르는 실행 규범이다. 사용자 지시에 따라 서브에이전트를 동적으로 조합하고, intake부터 완료까지 전체 실행 파이프라인을 구동한다.
-
-## Constraints
-
-- NEVER modify files via shell commands (sed, echo redirection, heredoc, tee, etc.) — harness의 전용 파일 편집 primitive를 항상 사용한다 (gate 강제)
-- NEVER terminate while pending tasks remain (Gate Stop nonstop)
-- NEVER spawn a new branch without checking for main/master first
-- MUST check tasks.json before executing — 없으면 먼저 plan을 생성한다
-- MUST spawn subagents per-task based on owner field — 태스크 수 ≥ 2 또는 대상 파일 ≥ 2인 경우 Lead 단독으로 처리하지 않는다
-- MUST NOT spawn parallel Engineers if their target files overlap — 겹치면 직렬화한다
-- MUST call nx_task_close before completing the cycle — plan+tasks를 history.json에 아카이브한다
-
-## Guidelines
-
-## Flow
-
-### Step 1: Intake (Lead)
-
-- **사용자가 에이전트/방향을 지정** → 지시를 그대로 따른다.
-- **[run] only (방향 없음)** → 진행 전 사용자에게 방향을 확인한다.
-- 사용자가 SCOPE와 구성을 결정한다. 명시되지 않은 부분은 Lead가 채운다.
-- **Branch Guard**: main/master에 있으면 진행 전에 태스크 유형에 맞는 브랜치를 생성한다 (prefix: `feat/`, `fix/`, `chore/`, `research/` 등 — Lead의 판단). 사용자 확인 없이 자동 생성한다.
-- `tasks.json` 확인:
-  - **존재** → 읽고 Step 2로 진행한다.
-  - **없음** → `{{skill_activation skill=nx-plan mode=auto}}`를 자동 호출하여 tasks.json을 생성한다. 묻지 않는다 — `[run]`은 실행 의도를 내포한다. plan 생성 후 Step 2로 진행한다.
-- tasks.json이 존재하면 `nx_plan_status`로 기존 결정을 확인한다.
-
-### Step 1.5: TUI Progress
-
-시각적 진행 추적(Ctrl+T)을 위해 태스크를 등록한다:
-
-- **태스크 ≤ 10개**: 태스크당 `{{task_register label="<per-task label>" state=pending}}`
-- **태스크 > 10개**: `plan_issue`로 그룹화하여 그룹당 `{{task_register label="<group label>" state=pending}}`
-- 실행이 진행됨에 따라 `{{task_register label="<label>" state=in_progress}}` / `{{task_register label="<label>" state=completed}}`로 등록 항목을 업데이트한다
-- **건너뛰는 경우**: non-TTY 환경 (VSCode, headless)
-- **Known issue**: auto-compact 중 TUI가 멈출 수 있다 (#27919) — 디스크의 태스크 데이터는 정확하게 유지된다
-
-### Step 2: Execute
-
-- **tasks.json을 사용자에게 제시한다** — owner, deps, approach 요약과 함께 태스크 목록을 보여준다. 확인을 묻지 않고 즉시 진행한다.
-- `owner` 필드에 따라 태스크를 실행한다:
-  - `owner: "lead"` → Lead가 직접 처리한다
-  - `owner: "engineer"`, `"researcher"`, `"writer"` 등 → owner 역할에 맞는 서브에이전트를 스폰한다
-  - `owner: "architect"`, `"tester"`, `"reviewer"` 등 → 해당 HOW/CHECK 서브에이전트를 스폰한다
-- 각 서브에이전트에게 태스크의 `context`, `approach`, `acceptance`를 프롬프트로 전달한다.
-- **병렬 실행**: 독립적인 태스크(대상 파일이 겹치지 않고, deps 없음)는 병렬로 스폰할 수 있다. 대상 파일이 공유되는 태스크는 직렬화해야 한다.
-- **SubagentStop 에스컬레이션 체인**: 서브에이전트가 미완성 상태로 종료되면:
-  1. **Do/Check 실패** → 해당 HOW 에이전트를 스폰하여 (예: Engineer 실패 → Architect) 실패를 진단하고, 접근법을 검토하며, 조정안을 제안하게 한다.
-  2. **재위임** → HOW의 조정된 접근법을 적용하여 새 Do/Check 에이전트에게 재위임한다.
-  3. **HOW도 실패** → Lead가 진단 내용과 함께 사용자에게 실패를 보고하고 방향을 요청한다.
-  - 최대: 태스크당 HOW 진단 1회 + 재위임 1회. 이후에는 사용자에게 에스컬레이션한다.
-  - 관련 HOW 매핑: Engineer→Architect, Writer→Strategist, Researcher→Postdoc, Tester→Architect.
-
-### Resume Dispatch Rule
-
-각 태스크에 대해 Lead는 `owner`의 `resume_tier`에 따라 새로 스폰할지 resume할지 결정한다:
-
-1. `agents/{owner}.md` frontmatter에서 `resume_tier`를 조회한다 (없으면 → `ephemeral`로 처리).
-2. `ephemeral`이면 → 새로 스폰한다. 종료.
-3. `bounded`이면 → tasks.json 이력을 확인한다: 동일 `owner`가 겹치는 대상 파일에 이전에 작업했는가? 그렇고 다른 에이전트의 개입 편집이 없으면 → resume 후보. 아니면 새로 스폰. resume 프롬프트에는 항상 "수정 전 대상 파일을 다시 읽을 것" 지시를 포함한다.
-4. `persistent`이면 → 이번 실행에서 동일 에이전트가 이전에 작업했으면 기본적으로 resume한다. 크로스 태스크 재사용 허용.
-5. resume 시도 전 harness의 resume 메커니즘이 사용 가능한지 확인한다. 사용 불가이면 오류를 발생시키지 않고 조용히 새로 스폰으로 폴백한다.
-
-### Step 3: Verify (Lead + Check subagents)
-
-**Lead**: 빌드 + E2E 통과/실패 여부를 확인한다.
-
-**Tester — acceptance criteria 검증**:
-- Tester는 tasks.json에서 완료된 각 태스크의 `acceptance` 필드를 읽는다
-- 각 기준을 PASS/FAIL로 판정한다
-- 태스크를 완료로 간주하려면 모든 기준을 통과해야 한다
-- 기준 하나라도 실패 → Step 2 재작업 (태스크 재개)
-- Tester 스폰 조건 (하나라도 해당되면):
-  - tasks.json에 `acceptance` 필드가 있는 태스크가 1개 이상
-  - 변경된 파일이 3개 이상
-  - 기존 테스트 파일이 수정됨
-  - 외부 API/DB 접근 코드가 변경됨
-  - 해당 영역의 실패 이력이 memory에 존재
-
-**Reviewer — writer 산출물 검증**:
-- Step 2에서 Writer가 산출물을 생성한 경우, Reviewer가 반드시 검증해야 한다
-- Writer → Reviewer는 선택이 아닌 필수 페어링이다
-- Reviewer 확인 항목: 사실 정확성, 소스 일관성, 문법/형식
-
-- 문제 발견 시: 코드 문제 → Step 2 재작업; 설계 문제 → 재실행 전 nx-plan을 다시 수행한다.
-
-### Step 4: Complete
-
-순서대로 실행한다:
-
-1. **nx-sync**: 이번 사이클에 코드 변경이 있었으면 `{{skill_activation skill=nx-sync}}`를 호출한다. Best effort — 실패해도 사이클 완료를 막지 않는다.
-2. **nx_task_close**: 호출하여 plan+tasks를 history.json에 아카이브한다. `.nexus/history.json`이 업데이트된다.
-3. **git commit**: 소스 변경, 빌드 artifact (`bridge/`, `scripts/`), `.nexus/history.json`, 수정된 `.nexus/memory/` 또는 `.nexus/context/`를 스테이징하고 커밋한다. 명시적인 `git add`에 경로를 지정한다 (`git add -A` 사용 금지). `Co-Authored-By`가 포함된 HEREDOC 커밋 메시지를 사용한다. 이렇게 하면 사이클의 history 아카이브가 코드 변경과 같은 커밋에 포함되어 1:1 사이클-커밋 매핑이 보장된다.
-4. **Report**: 사용자에게 요약 보고 — 변경된 파일, 적용된 핵심 결정, 권장 다음 단계. Merge/push는 사용자의 결정이며 이 스킬의 SCOPE 밖이다.
-
----
-
-## Reference Framework
-
-| Phase | Owner | Content |
-|-------|-------|---------|
-| 1. Intake | Lead | 의도 파악, 방향 확인, Branch Guard, tasks.json 확인 / 없으면 nx-plan 호출 |
-| 2. Execute | Do subagents | owner별 태스크당 스폰, 위임 기준, 안전한 경우 병렬 실행 |
-| 3. Verify | Lead + Check subagent | 빌드 확인, 품질 검증 |
-| 4. Complete | Lead | nx-sync, nx_task_close, git commit, 보고 |
-
----
-
-## Structured Delegation
-
-Lead가 서브에이전트에게 태스크를 위임할 때, 다음 형식으로 프롬프트를 구성한다:
-
-```
-TASK: {specific deliverable}
-
-CONTEXT:
-- Current state: {relevant code/doc locations}
-- Dependencies: {results from prior tasks}
-- Prior decisions: {relevant decisions}
-- Target files: {file path list}
-
-CONSTRAINTS:
-- {constraint 1}
-- {constraint 2}
-
-ACCEPTANCE:
-- {completion criterion 1}
-- {completion criterion 2}
-```
-
----
-
-## Key Principles
-
-1. **Lead = 사용자 지시 해석 + 조율 + 태스크 직접 처리**
-2. **사용자가 SCOPE와 구성을 결정한다**
-3. **tasks.json이 상태의 단일 진실 소스** — nx-plan이 생성하고, Step 1에서 읽으며, 태스크가 완료됨에 따라 업데이트된다
-4. **Do subagents = owner별 실행** — Lead는 `owner` 필드에 따라 태스크당 하나의 서브에이전트를 스폰한다. Engineer는 코드 변경에 집중한다. 문서 업데이트는 Step 4에서 Writer가 일괄 처리한다. Researcher는 즉시 reference/에 기록한다.
-5. **Check subagents = 검증** — Lead의 판단 + 4가지 조건
-6. **SubagentStop 에스컬레이션** — 서브에이전트가 미완성 상태로 종료되면 HOW 진단 → 재위임 → 사용자 보고 순으로 에스컬레이션한다. 태스크당 최대 1사이클.
-7. **Gate Stop nonstop** — 미결 태스크가 존재하는 동안 종료할 수 없다
-8. **Plan first** — tasks.json이 없으면 Step 2 전에 반드시 nx-plan을 실행한다
-9. **shell 명령으로 파일 수정 금지** — sed, echo redirection, heredoc, tee 및 유사한 shell 기반 파일 편집은 금지된다. harness의 전용 파일 편집 primitive를 항상 사용한다 (gate 강제)
-
-## State Management
-
-`.nexus/state/tasks.json` — nx-plan이 생성하고 `nx_task_add`/`nx_task_update`로 관리한다. Gate Stop 강제.
-사이클 종료 시 `nx_task_close`를 통해 plan+tasks를 `.nexus/history.json`에 아카이브한다.