@moreih29/nexus-core 0.17.0 → 0.18.2

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

@@ -1,160 +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
-
-Execution norm that Lead follows when the user invokes the [run] tag. Composes subagents dynamically based on user direction and drives the full execution pipeline from intake to completion.
-
-## Constraints
-
-- NEVER modify files via shell commands (sed, echo redirection, heredoc, tee, etc.) — always use the harness's dedicated file-editing primitives (gate enforced)
-- 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 — if absent, generate the plan first
-- MUST spawn subagents per-task based on owner field — Do not handle multi-task work as Lead solo when task count ≥ 2 or target files ≥ 2
-- MUST NOT spawn parallel Engineers if their target files overlap — serialize instead
-- MUST call nx_task_close before completing the cycle — archive plan+tasks to history.json
-
-## Guidelines
-
-## Flow
-
-### Step 1: Intake (Lead)
-
-- **User specifies agents/direction** → follow the instruction as given.
-- **[run] only (no direction)** → confirm direction with user before proceeding.
-- User decides scope and composition. Lead fills in what is not specified.
-- **Branch Guard**: if on main/master, create a branch appropriate to the task type before proceeding (prefix: `feat/`, `fix/`, `chore/`, `research/`, etc. — Lead's judgment). Auto-create without user confirmation.
-- Check for `tasks.json`:
-  - **Exists** → read it and proceed to Step 2.
-  - **Absent** → auto-invoke `{{skill_activation skill=nx-plan mode=auto}}` to generate tasks.json. Do NOT ask — `[run]` implies execution intent. After plan generation, proceed to Step 2.
-- If tasks.json exists, check prior decisions with `nx_plan_status`.
-
-### Step 1.5: TUI Progress
-
-Register tasks for visual progress tracking (Ctrl+T):
-
-- **≤ 10 tasks**: `{{task_register label="<per-task label>" state=pending}}` per task
-- **> 10 tasks**: group by `plan_issue`, `{{task_register label="<group label>" state=pending}}` per group
-- Update the registered entry via `{{task_register label="<label>" state=in_progress}}` / `{{task_register label="<label>" state=completed}}` as execution proceeds
-- **Skip only if**: non-TTY environment (VSCode, headless)
-- **Known issue**: TUI may freeze during auto-compact (#27919) — task data on disk remains correct
-
-### Step 2: Execute
-
-- **Present tasks.json** to the user — show task list with owner, deps, approach summary. Proceed immediately without asking for confirmation.
-- Execute tasks based on `owner` field:
-  - `owner: "lead"` → Lead handles directly
-  - `owner: "engineer"`, `"researcher"`, `"writer"`, etc. → spawn subagent matching the owner role
-  - `owner: "architect"`, `"tester"`, `"reviewer"`, etc. → spawn corresponding HOW/CHECK subagent
-- For each subagent, pass the task's `context`, `approach`, and `acceptance` as the prompt.
-- **Parallel execution**: independent tasks (no overlapping target files, no deps) can be spawned in parallel. Tasks sharing target files must be serialized.
-- **SubagentStop escalation chain**: when a subagent stops with incomplete work:
-  1. **Do/Check failed** → spawn the relevant HOW agent (e.g., Engineer failed → Architect) to diagnose the failure, review the approach, and suggest adjustments.
-  2. **Re-delegate** → apply HOW's adjusted approach and re-delegate to a new Do/Check agent.
-  3. **HOW also failed** → Lead reports the failure to the user with diagnosis details and asks for direction.
-  - Maximum: 1 HOW diagnosis + 1 re-delegation per task. After that, escalate to user.
-  - Relevant HOW mapping: Engineer→Architect, Writer→Strategist, Researcher→Postdoc, Tester→Architect.
-
-### Resume Dispatch Rule
-
-For each task, Lead chooses between fresh spawn and resume based on the `owner`'s `resume_tier`:
-
-1. Lookup `resume_tier` from `agents/{owner}.md` frontmatter (if absent → treat as `ephemeral`).
-2. If `ephemeral` → fresh spawn. Stop.
-3. If `bounded` → check tasks.json history: did the same `owner` previously work on overlapping target files? If yes AND no intervening edits by other agents → resume candidate. Otherwise fresh. Always include "re-read target files before any modification" instruction in the resume prompt.
-4. If `persistent` → resume by default if the same agent worked earlier in this run. Cross-task reuse allowed.
-5. Before attempting any resume, verify the harness's resume mechanism is available. If unavailable, fall back to fresh spawn silently — do NOT throw an error.
-
-### Step 3: Verify (Lead + Check subagents)
-
-**Lead**: confirm build + E2E pass/fail.
-
-**Tester — acceptance criteria verification**:
-- Tester reads each completed task's `acceptance` field from tasks.json
-- Verifies each criterion with PASS/FAIL judgment
-- All criteria must pass for the task to be considered done
-- If any criterion fails → Step 2 rework (reopen task)
-- Tester spawn conditions (any one triggers):
-  - tasks.json contains at least 1 task with an `acceptance` field
-  - 3 or more files changed
-  - Existing test files modified
-  - External API/DB access code changed
-  - Failure history for this area exists in memory
-
-**Reviewer — writer deliverable verification**:
-- Whenever Writer produced a deliverable in Step 2, Reviewer MUST verify it
-- Writer → Reviewer is a mandatory pairing, not optional
-- Reviewer checks: factual accuracy, source consistency, grammar/format
-
-- If issues found: code problems → Step 2 rework; design problems → re-run nx-plan before re-executing.
-
-### Step 4: Complete
-
-Execute in order:
-
-1. **nx-sync**: invoke `{{skill_activation skill=nx-sync}}` if code changes were made in this cycle. Best effort — failure does not block cycle completion.
-2. **nx_task_close**: call to archive plan+tasks to history.json. This updates `.nexus/history.json`.
-3. **git commit**: stage and commit source changes, build artifacts (`bridge/`, `scripts/`), `.nexus/history.json`, and any modified `.nexus/memory/` or `.nexus/context/`. Use explicit `git add` with paths (not `git add -A`) and a HEREDOC commit message with `Co-Authored-By`. This ensures the cycle's history archive lands in the same commit as the code changes, giving a 1:1 cycle-commit mapping.
-4. **Report**: summarize to user — changed files, key decisions applied, and suggested next steps. Merge/push is the user's decision and outside this skill's scope.
-
----
-
-## Reference Framework
-
-| Phase | Owner | Content |
-|-------|-------|---------|
-| 1. Intake | Lead | Clarify intent, confirm direction, Branch Guard, check tasks.json / invoke nx-plan if absent |
-| 2. Execute | Do subagents | Spawn per-task by owner, delegation criteria, parallel where safe |
-| 3. Verify | Lead + Check subagent | Build check, quality verification |
-| 4. Complete | Lead | nx-sync, nx_task_close, git commit, report |
-
----
-
-## Structured Delegation
-
-When Lead delegates tasks to subagents, structure the prompt in this format:
-
-```
-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 = interpret user direction + coordinate + own tasks**
-2. **User decides scope and composition**
-3. **tasks.json is the single source of state** — produced by nx-plan, read at Step 1, updated as tasks complete
-4. **Do subagents = execute per owner** — Lead spawns one subagent per task based on the `owner` field. Engineers focus on code changes. Doc updates are done in bulk by Writer in Step 4. Researcher records to reference/ immediately.
-5. **Check subagents = verify** — Lead's discretion + 4 conditions
-6. **SubagentStop escalation** — when a subagent stops with incomplete work, escalate through HOW diagnosis → re-delegation → user report. Max 1 cycle per task.
-7. **Gate Stop nonstop** — cannot terminate while pending tasks exist
-8. **Plan first** — if tasks.json is absent, nx-plan must run before Step 2
-9. **No file modification via shell commands** — sed, echo redirection, heredoc, tee, and similar shell-based file edits are prohibited. Always use the harness's dedicated file-editing primitives (gate enforced)
-## State Management
-
-`.nexus/state/tasks.json` — produced by nx-plan, managed via `nx_task_add`/`nx_task_update`. Gate Stop enforcement.
-On cycle end, archive plan+tasks to `.nexus/history.json` via `nx_task_close`.

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

@@ -1,92 +0,0 @@
----
-name: nx-sync
-description: Context knowledge synchronization — scans project state and updates
-  .nexus/context/ design documents
-summary: "Context knowledge synchronization"
-triggers:
-  - sync
-id: nx-sync
----
-
-## Role
-
-현재 프로젝트 상태를 스캔하고 `.nexus/context/` 설계 문서를 동기화한다. git diff를 사용하여 코드 변경 사항을 식별한 뒤, 코드만으로는 추론할 수 없는 추상 설계 문서(원칙, 철학, 개발 스택, 아키텍처 결정)를 업데이트한다.
-
-## Constraints
-
-- 기존 context 파일을 절대 삭제하지 않는다 — 업데이트하거나 추가만 한다
-- 소스 코드를 절대 수정하지 않는다 — 이 skill은 문서만 업데이트한다
-- 소스에서 확인할 수 없는 정보는 추측하지 않는다 — 대신 "needs verification"으로 표시한다
-- 기존 내용 구조를 반드시 보존한다 — 전체 파일을 불필요하게 재작성하지 않고 섹션만 업데이트한다
-- 사용 중단된 MCP 지식 도구는 절대 사용하지 않는다 — harness의 파일 읽기 및 파일 생성 프리미티브만 사용한다
-
-## Guidelines
-
-## Trigger
-
-- `[sync]` — 현재 프로젝트 상태와 `.nexus/context/`를 동기화한다
-
-## Process
-
-### Step 1: Gather Sources
-
-모든 사용 가능한 소스에서 정보를 수집한다:
-
-1. **git diff** — `git diff --name-only HEAD~10..HEAD` 실행 (또는 최근 커밋을 사용하여 변경된 파일 식별)
-   - 어떤 소스 파일이 변경되었는지 식별한다
-   - 어떤 context 문서가 오래되었는지 판단하는 1차 신호
-2. **대화 context** — 현재 세션에서 사용 가능한 경우
-   - 논의되었으나 아직 context 문서에 반영되지 않은 설계 결정
-   - 모든 업데이트의 보조 소스
-
-### Step 2: Read Current Context
-
-harness의 파일 읽기 프리미티브를 사용하여 `.nexus/context/`의 모든 파일을 읽는다:
-
-- 파일 목록 확인: `ls .nexus/context/`
-- 각 파일을 읽어 현재 문서화된 상태를 파악한다
-- 감지된 변경 사항과 비교하여 누락되거나 오래된 내용을 식별한다
-
-구체적인 변경이 감지된 파일만 업데이트한다. 오래된 내용이 없으면 "already current"를 보고하고 건너뛴다.
-
-### Step 3: Execute Updates
-
-Writer agent를 스폰하여 영향받은 context 문서를 업데이트한다:
-
-```
-{{subagent_spawn target_role=writer name=writer-sync-context prompt=>>WRITER_SYNC_PROMPT}}
-Update .nexus/context/ documents based on the following changes. Read current files with the harness's file-reading primitive, then write updates with the harness's file-creation primitive. Changes: {change_manifest}
-<<WRITER_SYNC_PROMPT
-```
-
-Writer agent:
-- harness의 파일 읽기 프리미티브로 각 관련 context 파일을 읽는다
-- 오래된 섹션만 수정하는 표적 업데이트를 적용한다
-- harness의 파일 생성 프리미티브로 업데이트된 파일을 다시 작성한다
-- 이미 정확한 파일은 재작성하지 않는다
-
-### Step 4: Report
-
-다음을 사용자에게 보고한다:
-- 스캔한 context 파일
-- 업데이트된 파일과 변경된 내용
-- 이미 최신 상태인 파일
-- "needs verification"으로 표시된 항목
-
-## Key Principles
-
-1. **전체 재작성보다 표적 업데이트** — 실제로 오래된 섹션만 변경한다
-2. **증거 기반** — 모든 업데이트는 소스(git diff 또는 대화)를 추적할 수 있어야 한다
-3. **구조 보존** — 기존 문서 구성, 헤딩, 형식을 유지한다
-4. **추측 금지** — 변경 사항이 context 문서에 미치는 영향이 불명확하면 추측하지 않고 표시한다
-
-## What .nexus/context/ Contains
-
-Context 문서는 소스 코드에서 직접 읽을 수 없는 추상 지식을 담는다:
-
-- 설계 원칙 및 철학
-- 아키텍처 결정과 그 근거
-- 개발 스택 선택과 제약
-- 프로젝트 컨벤션과 표준
-
-이 문서들은 코드 변경이 원칙의 전환을 반영하거나, 새로운 아키텍처 결정이 내려지거나, 개발 스택이 변화할 때 업데이트된다. 기저 설계를 변경하지 않는 일상적인 코드 추가에는 업데이트하지 않는다.

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

@@ -1,92 +0,0 @@
----
-name: nx-sync
-description: Context knowledge synchronization — scans project state and updates
-  .nexus/context/ design documents
-summary: "Context knowledge synchronization"
-triggers:
-  - sync
-id: nx-sync
----
-
-## Role
-
-Scans the current project state and synchronizes .nexus/context/ design documents. Uses git diff to identify code changes, then updates abstract design documents (principles, philosophy, development stack, architectural decisions) that cannot be inferred from code alone.
-
-## Constraints
-
-- NEVER delete existing context files — only update or add
-- NEVER modify source code — this skill updates documentation only
-- NEVER guess information that cannot be confirmed from sources — mark as "needs verification" instead
-- MUST preserve existing content structure — update sections, don't rewrite entire files unnecessarily
-- NEVER use deprecated MCP knowledge tools — use the harness's file-reading and file-creation primitives only
-
-## Guidelines
-
-## Trigger
-
-- `[sync]` — synchronize .nexus/context/ with current project state
-
-## Process
-
-### Step 1: Gather Sources
-
-Collect information from all available sources:
-
-1. **git diff** — run `git diff --name-only HEAD~10..HEAD` (or use recent commits to identify changed files)
-   - Identifies which source files changed
-   - Primary signal for determining which context documents may be stale
-2. **Conversation context** — if available in current session
-   - Design decisions discussed but not yet reflected in context documents
-   - Supplementary source for all updates
-
-### Step 2: Read Current Context
-
-Read all files in `.nexus/context/` using the harness's file-reading primitive:
-
-- List files: `ls .nexus/context/`
-- Read each file to understand current documented state
-- Compare against detected changes to identify gaps or stale content
-
-Only update files where a concrete change is detected. If no staleness is found, report "already current" and skip.
-
-### Step 3: Execute Updates
-
-Spawn Writer agent to update affected context documents:
-
-```
-{{subagent_spawn target_role=writer name=writer-sync-context prompt=>>WRITER_SYNC_PROMPT}}
-Update .nexus/context/ documents based on the following changes. Read current files with the harness's file-reading primitive, then write updates with the harness's file-creation primitive. Changes: {change_manifest}
-<<WRITER_SYNC_PROMPT
-```
-
-The Writer agent:
-- Reads each relevant context file with the harness's file-reading primitive
-- Applies targeted updates — changes only the sections that are stale
-- Writes the updated file back with the harness's file-creation primitive
-- Does not rewrite files that are already accurate
-
-### Step 4: Report
-
-Report to user:
-- Which context files were scanned
-- Which files were updated and what changed
-- Which files were already up to date
-- Any items marked "needs verification"
-
-## Key Principles
-
-1. **Targeted updates over full rewrites** — only change sections that are actually stale
-2. **Evidence-based** — every update must trace to a source (git diff or conversation)
-3. **Preserve structure** — maintain existing document organization, headings, and format
-4. **No speculation** — if a change's impact on context docs is unclear, flag it rather than guess
-
-## What .nexus/context/ Contains
-
-Context documents capture abstract knowledge that cannot be read directly from source code:
-
-- Design principles and philosophy
-- Architectural decisions and their rationale
-- Development stack choices and constraints
-- Project conventions and standards
-
-These documents are updated when code changes reflect a shift in principles, a new architectural decision is made, or the development stack evolves. They are not updated for routine code additions that do not change the underlying design.