From 8658853a326d6a11bbc0bcfe26958ecdf1e4666b Mon Sep 17 00:00:00 2001 From: toki Date: Tue, 14 Apr 2026 09:14:04 +0900 Subject: [PATCH] sync: from toki_socket v1.1.1 --- agent-ops/.version | 2 +- agent-ops/rules/common/rules.md | 17 -- agent-ops/skills/common/code-review/SKILL.md | 218 ++++++++++++++++++ .../common/code-review/agents/openai.yaml | 4 + agent-ops/skills/common/plan/SKILL.md | 202 ++++++++++++++++ .../skills/common/plan/agents/openai.yaml | 4 + agent-ops/skills/common/router.md | 5 +- .../skills/common/sync-agent-ops/SKILL.md | 68 ++---- agent-ops/skills/common/version-bump/SKILL.md | 81 ------- 9 files changed, 454 insertions(+), 147 deletions(-) delete mode 100644 agent-ops/rules/common/rules.md create mode 100644 agent-ops/skills/common/code-review/SKILL.md create mode 100644 agent-ops/skills/common/code-review/agents/openai.yaml create mode 100644 agent-ops/skills/common/plan/SKILL.md create mode 100644 agent-ops/skills/common/plan/agents/openai.yaml delete mode 100644 agent-ops/skills/common/version-bump/SKILL.md diff --git a/agent-ops/.version b/agent-ops/.version index 9084fa2..524cb55 100644 --- a/agent-ops/.version +++ b/agent-ops/.version @@ -1 +1 @@ -1.1.0 +1.1.1 diff --git a/agent-ops/rules/common/rules.md b/agent-ops/rules/common/rules.md deleted file mode 100644 index 29ccc4b..0000000 --- a/agent-ops/rules/common/rules.md +++ /dev/null @@ -1,17 +0,0 @@ -# 공통 규칙 - -- 기존 구조를 우선한다. 새 파일 생성보다 기존 파일 수정을 우선한다. -- 코드 변경 전 관련 domain rule을 먼저 확인한다. -- 요청 범위를 넘는 변경을 하지 않는다. -- 불확실하면 단정하지 말고 후보를 제시한다. - -아래 요청은 `agent-ops/skills/common/router.md`를 읽고 수행한다. -- agent-ops 초기화 -- domain rule 생성 -- skill 생성 -- git commit / git push -- 버전 올려줘 -- agent-ops 업데이트 / 진입 파일 재적용 - -`agent-ops/rules/project/rules.md`와 -`agent-ops/rules/private/rules.md`를 읽고 작업을 시작한다. 파일이 없을경우 무시한다. diff --git a/agent-ops/skills/common/code-review/SKILL.md b/agent-ops/skills/common/code-review/SKILL.md new file mode 100644 index 0000000..7ae784b --- /dev/null +++ b/agent-ops/skills/common/code-review/SKILL.md @@ -0,0 +1,218 @@ +--- +name: code-review +description: Review completed implementation work in the current repository. Reads PLAN.md and CODE_REVIEW.md from the active task, reviews the actual changed source files, appends a verdict to CODE_REVIEW.md, then archives both files as .log. On PASS, writes complete.log summarising the full loop history. If Required or Suggested issues are found (FAIL or WARN), writes a new PLAN.md and CODE_REVIEW.md stub so the loop continues immediately. Nit-only findings may still PASS. +--- + +# Code Review + +## Purpose + +Review the implementation phase of the plan-code-review loop: + +```text +plan skill -> implementation -> code-review skill + ^ | + +----- issues found: new PLAN.md +``` + +## Workflow Contract + +Active work must live at `agent-task/{task_name}/PLAN.md` and `agent-task/{task_name}/CODE_REVIEW.md`. These paths are the state protocol shared with the plan skill. Do not adapt them per repository unless the whole loop contract is intentionally changed in both skills. + +Directory states: + +| State | Meaning | +|-------|---------| +| `PLAN.md` + `CODE_REVIEW.md` | Ready for review | +| `complete.log` + `*.log` files | Task complete (PASS) | +| Only `*.log` files (no `complete.log`) | Task terminated mid-loop or abandoned | + +The implementing agent never archives or deletes active files; archiving is this skill's responsibility. + +## Step 1 - Find Active Task + +Glob `agent-task/*/CODE_REVIEW.md`: + +| Result | Action | +|--------|--------| +| Exactly one | Review that task; `PLAN.md` is expected beside it | +| None | Nothing to review; stop and report | +| Multiple | List paths and ask which task to review | + +## Step 2 - Load Context + +Count `agent-task/{task_name}/code_review_*.log`: + +- `0`: first review. Read `CODE_REVIEW.md`, `PLAN.md`, every planned source file, related tests, and files importing/imported by changed files up to 2 levels deep. +- `>=1`: follow-up review. Start with `git diff`, `git diff --cached`, and `git log --oneline -5`, then expand to related callers, implementers, tests, and any planned files missing from the diff. + +The diff is the starting point, not the boundary. Follow behavior and API connections far enough to judge correctness. + +## Step 3 - Pre-Review Checklist + +Before writing the verdict: + +- Compare actual source files against every planned checklist item. +- Grep renamed/removed symbols for stale references. +- Confirm every required test exists, name matches, and assertions are meaningful. +- Cross-check claimed verification output in `CODE_REVIEW.md` against actual code and project commands. +- For follow-up reviews, compare diff against the plan and scan for unplanned changes, debug prints, dead code, TODOs, formatting-only noise, and unrelated edits. + +## Step 4 - Append Verdict + +Append `코드리뷰 결과` to `CODE_REVIEW.md`. + +Required fields: + +- `종합 판정`: exactly `PASS`, `WARN`, or `FAIL`. +- `차원별 평가`: Pass/Warn/Fail for correctness, completeness, test coverage, API contract, code quality, plan deviation, verification trust. +- `발견된 문제`: `없음`, or bullets using `Required`, `Suggested`, or `Nit` with `file:line` and a concrete fix. +- `다음 단계`: keep only the matching PASS/WARN/FAIL line. + +Severity semantics: + +| Verdict | Meaning | Follow-up plan | +|---------|---------|----------------| +| `PASS` | No Required/Suggested issues. Nit-only findings may still PASS. | No | +| `WARN` | One or more Suggested issues, zero Required. | Yes | +| `FAIL` | One or more Required issues. | Yes | + +Issue severity: + +- `Required`: correctness, API contract, missing required test, or plan-completeness issue. +- `Suggested`: useful improvement that should enter the loop but does not block correctness. +- `Nit`: tiny cleanup; may be recorded without forcing WARN. + +## Step 5 - Archive Active Files + +Archive order is fixed: + +1. Count existing `code_review_*.log` as `N`; rename `CODE_REVIEW.md` to `code_review_N.log`. +2. Count existing `plan_*.log` as `M`; rename `PLAN.md` to `plan_M.log`. + +After archiving, neither active `.md` file remains unless Step 6 writes a follow-up. + +## Step 6 - Post-Review Actions + +For `PASS`, write `agent-task/{task_name}/complete.log` before reporting: + +Required fields in `complete.log`: +- `완료 일시`: date completed. +- `요약`: one-line task description and loop count. +- `루프 이력`: table of plan/code_review log pairs with their verdict. +- `최종 리뷰 요약`: bullet list of what was implemented. +- `잔여 Nit`: any Nit-only findings recorded but not acted on (omit section if none). + +Then report: + +- Verdict. +- Archive filenames. +- `complete.log` written; task complete. + +For `WARN` or `FAIL`, write a new `PLAN.md` and `CODE_REVIEW.md` stub using the plan skill format: + +- New plan number is the count of `plan_*.log` after archive. +- Header tag is `REVIEW_`. +- `FAIL`: one plan item per Required issue. +- `WARN`: one grouped plan item for Suggested issues, plus related Nit issues if useful. +- Each plan item needs problem, solution with before/after when non-trivial, checklist, test decision, intermediate verification. + +`CODE_REVIEW.md` stub template (fill `{…}` placeholders; everything else is fixed and must not be changed by the implementing agent): + +```markdown + + +# Code Review Reference - {TAG} + +## 개요 + +date={YYYY-MM-DD} +task={task_name}, plan={N}, tag={TAG} + +## 이 파일을 읽는 리뷰 에이전트에게 + +각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요. +리뷰 완료 후 반드시 아래 순서로 아카이브하세요. + +1. `CODE_REVIEW.md` → `code_review_N.log` (N = 기존 code_review_*.log 수) +2. `PLAN.md` → `plan_M.log` (M = 기존 plan_*.log 수) +3. PASS인 경우 `complete.log` 작성 후 종료. WARN/FAIL인 경우 새 `PLAN.md` + `CODE_REVIEW.md` 스텁 작성. + +--- + +## 구현 항목별 완료 여부 + +| 항목 | 완료 여부 | +|------|---------| +| [{TAG}-1] {item description} | [ ] | +| [{TAG}-2] {item description} | [ ] | + +## 계획 대비 변경 사항 + +_구현 에이전트가 계획과 다르게 구현한 부분을 이유와 함께 기록한다._ + +## 주요 설계 결정 + +_구현 에이전트가 주요 설계 결정 사항을 기록한다._ + +## 리뷰어를 위한 체크포인트 + +{pre-filled from plan — one bullet per review focus area} + +## 검증 결과 + +_구현 에이전트가 각 중간 검증 및 최종 검증 명령 실행 후 출력을 여기에 붙여 넣는다._ + +### {TAG}-1 중간 검증 +``` +$ {verification command from plan} +(output) +``` + +### 최종 검증 +``` +$ {final verification command from plan} +(output) +``` +``` + +Sections and their ownership: + +| 섹션 | 소유자 | 설명 | +|------|--------|------| +| 헤더 주석, 개요(date/task/plan/tag), 리뷰 에이전트 지시 | 스텁 생성 시 고정 | 구현 에이전트가 수정하지 않음 | +| 구현 항목별 완료 여부 (항목명) | 스텁 생성 시 고정 | `[ ]` → `[x]` 체크만 구현 에이전트가 수행 | +| 계획 대비 변경 사항, 주요 설계 결정 | 구현 에이전트가 채움 | placeholder 텍스트를 실제 내용으로 교체 | +| 리뷰어를 위한 체크포인트 | 스텁 생성 시 고정 | 계획에서 추출한 리뷰 포인트 | +| 검증 결과 (섹션 제목 + 명령) | 스텁 생성 시 고정 | 실행 출력만 구현 에이전트가 채움 | +| 코드리뷰 결과 | 리뷰 에이전트가 append | 스텁에 포함하지 않음 | + +Report Required/Suggested counts, archive names, and the new plan path. + +## Review Dimensions + +| Dimension | Check | +|-----------|-------| +| Correctness | Logic, edge cases, concurrency, errors | +| Completeness | All planned checklist items done | +| Test coverage | Required tests present and meaningful | +| API contract | Call sites, compatibility, docs | +| Code quality | No debug prints, dead code, leftover TODOs | +| Plan deviation | Deviations justified, no unrelated risk | +| Verification trust | Reported output matches actual code | + +## Quality Rules + +- Lead with findings; use specific `file:line`. +- Provide a concrete fix for every Required issue. +- Name exact stale symbols or missing tests. +- Do not write vague praise or style opinions without a rule. +- Every dimension gets Pass/Warn/Fail. + +## Final Checklist + +- `code_review_N.log` exists with verdict appended. +- `plan_M.log` exists. +- No active `.md` files remain after PASS. +- PASS: `complete.log` written with loop history, implementation summary, and residual Nits. +- WARN/FAIL: new active `PLAN.md` and `CODE_REVIEW.md` created with matching headers; no `complete.log`. diff --git a/agent-ops/skills/common/code-review/agents/openai.yaml b/agent-ops/skills/common/code-review/agents/openai.yaml new file mode 100644 index 0000000..d45d468 --- /dev/null +++ b/agent-ops/skills/common/code-review/agents/openai.yaml @@ -0,0 +1,4 @@ +interface: + display_name: "Code Review" + short_description: "Review task implementation" + default_prompt: "Use $code-review to review the active repository task and archive or continue the loop." diff --git a/agent-ops/skills/common/plan/SKILL.md b/agent-ops/skills/common/plan/SKILL.md new file mode 100644 index 0000000..fefbf5f --- /dev/null +++ b/agent-ops/skills/common/plan/SKILL.md @@ -0,0 +1,202 @@ +--- +name: plan +description: Analyze the current repository and write a detailed PLAN.md for implementation work. Also writes the CODE_REVIEW.md stub that the implementing agent will fill in after coding. Use for any feature, refactor, bug fix, or follow-up fix that should enter the plan-code-review loop. A separate implementing agent, or the same agent in an implementation pass, reads PLAN.md and does the coding. The code-review skill archives both files after review. +--- + +# Plan + +## Purpose + +Create the planning artifacts for the implementation loop: + +```text +plan skill -> PLAN.md + CODE_REVIEW.md stub +implementation -> code changes + filled CODE_REVIEW.md +code-review skill -> verdict + archive, or new follow-up PLAN.md +``` + +## Workflow Contract + +This skill intentionally uses `agent-task/{task_name}/PLAN.md` and `agent-task/{task_name}/CODE_REVIEW.md` as the state protocol between planning, implementation, and review. Do not change these paths or filenames unless the paired plan and code-review skills are updated together. This convention is not project-specific; it is the workflow contract for this skill loop. + +Directory states: + +| State | Meaning | +|-------|---------| +| `PLAN.md` only | Invalid; plan skill always writes both files | +| `PLAN.md` + `CODE_REVIEW.md` stub | Implementation is pending/in progress | +| `PLAN.md` + filled `CODE_REVIEW.md` | Ready for code-review skill | +| `complete.log` + `*.log` files | Task complete (PASS) | +| Only `*.log` files (no `complete.log`) | Task terminated mid-loop or abandoned | + +## Step 1 - Determine Task + +If the user names the task explicitly, use that task name. + +Otherwise, glob `agent-task/*/PLAN.md`: + +| Result | Action | +|--------|--------| +| Exactly one | Continue that task | +| None | Create a new task only for a feature/refactor/fix/follow-up that belongs in this workflow | +| Multiple | List paths and ask which task to use | + +`PLAN.md` is the loop entry point. A missing `PLAN.md` normally means only that no plan has been started for a new task; do not create task files for casual analysis, status, or review requests unless the user explicitly asks for a plan. + +Use short snake_case task names, e.g. `api_refactor`. + +## Step 2 - Analyze Before Writing + +Complete these before creating files: + +- Read every source file the change will touch, whole file. +- Read every test file that exercises changed behavior. +- For each behavior change, note whether existing tests cover it. +- Grep renamed/removed symbols for all call sites and import chains. +- Check package manifests/dependency files before adding dependencies. +- Anticipate compile issues: missing overrides, type mismatches, broken imports. +- Confirm final verification commands work in this repository layout. + +## Step 3 - Archive Existing Active Files + +Before writing new active files for the chosen task: + +- Count existing `agent-task/{task_name}/plan_*.log`; call it `N`. If `PLAN.md` exists, rename it to `plan_N.log`. +- Count existing `agent-task/{task_name}/code_review_*.log`; call it `M`. If `CODE_REVIEW.md` exists, rename it to `code_review_M.log`. + +The new plan number is the count of `plan_*.log` after archiving. + +## Step 4 - Write PLAN.md + +Header line must be exactly: + +```markdown + +``` + +Required sections: + +- Title. +- `이 파일을 읽는 구현 에이전트에게`: tell the implementer to complete checklists, run intermediate/final verification, and fill every `CODE_REVIEW.md` section with actual implementation notes and command output. +- `배경`: 2-4 sentences explaining why the work is needed. +- One item per change: `### [TAG-1] Title`, `TAG-2`, etc. +- `수정 파일 요약`: table mapping files to item ids. +- `최종 검증`: runnable commands and expected outcome. + +Each plan item must include: + +- `문제`: concrete problem with file:line references. +- `해결 방법`: exact approach and before/after code block for non-trivial changes. +- `수정 파일 및 체크리스트`: exhaustive file-level checklist. +- `테스트 작성`: explicit write/skip decision. If writing tests, include path, test name, assertion goal, and fixtures. If skipping, justify. +- `중간 검증`: runnable commands and expected result. + +Include `의존 관계 및 구현 순서` only when order matters. + +Quality rules: + +- Exact line numbers in every Before snippet. +- Use the language's required override annotation/keyword wherever an abstract method is implemented. +- Include full import statements for new packages. +- List all call sites for renamed/removed symbols. +- Never write "add tests as needed"; decide up front. +- Do not cite files you did not read. + +Test policy: + +| Change | Test requirement | +|--------|------------------| +| Bug fix | Regression test required | +| New public API | Normal + boundary tests required | +| API rename | Existing test call-site updates usually enough | +| Internal refactor | Existing tests may be enough | +| Concurrency logic | Race/ordering test recommended | + +## Step 5 - Write CODE_REVIEW.md Stub + +Use the template below exactly. Fill `{…}` placeholders from the plan; everything else is fixed and must not be changed by the implementing agent. + +```markdown + + +# Code Review Reference - {TAG} + +## 개요 + +date={YYYY-MM-DD} +task={task_name}, plan={N}, tag={TAG} + +## 이 파일을 읽는 리뷰 에이전트에게 + +각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요. +리뷰 완료 후 반드시 아래 순서로 아카이브하세요. + +1. `CODE_REVIEW.md` → `code_review_N.log` (N = 기존 code_review_*.log 수) +2. `PLAN.md` → `plan_M.log` (M = 기존 plan_*.log 수) +3. PASS인 경우 `complete.log` 작성 후 종료. WARN/FAIL인 경우 새 `PLAN.md` + `CODE_REVIEW.md` 스텁 작성. + +--- + +## 구현 항목별 완료 여부 + +| 항목 | 완료 여부 | +|------|---------| +| [{TAG}-1] {item description} | [ ] | +| [{TAG}-2] {item description} | [ ] | + +## 계획 대비 변경 사항 + +_구현 에이전트가 계획과 다르게 구현한 부분을 이유와 함께 기록한다._ + +## 주요 설계 결정 + +_구현 에이전트가 주요 설계 결정 사항을 기록한다._ + +## 리뷰어를 위한 체크포인트 + +{pre-filled from plan — one bullet per review focus area} + +## 검증 결과 + +_구현 에이전트가 각 중간 검증 및 최종 검증 명령 실행 후 출력을 여기에 붙여 넣는다._ + +### {TAG}-1 중간 검증 +``` +$ {verification command from plan} +(output) +``` + +### 최종 검증 +``` +$ {final verification command from plan} +(output) +``` +``` + +Sections and their ownership: + +| 섹션 | 소유자 | 설명 | +|------|--------|------| +| 헤더 주석, 개요(date/task/plan/tag), 리뷰 에이전트 지시 | 스텁 생성 시 고정 | 구현 에이전트가 수정하지 않음 | +| 구현 항목별 완료 여부 (항목명) | 스텁 생성 시 고정 | `[ ]` → `[x]` 체크만 구현 에이전트가 수행 | +| 계획 대비 변경 사항, 주요 설계 결정 | 구현 에이전트가 채움 | placeholder 텍스트를 실제 내용으로 교체 | +| 리뷰어를 위한 체크포인트 | 스텁 생성 시 고정 | 계획에서 추출한 리뷰 포인트 | +| 검증 결과 (섹션 제목 + 명령) | 스텁 생성 시 고정 | 실행 출력만 구현 에이전트가 채움 | +| 코드리뷰 결과 | 리뷰 에이전트가 append | 스텁에 포함하지 않음 | + +## Naming + +| Tag | Use for | +|-----|---------| +| `API` | Public API changes | +| `REFACTOR` | Internal refactoring | +| `TEST` | Test additions/fixes | +| `REVIEW_` | Follow-up fixes after review | + +## Final Checklist + +- `PLAN.md` and `CODE_REVIEW.md` both exist under `agent-task/{task_name}/`. +- Both first lines match ``. +- Previous active files, if any, were archived with correct numeric suffixes. +- Every plan item has problem, solution, checklist, test decision, and intermediate verification. +- `CODE_REVIEW.md` completion table lists every plan item. diff --git a/agent-ops/skills/common/plan/agents/openai.yaml b/agent-ops/skills/common/plan/agents/openai.yaml new file mode 100644 index 0000000..751c35e --- /dev/null +++ b/agent-ops/skills/common/plan/agents/openai.yaml @@ -0,0 +1,4 @@ +interface: + display_name: "Plan" + short_description: "Write implementation plans" + default_prompt: "Use $plan to create a task PLAN.md and CODE_REVIEW.md stub for this repository change." diff --git a/agent-ops/skills/common/router.md b/agent-ops/skills/common/router.md index 5eea531..6fe73f5 100644 --- a/agent-ops/skills/common/router.md +++ b/agent-ops/skills/common/router.md @@ -5,6 +5,7 @@ | agent-ops 세팅해줘, scaffold 만들어줘, 초기화해줘 | `agent-ops/skills/common/init-agent-ops/SKILL.md` | | domain rule 만들어줘, rules.md 생성, 새 도메인 규칙 | `agent-ops/skills/common/create-domain-rule/SKILL.md` | | skill 만들어줘, SKILL.md 생성, 새 스킬 추가 | `agent-ops/skills/common/create-skill/SKILL.md` | +| 계획 세워줘, 구현 계획, PLAN.md, plan | `agent-ops/skills/common/plan/SKILL.md` | +| 코드 리뷰해줘, code review, CODE_REVIEW.md, 리뷰 루프 | `agent-ops/skills/common/code-review/SKILL.md` | | 커밋해줘, 푸시해줘, commit, push, 반영해줘 | `agent-ops/skills/common/commit-push/SKILL.md` | -| 버전 올려줘, 버전 변경 | `agent-ops/skills/common/version-bump/SKILL.md` | -| agent-ops 업데이트해줘, 진입 파일 재적용해줘 | `agent-ops/skills/common/sync-agent-ops/SKILL.md` | +| agent-ops 싱크해, agent-ops 동기화해, agentic-framework에 올려줘, agent-ops를 [프로젝트]로 싱크해 | `agent-ops/skills/common/sync-agent-ops/SKILL.md` | diff --git a/agent-ops/skills/common/sync-agent-ops/SKILL.md b/agent-ops/skills/common/sync-agent-ops/SKILL.md index ed60346..bc3f9ae 100644 --- a/agent-ops/skills/common/sync-agent-ops/SKILL.md +++ b/agent-ops/skills/common/sync-agent-ops/SKILL.md @@ -1,68 +1,44 @@ --- name: sync-agent-ops -version: 1.0.0 -description: 공통 관리 레포의 rules/common/rules.md 변경 내용을 진입 파일에 재적용한다. "agent-ops 업데이트해줘", "진입 파일 재적용해줘" 요청 시 사용한다. +description: agent-ops를 agentic-framework와 동기화한다. "agent-ops 싱크해", "agent-ops 동기화해" 요청 시 사용한다. --- # sync-agent-ops ## 목적 -공통 관리 레포에서 `rules/common/rules.md`가 변경됐을 때, -프로젝트 루트의 에이전트 진입 파일들에 변경 내용을 반영한다. +`agent-ops/bin/sync.sh`를 호출해 agent-ops를 동기화한다. +현재 프로젝트가 agentic-framework인지 여부에 따라 동작이 달라진다. ## 언제 호출할지 -- 공통 관리 레포에서 `rules/common/`이 업데이트된 후 -- "agent-ops 업데이트해줘", "진입 파일 재적용해줘" 요청 시 -- 진입 파일이 `rules/common/rules.md`와 동기화되지 않은 것이 확인됐을 때 - -## 입력 - -- 없음 (파라미터 없이 실행) - -## 먼저 확인할 것 - -- [ ] `agent-ops/rules/common/rules.md` 파일이 존재하는가 -- [ ] 프로젝트 루트에 진입 파일이 하나 이상 존재하는가 +- "agent-ops 싱크해", "agent-ops 동기화해" 요청 시 +- "agentic-framework에 올려줘" 요청 시 +- "agent-ops를 [프로젝트]로 싱크해" 요청 시 ## 실행 절차 -1. `agent-ops/.version` 파일이 있으면 현재 프레임워크 버전을 읽고 출력한다 -2. `agent-ops/rules/common/rules.md`를 읽는다 -3. 프로젝트 루트에 존재하는 진입 파일을 확인한다 -4. 존재하는 진입 파일을 `rules/common/rules.md` 내용으로 덮어쓴다 -5. 결과를 출력한다 +### 현 프로젝트가 일반 프로젝트인 경우 (`.agent-ops-source` 없음) -## 에이전트별 진입 파일 +1. 동일 레벨에 `agentic-framework` 폴더가 있는지 확인한다 +2. **있으면**: `agent-ops/bin/sync.sh agentic-framework` 실행 +3. **없으면**: 사용자에게 agentic-framework 경로 입력을 안내하고, 입력받은 경로로 실행 -| 에이전트 | 파일명 | -|---------|--------| -| Claude | `CLAUDE.md` | -| Gemini | `GEMINI.md` | -| Kilo Code / OpenCode | `AGENTS.md` | -| Cursor | `.cursorrules` | -| Cline | `.clinerules` | +### 현 프로젝트가 agentic-framework인 경우 (`.agent-ops-source` 있음) + +1. 사용자 요청에서 target 프로젝트명 또는 경로를 추출한다 +2. **명시된 경우**: `agent-ops/bin/sync.sh ` 실행 +3. **명시되지 않은 경우**: 사용자에게 대상 프로젝트 입력을 요청한다 + +```bash +agent-ops/bin/sync.sh +``` ## 실행 결과 검증 -- [ ] 덮어쓴 진입 파일의 내용이 `rules/common/rules.md`와 정확히 일치하는가 -- [ ] 기존에 존재하던 진입 파일이 누락 없이 모두 업데이트되었는가 -- 검증 실패 시: 불일치하는 파일명과 차이점을 사용자에게 알린다 - -## 출력 형식 - -``` -## 동기화 완료 - -- 프레임워크 버전: {버전} (해당 시) -- 업데이트된 진입 파일: - - {파일명}: 업데이트 완료 -- 변경 없는 파일: {파일명} (해당 시) -``` +- [ ] sync.sh 가 오류 없이 완료됐는가 +- [ ] 버전 충돌 경고가 없었는가 — 있었다면 사용자에게 수동 머지 필요함을 알린다 ## 금지 사항 -- `rules/common/rules.md`를 수정하지 않는다. -- `rules/project/rules.md` 등 다른 파일을 건드리지 않는다. -- 존재하지 않는 진입 파일을 새로 생성하지 않는다. +- sync.sh 를 거치지 않고 직접 파일을 복사하지 않는다 diff --git a/agent-ops/skills/common/version-bump/SKILL.md b/agent-ops/skills/common/version-bump/SKILL.md deleted file mode 100644 index 178447c..0000000 --- a/agent-ops/skills/common/version-bump/SKILL.md +++ /dev/null @@ -1,81 +0,0 @@ ---- -name: version-bump -version: 1.0.0 -description: 프로젝트의 버전 정보를 업데이트한다. "버전 올려줘", "버전 변경" 요청 시 사용한다. ---- - -# version-bump - -## 목적 - -프로젝트의 버전 정보를 관리하며, 요청에 따라 버전을 올리거나 지정된 값으로 변경한다. - -## 언제 호출할지 - -- "버전 올려줘", "버전 변경해줘" 요청 시 -- 릴리스 준비 시 버전 업데이트가 필요할 때 -- patch, minor, major 버전 변경 요청 시 - -## 입력 - -- `version-type`: patch / minor / major 중 하나 (선택, 기본값: patch) -- `version-value`: 직접 지정할 버전 값 (선택, version-type과 배타적) - -## 먼저 확인할 것 - -- [ ] 버전 관리 파일(빌드 설정 또는 패키지 파일)이 프로젝트에 존재하는가 -- [ ] 현재 버전 값을 읽을 수 있는가 - -## 실행 절차 -1. 현재 버전 정보를 읽는다 -2. 사용자에게 변경할 버전을 확인한다 - - 인자 없으면: patch 버전 +1 - - 인자 있으면: 지정된 값으로 변경 -3. 버전 파일의 해당 값을 수정 -4. 변경 결과를 출력 - -## 버전 규칙 - -### 형식 -`major.minor.patch` (예: `1.0.0`) - -### 각 자리 제약 -| 자리 | 최대값 | 제약 | -|------|--------|------| -| major | 제한 없음 | 자유롭게 증가 | -| minor | 999 | 0~999 범위 | -| patch | 999 | 0~999 범위 | - -### 올림(carry) 규칙 -버전을 +1 할 때 해당 자리가 999이면 상위 자리를 올리고 현재 자리를 0으로 초기화한다. - -``` -patch +1 시: - patch < 999 → patch + 1 - patch = 999 → minor + 1, patch = 0 - (minor도 999이면 → major + 1, minor = 0, patch = 0) - -예시: - 1.0.998 → 1.0.999 - 1.0.999 → 1.1.0 - 1.999.999 → 2.0.0 -``` - -## 출력 형식 -``` -버전 업데이트 완료: -- 이전: 1.0.0 -- 이후: 1.0.1 -``` - -## 실행 결과 검증 - -- [ ] 버전 파일을 다시 읽어 변경된 버전 값이 의도한 값과 일치하는가 -- [ ] 버전 형식이 `major.minor.patch` 규칙을 준수하는가 (minor, patch가 0~999 범위) -- 검증 실패 시: 변경 전 버전과 현재 값을 사용자에게 보여주고 수동 확인을 요청한다 - -## 금지 사항 - -- 사용자 확인 없이 버전을 변경하지 않는다 -- 버전 형식(`major.minor.patch`)을 벗어나는 값으로 변경하지 않는다 -- minor, patch 값을 999 초과로 설정하지 않는다