From 648457d71747b6bcceb008c5c550a7a0fa7156ca Mon Sep 17 00:00:00 2001 From: Eyejoker Date: Tue, 31 Mar 2026 05:16:48 +0900 Subject: [PATCH] chore: remove nanoclaw legacy skills and scripts Remove 9 inherited skills (Qodo, update-ejclaw, add-* addons, update-skills) and restart-ejclaw-stack.sh that came from the nanoclaw fork and are no longer used. --- .claude/skills/add-compact/SKILL.md | 46 --- .claude/skills/add-discord/SKILL.md | 84 ----- .claude/skills/add-ollama-tool/SKILL.md | 84 ----- .claude/skills/add-parallel/SKILL.md | 73 ---- .../skills/add-voice-transcription/SKILL.md | 60 ---- .claude/skills/get-qodo-rules/SKILL.md | 122 ------- .../references/output-format.md | 41 --- .../get-qodo-rules/references/pagination.md | 33 -- .../references/repository-scope.md | 26 -- .claude/skills/qodo-pr-resolver/SKILL.md | 326 ----------------- .../qodo-pr-resolver/resources/providers.md | 329 ------------------ .claude/skills/update-ejclaw/SKILL.md | 100 ------ .claude/skills/update-skills/SKILL.md | 130 ------- CLAUDE.md | 3 - scripts/restart-ejclaw-stack.sh | 8 - 15 files changed, 1465 deletions(-) delete mode 100644 .claude/skills/add-compact/SKILL.md delete mode 100644 .claude/skills/add-discord/SKILL.md delete mode 100644 .claude/skills/add-ollama-tool/SKILL.md delete mode 100644 .claude/skills/add-parallel/SKILL.md delete mode 100644 .claude/skills/add-voice-transcription/SKILL.md delete mode 100644 .claude/skills/get-qodo-rules/SKILL.md delete mode 100644 .claude/skills/get-qodo-rules/references/output-format.md delete mode 100644 .claude/skills/get-qodo-rules/references/pagination.md delete mode 100644 .claude/skills/get-qodo-rules/references/repository-scope.md delete mode 100644 .claude/skills/qodo-pr-resolver/SKILL.md delete mode 100644 .claude/skills/qodo-pr-resolver/resources/providers.md delete mode 100644 .claude/skills/update-ejclaw/SKILL.md delete mode 100644 .claude/skills/update-skills/SKILL.md delete mode 100755 scripts/restart-ejclaw-stack.sh diff --git a/.claude/skills/add-compact/SKILL.md b/.claude/skills/add-compact/SKILL.md deleted file mode 100644 index c24c81a..0000000 --- a/.claude/skills/add-compact/SKILL.md +++ /dev/null @@ -1,46 +0,0 @@ ---- -name: add-compact -description: Verify or port the existing /compact session command in current EJClaw. ---- - -# Add /compact Command - -현재 EJClaw에는 `/compact`가 이미 들어 있습니다. 이 스킬은 새로 브랜치를 머지하는 용도보다, 오래된 포크에 같은 기능을 옮기거나 리팩터링 뒤 동작을 검증하는 체크리스트로 씁니다. - -## 관련 파일 - -- `src/session-commands.ts` - 명령 파싱, 권한 검사, pre-compact 처리 -- `src/index.ts` - 메시지 루프에서 세션 명령을 가로채는 호출부 -- `runners/agent-runner/src/index.ts` - Claude Code 쪽 compaction 처리 -- `runners/codex-runner/src/index.ts` - Codex 쪽 compaction 처리 - -## 확인할 동작 - -1. `/compact`가 정확히 명령으로 인식되는지 -2. 메인 그룹 또는 admin/trusted sender만 허용되는지 -3. `/compact` 전에 들어온 메시지를 먼저 세션에 반영하는지 -4. compaction 후 세션이 이어지고 `newSessionId`가 갱신되는지 -5. 대화 아카이브가 `groups//conversations/`에 남는지 - -## 포팅할 때 원칙 - -- 예전 skill branch를 다시 머지하지 말고 현재 트리의 관련 파일을 기준으로 옮깁니다 -- Claude 러너와 Codex 러너 양쪽을 같이 봅니다 -- `/clear`와 `/compact`의 의미를 섞지 않습니다 - -## 검증 - -```bash -bun run typecheck -bun test -bun run build:runners -bun run build -``` - -그 다음 디스코드에서 확인합니다. - -- 메인 채널에서 `/compact` -- 비메인 채널에서 일반 사용자 `/compact` 또는 멘션 포함 `/compact` -- 비메인 채널에서 admin/trusted sender의 `/compact` - -정상이라면 비권한 사용자는 거부되고, 권한 있는 쪽은 세션이 압축된 뒤 계속 이어집니다. diff --git a/.claude/skills/add-discord/SKILL.md b/.claude/skills/add-discord/SKILL.md deleted file mode 100644 index 03fe648..0000000 --- a/.claude/skills/add-discord/SKILL.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -name: add-discord -description: Finish Discord bot setup and registration for EJClaw. ---- - -# Add Discord Channel - -현재 저장소에는 디스코드 채널 구현이 이미 포함되어 있습니다. 이 스킬은 외부 브랜치를 머지하는 용도가 아니라, 토큰 설정과 채널 등록을 빠르게 끝내는 체크리스트로 사용합니다. - -## 1. 전제 확인 - -확인할 것: - -- `src/channels/discord.ts`가 존재하는지 -- `package.json`에 `discord.js`가 있는지 -- `bun run typecheck`가 통과하는지 - -## 2. 봇 토큰 준비 - -토큰이 없다면 디스코드 개발자 포털에서 새 애플리케이션과 봇을 만들고 아래 권한을 켭니다. - -- `Message Content Intent` -- 필요하면 `Server Members Intent` - -봇 초대 링크는 `bot` 스코프와 최소 `Send Messages`, `Read Message History`, `View Channels` 권한으로 생성합니다. - -## 3. 환경 변수 설정 - -`.env`: - -```bash -DISCORD_BOT_TOKEN= -``` - -선택: - -```bash -DISCORD_CODEX_BOT_TOKEN= -``` - -두 번째 토큰이 있으면 Codex 전용 디스코드 봇도 따로 띄울 수 있습니다. - -## 4. 채널 등록 - -디스코드에서 개발자 모드를 켜고 채널 ID를 복사합니다. 등록 JID는 `dc:` 형식입니다. - -메인 채널: - -```bash -bun run setup -- --step register -- \ - --jid dc: \ - --name " #" \ - --folder discord_main \ - --trigger @Andy \ - --is-main \ - --no-trigger-required -``` - -보조 채널: - -```bash -bun run setup -- --step register -- \ - --jid dc: \ - --name " #" \ - --folder discord_ \ - --trigger @Andy -``` - -## 5. 빌드와 검증 - -```bash -bun run build -bun run build:runners -bun run setup -- --step service -bun run setup -- --step verify -``` - -필요하면 로그 확인: - -```bash -tail -f logs/ejclaw.log -``` - -메인 채널이면 일반 메시지, 보조 채널이면 멘션 또는 트리거 메시지로 테스트합니다. diff --git a/.claude/skills/add-ollama-tool/SKILL.md b/.claude/skills/add-ollama-tool/SKILL.md deleted file mode 100644 index 0526aa3..0000000 --- a/.claude/skills/add-ollama-tool/SKILL.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -name: add-ollama-tool -description: Add an Ollama MCP tool to the current host-process Claude runner. ---- - -# Add Ollama Tool - -현재 구조에서는 컨테이너를 건드리지 않습니다. Ollama 연동은 호스트에서 실행되는 Claude 러너에 MCP를 추가하는 방식으로 넣습니다. - -## 전제 조건 - -```bash -ollama list -``` - -- Ollama가 설치되어 있어야 합니다. -- 최소 한 개 이상의 모델이 있어야 합니다. - -권장 예시: - -```bash -ollama pull gemma3:1b -ollama pull llama3.2 -``` - -## 수정 지점 - -### 1. 환경 변수 전달 - -`src/agent-runner.ts` - -- `.env`에서 `OLLAMA_HOST`를 읽도록 `readEnvFile([...])` 목록에 추가합니다. -- Claude 러너 child env에 `OLLAMA_HOST`를 명시적으로 넣습니다. - -기본값을 쓰면 생략 가능하지만, 원격 Ollama나 다른 포트를 쓸 때는 필요합니다. - -## 2. MCP 서버 추가 - -`runners/agent-runner/src/index.ts` - -- 호스트에서 동작하는 stdio MCP 서버 파일을 추가합니다. - - 예: `runners/agent-runner/src/ollama-mcp-stdio.ts` -- `query({ options: { mcpServers, allowedTools } })` 쪽에 Ollama 서버를 등록합니다. -- `allowedTools`에 `mcp__ollama__*` 또는 실제 툴 prefix를 추가합니다. - -핵심은 두 가지입니다. - -- Claude가 Ollama를 CLI가 아니라 MCP 도구로 보게 만들 것 -- 툴 이름이 `allowedTools`에 포함될 것 - -## 3. 프롬프트 문서화 - -`groups/global/CLAUDE.md` 또는 대상 그룹의 `CLAUDE.md` - -- 언제 Ollama를 쓰는지 -- 어떤 모델을 우선 쓰는지 -- 빠른 요약/분류/초안 작업에 먼저 쓰도록 할지 - -이 부분을 적어두지 않으면 에이전트가 도구를 잘 안 고릅니다. - -## 4. 빌드와 검증 - -```bash -bun run build:runners -bun run build -bun run setup -- --step service -``` - -디스코드에서 테스트: - -> `ollama 도구를 써서 이 문단을 3줄로 요약해줘` - -## 문제 확인 - -### 에이전트가 `ollama` CLI를 직접 치려고 함 - -- MCP 서버 등록이 빠졌거나 -- `allowedTools`에 툴 prefix가 없거나 -- 프롬프트 문서에 사용 규칙이 없습니다 - -### 연결 실패 - -- `ollama list`가 호스트에서 되는지 먼저 확인합니다 -- 원격 호스트면 `.env`의 `OLLAMA_HOST`를 확인합니다 diff --git a/.claude/skills/add-parallel/SKILL.md b/.claude/skills/add-parallel/SKILL.md deleted file mode 100644 index 9ea3552..0000000 --- a/.claude/skills/add-parallel/SKILL.md +++ /dev/null @@ -1,73 +0,0 @@ ---- -name: add-parallel -description: Add Parallel AI MCP tools to the current host-process Claude runner. ---- - -# Add Parallel AI Integration - -Parallel AI는 현재 구조에서도 유효한 도구 연동입니다. 다만 예전 문서처럼 컨테이너를 수정하지 않고, Claude 러너의 MCP 설정만 바꿉니다. - -## 1. API 키 준비 - -`PARALLEL_API_KEY`를 `.env`에 넣습니다. - -```bash -PARALLEL_API_KEY=... -``` - -## 2. 환경 변수 전달 - -`src/agent-runner.ts` - -- `.env`에서 `PARALLEL_API_KEY`를 읽도록 `readEnvFile([...])` 목록에 추가합니다. -- Claude 러너 child env에 `PARALLEL_API_KEY`를 넣습니다. - -## 3. MCP 서버 등록 - -`runners/agent-runner/src/index.ts` - -- `query({ options: { mcpServers } })`에 Parallel HTTP MCP 서버를 추가합니다. -- `allowedTools`에 `mcp__parallel-search__*`, `mcp__parallel-task__*`를 추가합니다. - -구분은 이렇게 가져가는 편이 안전합니다. - -- `parallel-search`: 빠른 검색, 저비용, 기본 허용 -- `parallel-task`: 긴 조사 작업, 비용/시간이 더 큼, 명시적 승인 후 사용 - -## 4. 프롬프트 규칙 추가 - -`groups/global/CLAUDE.md` 또는 대상 그룹의 `CLAUDE.md` - -아래 원칙을 문서화합니다. - -- 빠른 사실 조회나 최신 정보 확인은 `parallel-search` -- 긴 조사나 깊은 분석은 `parallel-task` -- `parallel-task`는 항상 먼저 사용자 허가를 받을 것 -- 오래 걸리는 작업은 답변을 붙잡고 있지 말고 `mcp__ejclaw__schedule_task`로 후속 체크를 맡길 것 - -## 5. 빌드와 검증 - -```bash -bun run build:runners -bun run build -bun run setup -- --step service -``` - -디스코드 테스트 예시: - -> `최신 AI 뉴스 찾아줘` - -> `AI 에이전트 역사 자세히 조사해줘` - -두 번째 요청에서는 비용/시간 안내 후 허가를 먼저 묻게 만드는 게 맞습니다. - -## 문제 확인 - -### MCP가 안 뜸 - -- `PARALLEL_API_KEY`가 child env까지 전달되는지 확인합니다 -- `allowedTools`에 Parallel prefix가 빠지지 않았는지 봅니다 - -### 긴 작업이 응답을 오래 붙잡음 - -- `parallel-task` 결과를 기다리며 블로킹하지 말고 스케줄러로 넘기도록 프롬프트와 구현을 같이 수정합니다 diff --git a/.claude/skills/add-voice-transcription/SKILL.md b/.claude/skills/add-voice-transcription/SKILL.md deleted file mode 100644 index 4eb3703..0000000 --- a/.claude/skills/add-voice-transcription/SKILL.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -name: add-voice-transcription -description: Enable Discord voice transcription using Groq Whisper with OpenAI fallback. ---- - -# Add Voice Transcription - -디스코드 음성 첨부 전사는 이미 코드에 들어 있습니다. 현재 구현은 `src/channels/discord.ts`에 있고, 별도 브랜치 머지나 채널 추가 작업은 필요 없습니다. - -우선순위는 `Groq Whisper -> OpenAI Whisper fallback` 입니다. - -## 1. 환경 변수 설정 - -`.env`에 아래 중 하나 이상을 넣습니다. - -```bash -GROQ_API_KEY=gsk_... # 권장. 빠르고 무료 티어가 있음 -OPENAI_API_KEY=sk-... # fallback -``` - -Groq를 쓰면 `whisper-large-v3-turbo`, OpenAI를 쓰면 `whisper-1` 경로를 탑니다. - -## 2. 재시작 - -```bash -bun run build -bun run setup -- --step service -``` - -이미 서비스가 떠 있다면 플랫폼에 맞게 재시작만 해도 됩니다. - -## 3. 검증 - -등록된 디스코드 채널에 음성 메시지나 오디오 첨부를 보냅니다. 정상이라면 에이전트 입력에 전사 텍스트가 포함됩니다. - -```bash -tail -f logs/ejclaw.log | grep -iE 'transcri|audio' -``` - -성공 신호: - -- `Audio transcribed + cached` -- `provider: "groq"` 또는 `provider: "openai"` -- 동일 첨부 재처리 시 cache hit - -## Troubleshooting - -**전사가 전혀 안 됨** - -- `.env`에 `GROQ_API_KEY`나 `OPENAI_API_KEY`가 없는 경우가 대부분입니다. -- 서비스 재시작 전에는 새 키가 반영되지 않습니다. - -**너무 느림** - -- 로그에 `provider: "groq"`가 안 보이면 Groq 키가 빠졌거나 잘못된 상태입니다. - -**채널에서는 보이는데 에이전트가 못 읽음** - -- 채널 등록과 서비스 상태를 먼저 확인합니다. -- `bun run setup -- --step verify` 결과에서 `REGISTERED_GROUPS`와 `SERVICE`를 같이 봅니다. diff --git a/.claude/skills/get-qodo-rules/SKILL.md b/.claude/skills/get-qodo-rules/SKILL.md deleted file mode 100644 index 69abaf7..0000000 --- a/.claude/skills/get-qodo-rules/SKILL.md +++ /dev/null @@ -1,122 +0,0 @@ ---- -name: get-qodo-rules -description: "Loads org- and repo-level coding rules from Qodo before code tasks begin, ensuring all generation and modification follows team standards. Use before any code generation or modification task when rules are not already loaded. Invoke when user asks to write, edit, refactor, or review code, or when starting implementation planning." -version: 2.0.0 -allowed-tools: ["Bash"] -triggers: - - "get.?qodo.?rules" - - "get.?rules" - - "load.?qodo.?rules" - - "load.?rules" - - "fetch.?qodo.?rules" - - "fetch.?rules" - - "qodo.?rules" - - "coding.?rules" - - "code.?rules" - - "before.?cod" - - "start.?coding" - - "write.?code" - - "implement" - - "create.*code" - - "build.*feature" - - "add.*feature" - - "fix.*bug" - - "refactor" - - "modify.*code" - - "update.*code" ---- - -# Get Qodo Rules Skill - -## Description - -Fetches repository-specific coding rules from the Qodo platform API before code generation or modification tasks. Rules include security requirements, coding standards, quality guidelines, and team conventions that must be applied during code generation. -**Use** before any code generation or modification task when rules are not already loaded. Invoke when user asks to write, edit, refactor, or review code, or when starting implementation planning. -**Skip** if "Qodo Rules Loaded" already appears in conversation context - ---- - -## Workflow - -### Step 1: Check if Rules Already Loaded - -If rules are already loaded (look for "Qodo Rules Loaded" in recent messages), skip to step 6. - -### Step 2: Verify working in a git repository - -- Check that the current directory is inside a git repository. If not, inform the user that a git repository is required and exit gracefully. -- Extract the repository scope from the git `origin` remote URL. If no remote is found, exit silently. If the URL cannot be parsed, inform the user and exit gracefully. -- Detect module-level scope: if inside a `modules/*` subdirectory, use it as the query scope; otherwise use repository-wide scope. - -See [repository scope detection](references/repository-scope.md) for details. - -### Step 3: Verify Qodo Configuration - -Check that the required Qodo configuration is present. The default location is `~/.qodo/config.json`. - -- **API key**: Read from `~/.qodo/config.json` (`API_KEY` field). If not found, inform the user that an API key is required and provide setup instructions, then exit gracefully. -- **Environment name**: Read from `~/.qodo/config.json` (`ENVIRONMENT_NAME` field), with `QODO_ENVIRONMENT_NAME` environment variable taking precedence. If not found, inform the user that an API key is required and provide setup instructions, then exit gracefully. - -### Step 4: Fetch Rules with Pagination - -- Fetch all pages from the API (50 rules per page) until no more results are returned. -- On each page, handle HTTP errors and exit gracefully with a user-friendly message. -- Accumulate all rules across pages into a single list. -- Stop after 100 pages maximum (safety limit). -- If no rules are found after all pages, inform the user and exit gracefully. - -See [pagination details](references/pagination.md) for the full algorithm and error handling. - -### Step 5: Format and Output Rules - -- Print the "📋 Qodo Rules Loaded" header with repository scope, scope context, and total rule count. -- Group rules by severity and print each non-empty group: ERROR, WARNING, RECOMMENDATION. -- Each rule is formatted as: `- **{name}** ({category}): {description}` -- End output with `---`. - -See [output format details](references/output-format.md) for the exact format. - -### Step 6: Apply Rules by Severity - -| Severity | Enforcement | When Skipped | -|---|---|---| -| **ERROR** | Must comply, non-negotiable. Add comment documenting compliance (e.g., `# Following Qodo rule: No Hardcoded Credentials`) | Explain to user and ask for guidance | -| **WARNING** | Should comply by default | Briefly explain why in response | -| **RECOMMENDATION** | Consider when appropriate | No action needed | - -### Step 7: Report - -After code generation, inform the user about rule application: -- **ERROR rules applied**: List which rules were followed -- **WARNING rules skipped**: Explain why -- **No rules applicable**: Inform: "No Qodo rules were applicable to this code change" -- **RECOMMENDATION rules**: Mention only if they influenced a design decision - ---- - -## How Scope Levels Work - -Determines scope from git remote and working directory (see [Step 2](#step-2-verify-working-in-a-git-repository)): - -**Scope Hierarchy**: -- **Universal** (`/`) - applies everywhere -- **Org Level** (`/org/`) - applies to organization -- **Repo Level** (`/org/repo/`) - applies to repository -- **Path Level** (`/org/repo/path/`) - applies to specific paths - ---- - -## Configuration - -See `~/.qodo/config.json` for API key setup. Set `QODO_ENVIRONMENT_NAME` env var or `ENVIRONMENT_NAME` in config to select environment. - ---- - -## Common Mistakes - -- **Re-running when rules are loaded** - Check for "Qodo Rules Loaded" in context first -- **Missing compliance comments on ERROR rules** - ERROR rules require a comment documenting compliance -- **Forgetting to report when no rules apply** - Always inform the user when no rules were applicable, so they know the rules system is active -- **Not in git repo** - Inform the user that a git repository is required and exit gracefully; do not attempt code generation -- **No API key** - Inform the user with setup instructions; set `QODO_API_KEY` or create `~/.qodo/config.json` -- **No rules found** - Inform the user; set up rules at app.qodo.ai diff --git a/.claude/skills/get-qodo-rules/references/output-format.md b/.claude/skills/get-qodo-rules/references/output-format.md deleted file mode 100644 index 06b51d3..0000000 --- a/.claude/skills/get-qodo-rules/references/output-format.md +++ /dev/null @@ -1,41 +0,0 @@ -# Formatting and Outputting Rules - -## Output Structure - -Print the following header: - -``` -# 📋 Qodo Rules Loaded - -Scope: `{QUERY_SCOPE}` -Rules loaded: **{TOTAL_RULES}** (universal, org level, repo level, and path level rules) - -These rules must be applied during code generation based on severity: -``` - -## Grouping by Severity - -Group rules into three sections and print each non-empty section: - -**ERROR** (`severity == "error"`): -``` -## ❌ ERROR Rules (Must Comply) - {count} - -- **{name}** ({category}): {description} -``` - -**WARNING** (`severity == "warning"`): -``` -## ⚠️ WARNING Rules (Should Comply) - {count} - -- **{name}** ({category}): {description} -``` - -**RECOMMENDATION** (`severity == "recommendation"`): -``` -## 💡 RECOMMENDATION Rules (Consider) - {count} - -- **{name}** ({category}): {description} -``` - -End output with `---`. diff --git a/.claude/skills/get-qodo-rules/references/pagination.md b/.claude/skills/get-qodo-rules/references/pagination.md deleted file mode 100644 index be72adf..0000000 --- a/.claude/skills/get-qodo-rules/references/pagination.md +++ /dev/null @@ -1,33 +0,0 @@ -# Fetching Rules with Pagination - -The API returns rules in pages of 50. All pages must be fetched to ensure no rules are missed. - -## Algorithm - -1. Start with `page=1`, `page_size=50`, accumulate results in an empty list -2. Request: `GET {API_URL}/rules?scopes={ENCODED_SCOPE}&state=active&page={PAGE}&page_size=50` - - Header: `Authorization: Bearer {API_KEY}` -3. On non-200 response, handle the error and exit gracefully: - - `401` — invalid/expired API key - - `403` — access forbidden - - `404` — endpoint not found (check `QODO_ENVIRONMENT_NAME`) - - `429` — rate limit exceeded - - `5xx` — API temporarily unavailable - - connection error — check internet connection -4. Parse `rules` array from JSON response body -5. Append page rules to accumulated list -6. If rules returned on this page < 50 → last page, stop -7. Otherwise increment page and repeat from step 2 -8. Safety limit: stop after 100 pages (5000 rules max) - -## API URL - -Construct `{API_URL}` from `ENVIRONMENT_NAME` (read from `~/.qodo/config.json`): - -| `ENVIRONMENT_NAME` | `{API_URL}` | -|---|---| -| set (e.g. `staging`) | `https://qodo-platform.staging.qodo.ai/rules/v1` | - -## After Fetching - -If total rules == 0, inform the user no rules are configured for the repository scope and exit gracefully. diff --git a/.claude/skills/get-qodo-rules/references/repository-scope.md b/.claude/skills/get-qodo-rules/references/repository-scope.md deleted file mode 100644 index e8693b6..0000000 --- a/.claude/skills/get-qodo-rules/references/repository-scope.md +++ /dev/null @@ -1,26 +0,0 @@ -# Repository Scope Detection - -## Extracting Repository Scope from Git Remote URL - -Parse the `origin` remote URL to derive the scope path. Both URL formats are supported: - -- SSH: `git@github.com:org/repo.git` → `/org/repo/` -- HTTPS: `https://github.com/org/repo.git` → `/org/repo/` - -If no remote is found, exit silently. If the URL cannot be parsed, inform the user and exit gracefully. - -## Module-Level Scope Detection - -If the current working directory is inside a `modules/*` subdirectory relative to the repository root, use it as the query scope: - -- `modules/rules/src/service.py` → query scope: `/org/repo/modules/rules/` -- repository root or any other path → query scope: `/org/repo/` - -## Scope Hierarchy - -The API returns all rules matching the query scope via prefix matching: - -| Query scope | Rules returned | -|---|---| -| `/org/repo/modules/rules/` | universal + org + repo + path-level rules | -| `/org/repo/` | universal + org + repo-level rules | diff --git a/.claude/skills/qodo-pr-resolver/SKILL.md b/.claude/skills/qodo-pr-resolver/SKILL.md deleted file mode 100644 index c0cbe22..0000000 --- a/.claude/skills/qodo-pr-resolver/SKILL.md +++ /dev/null @@ -1,326 +0,0 @@ ---- -name: qodo-pr-resolver -description: Review and resolve PR issues with Qodo - get AI-powered code review issues and fix them interactively (GitHub, GitLab, Bitbucket, Azure DevOps) -version: 0.3.0 -triggers: - - qodo.?pr.?resolver - - pr.?resolver - - resolve.?pr - - qodo.?fix - - fix.?qodo - - qodo.?review - - review.?qodo - - qodo.?issues? - - show.?qodo - - get.?qodo - - qodo.?resolve ---- - -# Qodo PR Resolver - -Fetch Qodo review issues for your current branch's PR/MR, fix them interactively or in batch, and reply to each inline comment with the decision. Supports GitHub, GitLab, Bitbucket, and Azure DevOps. - -## Prerequisites - -### Required Tools: -- **Git** - For branch operations -- **Git Provider CLI** - One of: `gh` (GitHub), `glab` (GitLab), `bb` (Bitbucket), or `az` (Azure DevOps) - -**Installation and authentication details:** See [providers.md](./resources/providers.md) for provider-specific setup instructions. - -### Required Context: -- Must be in a git repository -- Repository must be hosted on a supported git provider (GitHub, GitLab, Bitbucket, or Azure DevOps) -- Current branch must have an open PR/MR -- PR/MR must have been reviewed by Qodo (pr-agent-pro bot, qodo-merge[bot], etc.) - -### Quick Check: -```bash -git --version # Check git installed -git remote get-url origin # Identify git provider -``` - -See [providers.md](./resources/providers.md) for provider-specific verification commands. - -## Understanding Qodo Reviews - -Qodo (formerly Codium AI) is an AI-powered code review tool that analyzes PRs/MRs with compliance checks, bug detection, and code quality suggestions. - -### Bot Identifiers -Look for comments from: **`pr-agent-pro`**, **`pr-agent-pro-staging`**, **`qodo-merge[bot]`**, **`qodo-ai[bot]`** - -### Review Comment Types -1. **PR Compliance Guide** 🔍 - Security/ticket/custom compliance with 🟢/🟡/🔴/⚪ indicators -2. **PR Code Suggestions** ✨ - Categorized improvements with importance ratings -3. **Code Review by Qodo** - Structured issues with 🐞/📘/📎 sections and agent prompts (most detailed) - -## Instructions - -When the user asks for a code review, to see Qodo issues, or fix Qodo comments: - -### Step 0: Check code push status - -Check for uncommitted changes, unpushed commits, and get the current branch. - -#### Scenario A: Uncommitted changes exist - -- Inform: "⚠️ You have uncommitted changes. These won't be included in the Qodo review." -- Ask: "Would you like to commit and push them first?" -- If yes: Wait for user action, then proceed to Step 1 -- If no: Warn "Proceeding with review of pushed code only" and continue to Step 1 - -#### Scenario B: Unpushed commits exist - -(no uncommitted changes) - -- Inform: "⚠️ You have N unpushed commits. Qodo hasn't reviewed them yet." -- Ask: "Would you like to push them now?" -- If yes: Execute `git push`, inform "Pushed! Qodo will review shortly. Please wait ~5 minutes then run this skill again." -- Exit skill (don't proceed - Qodo needs time to review) -- If no: Warn "Proceeding with existing PR review" and continue to Step 1 - -#### Scenario C: Everything pushed - -(both uncommitted changes and unpushed commits are empty) - -- Proceed to Step 1 - -### Step 1: Detect git provider - -Detect git provider from the remote URL (`git remote get-url origin`). - -See [providers.md](./resources/providers.md) for provider detection patterns. - -### Step 2: Find the open PR/MR - -Find the open PR/MR for this branch using the provider's CLI. - -See [providers.md § Find Open PR/MR](./resources/providers.md#find-open-prmr) for provider-specific commands. - -### Step 3: Get Qodo review comments - -Get the Qodo review comments using the provider's CLI. - -Qodo typically posts both a **summary comment** (PR-level, containing all issues) and **inline review comments** (one per issue, attached to specific lines of code). You must fetch both. - -See [providers.md § Fetch Review Comments](./resources/providers.md#fetch-review-comments) for provider-specific commands. - -Look for comments where the author is "qodo-merge[bot]", "pr-agent-pro", "pr-agent-pro-staging" or similar Qodo bot name. - -#### Step 3a: Check if review is still in progress - -- If any comment contains "Come back again in a few minutes" or "An AI review agent is analysing this pull request", the review is still running -- In this case, inform the user: "⏳ Qodo review is still in progress. Please wait a few minutes and try again." -- Exit early - don't try to parse incomplete reviews - -#### Step 3b: Deduplicate issues - -Deduplicate issues across summary and inline comments: - -- Qodo posts each issue in two places: once in the **summary comment** (PR-level) and once as an **inline review comment** (attached to the specific code line). These will share the same issue title. -- Qodo may also post multiple summary comments (Compliance Guide, Code Suggestions, Code Review, etc.) where issues can overlap with slightly different wording. -- Deduplicate by matching on **issue title** (primary key - the same title means the same issue): - - If an issue appears in both the summary comment and as an inline comment, merge them into a single issue - - Prefer the **inline comment** for file location (it has the exact line context) - - Prefer the **summary comment** for severity, type, and agent prompt (it is more detailed) - - **IMPORTANT:** Preserve each issue's **inline review comment ID** — you will need it later (Step 8) to reply directly to that comment with the decision -- Also deduplicate across multiple summary comments by location (file path + line numbers) as a secondary key -- If the same issue appears in multiple places, combine the agent prompts - -### Step 4: Parse and display the issues - -- Extract the review body/comments from Qodo's review -- Parse out individual issues/suggestions -- **IMPORTANT: Preserve Qodo's exact issue titles verbatim** — do not rename, paraphrase, or summarize them. Use the title exactly as Qodo wrote it. -- **IMPORTANT: Preserve Qodo's original ordering** — display issues in the same order Qodo listed them. Qodo already orders by severity. -- Extract location, issue description, and suggested fix -- Extract the agent prompt from Qodo's suggestion (the description of what needs to be fixed) - -#### Severity mapping - -Derive severity from Qodo's action level and position: - -1. **Action level determines severity range:** - - **"Action required"** issues → Can only be 🔴 CRITICAL or 🟠 HIGH - - **"Review recommended"** / **"Remediation recommended"** issues → Can only be 🟡 MEDIUM or ⚪ LOW - - **"Other"** / **"Advisory comments"** issues → Always ⚪ LOW (lowest priority) - -2. **Qodo's position within each action level determines the specific severity:** - - Group issues by action level ("Action required" vs "Review recommended" vs "Other") - - Within "Action required" and "Review recommended" groups: earlier positions → higher severity, later positions → lower severity - - Split point: roughly first half of each group gets the higher severity, second half gets the lower - - All "Other" issues are treated as ⚪ LOW regardless of position - -**Example:** 7 "Action required" issues would be split as: -- Issues 1-3: 🔴 CRITICAL -- Issues 4-7: 🟠 HIGH -- Result: No MEDIUM or LOW issues (because there are no "Review recommended" or "Other" issues) - -**Example:** 5 "Action required" + 3 "Review recommended" + 2 "Other" issues would be split as: -- Issues 1-2 or 1-3: 🔴 CRITICAL (first ~half of "Action required") -- Issues 3-5 or 4-5: 🟠 HIGH (second ~half of "Action required") -- Issues 6-7: 🟡 MEDIUM (first ~half of "Review recommended") -- Issue 8: ⚪ LOW (second ~half of "Review recommended") -- Issues 9-10: ⚪ LOW (all "Other" issues) - -**Action guidelines:** -- 🔴 CRITICAL / 🟠 HIGH ("Action required"): Always "Fix" -- 🟡 MEDIUM ("Review recommended"): Usually "Fix", can "Defer" if low impact -- ⚪ LOW ("Review recommended" or "Other"): Can be "Defer" unless quick to fix; "Other" issues are lowest priority - -#### Output format - -Display as a markdown table in Qodo's exact original ordering (do NOT reorder by severity - Qodo's order IS the severity ranking): - -``` -Qodo Issues for PR #123: [PR Title] - -| # | Severity | Issue Title | Issue Details | Type | Action | -|---|----------|-------------|---------------|------|--------| -| 1 | 🔴 CRITICAL | Insecure authentication check | • **Location:** src/auth/service.py:42

