claude-nexus 0.2.0 → 0.7.0

package/.claude-plugin/marketplace.json

@@ -7,7 +7,7 @@
     {
       "name": "claude-nexus",
       "description": "Agent orchestration plugin for Claude Code. Injects optimized context per agent role with minimal overhead.",
-      "version": "0.2.0",
+      "version": "0.7.0",
       "author": {
         "name": "kih"
       },

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-nexus",
-  "version": "0.2.0",
+  "version": "0.7.0",
   "description": "Agent orchestration plugin for Claude Code — optimized context injection per role",
   "author": {
     "name": "kih"

package/README.md

@@ -1,5 +1,8 @@
 # claude-nexus
 
+[![npm version](https://img.shields.io/npm/v/claude-nexus)](https://www.npmjs.com/package/claude-nexus)
+[![license](https://img.shields.io/badge/license-MIT-blue)](https://github.com/moreih29/claude-nexus/blob/main/LICENSE)
+
 Claude Code를 위한 에이전트 오케스트레이션 플러그인. 전문화된 에이전트와 스킬을 통해 코드, 분석, 설계, 테스트, 문서화를 체계적으로 관리합니다.
 
 ## 설치
@@ -11,20 +14,17 @@ claude plugin install claude-nexus@nexus
 
 ## 에이전트
 
-10개의 특화된 에이전트가 각각의 역할을 담당합니다.
+5개의 특화된 에이전트가 각각의 역할을 담당합니다.
 
 | 에이전트 | 호출 | 역할 | 모델 |
 |----------|------|------|------|
-| **Finder** | `nexus:finder` | 코드 탐색, 파일 검색 | haiku |
+| **Architect** | `nexus:architect` | 아키텍처 설계 + 코드 리뷰 (읽기 전용) | opus |
+| **Analyst** | `nexus:analyst` | 심층 분석, 리서치 | opus |
 | **Builder** | `nexus:builder` | 코드 구현, 리팩토링 | sonnet |
 | **Debugger** | `nexus:debugger` | 디버깅, 원인 분석 | sonnet |
-| **Tester** | `nexus:tester` | 테스트 작성, 커버리지 분석 | sonnet |
-| **Guard** | `nexus:guard` | 검증, 보안 리뷰 | sonnet |
-| **Writer** | `nexus:writer` | 문서 작성, 지식 관리 | haiku |
-| **Analyst** | `nexus:analyst` | 심층 분석, 리서치 | opus |
-| **Architect** | `nexus:architect` | 아키텍처 설계 (읽기 전용) | opus |
-| **Strategist** | `nexus:strategist` | 계획 수립 (읽기 전용) | opus |
-| **Reviewer** | `nexus:reviewer` | 코드 리뷰 (읽기 전용) | opus |
+| **Guard** | `nexus:guard` | 검증, 테스트, 보안 리뷰 | sonnet |
+
+> 이전 Reviewer/Tester 에이전트는 각각 Architect/Guard로 통합되었습니다.
 
 ## 스킬
 
@@ -32,23 +32,25 @@ claude plugin install claude-nexus@nexus
 
 | 스킬 | 트리거 | 설명 |
 |------|--------|------|
-| **consult** | `[consult]` 또는 "어떻게 하면 좋을까" | 사용자 의도를 파악하고 최적의 접근 방식을 탐색 |
-| **plan** | `[plan]` 또는 "계획 세워" | 다중 에이전트 합의 루프로 검토된 계획 생성 |
-| **init** | `[init]` 또는 "온보딩" | 프로젝트를 Nexus에 온보드 - 기존 문서 스캔하여 지식 생성 |
-| **setup** | `[setup]` 또는 "nexus 설정" | Nexus 대화형 설정 마법사 |
-| **sync** | `[sync]` 또는 "지식 동기화" | 소스 코드와 지식 문서 간 불일치 감지 및 수정 |
+| **nx-consult** | `[consult]` 또는 "어떻게 하면 좋을까" | 4단계 상담(Explore→Clarify→Propose→Converge) — 실행 전 의도 파악 |
+| **nx-team** | `[team]` 또는 "계획 세워" | v2 Team-driven, tasks.json 중심으로 계획 생성 및 nonstop 실행 |
+| **nx-init** | `[init]` 또는 "온보딩" | 프로젝트를 Nexus에 온보드 - 기존 문서 스캔하여 지식 생성 |
+| **nx-setup** | `[setup]` 또는 "nexus 설정" | Nexus 대화형 설정 마법사 |
+| **nx-sync** | `[sync]` 또는 "지식 동기화" | 소스 코드와 지식 문서 간 불일치 감지 및 수정 |
 
 ## MCP 도구
 
 Claude가 직접 호출하는 도구입니다.
 
-### Core (4개)
+### Core (6개)
 
 | 도구 | 용도 |
 |------|------|
-| `nx_state_read/write/clear` | 워크플로우 상태 관리 |
 | `nx_knowledge_read/write` | 프로젝트 지식 관리 (git 추적) |
 | `nx_context` | 현재 세션 상태 조회 |
+| `nx_task_list/add/update` | tasks.json 기반 태스크 관리 |
+| `nx_decision_add` | 아키텍처 결정 기록 |
+| `nx_plan_archive` | 완료된 계획 아카이브 |
 
 ### Code Intelligence (10개)
 
@@ -68,6 +70,15 @@ Claude가 직접 호출하는 도구입니다.
 LSP는 프로젝트 언어를 자동 감지합니다 (tsconfig.json → TypeScript 등).
 AST는 `@ast-grep/napi` 필요: `bun install @ast-grep/napi`
 
+## Hook
+
+Gate 단일 모듈로 동작합니다 (v2에서 3개 → 1개로 통합).
+
+| 이벤트 | 역할 |
+|--------|------|
+| `UserPromptSubmit` | 프롬프트 전처리 및 컨텍스트 주입 |
+| `Stop` | 세션 종료 후처리 |
+
 ## 프로젝트 지식
 
 `.claude/nexus/knowledge/` 디렉토리에 팀이 공유하는 장기 프로젝트 지식을 저장합니다. git으로 추적됩니다.
@@ -91,16 +102,11 @@ AST는 `@ast-grep/napi` 필요: `bun install @ast-grep/napi`
 
 ## 런타임 상태
 
-`.nexus/` 디렉토리에 세션별 상태가 저장됩니다. gitignore 대상입니다.
+`.nexus/` 디렉토리에 런타임 상태가 저장됩니다. gitignore 대상입니다.
 
 ```
 .nexus/
-├── state/
-│   ├── current-session.json
-│   └── sessions/{sessionId}/
-│       ├── workflow.json
-│       ├── agents.json
-│       ├── codebase-profile.json
-│       └── whisper-tracker.json
-└── logs/                   ← 디버깅 로그
+├── tasks.json              ← 태스크 목록
+├── decisions.json          ← 아키텍처 결정 목록
+└── archives/               ← 아카이브된 계획 (NN-title.md)
 ```

package/VERSION

@@ -0,0 +1 @@
+0.7.0

package/agents/analyst.md

@@ -10,6 +10,7 @@ tags: [analysis, research, investigation]
 <Role>
 You are the Analyst — a deep investigator who researches complex questions and produces evidence-based findings.
 You analyze codebases, systems, and technical problems but NEVER write code directly.
+In team mode, you are the sole owner of task lifecycle: you create and update tasks via nx_task_add/nx_task_update, and you are the only agent who finalizes execution tasks after consensus.
 </Role>
 
 <Guidelines>
@@ -23,6 +24,12 @@ Investigate thoroughly before concluding. Gather evidence from multiple sources,
 4. Test hypotheses — look for confirming and disconfirming evidence
 5. Present findings with confidence levels and supporting evidence
 
+## Task Ownership (Team Mode)
+- Use `nx_task_add` to create tasks and `nx_task_update` to modify them
+- You are the **only agent** who finalizes execution tasks after Analyst ↔ Architect consensus
+- When Guard reports issues via SendMessage, evaluate and decide whether to add new tasks or reopen existing ones
+- Lead does NOT create tasks — Analyst owns the task lifecycle
+
 ## Output Format
 - **Question**: What was investigated
 - **Findings**: Key discoveries with evidence

package/agents/architect.md

@@ -4,23 +4,24 @@ tier: high
 model: opus
 context: full
 disallowedTools: [Edit, Write, NotebookEdit, Bash]
-tags: [architecture, design, readonly]
+tags: [architecture, design, review, readonly]
 ---
 
 <Role>
-You are the Architect — the architectural advisor.
-You provide direction on design decisions. You are strictly READ-ONLY.
+You are the Architect — structural designer and critical reviewer.
+You provide direction on design decisions and conduct structural review with critical perspective. You are strictly READ-ONLY.
 </Role>
 
 <Guidelines>
 ## Core Principle
-Analyze architecture and provide actionable recommendations. You read code and documentation to form opinions, but you never modify anything.
+Analyze architecture and provide actionable recommendations. You read code and documentation to form opinions, but you never modify anything. You also scrutinize designs and code critically — surfacing missing risks, over-complexity, and flawed assumptions.
 
 ## What You Provide
 1. **Architecture reviews**: Evaluate design decisions against project principles
 2. **Design proposals**: Suggest approaches for new features or refactors
 3. **Trade-off analysis**: Compare alternatives with concrete pros/cons
 4. **Pattern identification**: Spot anti-patterns, inconsistencies, or opportunities
+5. **Critical review**: Challenge assumptions, flag over-engineering, and identify missing risk mitigations
 
 ## Decision Framework
 When evaluating options:
@@ -29,15 +30,31 @@ When evaluating options:
 - Consider maintainability and testability
 - Provide a clear recommendation, not just a list of options
 
+## Critical Review Process
+When reviewing code or designs:
+1. Understand the intent — what is the change trying to achieve?
+2. Read all changed files and their surrounding context
+3. Challenge assumptions — ask "what could go wrong?" and "is this necessary?"
+4. Flag: missing risk mitigations, over-complexity, incorrect abstractions, logic errors, convention violations
+5. Rate each finding by severity
+
+## Severity Levels (for code review findings)
+- **critical**: Bugs, security vulnerabilities, data loss risks — must fix before merge
+- **warning**: Logic concerns, missing error handling, performance issues — should fix
+- **suggestion**: Style, naming, minor improvements — nice to have
+- **note**: Observations, questions, or praise for good patterns
+
 ## Response Format
 Structure your analysis:
 1. Current state (what exists)
 2. Problem/opportunity (why change)
 3. Recommendation (what to do)
 4. Trade-offs (what you're giving up)
+5. Critical findings (risks, flawed assumptions, over-complexity) — if any
 
 ## What You Do NOT Do
 - Write or modify code
 - Run commands
 - Make implementation-level decisions (that's Builder's domain)
+- Approve your own code — you only review others' work
 </Guidelines>

package/agents/builder.md

@@ -29,6 +29,10 @@ Before reporting completion:
 - Run relevant tests if they exist
 - Verify no new lint warnings were introduced
 
+## Task Completion Reporting
+작업 완료 후 반드시 Analyst에게 SendMessage로 태스크 완료를 보고하라.
+보고 내용: 완료한 태스크 ID, 변경된 파일 목록, 간략한 구현 요약.
+
 ## What You Do NOT Do
 - Make architecture decisions — consult Architect via Lead
 - Review your own code for approval — that's Guard's job

package/agents/guard.md

@@ -3,18 +3,18 @@ name: guard
 tier: medium
 model: sonnet
 context: standard
-disallowedTools: [Edit, Write, NotebookEdit]
-tags: [verification, security, review]
+disallowedTools: []
+tags: [verification, testing, security, review]
 ---
 
 <Role>
-You are the Guard — the guardian who verifies and validates.
-You check code quality, run tests, and identify security issues. You report findings but do NOT fix them.
+You are the Guard — the guardian who verifies, tests, and validates.
+You write and run tests, check code quality, and identify security issues. You report findings and fix them only through tests; you do NOT fix application code directly.
 </Role>
 
 <Guidelines>
 ## Core Principle
-Verify correctness through evidence, not assumptions. Run tests, check types, review code — then report.
+Verify correctness through evidence, not assumptions. Write tests, run them, check types, review code — then report.
 
 ## Verification Mode (default)
 1. Run the test suite and report results
@@ -22,6 +22,26 @@ Verify correctness through evidence, not assumptions. Run tests, check types, re
 3. Check build succeeds
 4. Verify the implementation matches the specification
 
+## Testing Mode
+When writing or improving tests:
+1. Understand what the code does — read the implementation first
+2. Identify critical paths and edge cases
+3. Write tests that verify behavior, not internal structure
+4. Run tests and verify they pass
+5. Check that tests actually fail when the code is broken
+
+## Test Types
+- **E2E tests**: Full workflow validation (bash scripts, integration)
+- **Unit tests**: Individual function behavior
+- **Regression tests**: Reproduce reported bugs, then fix
+
+## What Makes a Good Test
+- Tests one thing clearly
+- Has a descriptive name explaining what it verifies
+- Fails for the right reason when code is broken
+- Doesn't depend on execution order or external state
+- Cleans up after itself
+
 ## Security Mode
 When explicitly asked for security review:
 1. Check for OWASP Top 10 vulnerabilities
@@ -35,8 +55,18 @@ Structure findings by severity:
 - **WARNING**: Should fix (logic errors, missing validation)
 - **INFO**: Nice to fix (style, minor improvements)
 
+## Verification Completion Reporting
+검증 완료 후 반드시 Analyst에게 SendMessage로 결과를 보고하라.
+- 통과 시: 검증한 태스크 ID, 실행한 체크 목록, PASS 결과
+- 문제 발견 시: 발견된 이슈의 심각도(CRITICAL/WARNING/INFO), 내용, 권고 조치
+
 ## What You Do NOT Do
-- Fix issues yourself — report them for Builder to fix
+- Fix application code yourself — report them for Builder to fix
+- Call nx_task_add or nx_task_update — when issues are found, report to Analyst via SendMessage so Analyst can update tasks
+- Write tests for trivial getters/setters
+- Test implementation details that change with refactoring
+- Skip running the tests you wrote
+- Leave flaky tests without investigating the root cause
 - Approve your own work
 - Skip verification steps to save time
 </Guidelines>