toki/iop
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

sync: agent-ops from agentic-framework v1.1.110

Browse source
This commit is contained in:
toki 2026-05-30 21:09:24 +09:00
parent 11382a397f
commit e641daef38
3 changed files with 32 additions and 13 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
agent-ops/.version
View file

@ -1 +1 @@
1.1.108
1.1.110

31
agent-ops/skills/common/create-test/SKILL.md
View file

@ -1,14 +1,14 @@
---
name: create-test
version: 1.1.1
description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테스트 rule 문서를 생성하는 스킬
version: 1.1.4
description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테스트 rule 문서를 생성하거나 구조적 blank/skeleton baseline을 보완하는 스킬
---
# create-test
## 목적
`agent-test/<env>/rules.md`와 `agent-test/<env>/<test-profile>.md`를 템플릿 기준으로 생성한다.
`agent-test/<env>/rules.md`와 `agent-test/<env>/<test-profile>.md`를 템플릿 기준으로 생성하거나 구조적 blank/skeleton 상태에서 baseline으로 보완한다.
공통 진입점은 얇게 유지하고, 실제 테스트 기준은 환경/도메인/검증 시나리오별 문서에 둔다.
`test-case`는 기존 호출과의 호환을 위한 alias이며, 새 문서 기준 이름은 `test-profile`이다.
@ -17,6 +17,7 @@ description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테
- 새 테스트 환경을 추가할 때
- 특정 환경의 `rules.md`가 없을 때
- 특정 환경의 `rules.md`가 비어 있거나 템플릿 뼈대만 있어 baseline 보완이 필요할 때
- 새 도메인/검증 시나리오별 테스트 문서와 라우팅을 추가할 때
- `init-agent-ops` 후 local 테스트 환경 보완이 필요할 때
@ -34,6 +35,10 @@ description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테
- 도메인 매핑이나 domain rule에서 도메인이 하나 이상 확인되면, 누락된 `agent-test/<env>/<domain>-smoke.md`를 도메인별로 항상 생성한다.
- 명시 `test-profile`은 추가 생성 대상이다. 명시 대상만 만들고 도메인 baseline을 생략하지 않는다.
- 도메인이 하나도 확인되지 않을 때만 `agent-test/<env>/project-smoke.md`를 fallback baseline으로 만든다.
- env rules는 빈 파일, 제목/frontmatter만 있는 파일, 필수 섹션 누락, 또는 `## 라우팅`에 실제 profile 경로가 없으면 구조적 blank/skeleton으로 본다.
- test-profile 문서는 빈 파일, 제목/frontmatter만 있는 파일, 필수 섹션 누락, 또는 적용 범위/분류/명령/필수 검증/판정 기준 섹션 자체가 없으면 구조적 blank/skeleton으로 본다.
- 필수 섹션은 있고 일부 값이 비어 있거나 `<확인 필요>`인 상태는 구조적 blank/skeleton이 아니다. 이 경우 structured-incomplete로 보고 확인된 구체 값과 미확인 항목을 결과에 남긴다.
- 구조적 blank/skeleton env rules나 profile은 기존 완성 문서가 아니라 baseline 보완 대상으로 본다. 확인된 구체 값은 보존하고, 빠진 필수 섹션과 baseline 라우팅만 채운다.
## 먼저 확인할 것
@ -45,15 +50,18 @@ description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테
- [ ] `agent-ops/rules/common/_templates/test-env-rules-template.md`를 읽는다.
- [ ] `agent-ops/rules/common/_templates/test-case-rule-template.md`를 읽는다.
- [ ] `agent-test/<env>/rules.md` 존재 여부를 확인한다.
- [ ] 도메인 baseline과 추가 생성 대상 `agent-test/<env>/*.md`의 존재 여부를 확인한다.
- [ ] `agent-test/<env>/rules.md`가 있으면 읽고 missing / blank-skeleton / structured-incomplete / usable 중 하나로 분류한다.
- [ ] 도메인 baseline과 추가 생성 대상 `agent-test/<env>/*.md`의 존재 여부를 확인하고, 있으면 blank-skeleton / structured-incomplete / usable 중 하나로 분류한다.
## 실행 절차
1. **환경 rules 생성**
- `agent-test/<env>/rules.md`가 없으면 `test-env-rules-template.md` 형식으로 만든다.
- `agent-test/<env>/rules.md`가 구조적 blank/skeleton이면 기존 구체 값을 보존한 채 빠진 frontmatter, 정독 필수 문구, 필수 섹션, baseline 라우팅 영역만 보완한다.
- usable한 기존 env rules는 덮어쓰지 않고 라우팅 추가가 필요한 경우에만 최소 수정한다.
- 제목은 `# <env> 테스트 규칙`으로 쓴다.
- 제목 바로 아래 정독 필수 문구를 유지한다.
- `last_rule_updated_at`은 생성일 `YYYY-MM-DD`로 쓴다.
- `last_rule_updated_at`은 생성/보완일 `YYYY-MM-DD`로 쓴다.
2. **생성 대상 확정**
- `test-case`가 있고 `test-profile`이 없으면 `test-profile`로 취급한다.
@ -66,7 +74,9 @@ description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테
- 도메인은 새로 발명하지 않는다. 도메인 매핑이나 domain rule에서 확인되지 않은 이름은 `project-wide`로 기록한다.
3. **도메인/검증 시나리오별 문서 생성**
- 생성 대상마다 `agent-test/<env>/<test-profile>.md`를 `test-case-rule-template.md` 형식으로 만든다.
- 생성 대상 문서가 없으면 `agent-test/<env>/<test-profile>.md`를 `test-case-rule-template.md` 형식으로 만든다.
- 대상 문서가 이미 있고 usable하면 덮어쓰지 않는다.
- 대상 문서가 구조적 blank/skeleton이면 기존 구체 값을 보존한 채 빠진 frontmatter와 필수 섹션을 보완한다.
- frontmatter에는 `test_profile`, `domain`, `verification_type`, `last_rule_updated_at`을 채운다.
- 파일명은 kebab-case로 쓴다.
- 실제 확인된 환경, 명령, 판정 기준만 채운다.
@ -75,7 +85,8 @@ description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테
4. **라우팅 갱신**
- 새 환경을 만들었고 `agent-ops/rules/common/rules.md`에 해당 env 라인이 없으면 `# 테스트 규칙`에 한 줄을 추가한다.
- 생성한 `test-profile` 문서는 `agent-test/<env>/rules.md`의 `## 라우팅`에 한 줄씩 추가한다.
- 생성하거나 보완한 `test-profile` 문서는 `agent-test/<env>/rules.md`의 `## 라우팅`에 한 줄씩 추가한다.
- 이미 같은 profile로 향하는 라우팅이 있으면 중복 추가하지 않고 설명만 필요할 때 최소 보정한다.
- 라우팅 설명은 `<domain 또는 project-wide> / <verification-type> / <scope 요약>` 형식으로 쓴다.
- 도메인/검증 시나리오별 문서에서 다른 테스트 문서로 라우팅하지 않는다.
- 공통룰에서 스킬 최종 진입까지의 경로는 `rules.md` -> `router.md` -> `create-test/SKILL.md`로 유지한다.
@ -87,6 +98,7 @@ description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테
- 생성한 파일
- 추가한 라우팅
- 자동 생성 기준: 도메인 baseline / 명시 입력 / scope 매칭 / project-smoke fallback
- 구조적 blank/skeleton 보완 대상
- 비워 둔 확인 필요 항목
## 실행 결과 검증
@ -97,6 +109,7 @@ description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테
- [ ] 새 도메인/검증 시나리오별 문서가 env rules의 라우팅에 연결되었는가
- [ ] 확인된 모든 도메인에 `<domain>-smoke` 문서가 생성되었는가
- [ ] 도메인이 없을 때 `project-smoke` fallback 문서가 생성되었는가
- [ ] 생성/보완 대상에 섹션 누락이나 라우팅 없는 구조적 blank/skeleton 파일이 남아 있지 않고, 불확실한 값은 `<확인 필요>`로 보고되었는가
- [ ] local 생성 시 `.gitignore`에 local 경로가 반영되었는가
- 검증 실패 시: 누락된 파일/섹션/라우팅만 보완한다.
@ -110,12 +123,14 @@ description: agent-test 환경 rules.md와 도메인/검증 시나리오별 테
- 테스트 profiles: <agent-test/<env>/<test-profile>.md 목록>
- 라우팅 추가: <내용>
- 자동 생성 기준: <도메인 baseline | 명시 입력 | scope 매칭 | project-smoke fallback>
- 구조적 blank/skeleton 보완: <파일 목록 또는 없음>
- 확인 필요: <항목 또는 없음>
```
## 금지 사항
- 기존 테스트 문서를 덮어쓰지 않는다.
- usable한 기존 테스트 문서를 덮어쓰지 않는다.
- 구조적 blank/skeleton 보완 시에도 확인된 구체 환경값, 명령, 판정 기준을 추측으로 교체하지 않는다.
- 도메인/검증 시나리오별 문서에서 추가 테스트 문서로 라우팅하지 않는다.
- 도메인 매핑이나 domain rule에 없는 도메인을 확정값처럼 만들지 않는다.
- 확인되지 않은 host, port, token, endpoint를 추측해 쓰지 않는다.

12
agent-ops/skills/common/plan/SKILL.md
View file

@ -161,10 +161,12 @@ Before choosing plan files or task directory names, apply the split decision pol
## Step 2 - Analyze Before Writing
Complete all items below before creating any files. Work through them in order; do not proceed to the next step until every checkbox is done.
Complete all items below before creating active plan/review files. Work through them in order; do not proceed to the next step until every checkbox is done. The only allowed pre-plan file edits are `create-test` or `update-test` edits needed to make test rules usable for this plan.
- [ ] **Load test environment rules** — because implementation plans include verification, determine `test_env` before choosing verification commands. Use the user-specified environment when provided; otherwise use `local`. Check `agent-test/<test_env>/rules.md` and read it in full when present, even if it appears blank or skeleton. If it is absent, or present but structurally blank/skeleton, invoke `create-test` with `env=<test_env>` when this repo can be edited, then re-read the generated or completed rules before writing the plan. If creation is not possible in the current task context, record the gap and fallback source; absence is not a user-review blocker by itself.
- [ ] **Read all source files in full** — read every source file the change will touch, whole file. No partial reads.
- [ ] **Read all test files in full** — read every test file that exercises the changed behavior.
- [ ] **Resolve test profiles** — from the env rules `## 라우팅`, read every matching `agent-test/<test_env>/<test-profile>.md` in full. Use `create-test` for missing or structurally blank routes/profiles when the current task can safely fill the gap. Use `update-test` only when verified command or criteria facts are available or the user asked to maintain test rules. If a profile exists but leaves command/criteria values as `<확인 필요>`, record the incomplete values and choose fallback verification commands from repository manifests or workflows with lower confidence. Do not claim agent-test requires a command that is not written in the env rules or matched profiles.
- [ ] **Read all test files in full** — read every test file that exercises the changed behavior, including files implied by the matched agent-test profiles and repository test layout.
- [ ] **Assess test coverage** — for each behavior change, explicitly record whether existing tests cover it.
- [ ] **Assess split boundaries first** — identify dependency boundaries, ownership boundaries, API-vs-call-site phases, test strategy splits, risk profile splits, and independently verifiable subwork before selecting plan files. If any split gate applies or the decision is uncertain, write multiple subtask directories under one task group instead of one plan.
- [ ] **Grep all symbol references** — for any renamed or removed symbol, find every call site and import chain.
@ -226,7 +228,8 @@ Required sections:
- Completion mode: check-on-pass
```
- `분석 결과`: record the findings from Step 2 and Step 3. This section is the written output of the analysis — not a summary, but the actual findings that justify the plan's scope and decisions. Must include all of the following subsections:
- `읽은 파일`: list every source and test file read during analysis, with path.
- `읽은 파일`: list every source, test, and agent-test rule/profile file read during analysis, with path.
- `테스트 환경 규칙`: state the chosen `test_env`, whether `agent-test/<test_env>/rules.md` was present and read, every matched profile path read, the concrete rules/commands applied, any structural blank/skeleton or missing rules, any `<확인 필요>` values, and any fallback verification source. If agent-test is absent or unusable, explicitly say no agent-test rule was applied and whether `create-test` or `update-test` should later fill the gap.
- `테스트 커버리지 공백`: list each behavior change and whether existing tests cover it; explicitly note gaps.
- `심볼 참조`: list renamed/removed symbols and every call site found, or state "none" if no symbols were changed.
- `분할 판단`: state that the split decision policy was evaluated before choosing plan files. For a single plan, explain why each relevant split gate does not apply and why single-plan coordination is safer than splitting. For multi-plan output, list the shared task group plus each sibling subtask directory and dependency relationship.
@ -235,7 +238,7 @@ Required sections:
- `구현 체크리스트`: a top-level checklist the implementing agent must follow while coding. Include one item per implementation/verification unit; if the roadmap feature Task has `검증:`, keep that verification in the same checklist item instead of making a separate completion-criteria item. Include one item for whole-plan intermediate/final verification only when it is not already covered by the feature items, and make the final item exactly: `- [ ] CODE_REVIEW-*-G??.md의 구현 에이전트 소유 섹션을 실제 구현 내용과 검증 출력으로 채운다. 이 항목이 완료되기 전에는 구현이 완료된 것이 아니다.` Copy this checklist into the review stub's `구현 체크리스트` section with the same item text and order.
- One item per change: `### [TAG-1] Title`, `TAG-2`, etc.
- `수정 파일 요약`: table mapping files to item ids.
- `최종 검증`: runnable commands and expected outcome. Commands must be exact and deterministic enough for the reviewer to rerun; use stable ordering for searches and state whether cached test output is acceptable. The final line of this section must read exactly — **"모든 코드 변경 완료 후 반드시 `CODE_REVIEW-*-G??.md`의 구현 에이전트 소유 섹션을 채운다. 이 파일 작성이 구현의 마지막 단계다."**
- `최종 검증`: runnable commands and expected outcome. Prefer commands from the matched agent-test env/profile rules. If agent-test is missing, blank, skeleton, or lacks a matching command, use repository manifests/workflows as fallback and record that fallback in `분석 결과 > 테스트 환경 규칙`. Commands must be exact and deterministic enough for the reviewer to rerun; use stable ordering for searches and state whether cached test output is acceptable. The final line of this section must read exactly — **"모든 코드 변경 완료 후 반드시 `CODE_REVIEW-*-G??.md`의 구현 에이전트 소유 섹션을 채운다. 이 파일 작성이 구현의 마지막 단계다."**
Each plan item must include:
@ -436,6 +439,7 @@ Sections and their ownership:
- If resuming from `USER_REVIEW.md`, it was archived to `user_review_N.log` and the user decision was recorded in the new plan.
- `Roadmap Targets` exists only when PASS should check explicit Milestone Task ids, the task group is `m-<milestone-slug>` for the listed Milestone path, and every listed Task id exists in the selected active Milestone.
- If `Roadmap Targets` exists in the plan, the review stub contains the identical section. If it does not exist in the plan, the review stub omits it too.
- `분석 결과 > 테스트 환경 규칙` records the selected test env, env rules read/missing/structural-blank state, matched profiles read, and any fallback verification source.
- Every plan item has problem, solution, checklist, test decision, and intermediate verification.
- The plan and review stub have matching `구현 체크리스트` item text/order, and the final checkbox is the mandatory `CODE_REVIEW-*-G??.md` completion item.
- The plan's implementer instructions and review stub both explain the implementation-time `사용자 리뷰 요청` stop path.