• **Issue:** Authorization logic is inverted | 🐞 Bug ⛨ Security | Fix | -| 2 | 🔴 CRITICAL | Missing input validation | • **Location:** src/api/handlers.py:156

• **Issue:** User input not sanitized before database query | 📘 Rule violation ⛯ Reliability | Fix | -| 3 | 🟠 HIGH | Database query not awaited | • **Location:** src/db/repository.py:89

• **Issue:** Async call missing await keyword | 🐞 Bug ✓ Correctness | Fix | -``` - -### Step 5: Ask user for fix preference - -After displaying the table, ask the user how they want to proceed using AskUserQuestion: - -**Options:** -- 🔍 "Review each issue" - Review and approve/defer each issue individually (recommended for careful review) -- ⚡ "Auto-fix all" - Automatically apply all fixes marked as "Fix" without individual approval (faster, but less control) -- ❌ "Cancel" - Exit without making changes - -**Based on the user's choice:** -- If "Review each issue": Proceed to Step 6 (manual review) -- If "Auto-fix all": Skip to Step 7 (auto-fix mode - apply all "Fix" issues automatically using Qodo's agent prompts) -- If "Cancel": Exit the skill - -### Step 6: Review and fix issues (manual mode) - -If "Review each issue" was selected: - -- For each issue marked as "Fix" (starting with CRITICAL): - - Read the relevant file(s) to understand the current code - - Implement the fix by **executing the Qodo agent prompt as a direct instruction**. The agent prompt is the fix specification — follow it literally, do not reinterpret or improvise a different solution. Only deviate if the prompt is clearly outdated relative to the current code (e.g. references lines that no longer exist). - - Calculate the proposed fix in memory (DO NOT use Edit or Write tool yet) - - **Present the fix and ask for approval in a SINGLE step:** - 1. Show a brief header with issue title and location - 2. **Show Qodo's agent prompt in full** so the user can verify the fix matches it - 3. Display current code snippet - 4. Display proposed change as markdown diff - 5. Immediately use AskUserQuestion with these options: - - ✅ "Apply fix" - Apply the proposed change - - ⏭️ "Defer" - Skip this issue (will prompt for reason) - - 🔧 "Modify" - User wants to adjust the fix first - - **WAIT for user's choice via AskUserQuestion** - - **If "Apply fix" selected:** - - Apply change using Edit tool (or Write if creating new file) - - Reply to the Qodo inline comment with the decision (see Step 8 for inline reply commands) - - Git commit the fix: `git add && git commit -m "fix: "` - - Confirm: "✅ Fix applied, commented, and committed!" - - Mark issue as completed - - **If "Defer" selected:** - - Ask for deferral reason using AskUserQuestion - - Reply to the Qodo inline comment with the deferral (see Step 8 for inline reply commands) - - Record reason and move to next issue - - **If "Modify" selected:** - - Inform user they can make changes manually - - Move to next issue -- Continue until all "Fix" issues are addressed or the user decides to stop - -#### Important notes - -**Single-step approval with AskUserQuestion:** -- NO native Edit UI (no persistent permissions possible) -- Each fix requires explicit approval via custom question -- Clearer options, no risk of accidental auto-approval - -**CRITICAL:** Single validation only - do NOT show the diff separately and then ask. Combine the diff display and the question into ONE message. The user should see: brief context → current code → proposed diff → AskUserQuestion, all at once. - -**Example:** Show location, Qodo's guidance, current code, proposed diff, then AskUserQuestion with options (✅ Apply fix / ⏭️ Defer / 🔧 Modify). Wait for user choice, apply via Edit tool if approved. - -### Step 7: Auto-fix mode - -If "Auto-fix all" was selected: - -- For each issue marked as "Fix" (starting with CRITICAL): - - Read the relevant file(s) to understand the current code - - Implement the fix by **executing the Qodo agent prompt as a direct instruction**. The agent prompt is the fix specification — follow it literally, do not reinterpret or improvise a different solution. Only deviate if the prompt is clearly outdated relative to the current code (e.g. references lines that no longer exist). - - Apply the fix using Edit tool - - Reply to the Qodo inline comment with the decision (see Step 8 for inline reply commands) - - Git commit the fix: `git add && git commit -m "fix: "` - - Report each fix with the agent prompt that was followed: - > ✅ **Fixed: [Issue Title]** at `[Location]` - > **Agent prompt:** [the Qodo agent prompt used] - - Mark issue as completed -- After all auto-fixes are applied, display summary: - - List of all issues that were fixed - - List of any issues that were skipped (with reasons) - -### Step 8: Post summary to PR/MR - -**REQUIRED:** After all issues have been reviewed (fixed or deferred), ALWAYS post a comment summarizing the actions taken, even if all issues were deferred. - -See [providers.md § Post Summary Comment](./resources/providers.md#post-summary-comment) for provider-specific commands and summary format. - -**After posting the summary, resolve the Qodo review comment:** - -Find the Qodo "Code Review by Qodo" comment and mark it as resolved or react to acknowledge it. - -See [providers.md § Resolve Qodo Review Comment](./resources/providers.md#resolve-qodo-review-comment) for provider-specific commands. - -If resolve fails (comment not found, API error), continue — the summary comment is the important part. - -### Step 9: Push to remote - -If any fixes were applied (commits were created in Steps 6/7), ask the user if they want to push: -- If yes: `git push` -- If no: Inform them they can push later with `git push` - -**Important:** If all issues were deferred, there are no commits to push — skip this step. - -### Special cases - -#### Unsupported git provider - -If the remote URL doesn't match GitHub, GitLab, Bitbucket, or Azure DevOps, inform the user and exit. - -See [providers.md § Error Handling](./resources/providers.md#error-handling) for details. - -#### No PR/MR exists - -- Inform: "No PR/MR found for branch ``" -- Ask: "Would you like me to create a PR/MR?" -- If yes: Use appropriate CLI to create PR/MR (see [providers.md § Create PR/MR](./resources/providers.md#create-prmr-special-case)), then inform "PR created! Qodo will review it shortly. Run this skill again in ~5 minutes." -- If no: Exit skill - -**IMPORTANT:** Do NOT proceed without a PR/MR - -#### No Qodo review yet - -- Check if PR/MR has comments from Qodo bots (pr-agent-pro, qodo-merge[bot], etc.) -- If no Qodo comments found: Inform "Qodo hasn't reviewed this PR/MR yet. Please wait a few minutes for Qodo to analyze it." -- Exit skill (do NOT attempt manual review) - -**IMPORTANT:** This skill only works with Qodo reviews, not manual reviews - -#### Review in progress - -If "Come back again in a few minutes" message is found, inform user to wait and try again, then exit. - -#### Missing CLI tool - -If the detected provider's CLI is not installed, provide installation instructions and exit. - -See [providers.md § Error Handling](./resources/providers.md#error-handling) for provider-specific installation commands. - -#### Inline reply commands - -Used per-issue in Steps 6 and 7 to reply to Qodo's inline comments: - -Use the inline comment ID preserved during deduplication (Step 3b) to reply directly to Qodo's comment. - -See [providers.md § Reply to Inline Comments](./resources/providers.md#reply-to-inline-comments) for provider-specific commands and reply format. - -Keep replies short (one line). If a reply fails, log it and continue. diff --git a/.claude/skills/qodo-pr-resolver/resources/providers.md b/.claude/skills/qodo-pr-resolver/resources/providers.md deleted file mode 100644 index 600dea8..0000000 --- a/.claude/skills/qodo-pr-resolver/resources/providers.md +++ /dev/null @@ -1,329 +0,0 @@ -# Git Provider Commands Reference - -This document contains all provider-specific CLI commands and API interactions for the Qodo PR Resolver skill. Reference this file when implementing provider-specific operations. - -## Supported Providers - -- GitHub (via `gh` CLI) -- GitLab (via `glab` CLI) -- Bitbucket (via `bb` CLI) -- Azure DevOps (via `az` CLI with DevOps extension) - -## Provider Detection - -Detect the git provider from the remote URL: - -```bash -git remote get-url origin -``` - -Match against: -- `github.com` → GitHub -- `gitlab.com` → GitLab -- `bitbucket.org` → Bitbucket -- `dev.azure.com` → Azure DevOps - -## Prerequisites by Provider - -### GitHub - -**CLI:** `gh` -- **Install:** `brew install gh` or [cli.github.com](https://cli.github.com/) -- **Authenticate:** `gh auth login` -- **Verify:** - ```bash - gh --version && gh auth status - ``` - -### GitLab - -**CLI:** `glab` -- **Install:** `brew install glab` or [glab.readthedocs.io](https://glab.readthedocs.io/) -- **Authenticate:** `glab auth login` -- **Verify:** - ```bash - glab --version && glab auth status - ``` - -### Bitbucket - -**CLI:** `bb` or API access -- **Install:** See [bitbucket.org/product/cli](https://bitbucket.org/product/cli) -- **Verify:** - ```bash - bb --version - ``` - -### Azure DevOps - -**CLI:** `az` with DevOps extension -- **Install:** `brew install azure-cli` or [docs.microsoft.com/cli/azure](https://docs.microsoft.com/cli/azure) -- **Install extension:** `az extension add --name azure-devops` -- **Authenticate:** `az login` then `az devops configure --defaults organization=https://dev.azure.com/yourorg project=yourproject` -- **Verify:** - ```bash - az --version && az devops - ``` - -## Find Open PR/MR - -Get the PR/MR number for the current branch: - -### GitHub - -```bash -gh pr list --head --state open --json number,title -``` - -### GitLab - -```bash -glab mr list --source-branch --state opened -``` - -### Bitbucket - -```bash -bb pr list --source-branch --state OPEN -``` - -### Azure DevOps - -```bash -az repos pr list --source-branch --status active --output json -``` - -## Fetch Review Comments - -Qodo posts both **summary comments** (PR-level) and **inline review comments** (per-line). Fetch both. - -### GitHub - -```bash -# PR-level comments (includes the summary comment with all issues) -gh pr view --json comments - -# Inline review comments (per-line comments on specific code) -gh api repos/{owner}/{repo}/pulls//comments -``` - -### GitLab - -```bash -# All MR notes including inline comments -glab mr view --comments -``` - -### Bitbucket - -```bash -# All PR comments including inline comments -bb pr view --comments -``` - -### Azure DevOps - -```bash -# PR-level threads (includes summary comments) -az repos pr show --id --output json - -# All PR threads including inline comments -az repos pr policy list --id --output json -az repos pr thread list --id --output json -``` - -## Reply to Inline Comments - -Use the inline comment ID preserved during deduplication to reply directly to Qodo's comments. - -### GitHub - -```bash -gh api repos/{owner}/{repo}/pulls//comments//replies \ - -X POST \ - -f body='' -``` - -**Reply format:** -- **Fixed:** `✅ **Fixed** — ` -- **Deferred:** `⏭️ **Deferred** — ` - -### GitLab - -```bash -glab api "/projects/:id/merge_requests//discussions//notes" \ - -X POST \ - -f body='' -``` - -### Bitbucket - -```bash -bb api "/2.0/repositories/{workspace}/{repo}/pullrequests//comments" \ - -X POST \ - -f 'content.raw=' \ - -f 'parent.id=' -``` - -### Azure DevOps - -```bash -az repos pr thread comment add \ - --id \ - --thread-id \ - --content '' -``` - -## Post Summary Comment - -After reviewing all issues, post a summary comment to the PR/MR. - -### GitHub - -```bash -gh pr comment --body '' -``` - -### GitLab - -```bash -glab mr comment --message '' -``` - -### Bitbucket - -```bash -bb pr comment '' -``` - -### Azure DevOps - -```bash -az repos pr thread create \ - --id \ - --comment-content '' -``` - -**Summary format:** - -```markdown -## Qodo Fix Summary - -Reviewed and addressed Qodo review issues: - -### ✅ Fixed Issues -- **Issue Title** (Severity) - Brief description of what was fixed - -### ⏭️ Deferred Issues -- **Issue Title** (Severity) - Reason for deferring - ---- -*Generated by Qodo PR Resolver skill* -``` - -## Resolve Qodo Review Comment - -After posting the summary, resolve the main Qodo review comment. - -**Steps:** -1. Fetch all PR/MR comments -2. Find the Qodo bot comment containing "Code Review by Qodo" -3. Resolve or react to the comment - -### GitHub - -```bash -# 1. Fetch comments to find the comment ID -gh pr view --json comments - -# 2. React with thumbs up to acknowledge -gh api "repos/{owner}/{repo}/issues/comments//reactions" \ - -X POST \ - -f content='+1' -``` - -### GitLab - -```bash -# 1. Fetch discussions to find the discussion ID -glab api "/projects/:id/merge_requests//discussions" - -# 2. Resolve the discussion -glab api "/projects/:id/merge_requests//discussions/" \ - -X PUT \ - -f resolved=true -``` - -### Bitbucket - -```bash -# Fetch comments via bb api, find the comment ID, then update to resolved status -bb api "/2.0/repositories/{workspace}/{repo}/pullrequests//comments/" \ - -X PUT \ - -f 'resolved=true' -``` - -### Azure DevOps - -```bash -# Mark the thread as resolved -az repos pr thread update \ - --id \ - --thread-id \ - --status resolved -``` - -## Create PR/MR (Special Case) - -If no PR/MR exists for the current branch, offer to create one. - -### GitHub - -```bash -gh pr create --title '' --body '<body>' -``` - -### GitLab - -```bash -glab mr create --title '<title>' --description '<body>' -``` - -### Bitbucket - -```bash -bb pr create --title '<title>' --description '<body>' -``` - -### Azure DevOps - -```bash -az repos pr create \ - --title '<title>' \ - --description '<body>' \ - --source-branch <branch-name> \ - --target-branch main -``` - -## Error Handling - -### Missing CLI Tool - -If the detected provider's CLI is not installed: -1. Inform the user: "❌ Missing required CLI tool: `<cli-name>`" -2. Provide installation instructions from the Prerequisites section -3. Exit the skill - -### Unsupported Provider - -If the remote URL doesn't match any supported provider: -1. Inform: "❌ Unsupported git provider detected: `<url>`" -2. List supported providers: GitHub, GitLab, Bitbucket, Azure DevOps -3. Exit the skill - -### API Failures - -If inline reply or summary posting fails: -- Log the error -- Continue with remaining operations -- The workflow should not abort due to comment posting failures diff --git a/.claude/skills/update-ejclaw/SKILL.md b/.claude/skills/update-ejclaw/SKILL.md deleted file mode 100644 index 9c6903c..0000000 --- a/.claude/skills/update-ejclaw/SKILL.md +++ /dev/null @@ -1,100 +0,0 @@ ---- -name: update-ejclaw -description: Safely merge upstream EJClaw changes into a customized install with minimal drift. ---- - -# Update EJClaw - -커스텀된 EJClaw에 upstream 변경을 가져올 때 쓰는 절차입니다. 현재 기준 중요 경로는 `src/`, `runners/`, `setup/`, `.claude/skills/`, `groups/`, `README.md` 입니다. - -## 원칙 - -- 워킹트리가 더럽다면 진행하지 않습니다 -- 시작 전에 항상 백업 브랜치와 태그를 만듭니다 -- 먼저 `preview`, 그 다음 `merge` 또는 `cherry-pick` 순서로 갑니다 -- 충돌이 나면 충돌 파일만 엽니다 - -## 1. 사전 점검 - -```bash -git status --porcelain -git remote -v -git fetch upstream --prune -``` - -- 변경 파일이 남아 있으면 먼저 정리하게 합니다 -- `upstream`이 없으면 추가합니다 -- upstream 기본 브랜치가 `main`인지 먼저 확인합니다 - -## 2. 백업 - -```bash -HASH=$(git rev-parse --short HEAD) -TIMESTAMP=$(date +%Y%m%d-%H%M%S) -git branch backup/pre-update-$HASH-$TIMESTAMP -git tag pre-update-$HASH-$TIMESTAMP -``` - -## 3. 미리 보기 - -```bash -BASE=$(git merge-base HEAD upstream/main) -git log --oneline $BASE..upstream/main -git log --oneline $BASE..HEAD -git diff --name-only $BASE..upstream/main -``` - -파일은 대략 이렇게 나눠서 봅니다. - -- `.claude/skills/` - 스킬 문서/도우미 -- `src/` - 런타임과 채널 처리 -- `runners/` - Claude/Codex 실행 경로 -- `setup/` - 설치, 등록, 검증, 서비스 -- `README.md`, `groups/` - 운영 문서와 프롬프트 - -## 4. 적용 - -기본은 merge 입니다. - -```bash -git merge upstream/main --no-edit -``` - -일부 커밋만 가져올 거면 cherry-pick으로 갑니다. - -```bash -git cherry-pick <hash1> <hash2> -``` - -## 5. 충돌 처리 - -- 충돌 파일만 엽니다 -- 로컬 커스터마이징은 유지합니다 -- 주변 리팩터링은 하지 않습니다 -- 해결 후 바로 `git add <file>` 합니다 - -## 6. 검증 - -```bash -pnpm typecheck -pnpm test -pnpm build:runners -pnpm build -``` - -런타임 경로가 바뀌었으면 추가로 확인합니다. - -```bash -pnpm setup -- --step verify -``` - -## 7. 요약 - -사용자에게 최소한 이 네 가지를 알려줍니다. - -- 백업 태그 이름 -- 새 HEAD -- 해결한 충돌 파일 목록 -- upstream 대비 아직 남은 로컬 diff - -롤백 안내는 태그 기준으로 알려줍니다. diff --git a/.claude/skills/update-skills/SKILL.md b/.claude/skills/update-skills/SKILL.md deleted file mode 100644 index 4db8e2b..0000000 --- a/.claude/skills/update-skills/SKILL.md +++ /dev/null @@ -1,130 +0,0 @@ ---- -name: update-skills -description: Check for and apply updates to installed skill branches from upstream. ---- - -# About - -Skills are distributed as git branches (`skill/*`). When you install a skill, you merge its branch into your repo. This skill checks upstream for newer commits on those skill branches and helps you update. - -Run `/update-skills` in Claude Code. - -## How it works - -**Preflight**: checks for clean working tree and upstream remote. - -**Detection**: fetches upstream, lists all `upstream/skill/*` branches, determines which ones you've previously merged (via merge-base), and checks if any have new commits. - -**Selection**: presents a list of skills with available updates. You pick which to update. - -**Update**: merges each selected skill branch, resolves conflicts if any, then validates with build + test. - ---- - -# Goal -Help users update their installed skill branches from upstream without losing local customizations. - -# Operating principles -- Never proceed with a dirty working tree. -- Only offer updates for skills the user has already merged (installed). -- Use git-native operations. Do not manually rewrite files except conflict markers. -- Keep token usage low: rely on `git` commands, only open files with actual conflicts. - -# Step 0: Preflight - -Run: -- `git status --porcelain` - -If output is non-empty: -- Tell the user to commit or stash first, then stop. - -Check remotes: -- `git remote -v` - -If `upstream` is missing: -- Ask the user for the upstream repo URL (default: `https://github.com/phj1081/EJClaw.git`). -- `git remote add upstream <url>` - -Fetch: -- `git fetch upstream --prune` - -# Step 1: Detect installed skills with available updates - -List all upstream skill branches: -- `git branch -r --list 'upstream/skill/*'` - -For each `upstream/skill/<name>`: -1. Check if the user has merged this skill branch before: - - `git merge-base --is-ancestor upstream/skill/<name>~1 HEAD` — if this succeeds (exit 0) for any ancestor commit of the skill branch, the user has merged it at some point. A simpler check: `git log --oneline --merges --grep="skill/<name>" HEAD` to see if there's a merge commit referencing this branch. - - Alternative: `MERGE_BASE=$(git merge-base HEAD upstream/skill/<name>)` — if the merge base is NOT the initial commit and the merge base includes commits unique to the skill branch, it has been merged. - - Simplest reliable check: compare `git merge-base HEAD upstream/skill/<name>` with `git merge-base HEAD upstream/main`. If the skill merge-base is strictly ahead of (or different from) the main merge-base, the user has merged this skill. -2. Check if there are new commits on the skill branch not yet in HEAD: - - `git log --oneline HEAD..upstream/skill/<name>` - - If this produces output, there are updates available. - -Build three lists: -- **Updates available**: skills that are merged AND have new commits -- **Up to date**: skills that are merged and have no new commits -- **Not installed**: skills that have never been merged - -# Step 2: Present results - -If no skills have updates available: -- Tell the user all installed skills are up to date. List them. -- If there are uninstalled skills, mention them briefly (e.g., "3 other skills available in upstream that you haven't installed"). -- Stop here. - -If updates are available: -- Show the list of skills with updates, including the number of new commits for each: - ``` - skill/<name>: 3 new commits - skill/<other>: 1 new commit - ``` -- Also show skills that are up to date (for context). -- Use AskUserQuestion with `multiSelect: true` to let the user pick which skills to update. - - One option per skill with updates, labeled with the skill name and commit count. - - Add an option: "Skip — don't update any skills now" -- If user selects Skip, stop here. - -# Step 3: Apply updates - -For each selected skill (process one at a time): - -1. Tell the user which skill is being updated. -2. Run: `git merge upstream/skill/<name> --no-edit` -3. If the merge is clean, move to the next skill. -4. If conflicts occur: - - Run `git status` to identify conflicted files. - - For each conflicted file: - - Open the file. - - Resolve only conflict markers. - - Preserve intentional local customizations. - - `git add <file>` - - Complete the merge: `git commit --no-edit` - -If a merge fails badly (e.g., cannot resolve conflicts): -- `git merge --abort` -- Tell the user this skill could not be auto-updated and they should resolve it manually. -- Continue with the remaining skills. - -# Step 4: Validation - -After all selected skills are merged: -- `bun run build` -- `bun test` (do not fail the flow if tests are not configured) - -If build fails: -- Show the error. -- Only fix issues clearly caused by the merge (missing imports, type mismatches). -- Do not refactor unrelated code. -- If unclear, ask the user. - -# Step 5: Summary - -Show: -- Skills updated (list) -- Skills skipped or failed (if any) -- New HEAD: `git rev-parse --short HEAD` -- Any conflicts that were resolved (list files) - -If the service is running, remind the user to restart it to pick up changes. diff --git a/CLAUDE.md b/CLAUDE.md index 9d4c120..0f30238 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -29,9 +29,6 @@ Single unified service (`ejclaw`) manages three Discord bots (Claude, Codex-main | `/setup` | First-time installation, authentication, service configuration | | `/customize` | Adding channels, integrations, changing behavior | | `/debug` | Agent issues, logs, troubleshooting | -| `/update-ejclaw` | Bring upstream EJClaw updates into a customized install | -| `/qodo-pr-resolver` | Fetch and fix Qodo PR review issues interactively or in batch | -| `/get-qodo-rules` | Load org- and repo-level coding rules from Qodo before code tasks | ## Development diff --git a/scripts/restart-ejclaw-stack.sh b/scripts/restart-ejclaw-stack.sh deleted file mode 100755 index e60923a..0000000 --- a/scripts/restart-ejclaw-stack.sh +++ /dev/null @@ -1,8 +0,0 @@ -#!/usr/bin/env bash -set -euo pipefail - -SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)" -PROJECT_ROOT="$(cd "${SCRIPT_DIR}/.." && pwd)" - -cd "${PROJECT_ROOT}" -bun setup/restart-stack.ts "$@"