chore: sync agent-ops
This commit is contained in:
parent
1eff82483b
commit
30efee61df
25 changed files with 1966 additions and 24 deletions
16
.clinerules
Normal file
16
.clinerules
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
# 공통 규칙
|
||||
|
||||
- 기존 구조를 우선한다. 새 파일 생성보다 기존 파일 수정을 우선한다.
|
||||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
|
||||
|
||||
`agent-ops/rules/project/rules.md`와 `agent-ops/rules/private/rules.md`는 세션 최초 1회 읽는다. 파일이 없으면 무시한다.
|
||||
|
||||
아래 성격의 요청은 사용자가 명시적으로 요청한 경우에만 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다. 자동으로 수행하지 않는다.
|
||||
- agent-ops 초기화
|
||||
- domain rule 생성
|
||||
- skill 생성
|
||||
- git commit / push
|
||||
- agent-ops 업데이트 / 진입 파일 재적용
|
||||
16
.cursorrules
Normal file
16
.cursorrules
Normal file
|
|
@ -0,0 +1,16 @@
|
|||
# 공통 규칙
|
||||
|
||||
- 기존 구조를 우선한다. 새 파일 생성보다 기존 파일 수정을 우선한다.
|
||||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
|
||||
|
||||
`agent-ops/rules/project/rules.md`와 `agent-ops/rules/private/rules.md`는 세션 최초 1회 읽는다. 파일이 없으면 무시한다.
|
||||
|
||||
아래 성격의 요청은 사용자가 명시적으로 요청한 경우에만 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다. 자동으로 수행하지 않는다.
|
||||
- agent-ops 초기화
|
||||
- domain rule 생성
|
||||
- skill 생성
|
||||
- git commit / push
|
||||
- agent-ops 업데이트 / 진입 파일 재적용
|
||||
23
AGENTS.md
23
AGENTS.md
|
|
@ -1,9 +1,16 @@
|
|||
## 응답 언어
|
||||
한국어로 응답한다.
|
||||
# 공통 규칙
|
||||
|
||||
## 기본 원칙
|
||||
- 기존 구조를 우선한다.
|
||||
- 새 파일 생성보다 기존 파일 수정을 우선한다.
|
||||
- 작업 전 `agent-ops/skills/router.md`를 참조하여 필요한 skill 또는 domain rule만 로드한다.
|
||||
- 관련 rule / skill만 최소로 로드한다.
|
||||
- 세부 규칙은 `agent-ops/` 아래 파일을 따른다.
|
||||
- 기존 구조를 우선한다. 새 파일 생성보다 기존 파일 수정을 우선한다.
|
||||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
|
||||
|
||||
`agent-ops/rules/project/rules.md`와 `agent-ops/rules/private/rules.md`는 세션 최초 1회 읽는다. 파일이 없으면 무시한다.
|
||||
|
||||
아래 성격의 요청은 사용자가 명시적으로 요청한 경우에만 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다. 자동으로 수행하지 않는다.
|
||||
- agent-ops 초기화
|
||||
- domain rule 생성
|
||||
- skill 생성
|
||||
- git commit / push
|
||||
- agent-ops 업데이트 / 진입 파일 재적용
|
||||
|
|
|
|||
23
CLAUDE.md
23
CLAUDE.md
|
|
@ -1,9 +1,16 @@
|
|||
## 응답 언어
|
||||
한국어로 응답한다.
|
||||
# 공통 규칙
|
||||
|
||||
## 기본 원칙
|
||||
- 기존 구조를 우선한다.
|
||||
- 새 파일 생성보다 기존 파일 수정을 우선한다.
|
||||
- 작업 전 `agent-ops/skills/router.md`를 참조하여 필요한 skill 또는 domain rule만 로드한다.
|
||||
- 관련 rule / skill만 최소로 로드한다.
|
||||
- 세부 규칙은 `agent-ops/` 아래 파일을 따른다.
|
||||
- 기존 구조를 우선한다. 새 파일 생성보다 기존 파일 수정을 우선한다.
|
||||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
|
||||
|
||||
`agent-ops/rules/project/rules.md`와 `agent-ops/rules/private/rules.md`는 세션 최초 1회 읽는다. 파일이 없으면 무시한다.
|
||||
|
||||
아래 성격의 요청은 사용자가 명시적으로 요청한 경우에만 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다. 자동으로 수행하지 않는다.
|
||||
- agent-ops 초기화
|
||||
- domain rule 생성
|
||||
- skill 생성
|
||||
- git commit / push
|
||||
- agent-ops 업데이트 / 진입 파일 재적용
|
||||
|
|
|
|||
23
GEMINI.md
23
GEMINI.md
|
|
@ -1,9 +1,16 @@
|
|||
## 응답 언어
|
||||
한국어로 응답한다.
|
||||
# 공통 규칙
|
||||
|
||||
## 기본 원칙
|
||||
- 기존 구조를 우선한다.
|
||||
- 새 파일 생성보다 기존 파일 수정을 우선한다.
|
||||
- 작업 전 `agent-ops/skills/router.md`를 참조하여 필요한 skill 또는 domain rule만 로드한다.
|
||||
- 관련 rule / skill만 최소로 로드한다.
|
||||
- 세부 규칙은 `agent-ops/` 아래 파일을 따른다.
|
||||
- 기존 구조를 우선한다. 새 파일 생성보다 기존 파일 수정을 우선한다.
|
||||
- 코드 변경 전 관련 domain rule을 먼저 확인한다.
|
||||
- 요청 범위를 넘는 변경을 하지 않는다.
|
||||
- 불확실하면 단정하지 말고 후보를 제시한다.
|
||||
- `agent-task/archive/**`는 사용자가 명시적으로 요청한 경우에만 읽는다.
|
||||
|
||||
`agent-ops/rules/project/rules.md`와 `agent-ops/rules/private/rules.md`는 세션 최초 1회 읽는다. 파일이 없으면 무시한다.
|
||||
|
||||
아래 성격의 요청은 사용자가 명시적으로 요청한 경우에만 `agent-ops/skills/common/router.md`를 작업 최초 1회 읽고 수행한다. 자동으로 수행하지 않는다.
|
||||
- agent-ops 초기화
|
||||
- domain rule 생성
|
||||
- skill 생성
|
||||
- git commit / push
|
||||
- agent-ops 업데이트 / 진입 파일 재적용
|
||||
|
|
|
|||
1
agent-ops/.version
Normal file
1
agent-ops/.version
Normal file
|
|
@ -0,0 +1 @@
|
|||
1.1.14
|
||||
28
agent-ops/bin/bump-version.sh
Executable file
28
agent-ops/bin/bump-version.sh
Executable file
|
|
@ -0,0 +1,28 @@
|
|||
#!/usr/bin/env bash
|
||||
# bump-version.sh <version>
|
||||
# patch +1, 999 초과 시 minor 올림. major는 수동 관리.
|
||||
# 결과 버전을 stdout으로 출력.
|
||||
|
||||
set -euo pipefail
|
||||
|
||||
YELLOW='\033[1;33m'; RESET='\033[0m'
|
||||
|
||||
VERSION="${1:-}"
|
||||
if [[ -z "$VERSION" ]]; then
|
||||
echo "사용법: $0 <major.minor.patch>" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
IFS='.' read -r major minor patch <<< "$VERSION"
|
||||
|
||||
patch=$((patch + 1))
|
||||
if [[ $patch -gt 999 ]]; then
|
||||
patch=0
|
||||
minor=$((minor + 1))
|
||||
fi
|
||||
if [[ $minor -gt 999 ]]; then
|
||||
minor=0
|
||||
echo -e "${YELLOW}⚠ minor 버전이 999를 초과했습니다. major 버전을 수동으로 올려주세요.${RESET}" >&2
|
||||
fi
|
||||
|
||||
echo "$major.$minor.$patch"
|
||||
24
agent-ops/bin/entry-files.sh
Normal file
24
agent-ops/bin/entry-files.sh
Normal file
|
|
@ -0,0 +1,24 @@
|
|||
#!/usr/bin/env bash
|
||||
|
||||
# Shared entry-point file list for init/sync scripts.
|
||||
AGENT_OPS_ENTRY_FILES=("GEMINI.md" "CLAUDE.md" "AGENTS.md" ".cursorrules" ".clinerules")
|
||||
|
||||
apply_agent_ops_entry_files() {
|
||||
local rules_md="$1"
|
||||
local target_root="$2"
|
||||
|
||||
if [[ ! -f "$rules_md" ]]; then
|
||||
if [[ -n "${YELLOW:-}" && -n "${RESET:-}" ]]; then
|
||||
echo -e "${YELLOW} rules.md 없음, 진입 파일 재적용 건너뜀${RESET}"
|
||||
else
|
||||
echo " rules.md 없음, 진입 파일 재적용 건너뜀"
|
||||
fi
|
||||
return
|
||||
fi
|
||||
|
||||
local f
|
||||
for f in "${AGENT_OPS_ENTRY_FILES[@]}"; do
|
||||
cp "$rules_md" "$target_root/$f"
|
||||
echo " 진입 파일 적용: $f"
|
||||
done
|
||||
}
|
||||
104
agent-ops/bin/init-agent-ops.sh
Executable file
104
agent-ops/bin/init-agent-ops.sh
Executable file
|
|
@ -0,0 +1,104 @@
|
|||
#!/bin/bash
|
||||
|
||||
# agent-ops/bin/init-agent-ops.sh
|
||||
# 프로젝트에 agent-ops 스캐폴드를 초기화하는 스크립트
|
||||
|
||||
set -e
|
||||
|
||||
SCRIPT_DIR=$(realpath "$(dirname "$0")")
|
||||
SOURCE_DIR=$(realpath "$SCRIPT_DIR/..")
|
||||
source "$SCRIPT_DIR/entry-files.sh"
|
||||
|
||||
if [ -z "$1" ]; then
|
||||
echo "Usage: $0 <target_directory>"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
TARGET_DIR=$(realpath "$1")
|
||||
ARCHIVE_IGNORE_PATTERN="agent-task/archive/**"
|
||||
|
||||
append_unique_line() {
|
||||
local file="$1"
|
||||
local line="$2"
|
||||
|
||||
touch "$file"
|
||||
if ! grep -qxF "$line" "$file"; then
|
||||
printf "%s\n" "$line" >> "$file"
|
||||
fi
|
||||
}
|
||||
|
||||
echo "Initializing agent-ops in: $TARGET_DIR"
|
||||
echo "Source agent-ops: $SOURCE_DIR"
|
||||
|
||||
# 1. 대상 폴더 생성
|
||||
mkdir -p "$TARGET_DIR/agent-ops/rules/project/domain"
|
||||
mkdir -p "$TARGET_DIR/agent-ops/rules/private"
|
||||
mkdir -p "$TARGET_DIR/agent-ops/skills/project"
|
||||
|
||||
# 2. 공통 요소 복사 (프로젝트 전용 설정은 제외)
|
||||
cp "$SOURCE_DIR/.version" "$TARGET_DIR/agent-ops/"
|
||||
rm -rf "$TARGET_DIR/agent-ops/bin"
|
||||
cp -r "$SOURCE_DIR/bin" "$TARGET_DIR/agent-ops/"
|
||||
cp -r "$SOURCE_DIR/rules/common" "$TARGET_DIR/agent-ops/rules/"
|
||||
cp -r "$SOURCE_DIR/skills/common" "$TARGET_DIR/agent-ops/skills/"
|
||||
|
||||
# 3. 에이전트 진입 파일 생성 (common/rules.md 복사)
|
||||
COMMON_RULES="$SOURCE_DIR/rules/common/rules.md"
|
||||
apply_agent_ops_entry_files "$COMMON_RULES" "$TARGET_DIR"
|
||||
|
||||
# 4. AI ignore / permission 설정
|
||||
append_unique_line "$TARGET_DIR/.geminiignore" "$ARCHIVE_IGNORE_PATTERN"
|
||||
append_unique_line "$TARGET_DIR/.aiexclude" "$ARCHIVE_IGNORE_PATTERN"
|
||||
append_unique_line "$TARGET_DIR/.cursorignore" "$ARCHIVE_IGNORE_PATTERN"
|
||||
append_unique_line "$TARGET_DIR/.clineignore" "$ARCHIVE_IGNORE_PATTERN"
|
||||
|
||||
mkdir -p "$TARGET_DIR/.claude"
|
||||
if [ ! -f "$TARGET_DIR/.claude/settings.json" ]; then
|
||||
cat > "$TARGET_DIR/.claude/settings.json" <<'EOF'
|
||||
{
|
||||
"$schema": "https://json.schemastore.org/claude-code-settings.json",
|
||||
"permissions": {
|
||||
"deny": [
|
||||
"Read(./agent-task/archive/**)"
|
||||
]
|
||||
}
|
||||
}
|
||||
EOF
|
||||
elif ! grep -q "agent-task/archive" "$TARGET_DIR/.claude/settings.json"; then
|
||||
echo "Note: .claude/settings.json exists; add Read(./agent-task/archive/**) manually."
|
||||
fi
|
||||
|
||||
if [ ! -f "$TARGET_DIR/opencode.json" ]; then
|
||||
cat > "$TARGET_DIR/opencode.json" <<'EOF'
|
||||
{
|
||||
"$schema": "https://opencode.ai/config.json",
|
||||
"permission": {
|
||||
"read": {
|
||||
"agent-task/archive/**": "deny"
|
||||
},
|
||||
"glob": {
|
||||
"agent-task/archive/**": "deny"
|
||||
}
|
||||
},
|
||||
"watcher": {
|
||||
"ignore": [
|
||||
"agent-task/archive/**"
|
||||
]
|
||||
}
|
||||
}
|
||||
EOF
|
||||
elif ! grep -q "agent-task/archive" "$TARGET_DIR/opencode.json"; then
|
||||
echo "Note: opencode.json exists; add agent-task/archive/** read/glob deny and watcher ignore manually."
|
||||
fi
|
||||
|
||||
# 5. .gitignore 설정
|
||||
TOUCH_GITIGNORE="$TARGET_DIR/.gitignore"
|
||||
touch "$TOUCH_GITIGNORE"
|
||||
if ! grep -q "agent-ops/rules/private/" "$TOUCH_GITIGNORE"; then
|
||||
echo "" >> "$TOUCH_GITIGNORE"
|
||||
echo "# Agent-Ops Private Rules" >> "$TOUCH_GITIGNORE"
|
||||
echo "agent-ops/rules/private/" >> "$TOUCH_GITIGNORE"
|
||||
fi
|
||||
|
||||
echo "Successfully initialized agent-ops in $TARGET_DIR"
|
||||
echo "Note: agent-ops/rules/project and agent-ops/skills/project are initialized as empty."
|
||||
182
agent-ops/bin/sync.sh
Executable file
182
agent-ops/bin/sync.sh
Executable file
|
|
@ -0,0 +1,182 @@
|
|||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
# ── 경로 설정 ────────────────────────────────────────────────────────────────
|
||||
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
|
||||
AGENT_OPS_DIR="$(cd "$SCRIPT_DIR/.." && pwd)"
|
||||
PROJECT_ROOT="$(cd "$AGENT_OPS_DIR/.." && pwd)"
|
||||
|
||||
# ── 색상 ─────────────────────────────────────────────────────────────────────
|
||||
RED='\033[0;31m'; YELLOW='\033[1;33m'; GREEN='\033[0;32m'; RESET='\033[0m'
|
||||
|
||||
# ── 진입 파일 공통 관리 ──────────────────────────────────────────────────────
|
||||
source "$SCRIPT_DIR/entry-files.sh"
|
||||
|
||||
# ── 대상 경로 해석 (폴더명 / 상대경로 / 절대경로) ────────────────────────────
|
||||
resolve_target() {
|
||||
local input="$1"
|
||||
if [[ "$input" == /* ]]; then
|
||||
[[ -d "$input" ]] && echo "$input" || echo ""
|
||||
return
|
||||
fi
|
||||
if [[ "$input" == */* ]]; then
|
||||
local resolved
|
||||
resolved="$(cd "$input" 2>/dev/null && pwd)" || { echo ""; return; }
|
||||
echo "$resolved"
|
||||
return
|
||||
fi
|
||||
local sibling="$(dirname "$PROJECT_ROOT")/$input"
|
||||
[[ -d "$sibling" ]] && echo "$sibling" || echo ""
|
||||
}
|
||||
|
||||
# ── 버전 비교: v1 > v2 이면 0 반환 ───────────────────────────────────────────
|
||||
version_gt() {
|
||||
local v1="$1" v2="$2"
|
||||
[[ "$v1" == "$v2" ]] && return 1
|
||||
[[ "$(printf '%s\n%s' "$v1" "$v2" | sort -V | head -1)" == "$v2" ]]
|
||||
}
|
||||
|
||||
# ── 버전 +1 ──────────────────────────────────────────────────────────────────
|
||||
bump_version() {
|
||||
bash "$SCRIPT_DIR/bump-version.sh" "$1"
|
||||
}
|
||||
|
||||
# ── 폴더 동기화 (rules.md 제외, 삭제된 파일도 반영) ─────────────────────────
|
||||
sync_folder() {
|
||||
local src="$1" dst="$2" exclude="${3:-}"
|
||||
mkdir -p "$dst"
|
||||
# dst에서 src에 없는 항목 제거 (exclude 파일 보존)
|
||||
find "$dst" -mindepth 1 -maxdepth 1 | while IFS= read -r item; do
|
||||
local name
|
||||
name="$(basename "$item")"
|
||||
[[ -n "$exclude" && "$name" == "$exclude" ]] && continue
|
||||
if [[ ! -e "$src/$name" ]]; then
|
||||
rm -rf "$item"
|
||||
fi
|
||||
done
|
||||
# src에서 dst로 복사 (exclude 파일 제외)
|
||||
find "$src" -mindepth 1 -maxdepth 1 | while IFS= read -r item; do
|
||||
local name
|
||||
name="$(basename "$item")"
|
||||
[[ -n "$exclude" && "$name" == "$exclude" ]] && continue
|
||||
rm -rf "$dst/$name"
|
||||
cp -r "$item" "$dst/"
|
||||
done
|
||||
}
|
||||
|
||||
sync_common() {
|
||||
local src="$1" dst="$2"
|
||||
sync_folder "$src/rules/common" "$dst/rules/common" "rules.md"
|
||||
sync_folder "$src/skills/common" "$dst/skills/common"
|
||||
sync_folder "$src/bin" "$dst/bin"
|
||||
}
|
||||
|
||||
# ── 사용법 ────────────────────────────────────────────────────────────────────
|
||||
usage() {
|
||||
echo "사용법: $0 [--pull] <target>"
|
||||
echo ""
|
||||
echo " (기본) 현재 프로젝트 → target(agentic-framework) 으로 push"
|
||||
echo " --pull target(agentic-framework) → 현재 프로젝트 로 pull"
|
||||
echo ""
|
||||
echo " target: 폴더명 (동일 레벨 탐색) | 상대경로 | 절대경로"
|
||||
}
|
||||
|
||||
# ─────────────────────────────────────────────────────────────────────────────
|
||||
PULL_MODE="0"
|
||||
if [[ "${1:-}" == "--pull" ]]; then
|
||||
PULL_MODE="1"
|
||||
shift
|
||||
fi
|
||||
|
||||
TARGET_INPUT="${1:-}"
|
||||
if [[ -z "$TARGET_INPUT" ]]; then
|
||||
usage; exit 1
|
||||
fi
|
||||
|
||||
TARGET="$(resolve_target "$TARGET_INPUT")"
|
||||
if [[ -z "$TARGET" ]]; then
|
||||
echo -e "${RED}Error: 대상을 찾을 수 없습니다: $TARGET_INPUT${RESET}"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
SRC_AO="$AGENT_OPS_DIR"
|
||||
DST_AO="$TARGET/agent-ops"
|
||||
IS_FRAMEWORK="$([[ -f "$PROJECT_ROOT/.agent-ops-source" ]] && echo "1" || echo "0")"
|
||||
|
||||
# ── pull 모드: agentic-framework → 현재 프로젝트 ─────────────────────────────
|
||||
if [[ "$PULL_MODE" == "1" ]]; then
|
||||
if [[ "$IS_FRAMEWORK" == "1" ]]; then
|
||||
echo -e "${RED}Error: agentic-framework에서는 --pull을 사용할 수 없습니다.${RESET}"
|
||||
exit 1
|
||||
fi
|
||||
if [[ ! -f "$TARGET/.agent-ops-source" ]]; then
|
||||
echo -e "${RED}Error: target이 agentic-framework가 아닙니다 (.agent-ops-source 없음)${RESET}"
|
||||
exit 1
|
||||
fi
|
||||
SRC_VER="$(cat "$SRC_AO/.version" 2>/dev/null || echo "0.0.0")"
|
||||
DST_VER="$(cat "$DST_AO/.version" 2>/dev/null || echo "0.0.0")"
|
||||
echo "▶ $(basename "$TARGET") → $(basename "$PROJECT_ROOT") (pull)"
|
||||
echo " 현재 버전: $SRC_VER | framework 버전: $DST_VER"
|
||||
sync_common "$DST_AO" "$SRC_AO"
|
||||
cp "$DST_AO/.version" "$SRC_AO/.version"
|
||||
apply_agent_ops_entry_files "$DST_AO/rules/common/rules.md" "$PROJECT_ROOT"
|
||||
cd "$PROJECT_ROOT"
|
||||
git add agent-ops/rules/common agent-ops/skills/common agent-ops/bin agent-ops/.version \
|
||||
"${AGENT_OPS_ENTRY_FILES[@]}"
|
||||
git commit -m "sync: pull from agentic-framework v$DST_VER"
|
||||
git push
|
||||
echo -e "${GREEN}✓ 완료 (pull v$DST_VER)${RESET}"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
echo "▶ $(basename "$PROJECT_ROOT") → $(basename "$TARGET")"
|
||||
|
||||
# ── agentic-framework에서 다른 프로젝트로 ────────────────────────────────────
|
||||
if [[ "$IS_FRAMEWORK" == "1" ]]; then
|
||||
if [[ ! -d "$DST_AO" ]]; then
|
||||
echo " 최초 진행: agent-ops 전체 복사"
|
||||
cp -r "$SRC_AO" "$TARGET/"
|
||||
apply_agent_ops_entry_files "$SRC_AO/rules/common/rules.md" "$TARGET"
|
||||
echo -e "${YELLOW} init-agent-ops 스킬로 초기화를 진행하세요.${RESET}"
|
||||
else
|
||||
echo " 이후 진행: common/ 동기화"
|
||||
sync_common "$SRC_AO" "$DST_AO"
|
||||
cp "$SRC_AO/.version" "$DST_AO/.version"
|
||||
apply_agent_ops_entry_files "$SRC_AO/rules/common/rules.md" "$TARGET"
|
||||
fi
|
||||
echo -e "${GREEN}✓ 완료 → $(basename "$TARGET")${RESET}"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# ── 일반 프로젝트에서 agentic-framework로 (push) ─────────────────────────────
|
||||
if [[ ! -f "$TARGET/.agent-ops-source" ]]; then
|
||||
echo -e "${RED}Error: target이 agentic-framework가 아닙니다 (.agent-ops-source 없음)${RESET}"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
SRC_VER="$(cat "$SRC_AO/.version" 2>/dev/null || echo "0.0.0")"
|
||||
DST_VER="$(cat "$DST_AO/.version" 2>/dev/null || echo "0.0.0")"
|
||||
echo " 현재 버전: $SRC_VER | framework 버전: $DST_VER"
|
||||
|
||||
if version_gt "$DST_VER" "$SRC_VER"; then
|
||||
echo -e "${RED}⚠ 버전 충돌: framework($DST_VER) > current($SRC_VER)${RESET}"
|
||||
echo -e "${YELLOW} 먼저 sync-pull로 내려받은 뒤 재시도하세요.${RESET}"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
NEW_VER="$(bump_version "$SRC_VER")"
|
||||
sync_common "$SRC_AO" "$DST_AO"
|
||||
echo "$NEW_VER" > "$SRC_AO/.version"
|
||||
echo "$NEW_VER" > "$DST_AO/.version"
|
||||
|
||||
cd "$TARGET"
|
||||
git add agent-ops/rules/common agent-ops/skills/common agent-ops/bin agent-ops/.version
|
||||
git commit -m "sync: from $(basename "$PROJECT_ROOT") v$NEW_VER"
|
||||
git push
|
||||
cd "$PROJECT_ROOT"
|
||||
|
||||
git add agent-ops/rules/common agent-ops/skills/common agent-ops/bin agent-ops/.version
|
||||
git commit -m "sync: to agentic-framework v$NEW_VER"
|
||||
git push
|
||||
|
||||
echo -e "${GREEN}✓ 완료 (v$SRC_VER → v$NEW_VER)${RESET}"
|
||||
29
agent-ops/rules/common/_templates/domain-rule-template.md
Normal file
29
agent-ops/rules/common/_templates/domain-rule-template.md
Normal file
|
|
@ -0,0 +1,29 @@
|
|||
# <domain-name>
|
||||
|
||||
## 목적 / 책임
|
||||
|
||||
<이 도메인이 담당하는 책임을 1~2문장으로>
|
||||
|
||||
## 포함 경로
|
||||
|
||||
- `<path>/` — <이 경로가 이 도메인에 속하는 이유>
|
||||
|
||||
## 제외 경로
|
||||
|
||||
- `<path>/` — <왜 이 도메인이 아닌지>
|
||||
|
||||
## 주요 구성 요소
|
||||
|
||||
- `<ClassName>` — <역할>
|
||||
|
||||
## 유지할 패턴
|
||||
|
||||
- <네이밍 규칙 또는 아키텍처 패턴>
|
||||
|
||||
## 다른 도메인과의 경계
|
||||
|
||||
- **<인접 domain>**: <어디까지가 이 도메인이고 어디서부터 저 도메인인지>
|
||||
|
||||
## 금지 사항
|
||||
|
||||
- <이 도메인 코드에서 하면 안 되는 것>
|
||||
57
agent-ops/skills/common/_templates/skill-template.md
Normal file
57
agent-ops/skills/common/_templates/skill-template.md
Normal file
|
|
@ -0,0 +1,57 @@
|
|||
---
|
||||
name: <skill-name>
|
||||
version: 1.0.0
|
||||
description: <이 skill이 하는 일을 한 줄로 설명. 트리거 키워드 포함 권장>
|
||||
depends: [<other-skill>] # 선택 — 의존 skill이 없으면 이 줄 삭제
|
||||
---
|
||||
|
||||
# <skill-name>
|
||||
|
||||
## 목적
|
||||
|
||||
<이 skill이 해결하는 문제를 1~2문장으로 설명>
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
- <이 skill을 호출해야 하는 상황 1>
|
||||
- <이 skill을 호출해야 하는 상황 2>
|
||||
- <이 skill을 호출해야 하는 상황 3>
|
||||
|
||||
## 입력
|
||||
|
||||
- `<param-name>`: <설명> (필수)
|
||||
- `<param-name>`: <설명> (선택)
|
||||
|
||||
## 먼저 확인할 것
|
||||
|
||||
- [ ] <실행 전 반드시 확인해야 할 조건 1>
|
||||
- [ ] <실행 전 반드시 확인해야 할 조건 2>
|
||||
|
||||
## 실행 절차
|
||||
|
||||
1. **<단계명>**
|
||||
- <세부 행동>
|
||||
- <세부 행동>
|
||||
|
||||
2. **<단계명>**
|
||||
- <세부 행동>
|
||||
|
||||
3. **결과 보고**
|
||||
- <출력할 내용>
|
||||
|
||||
## 실행 결과 검증
|
||||
|
||||
- [ ] <실행 후 확인해야 할 성공 조건 1>
|
||||
- [ ] <실행 후 확인해야 할 성공 조건 2>
|
||||
- 검증 실패 시: <실패 시 취할 행동 — 롤백, 사용자 알림, 재시도 등>
|
||||
|
||||
## 출력 형식
|
||||
|
||||
```
|
||||
<출력 예시>
|
||||
```
|
||||
|
||||
## 금지 사항
|
||||
|
||||
- <절대 하면 안 되는 것>
|
||||
- <절대 하면 안 되는 것>
|
||||
324
agent-ops/skills/common/code-review/SKILL.md
Normal file
324
agent-ops/skills/common/code-review/SKILL.md
Normal file
|
|
@ -0,0 +1,324 @@
|
|||
---
|
||||
name: code-review
|
||||
description: Review completed implementation work in the current repository. Reads PLAN-{build_lane}-GNN.md and CODE_REVIEW-{review_lane}-GNN.md from the active task, reviews the actual changed source files, appends a verdict to the review file, then archives both files as .log. On PASS, writes complete.log summarising the full loop history and moves the completed task under agent-task/archive/YYYY/MM/. If Required or Suggested issues are found (FAIL or WARN), writes new routed plan/review files 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 routed plan/review files
|
||||
```
|
||||
|
||||
## Workflow Contract
|
||||
|
||||
Active work must live under `agent-task/{task_name}/` using routed filenames. This is the state protocol shared with the plan skill.
|
||||
|
||||
Filename rules:
|
||||
|
||||
- Plan file: `PLAN-{build_lane}-GNN.md`
|
||||
- Review file: `CODE_REVIEW-{review_lane}-GNN.md`
|
||||
- `{lane}` is only `local` or `cloud`; never put model names in filenames.
|
||||
- `GNN` is a two-digit capability grade from `G01` to `G10`; runtime maps lane+grade to current models externally.
|
||||
|
||||
Multi-plan runtime contract:
|
||||
|
||||
- Multi-plan work is represented as multiple task directories. Each directory owns exactly one normal active plan file and one normal active review file.
|
||||
- Directory names may encode runtime scheduling metadata. Preserve them verbatim; do not normalize, reinterpret, or choose execution order by agent judgment.
|
||||
- If the user/runtime names a task directory, review that directory even when other active review files exist.
|
||||
|
||||
Review routing rules:
|
||||
|
||||
- `local`: narrow, low-risk, or first-pass review where tests and scope are clear.
|
||||
- `cloud`: multi-file, API/call-site impact, meaningful test judgment, plan deviation, weak verification, security/auth, storage/migration, concurrency, protocol/schema, cross-domain, or repeated Required issues.
|
||||
- `cloud-G07` or higher is mandatory for terminal-agent follow-up work: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, or terminal benchmark-style tasks. Merely running deterministic tests such as `go test` does not make a task terminal-agent work.
|
||||
- `cloud-G07` or higher is mandatory for follow-up plans when a local implementation failed a real bin/smoke/integration command after unit tests passed, when the success condition depends on an interactive TUI/PTY/browser/external CLI or screen repaint/cursor stream, or when verification trust is Fail because recorded stdout/stderr does not match a rerun.
|
||||
|
||||
Directory states:
|
||||
|
||||
| State | Meaning |
|
||||
|-------|---------|
|
||||
| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` stub or placeholders | Implementation is pending/incomplete; review should fail completeness if invoked |
|
||||
| `PLAN-*-G??.md` + filled `CODE_REVIEW-*-G??.md` | Ready for code-review skill |
|
||||
| `complete.log` + `*.log` files | Task complete (PASS), before final task-directory archive move |
|
||||
| `agent-task/archive/YYYY/MM/{task_name}/complete.log` + `*.log` files | Archived completed task (PASS); not active |
|
||||
| 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.
|
||||
|
||||
Finalization invariant:
|
||||
|
||||
- Every review attempt that selects an active review file must end by archiving the active `CODE_REVIEW-*-G??.md` and `PLAN-*-G??.md` files.
|
||||
- After archiving, exactly one next state is allowed:
|
||||
- `PASS`: write `complete.log`, move `agent-task/{task_name}/` to `agent-task/archive/YYYY/MM/{task_name}/`, then complete the review-only checklist in the final archive path.
|
||||
- `WARN` or `FAIL`: write the next active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md`; do not write `complete.log`.
|
||||
- Never stop after appending a verdict. Do not report to the user until archive, required next-state file writes, review-only checklist updates, and PASS task-directory archive moves are complete.
|
||||
- If the review result feels ambiguous, choose `WARN` or `FAIL` according to the severity rules, archive the current files, and write the next plan/review pair. Ambiguity is not a reason to leave active files unarchived.
|
||||
|
||||
## Step 1 - Find Active Task
|
||||
|
||||
Glob `agent-task/*/CODE_REVIEW-*-G??.md`:
|
||||
|
||||
| Result | Action |
|
||||
|--------|--------|
|
||||
| Exactly one | Review that task; exactly one `PLAN-*-G??.md` is expected beside it |
|
||||
| None | Nothing to review; stop and report |
|
||||
| Multiple | If the user/runtime named a task directory, review that directory. Otherwise list paths and ask which task to review; do not choose by agent judgment. |
|
||||
|
||||
## Step 2 - Load Context
|
||||
|
||||
Count `agent-task/{task_name}/code_review_*.log`:
|
||||
|
||||
- `0`: first review. Read the active review file, active plan file, 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.
|
||||
- Compare the plan `구현 체크리스트` and review stub `구현 체크리스트`; item text/order must match.
|
||||
- Confirm the implementation marked the matching checklist items in the active review file, including the final mandatory `CODE_REVIEW-*-G??.md` completion item.
|
||||
- Treat blank placeholder sections, missing actual implementation notes, missing checklist completion, or missing actual stdout/stderr in the active review file as a completeness or verification-trust failure.
|
||||
- Grep renamed/removed symbols for stale references.
|
||||
- Confirm every required test exists, name matches, and assertions are meaningful.
|
||||
- Cross-check claimed verification output in the active review file 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 the active `CODE_REVIEW-*-G??.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.
|
||||
|
||||
Do not check archive/next-state items in `코드리뷰 전용 체크리스트` during Step 4. Complete the applicable dedicated checklist items in the archived `code_review_*.log` during Step 7, after archive, next-state writes, and PASS task-directory moves are done.
|
||||
|
||||
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, plan-completeness issue, or incomplete/placeholder `CODE_REVIEW-*-G??.md` content required from the implementing agent.
|
||||
- `Suggested`: useful improvement that should enter the loop but does not block correctness.
|
||||
- `Nit`: tiny cleanup; may be recorded without forcing WARN.
|
||||
|
||||
Verdict consistency:
|
||||
|
||||
- `PASS` requires all dimensions to be Pass and no Required/Suggested issues. Nit-only findings may still PASS only when every dimension remains Pass.
|
||||
- Any Fail dimension or any Required issue forces `FAIL`.
|
||||
- Any Warn dimension or any Suggested issue forces `WARN`, unless the only findings are explicitly Nit and every dimension remains Pass.
|
||||
|
||||
## Step 5 - Archive Active Files
|
||||
|
||||
Archive is mandatory for `PASS`, `WARN`, and `FAIL`. Archive order is fixed:
|
||||
|
||||
1. Count existing `code_review_*.log` as `N`; rename `CODE_REVIEW-{review_lane}-GNN.md` to `code_review_{review_lane}_GNN_N.log`.
|
||||
2. Count existing `plan_*.log` as `M`; rename `PLAN-{build_lane}-GNN.md` to `plan_{build_lane}_GNN_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.
|
||||
|
||||
Complete log template:
|
||||
|
||||
- Template path: `agent-ops/skills/common/code-review/templates/complete-log-template.md`
|
||||
- Copy the template's section order and fill every placeholder from the archived plan/review logs and final verdict.
|
||||
- Do not leave placeholders in `complete.log`.
|
||||
- Use `없음` for empty `잔여 Nit` or `후속 작업`.
|
||||
- A PASS `complete.log` must not contain unresolved Required or Suggested issues. Nit-only leftovers may be recorded under `잔여 Nit`.
|
||||
|
||||
After Step 7, report:
|
||||
|
||||
- Verdict.
|
||||
- Archive filenames.
|
||||
- Final task archive path under `agent-task/archive/YYYY/MM/`.
|
||||
|
||||
For `WARN` or `FAIL`, write new routed plan/review files using the plan skill format:
|
||||
|
||||
- New plan number is the count of `plan_*.log` after archive.
|
||||
- Header tag is `REVIEW_<PARENT_TAG>`.
|
||||
- Choose lane/grade again; preserve the prior route only when it was adequate, otherwise raise `GNN` and/or move `local -> cloud`.
|
||||
- Before choosing the follow-up route, apply this escalation gate:
|
||||
- If the archived plan was `local-*` and the verdict is `FAIL` for correctness, completeness, test coverage, or verification trust, move the follow-up build lane to `cloud` unless the issue is trivially deterministic and review-detectable without live environment behavior.
|
||||
- If the follow-up work is terminal-agent work (shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, or terminal benchmark-style tasks), use `cloud-G07` or higher.
|
||||
- If unit tests passed but a real bin/smoke/integration command failed, use `cloud-G07` or higher.
|
||||
- If the task depends on interactive TUI/PTY/browser/external CLI behavior, screen repaint/cursor stream parsing, or live command-palette state, use `cloud-G07` or higher.
|
||||
- If recorded verification output was reconstructed, stale, or mismatched on rerun, use `cloud-G07` or higher and make verification trust recovery a plan item.
|
||||
- `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.
|
||||
- The follow-up plan and review stub must contain matching `구현 체크리스트` item text/order, including the final mandatory `CODE_REVIEW-*-G??.md` completion item.
|
||||
|
||||
Routed review stub template (fill `{…}` placeholders; everything else is fixed and must not be changed by the implementing agent):
|
||||
|
||||
```markdown
|
||||
<!-- task={task_name} plan={N} tag={TAG} -->
|
||||
|
||||
# Code Review Reference - {TAG}
|
||||
|
||||
> **[IMPLEMENTING AGENT — READ FIRST] Filling in this file is the mandatory final step of implementation.**
|
||||
> The task is NOT complete until every implementation-owned section below is filled in.
|
||||
> Complete the `구현 체크리스트`; the final checklist item is mandatory before saving.
|
||||
> Do not modify or check the `코드리뷰 전용 체크리스트`; it is owned by the review agent only.
|
||||
> Follow the ownership table at the bottom of this file for which sections you own.
|
||||
|
||||
## 개요
|
||||
|
||||
date={YYYY-MM-DD}
|
||||
task={task_name}, plan={N}, tag={TAG}
|
||||
|
||||
## 이 파일을 읽는 리뷰 에이전트에게
|
||||
|
||||
각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
|
||||
Review 완료 후 반드시 아래 순서로 아카이브하세요.
|
||||
|
||||
1. `CODE_REVIEW-{review_lane}-GNN.md` → `code_review_{review_lane}_GNN_N.log` (N = 기존 code_review_*.log 수)
|
||||
2. `PLAN-{build_lane}-GNN.md` → `plan_{build_lane}_GNN_M.log` (M = 기존 plan_*.log 수)
|
||||
3. PASS인 경우 `complete.log` 작성 후 `agent-task/archive/YYYY/MM/{task_name}/`로 task 디렉터리 이동. WARN/FAIL인 경우 새 routed plan + review 스텁 작성.
|
||||
|
||||
어떤 판정에서도 아카이브를 건너뛰지 마세요. PASS/WARN/FAIL 모두 `코드리뷰 결과` append 후 active plan/review 파일을 먼저 아카이브하고, 그 다음 `complete.log` 또는 다음 plan/review 파일을 작성해야 합니다.
|
||||
PASS에서는 `agent-ops/skills/common/code-review/templates/complete-log-template.md`의 섹션 순서와 필수 항목을 기준으로 `complete.log`를 작성하세요. 작성 후 현재 날짜의 `YYYY/MM` 기준으로 task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동하고, 최종 archive 경로의 `code_review_*.log`에서 `코드리뷰 전용 체크리스트`를 갱신한 다음 보고하세요.
|
||||
WARN/FAIL에서는 다음 상태 파일 작성 후 현재 task 경로의 archived `code_review_*.log`에서 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 체크한 다음 보고하세요.
|
||||
|
||||
---
|
||||
|
||||
## 구현 항목별 완료 여부
|
||||
|
||||
| 항목 | 완료 여부 |
|
||||
|------|---------|
|
||||
| [{TAG}-1] {item description} | [ ] |
|
||||
| [{TAG}-2] {item description} | [ ] |
|
||||
|
||||
## 구현 체크리스트
|
||||
|
||||
{copy the follow-up plan's 구현 체크리스트 items exactly, preserving order and checkbox text}
|
||||
|
||||
## 코드리뷰 전용 체크리스트
|
||||
|
||||
> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
|
||||
> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.
|
||||
|
||||
- [ ] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
|
||||
- [ ] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
|
||||
- [ ] active `CODE_REVIEW-*-G??.md`를 `code_review_{review_lane}_GNN_N.log`로 아카이브한다.
|
||||
- [ ] active `PLAN-*-G??.md`를 `plan_{build_lane}_GNN_M.log`로 아카이브한다.
|
||||
- [ ] PASS이면 `agent-ops/skills/common/code-review/templates/complete-log-template.md` 기준으로 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
|
||||
- [ ] PASS이면 `agent-task/{task_name}/`를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동하고 최종 archive 경로에서 이 체크리스트를 갱신한다.
|
||||
- [ ] WARN/FAIL이면 다음 active `PLAN-{build_lane}-GNN.md`와 `CODE_REVIEW-{review_lane}-GNN.md`를 작성하고 `complete.log`를 작성하지 않는다.
|
||||
|
||||
## 계획 대비 변경 사항
|
||||
|
||||
_구현 에이전트가 계획과 다르게 구현한 부분을 이유와 함께 기록한다._
|
||||
|
||||
## 주요 설계 결정
|
||||
|
||||
_구현 에이전트가 주요 설계 결정 사항을 기록한다._
|
||||
|
||||
## 리뷰어를 위한 체크포인트
|
||||
|
||||
{pre-filled from plan — one bullet per review focus area}
|
||||
|
||||
## 검증 결과
|
||||
|
||||
_구현 에이전트가 각 중간 검증 및 최종 검증 명령 실행 후 출력을 여기에 붙여 넣는다._
|
||||
|
||||
필수 규칙:
|
||||
- 검증 명령은 고정된 계약이다. 임의로 대체하지 않는다.
|
||||
- 대체가 필요하면 `계획 대비 변경 사항`에 이유와 대체 명령을 기록한다.
|
||||
- `검증 결과`에는 실제 stdout/stderr를 붙여 넣는다.
|
||||
|
||||
### {TAG}-1 중간 검증
|
||||
```
|
||||
$ {verification command from plan}
|
||||
(output)
|
||||
```
|
||||
|
||||
### 최종 검증
|
||||
```
|
||||
$ {final verification command from plan}
|
||||
(output)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**
|
||||
> If anything is blank, go back and fill it in before saving this file.
|
||||
> Leave the review-agent-only checklist unchanged.
|
||||
```
|
||||
|
||||
Sections and their ownership:
|
||||
|
||||
| 섹션 | 소유자 | 설명 |
|
||||
|------|--------|------|
|
||||
| 헤더 주석, 개요(date/task/plan/tag), 리뷰 에이전트 지시 | 스텁 생성 시 고정 | 구현 에이전트가 수정하지 않음 |
|
||||
| 구현 항목별 완료 여부 (항목명) | 스텁 생성 시 고정 | `[ ]` → `[x]` 체크만 구현 에이전트가 수행 |
|
||||
| 구현 체크리스트 (항목 텍스트/순서) | follow-up plan에서 복사해 스텁 생성 시 고정 | 구현 에이전트가 `[ ]` → `[x]` 체크만 수행; 마지막 체크박스는 저장 전 필수 |
|
||||
| 코드리뷰 전용 체크리스트 | Review agent only | Implementing agent must not modify or check this section |
|
||||
| 계획 대비 변경 사항, 주요 설계 결정 | 구현 에이전트가 채움 | placeholder 텍스트를 실제 내용으로 교체 |
|
||||
| 리뷰어를 위한 체크포인트 | 스텁 생성 시 고정 | 계획에서 추출한 리뷰 포인트 |
|
||||
| 검증 결과 (섹션 제목 + 명령) | 스텁 생성 시 고정 | 실행 출력만 구현 에이전트가 채움; 명령 변경은 `계획 대비 변경 사항`에 기록 |
|
||||
| 코드리뷰 결과 | 리뷰 에이전트가 append | 스텁에 포함하지 않음 |
|
||||
|
||||
## Step 7 - Complete Review-Only Checklist, Move PASS Task, And Report
|
||||
|
||||
After Step 6:
|
||||
|
||||
- If verdict is `PASS`, determine archive month from the current completion date as `YYYY/MM`, create `agent-task/archive/YYYY/MM/` if missing, then move `agent-task/{task_name}/` to `agent-task/archive/YYYY/MM/{task_name}/`.
|
||||
- Do not overwrite an existing archive directory. If `agent-task/archive/YYYY/MM/{task_name}/` already exists, append the next numeric suffix: `agent-task/archive/YYYY/MM/{task_name}_1/`, `agent-task/archive/YYYY/MM/{task_name}_2/`, and so on.
|
||||
- For `PASS`, open the moved `agent-task/archive/YYYY/MM/{final_task_dir}/code_review_{review_lane}_GNN_N.log`.
|
||||
- For `WARN` or `FAIL`, open `agent-task/{task_name}/code_review_{review_lane}_GNN_N.log`.
|
||||
- Check every applicable item in `코드리뷰 전용 체크리스트`; leave mutually exclusive verdict items unchecked.
|
||||
- If any applicable item cannot be checked, finish the missing archive, `complete.log`, task-directory move, or follow-up plan/review write first.
|
||||
- Do not recreate an active review file just to update this checklist; update the archived `code_review_*.log`.
|
||||
- Only report after the archived review log has the verdict, applicable checked review-only checklist, required next-state files, and for `PASS` the final task archive move.
|
||||
|
||||
Report Required/Suggested counts, archive names, and the final task archive path for `PASS` or new plan path for `WARN`/`FAIL`.
|
||||
|
||||
## Review Dimensions
|
||||
|
||||
| Dimension | Check |
|
||||
|-----------|-------|
|
||||
| Correctness | Logic, edge cases, concurrency, errors |
|
||||
| Completeness | All planned checklist items done, including matching plan/review `구현 체크리스트` completion |
|
||||
| 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.
|
||||
- For follow-up plans about verification trust, specify deterministic commands, for example `rg --sort path`, and forbid repo-local tool artifacts.
|
||||
|
||||
## Final Checklist
|
||||
|
||||
- `code_review_{review_lane}_GNN_N.log` exists with verdict appended.
|
||||
- `plan_{build_lane}_GNN_M.log` exists.
|
||||
- No active `.md` files remain after PASS.
|
||||
- PASS: `complete.log` written from `agent-ops/skills/common/code-review/templates/complete-log-template.md`, then task directory moved under `agent-task/archive/YYYY/MM/`.
|
||||
- WARN/FAIL: new active `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` created with matching headers and matching `구현 체크리스트`; no `complete.log`.
|
||||
- The applicable review-agent-only finalization checklist was completed before reporting.
|
||||
4
agent-ops/skills/common/code-review/agents/openai.yaml
Normal file
4
agent-ops/skills/common/code-review/agents/openai.yaml
Normal file
|
|
@ -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."
|
||||
|
|
@ -0,0 +1,31 @@
|
|||
# Complete - {task_name}
|
||||
|
||||
## 완료 일시
|
||||
|
||||
{YYYY-MM-DD or ISO-8601}
|
||||
|
||||
## 요약
|
||||
|
||||
{one-line task summary, loop count, and final verdict}
|
||||
|
||||
## 루프 이력
|
||||
|
||||
| Plan | Review | Verdict | 메모 |
|
||||
|------|--------|---------|------|
|
||||
| `plan_{build_lane}_GNN_N.log` | `code_review_{review_lane}_GNN_N.log` | PASS/WARN/FAIL | {main outcome or follow-up reason} |
|
||||
|
||||
## 구현/정리 내용
|
||||
|
||||
- {implemented or cleaned-up change}
|
||||
|
||||
## 최종 검증
|
||||
|
||||
- `{command}` - {PASS/FAIL/BLOCKED}; {actual output summary or saved output path}
|
||||
|
||||
## 잔여 Nit
|
||||
|
||||
- 없음
|
||||
|
||||
## 후속 작업
|
||||
|
||||
- 없음
|
||||
124
agent-ops/skills/common/commit-push/SKILL.md
Normal file
124
agent-ops/skills/common/commit-push/SKILL.md
Normal file
|
|
@ -0,0 +1,124 @@
|
|||
---
|
||||
name: commit-push
|
||||
version: 1.0.0
|
||||
description: 변경 사항을 커밋하고 원격에 푸시한다. "커밋해줘", "푸시해줘", "커밋하고 푸시" 요청 시 사용한다.
|
||||
---
|
||||
|
||||
# commit-push
|
||||
|
||||
## 목적
|
||||
|
||||
현재 변경 내용을 분석하여 한국어 커밋 메시지를 작성하고, 커밋 및 푸시를 수행한다.
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
- "커밋해줘", "커밋하고 푸시해줘" 요청 시
|
||||
- "변경 사항 올려줘", "푸시해줘" 요청 시
|
||||
- 코드 작업 완료 후 "반영해줘", "올려줘" 요청 시
|
||||
|
||||
## 입력
|
||||
|
||||
- `scope`: 커밋 범위 — all(전체) 또는 특정 파일/경로 (선택, 기본값: all)
|
||||
- `push`: 푸시 여부 (선택, 기본값: true)
|
||||
|
||||
## 먼저 확인할 것
|
||||
|
||||
- [ ] 커밋할 변경 사항이 존재하는가 (`git status`로 확인)
|
||||
- [ ] 현재 브랜치가 올바른 브랜치인가
|
||||
- [ ] `.env`, 시크릿 파일 등 민감한 파일이 스테이징에 포함되어 있지 않은가
|
||||
|
||||
## 실행 절차
|
||||
|
||||
1. **변경 사항 파악**
|
||||
- `git status`로 변경/추가/삭제된 파일 목록을 확인한다
|
||||
- `git diff`로 구체적인 변경 내용을 확인한다
|
||||
- 변경 사항이 없으면 사용자에게 알리고 종료한다
|
||||
|
||||
2. **민감 파일 검사**
|
||||
- 스테이징 대상에 아래 패턴이 포함되면 해당 파일을 제외하고 사용자에게 경고한다
|
||||
- `.env`, `.env.*`
|
||||
- `*secret*`, `*credential*`, `*password*`
|
||||
- `*.pem`, `*.key`, `*.p12`
|
||||
- `.gitignore`에 이미 등록된 파일은 무시한다
|
||||
|
||||
3. **커밋 메시지 작성**
|
||||
- 변경 내용을 분석하여 한국어로 커밋 메시지를 작성한다
|
||||
- 아래 메시지 규칙을 따른다
|
||||
|
||||
4. **사용자 확인**
|
||||
- 커밋 메시지와 대상 파일 목록을 보여주고 승인을 받는다
|
||||
- 사용자가 메시지 수정을 요청하면 반영한다
|
||||
|
||||
5. **커밋 실행**
|
||||
- scope에 따라 파일을 스테이징한다
|
||||
- all: 변경된 전체 파일을 개별적으로 `git add`
|
||||
- 특정 경로: 해당 파일만 `git add`
|
||||
- 승인된 메시지로 `git commit`을 실행한다
|
||||
|
||||
6. **푸시 실행**
|
||||
- push가 true인 경우에만 실행한다
|
||||
- 현재 브랜치를 원격에 푸시한다
|
||||
- 원격 브랜치가 없으면 `-u origin {branch}`로 설정한다
|
||||
- 충돌 발생 시 사용자에게 알리고 중단한다
|
||||
|
||||
7. **결과 보고**
|
||||
- 커밋 해시, 메시지, 변경 파일 수, 푸시 결과를 출력한다
|
||||
|
||||
## 커밋 메시지 규칙
|
||||
|
||||
### 형식
|
||||
|
||||
```
|
||||
<타입>: <변경 요약>
|
||||
|
||||
<본문> (선택)
|
||||
```
|
||||
|
||||
### 타입 목록
|
||||
|
||||
| 타입 | 용도 |
|
||||
|------|------|
|
||||
| 기능 | 새로운 기능 추가 |
|
||||
| 수정 | 버그 수정 |
|
||||
| 개선 | 기존 기능 개선, 리팩토링 |
|
||||
| 문서 | 문서 추가/수정 |
|
||||
| 설정 | 빌드, CI/CD, 설정 파일 변경 |
|
||||
| 테스트 | 테스트 추가/수정 |
|
||||
| 정리 | 코드 정리, 불필요 코드 제거 |
|
||||
|
||||
### 작성 원칙
|
||||
|
||||
- **한국어**로 작성한다
|
||||
- 요약은 50자 이내로 간결하게 작성한다
|
||||
- 요약은 "~한다" 형태의 서술형으로 끝낸다 (예: "로그인 검증 로직을 추가한다")
|
||||
- 본문은 **무엇을** 변경했는지가 아니라 **왜** 변경했는지를 쓴다
|
||||
- 변경 파일이 3개 이하이면 본문을 생략할 수 있다
|
||||
- 여러 성격의 변경이 섞여 있으면 가장 핵심적인 변경을 기준으로 타입을 정한다
|
||||
|
||||
## 출력 형식
|
||||
|
||||
```
|
||||
## 커밋 완료
|
||||
|
||||
- 브랜치: {브랜치명}
|
||||
- 커밋: {해시} — {커밋 메시지 요약}
|
||||
- 변경 파일: {n}개
|
||||
- {파일 경로}: {변경 유형}
|
||||
- 푸시: {성공/생략/실패}
|
||||
```
|
||||
|
||||
## 실행 결과 검증
|
||||
|
||||
- [ ] `git log -1`로 방금 생성한 커밋이 존재하고, 메시지가 승인된 내용과 일치하는가
|
||||
- [ ] 커밋에 포함된 파일 목록이 의도한 scope와 일치하는가 (`git diff-tree --no-commit-id --name-only -r HEAD`)
|
||||
- [ ] push가 true인 경우, `git status`에서 "Your branch is up to date" 또는 원격과 동기화 상태인가
|
||||
- 검증 실패 시: 실패 원인(커밋 누락, 푸시 실패 등)을 사용자에게 알리고 재시도 여부를 확인한다
|
||||
|
||||
## 금지 사항
|
||||
|
||||
- `git add -A` 또는 `git add .`을 사용하지 않는다 (민감 파일 혼입 방지)
|
||||
- `git push --force`를 사용하지 않는다
|
||||
- 사용자 확인 없이 커밋하지 않는다
|
||||
- 영어로 커밋 메시지를 작성하지 않는다
|
||||
- 변경 내용과 무관한 커밋 메시지를 작성하지 않는다
|
||||
- `--no-verify` 옵션을 사용하지 않는다
|
||||
113
agent-ops/skills/common/create-domain-rule/SKILL.md
Normal file
113
agent-ops/skills/common/create-domain-rule/SKILL.md
Normal file
|
|
@ -0,0 +1,113 @@
|
|||
---
|
||||
name: create-domain-rule
|
||||
version: 1.0.0
|
||||
description: 새로운 도메인 rules.md 파일을 생성하기 위한 범용 스킬
|
||||
---
|
||||
|
||||
# Create Domain Rule
|
||||
|
||||
## 목적
|
||||
|
||||
`agent-ops/rules/project/domain/<domain-name>/rules.md` 파일을 올바른 형식으로 생성한다.
|
||||
실제 프로젝트 폴더 구조를 분석하여 경로와 구성 요소를 자동으로 채운다.
|
||||
생성 후 `rules/project/rules.md`의 도메인 룰 로딩 안내와 도메인 매핑 테이블을 갱신한다.
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
- 새로운 도메인 영역의 코드를 처음 변경하기 전에
|
||||
- 기존 domain rule이 없는 경로에 대해 규칙이 필요할 때
|
||||
- 사용자가 특정 도메인의 rule 파일을 만들어 달라고 요청할 때
|
||||
- agent-ops 초기 scaffold 이후 도메인을 추가 확장할 때
|
||||
|
||||
## 입력
|
||||
|
||||
- `domain-name`: 생성할 도메인 이름, kebab-case (필수)
|
||||
- `domain-type`: `core` / `supporting` / `generic` 중 하나 (필수)
|
||||
- `path-hints`: 이 도메인에 해당하는 경로 힌트 목록 (선택, 없으면 자동 탐색)
|
||||
|
||||
## 먼저 확인할 것
|
||||
|
||||
- [ ] `agent-ops/rules/project/domain/<domain-name>/rules.md` 가 이미 존재하는지 확인
|
||||
- [ ] `agent-ops/rules/common/_templates/domain-rule-template.md` 를 읽어 최신 템플릿 형식 파악
|
||||
- [ ] `agent-ops/rules/project/domain/` 하위 기존 domain rule 목록을 확인하여 중복·유사 도메인 여부 판단
|
||||
|
||||
## 실행 절차
|
||||
|
||||
1. **중복 확인**
|
||||
- `agent-ops/rules/project/domain/<domain-name>/` 폴더 존재 여부 확인
|
||||
- 책임이 겹치는 기존 domain rule 이 있으면 사용자에게 알리고 중단한다
|
||||
|
||||
2. **경로 탐색**
|
||||
- `path-hints` 가 제공된 경우: 해당 경로를 기준으로 폴더 구조 확인
|
||||
- `path-hints` 가 없는 경우: `domain-name` 과 연관된 폴더명·파일명으로 프로젝트를 탐색
|
||||
- 실제로 존재하는 경로만 포함 경로에 기재한다
|
||||
- 존재하지 않는 경로는 기재하지 않는다
|
||||
|
||||
3. **도메인 분석**
|
||||
- 탐색된 경로의 주요 파일·모듈을 읽어 아래를 도출한다
|
||||
- 도메인의 목적 / 책임 한 줄 요약
|
||||
- 포함 경로 목록
|
||||
- 제외 경로 (인접 도메인과 겹칠 수 있는 경로)
|
||||
- 주요 구성 요소 (파일, 모듈, 클래스, 함수 등)
|
||||
- 유지할 패턴 (네이밍 규칙, 아키텍처 패턴 등)
|
||||
- 다른 도메인과의 경계
|
||||
- 금지 사항
|
||||
|
||||
4. **도메인 rules.md 생성**
|
||||
- 경로: `agent-ops/rules/project/domain/<domain-name>/rules.md`
|
||||
- `domain-rule-template.md` 형식을 따른다
|
||||
- 실제 코드에서 확인된 내용만 기재한다
|
||||
- 불확실한 항목은 `<!-- TODO: 확인 필요 -->` 주석으로 남긴다
|
||||
|
||||
5. **rules/project/rules.md 업데이트**
|
||||
- `agent-ops/rules/project/rules.md` 를 읽는다
|
||||
- `## 도메인 룰 로딩` 섹션이 없으면 `## 도메인 매핑` 바로 위에 아래 형식으로 추가한다
|
||||
```
|
||||
## 도메인 룰 로딩
|
||||
|
||||
- 아래 도메인 매핑에 해당하는 작업에서 해당 domain 최초 진입 시 domain rule을 1회 읽는다.
|
||||
- 이미 읽은 domain rule은 같은 세션에서 반복해서 읽지 않는다.
|
||||
```
|
||||
- 도메인 매핑 테이블에 아래 형식으로 추가한다
|
||||
```
|
||||
| `<path-pattern>` | <domain-name> | `agent-ops/rules/project/domain/<domain-name>/rules.md` |
|
||||
```
|
||||
- 경로 패턴은 실제 포함 경로를 기준으로 작성한다
|
||||
- 기존 로딩 섹션과 테이블 항목을 삭제하거나 재정렬하지 않는다
|
||||
|
||||
6. **결과 보고**
|
||||
- 생성한 파일 경로
|
||||
- rules/project/rules.md 에 추가한 항목
|
||||
- 불확실하여 TODO로 남긴 항목 (해당 시)
|
||||
|
||||
## 출력 형식
|
||||
|
||||
```
|
||||
## 생성 완료
|
||||
|
||||
- Domain Rule 경로: agent-ops/rules/project/domain/<domain-name>/rules.md
|
||||
- 도메인 유형: <core | supporting | generic>
|
||||
- 도메인 룰 로딩 섹션: <추가함 | 이미 존재함>
|
||||
- rules/project/rules.md 추가 경로 패턴: <path-pattern>
|
||||
|
||||
## TODO 항목 (확인 필요)
|
||||
- <불확실하여 직접 확인이 필요한 항목> (해당 시)
|
||||
```
|
||||
|
||||
## 실행 결과 검증
|
||||
|
||||
- [ ] `agent-ops/rules/project/domain/<domain-name>/rules.md` 파일이 생성되었는가
|
||||
- [ ] 생성된 파일이 `domain-rule-template.md`의 모든 섹션(목적, 포함 경로, 제외 경로, 주요 구성 요소, 유지할 패턴, 경계, 금지 사항)을 포함하는가
|
||||
- [ ] `rules/project/rules.md`에 도메인 룰 로딩 섹션이 존재하는가
|
||||
- [ ] `rules/project/rules.md`의 도메인 매핑 테이블에 해당 도메인 항목이 추가되었는가
|
||||
- [ ] 포함 경로에 기재된 경로가 실제로 프로젝트에 존재하는가
|
||||
- 검증 실패 시: 누락된 섹션 또는 잘못된 경로를 사용자에게 알리고 해당 부분만 보완한다
|
||||
|
||||
## 금지 사항
|
||||
|
||||
- 이미 존재하는 rules.md 를 덮어쓰지 않는다
|
||||
- 실제 존재하지 않는 경로를 포함 경로에 넣지 않는다
|
||||
- 추측으로 패턴이나 금지 사항을 채우지 않는다 — 확인된 내용만 기재한다
|
||||
- rules/project/rules.md 의 기존 로딩 섹션과 테이블 항목을 삭제하거나 재정렬하지 않는다
|
||||
- 하나의 domain rule 에 여러 독립 도메인의 책임을 묶지 않는다
|
||||
- 코드 변경을 수행하지 않는다 — 이 skill 은 rule 파일 생성만 담당한다
|
||||
95
agent-ops/skills/common/create-skill/SKILL.md
Normal file
95
agent-ops/skills/common/create-skill/SKILL.md
Normal file
|
|
@ -0,0 +1,95 @@
|
|||
---
|
||||
name: create-skill
|
||||
version: 1.0.0
|
||||
description: 새로운 SKILL.md 파일을 생성하기 위한 범용 스킬
|
||||
---
|
||||
|
||||
# Create Skill
|
||||
|
||||
## 목적
|
||||
|
||||
`agent-ops/skills/` 하위에 올바른 형식의 SKILL.md 파일을 생성한다.
|
||||
기존 skill-template.md 를 기반으로, 요청 목적에 맞는 내용을 채워 넣는다.
|
||||
생성 후 라우팅 항목을 추가한다.
|
||||
|
||||
### 생성 위치 결정
|
||||
- `.agent-ops-source` 파일이 **있으면** (공통 관리 레포): `agent-ops/skills/common/<skill-name>/SKILL.md`
|
||||
- `.agent-ops-source` 파일이 **없으면** (타겟 프로젝트): `agent-ops/skills/project/<skill-name>/SKILL.md`
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
- 새로운 반복 작업 패턴이 생겨 skill로 정의해야 할 때
|
||||
- 기존 skill이 없는 작업 유형을 처음 수행하기 전에
|
||||
- 사용자가 특정 작업을 skill로 만들어 달라고 요청할 때
|
||||
|
||||
## 입력
|
||||
|
||||
- `skill-name`: 생성할 skill 이름, kebab-case (필수)
|
||||
- `purpose`: 이 skill이 해결하는 문제 한 줄 요약 (필수)
|
||||
- `trigger-cases`: 이 skill을 호출해야 하는 상황 목록 (선택)
|
||||
|
||||
## 먼저 확인할 것
|
||||
|
||||
- [ ] `agent-ops/skills/common/` 및 `agent-ops/skills/project/` 하위에 동일 이름의 디렉터리가 이미 존재하는지 확인
|
||||
- [ ] `agent-ops/rules/common/rules.md` 및 `agent-ops/rules/project/rules.md` 에 이미 유사한 라우팅 항목이 있는지 확인
|
||||
- [ ] `agent-ops/skills/common/_templates/skill-template.md` 를 읽어 최신 템플릿 형식 파악
|
||||
|
||||
## 실행 절차
|
||||
|
||||
1. **중복 확인**
|
||||
- `agent-ops/skills/common/<skill-name>/` 및 `agent-ops/skills/project/<skill-name>/` 폴더 존재 여부 확인
|
||||
- 기능이 겹치는 기존 skill이 있으면 사용자에게 알리고 중단한다
|
||||
|
||||
2. **목적 분석**
|
||||
- `purpose` 와 `trigger-cases` 를 바탕으로 아래 항목을 도출한다
|
||||
- 언제 호출할지 (2~4개)
|
||||
- 필요한 입력 파라미터
|
||||
- 사전 확인 항목
|
||||
- 실행 절차 (3~7단계)
|
||||
- 출력 형식
|
||||
- 금지 사항
|
||||
|
||||
3. **SKILL.md 생성**
|
||||
- 경로: 생성 위치 결정 규칙에 따라 `common/` 또는 `project/` 하위에 생성
|
||||
- `skill-template.md` 형식을 따른다
|
||||
- 프로젝트 특화 내용보다 범용 절차를 우선한다
|
||||
- 절차는 구체적이되 지나치게 세부 구현을 기술하지 않는다
|
||||
|
||||
4. **라우팅 업데이트**
|
||||
- `.agent-ops-source` 마커가 **있으면** (공통 관리 레포): `agent-ops/rules/common/rules.md`에 라우팅 항목 추가
|
||||
- `.agent-ops-source` 마커가 **없으면** (타겟 프로젝트): `agent-ops/rules/project/rules.md`의 프로젝트 스킬 라우터 섹션에 라우팅 항목 추가
|
||||
- 이 skill이 속할 라우팅 축(구조 분석/코드 변경/흐름 추적 등)을 판단한다
|
||||
- 기존 라우팅 구조를 깨지 않는다
|
||||
|
||||
5. **결과 보고**
|
||||
- 생성한 파일 경로
|
||||
- 라우팅 항목을 추가한 파일과 내용
|
||||
- 이 skill이 다루지 않는 범위(필요 시)
|
||||
|
||||
## 출력 형식
|
||||
|
||||
```
|
||||
## 생성 완료
|
||||
|
||||
- SKILL 경로: agent-ops/skills/{common|project}/<skill-name>/SKILL.md
|
||||
- 라우팅 추가: <대상 파일> → <라우팅 축> → <skill-name>
|
||||
|
||||
## 주의사항 (해당 시)
|
||||
- <이 skill이 다루지 않는 범위 또는 주의할 점>
|
||||
```
|
||||
|
||||
## 실행 결과 검증
|
||||
|
||||
- [ ] `agent-ops/skills/{common|project}/<skill-name>/SKILL.md` 파일이 생성되었는가
|
||||
- [ ] 생성된 파일이 `skill-template.md`의 필수 섹션(목적, 언제 호출할지, 실행 절차, 실행 결과 검증, 출력 형식, 금지 사항)을 포함하는가
|
||||
- [ ] frontmatter에 name, version, description이 올바르게 기재되었는가
|
||||
- [ ] 라우팅 대상 파일에 해당 스킬의 라우팅 항목이 추가되었는가
|
||||
- 검증 실패 시: 누락된 섹션 또는 라우팅 항목을 사용자에게 알리고 해당 부분만 보완한다
|
||||
|
||||
## 금지 사항
|
||||
|
||||
- 이미 존재하는 skill 을 덮어쓰지 않는다
|
||||
- 프로젝트 특화 경로(예: `app/screens/`)를 skill 본문에 하드코딩하지 않는다
|
||||
- skill 생성과 무관한 코드 파일을 수정하지 않는다
|
||||
- 라우팅 대상 파일의 기존 항목을 삭제하거나 재정렬하지 않는다
|
||||
- 하나의 skill 에 여러 독립적인 책임을 묶지 않는다
|
||||
243
agent-ops/skills/common/init-agent-ops/SKILL.md
Normal file
243
agent-ops/skills/common/init-agent-ops/SKILL.md
Normal file
|
|
@ -0,0 +1,243 @@
|
|||
---
|
||||
name: init-agent-ops
|
||||
version: 1.1.1
|
||||
description: 프로젝트 상태를 판별하고 agent-ops 기본 스캐폴드를 생성하기 위한 초기 규칙
|
||||
---
|
||||
|
||||
# init-agent-ops
|
||||
|
||||
## 목적
|
||||
|
||||
프로젝트에 Agent-Ops 구조가 없거나 불완전할 때,
|
||||
현재 프로젝트 상태를 분석하여 다음을 세팅한다.
|
||||
|
||||
1. 에이전트 진입 파일
|
||||
2. AI ignore / permission 기본 설정
|
||||
3. agent-ops 기본 폴더 구조
|
||||
4. rules/project/rules.md (프로젝트 특화 규칙, 분석 후 생성)
|
||||
5. 초기 domain rule 초안
|
||||
6. 초기 skill (필요 시)
|
||||
|
||||
"현재 프로젝트에 맞는 최소 스캐폴드" 생성을 우선한다.
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
- 프로젝트에 agent-ops 구조가 없을 때
|
||||
- agent-ops 구조가 불완전하여 재설정이 필요할 때
|
||||
- 사용자가 "agent-ops 초기화해줘", "에이전트 설정해줘" 요청 시
|
||||
|
||||
## 입력
|
||||
|
||||
- `project-type`: 신규 / 운영중 (선택, 미지정 시 자동 판별)
|
||||
|
||||
## 먼저 확인할 것
|
||||
|
||||
- [ ] 프로젝트 루트에 기존 agent-ops 관련 파일(`CLAUDE.md`, `agent-ops/` 등)이 있는지 확인
|
||||
- [ ] `.agent-ops-source` 파일이 있는지 확인 (공통 관리 레포 여부)
|
||||
- [ ] 기존 진입 파일(`CLAUDE.md`, `GEMINI.md` 등)이 있는지 확인
|
||||
- [ ] 기존 AI ignore / permission 파일(`.geminiignore`, `.aiexclude`, `.claude/settings.json`, `opencode.json` 등)이 있는지 확인
|
||||
|
||||
## 핵심 원칙
|
||||
|
||||
- 기존 구조를 우선한다.
|
||||
- 새 파일 생성은 꼭 필요한 최소 범위로 제한한다.
|
||||
- 도메인은 발명하지 말고 현재 구조에서 발견한다.
|
||||
- 처음에는 핵심 도메인만 생성한다.
|
||||
- 반복되는 작업만 초기 skill로 만든다.
|
||||
- 불확실한 내용은 후보로 제시한다.
|
||||
|
||||
## 상태 판별
|
||||
|
||||
### 신규 프로젝트
|
||||
- 코드/폴더 구조가 단순하다
|
||||
- 도메인 경계가 아직 약하다
|
||||
- Agent-Ops 관련 파일이 없다
|
||||
|
||||
### 운영중 프로젝트
|
||||
- 모듈/폴더/패키지 경계가 보인다
|
||||
- 반복 작업이 드러난다
|
||||
- 핵심 책임 경계가 식별된다
|
||||
|
||||
## 생성 대상
|
||||
|
||||
| 파일 | 방법 |
|
||||
|------|------|
|
||||
| `GEMINI.md`, `CLAUDE.md`, `AGENTS.md`, `.cursorrules`, `.clinerules` 등 진입 파일 | `rules/common/rules.md`를 `agent-ops/bin/entry-files.sh`의 파일 목록으로 프로젝트 루트에 복사 |
|
||||
| `agent-ops/.version` | 공통 관리 레포의 VERSION 파일을 그대로 복사 (프레임워크 버전 추적용) |
|
||||
| `agent-ops/bin/` | 공통 스크립트 전체 복사 (진입 파일 목록의 단일 기준인 `entry-files.sh` 포함) |
|
||||
| `agent-ops/rules/common/` | 공통 폴더 전체 복사 (수정 금지) |
|
||||
| `agent-ops/skills/common/` | 공통 폴더 전체 복사 (수정 금지) |
|
||||
| `agent-ops/rules/project/rules.md` | 프로젝트 분석 후 생성 |
|
||||
| `agent-ops/rules/project/domain/<domain>/rules.md` | 도메인 분석 후 생성 |
|
||||
| `agent-ops/rules/private/` | 폴더만 생성 (내용은 개인이 작성) |
|
||||
| `.gitignore`에 `agent-ops/rules/private/` 추가 | git 추적 제외 |
|
||||
| `.geminiignore`, `.aiexclude`, `.cursorignore`, `.clineignore` | `agent-task/archive/**` 한 줄 추가 |
|
||||
| `.claude/settings.json`, `opencode.json` | 파일이 없으면 `agent-task/archive/**` 읽기/검색 제외 설정 생성, 있으면 덮어쓰지 않고 수동 병합 안내 |
|
||||
|
||||
에이전트별 파일명:
|
||||
|
||||
실제 생성/동기화 대상 목록은 `agent-ops/bin/entry-files.sh`의 `AGENT_OPS_ENTRY_FILES`를 단일 기준으로 사용한다.
|
||||
|
||||
| 에이전트 | 파일명 |
|
||||
|---------|--------|
|
||||
| Gemini | `GEMINI.md` |
|
||||
| Claude | `CLAUDE.md` |
|
||||
| Kilo Code / OpenCode | `AGENTS.md` |
|
||||
| Cursor | `.cursorrules` |
|
||||
| Cline | `.clinerules` |
|
||||
|
||||
## 에이전트 진입 파일 원칙
|
||||
|
||||
진입 파일은 `rules/common/rules.md` 내용 그대로를 에이전트별 파일명으로 복사한다.
|
||||
별도 내용을 추가하거나 수정하지 않는다.
|
||||
|
||||
## Rule 구조 원칙
|
||||
|
||||
### rules/common/rules.md
|
||||
- 공통 관리 레포에서 제공. 프로젝트에서 직접 수정하지 않는다.
|
||||
- 실제 사용은 진입점 파일들에서 사용된다.
|
||||
|
||||
포함 항목:
|
||||
- 기본 원칙
|
||||
- 공통 스킬 라우팅 (router.md 참조)
|
||||
- project/rules.md 로드 지시
|
||||
|
||||
### rules/project/rules.md
|
||||
init-agent-ops가 프로젝트를 분석하여 생성한다.
|
||||
|
||||
포함 항목:
|
||||
- 응답 언어
|
||||
- 프로젝트 개요 / 주요 구조
|
||||
- 기술 스택
|
||||
- 프로젝트 특화 컨벤션
|
||||
- 도메인 매핑 테이블 (경로 패턴 → domain rules.md)
|
||||
- 프로젝트 스킬 라우팅 (해당 시)
|
||||
|
||||
common/rules.md와 내용이 중복되지 않도록 한다.
|
||||
|
||||
#### 도메인 매핑 테이블 형식
|
||||
|
||||
```markdown
|
||||
## 도메인 매핑
|
||||
|
||||
| 경로 패턴 | 도메인 | rules.md |
|
||||
|----------|--------|----------|
|
||||
| `src/order/**` | order | `agent-ops/rules/project/domain/order/rules.md` |
|
||||
| `src/payment/**` | payment | `agent-ops/rules/project/domain/payment/rules.md` |
|
||||
| `src/common/**` | common | `agent-ops/rules/project/domain/common/rules.md` |
|
||||
```
|
||||
|
||||
#### 프로젝트 스킬 라우팅 형식
|
||||
|
||||
```markdown
|
||||
## 스킬 라우팅
|
||||
|
||||
| 요청 키워드 | SKILL.md |
|
||||
|------------|----------|
|
||||
| 테스트 실행해줘 | `agent-ops/skills/project/run-test/SKILL.md` |
|
||||
```
|
||||
|
||||
### domain rule
|
||||
각 도메인 rules.md에는 아래만 둔다.
|
||||
|
||||
- 목적 / 책임
|
||||
- 포함 경로
|
||||
- 제외 경로
|
||||
- 주요 구성 요소
|
||||
- 유지할 패턴
|
||||
- 다른 도메인과의 경계
|
||||
- 금지 사항
|
||||
|
||||
## DDD 기준
|
||||
|
||||
- **Core Domain**: 핵심 가치와 주요 유즈케이스
|
||||
- **Supporting Domain**: 핵심 도메인을 지원
|
||||
- **Generic / Common**: 여러 도메인이 공통으로 사용
|
||||
|
||||
도메인은 실제 폴더, 모듈, 패키지, 책임 경계와 연결되어야 한다.
|
||||
|
||||
## 실행 (Execution)
|
||||
|
||||
지정한 대상 디렉토리에 agent-ops 스캐폴드를 생성한다.
|
||||
|
||||
```bash
|
||||
./agent-ops/bin/init-agent-ops.sh <target_directory>
|
||||
```
|
||||
|
||||
## 실행 절차
|
||||
|
||||
1. **상태 판별**
|
||||
- 프로젝트 구조, 모듈 경계, agent-ops 파일 유무를 분석하여 신규/운영중을 판별한다
|
||||
|
||||
2. **에이전트 진입 파일 생성**
|
||||
- `rules/common/rules.md`를 `agent-ops/bin/entry-files.sh`의 파일 목록으로 프로젝트 루트에 복사한다
|
||||
|
||||
3. **AI ignore / permission 기본 설정**
|
||||
- `.geminiignore`, `.aiexclude`, `.cursorignore`, `.clineignore`에 `agent-task/archive/**`를 추가한다
|
||||
- `.claude/settings.json`, `opencode.json`이 없으면 archive 읽기/검색 제외 설정을 생성한다
|
||||
- `agent-task/archive/**` 제외는 `.gitignore`에 추가하지 않는다
|
||||
|
||||
4. **agent-ops 폴더 구조 복사**
|
||||
- 공통 관리 레포의 `agent-ops/` 공통 폴더(bin, rules/common, skills/common)를 복사한다
|
||||
- `agent-ops/.version` 파일을 복사한다
|
||||
|
||||
5. **rules/project/rules.md 생성**
|
||||
- 프로젝트를 분석하여 응답 언어, 프로젝트 개요, 기술 스택 등을 채운다
|
||||
- common/rules.md와 내용이 중복되지 않도록 한다
|
||||
|
||||
6. **도메인 분석 및 domain rule 생성**
|
||||
- 신규 프로젝트: 핵심 domain placeholder 2~4개만 제안한다. domain rules를 과도하게 채우지 않는다
|
||||
- 운영중 프로젝트: Core/Supporting/Generic 도메인을 식별하고 실제 경로를 반영한 초안을 생성한다
|
||||
|
||||
7. **초기 skill 제안**
|
||||
- 신규 프로젝트: 최소 2개만 제안한다
|
||||
- 운영중 프로젝트: 반복 작업 기반으로 필요한 skill을 제안한다
|
||||
|
||||
8. **결과 보고**
|
||||
- 상태 판별 결과, 생성된 파일 목록, 도메인 제안, skill 제안, 주의사항을 출력한다
|
||||
|
||||
## 출력 형식
|
||||
|
||||
### 상태 판별
|
||||
- Agent-Ops 상태: 없음 / 부분 적용 / 운영중
|
||||
- 프로젝트 상태: 신규 / 운영중
|
||||
- 근거: 짧게 요약
|
||||
|
||||
### 스캐폴드 계획
|
||||
- 생성할 파일
|
||||
- 바로 채울 파일
|
||||
- placeholder로 둘 파일
|
||||
|
||||
### 도메인 제안
|
||||
- Core Domain
|
||||
- Supporting Domain
|
||||
- Generic / Common
|
||||
|
||||
### 초기 skill 제안
|
||||
- skill 이름
|
||||
- 필요한 이유
|
||||
|
||||
### 주의사항
|
||||
- 지금 만들지 말아야 할 것
|
||||
- 아직 확정하면 안 되는 것
|
||||
|
||||
## 실행 결과 검증
|
||||
|
||||
- [ ] `agent-ops/bin/entry-files.sh`의 모든 진입 파일이 프로젝트 루트에 존재하고, 내용이 초기화에 사용한 `rules/common/rules.md`와 일치하는가
|
||||
- [ ] `agent-ops/rules/project/rules.md`가 생성되었고, 필수 항목(응답 언어, 프로젝트 개요, 기술 스택)이 포함되어 있는가
|
||||
- [ ] 생성된 domain rules.md가 `domain-rule-template.md` 형식을 따르는가
|
||||
- [ ] `rules/project/rules.md`의 도메인 매핑 테이블에 생성된 도메인이 모두 등록되어 있는가
|
||||
- [ ] `.gitignore`에 `agent-ops/rules/private/` 항목이 추가되어 있는가
|
||||
- [ ] `.geminiignore`, `.aiexclude`, `.cursorignore`, `.clineignore`에 `agent-task/archive/**`가 포함되어 있는가
|
||||
- [ ] `.claude/settings.json`, `opencode.json`에 `agent-task/archive/**` 제외 설정이 있거나, 기존 파일 수동 병합 안내를 출력했는가
|
||||
- [ ] `.gitignore`에 `agent-task/archive/**`를 추가하지 않았는가
|
||||
- 검증 실패 시: 누락된 파일/항목을 사용자에게 알리고 해당 부분만 보완한다
|
||||
|
||||
## 금지 사항
|
||||
|
||||
- 진입 파일에 rules/common/rules.md 외 내용을 추가하지 않는다.
|
||||
- `agent-task/archive/**` 제외를 `.gitignore`에 추가하지 않는다.
|
||||
- 실제 구조보다 앞선 추상 구조를 강요하지 않는다.
|
||||
- 처음부터 많은 domain / skill을 만들지 않는다.
|
||||
- rules/common/rules.md를 프로젝트에서 직접 수정하지 않는다.
|
||||
- rules/project/rules.md에 rules/common/rules.md와 중복되는 내용을 넣지 않는다.
|
||||
317
agent-ops/skills/common/plan/SKILL.md
Normal file
317
agent-ops/skills/common/plan/SKILL.md
Normal file
|
|
@ -0,0 +1,317 @@
|
|||
---
|
||||
name: plan
|
||||
description: Analyze the current repository and write a detailed PLAN-{build_lane}-GNN.md for implementation work. Also writes the CODE_REVIEW-{review_lane}-GNN.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 the plan file and does the coding. The code-review skill archives both files after review and moves PASS tasks under agent-task/archive/YYYY/MM/.
|
||||
---
|
||||
|
||||
# Plan
|
||||
|
||||
## Purpose
|
||||
|
||||
Create the planning artifacts for the implementation loop:
|
||||
|
||||
```text
|
||||
plan skill -> PLAN-{build_lane}-GNN.md + CODE_REVIEW-{review_lane}-GNN.md stub
|
||||
implementation -> code changes + filled CODE_REVIEW-{review_lane}-GNN.md
|
||||
code-review skill -> verdict + archive, complete.log, and PASS task-directory archive move or new follow-up plan/review files
|
||||
```
|
||||
|
||||
## Workflow Contract
|
||||
|
||||
This skill intentionally uses routed active files under `agent-task/{task_name}/` as the state protocol. Do not change this filename contract unless the paired code-review skill is updated together.
|
||||
|
||||
Filename rules:
|
||||
|
||||
- Plan file: `PLAN-{build_lane}-GNN.md`
|
||||
- Review stub: `CODE_REVIEW-{review_lane}-GNN.md`
|
||||
- `{lane}` is only `local` or `cloud`; never put model names in filenames.
|
||||
- `GNN` is a two-digit capability grade from `G01` to `G10`; the runtime maps lane+grade to current models externally.
|
||||
|
||||
Task directory naming rules:
|
||||
|
||||
- A single-plan task uses `agent-task/{task_name}/` with a short snake_case task name.
|
||||
- If one plan is not enough, split the work into multiple task directories. Each directory owns exactly one normal active plan file and one normal active review stub.
|
||||
- Multi-plan output is a set of independent `PLAN-{build_lane}-GNN.md` + `CODE_REVIEW-{review_lane}-GNN.md` pairs across multiple folders, not multiple plan files inside one folder.
|
||||
- Multi-plan task directory names must start with an execution-order index: `01_{task_name}`, `02_{task_name}`, `03_{task_name}`, and so on.
|
||||
- If a later task cannot start until a specific current task is complete, mark that dependency immediately after the current task's index with `+`, not `_`: `01+{dependent_task_name}` means this task depends on completion of the `01_...` task.
|
||||
- When multiple dependent tasks share the same predecessor, order them after the dependency marker: `01+01_{task_name}`, `01+02_{task_name}`.
|
||||
- Directory names are runtime scheduling metadata. Preserve them verbatim; do not normalize, reinterpret, or choose execution order by agent judgment.
|
||||
- Every split plan must include `의존 관계 및 구현 순서` and list predecessor task directories that must reach `complete.log` before implementation begins.
|
||||
|
||||
Routing rules:
|
||||
|
||||
- Build defaults to `local` when the plan is explicit, tests are runnable, and failure is review-detectable.
|
||||
- Use `cloud` for weak tests, broad API/call-site impact, ambiguity, storage/concurrency/protocol/auth risk, or prior local failure.
|
||||
- Use `cloud-G07` or higher for terminal-agent work: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, or terminal benchmark-style tasks. Merely running deterministic tests such as `go test` does not make a task terminal-agent work.
|
||||
- Use `cloud-G07` or higher when acceptance depends on a real interactive external tool, TUI, PTY, browser, screen repaint/cursor stream, or bin-level smoke output. This is mandatory when unit tests pass but the real smoke/integration command fails.
|
||||
- Use `cloud-G07` or higher when a prior review found verification trust failure, reconstructed command output, or claimed stdout/stderr that does not match a rerun.
|
||||
- Keep high-risk design judgment on `cloud` with a higher grade; the runtime may map `cloud-GNN` to frontier-class models.
|
||||
- Review may be `local` for narrow/low-risk checks and `cloud` for multi-file/API/test-meaning reviews, security/auth, storage/migration, concurrency, protocol/schema, cross-domain, or repeated Required issues.
|
||||
- Raise `GNN` with scope, ambiguity, missing tests, irreversible behavior, and blast radius; keep grade model-independent.
|
||||
|
||||
Directory states:
|
||||
|
||||
| State | Meaning |
|
||||
|-------|---------|
|
||||
| `PLAN-*-G??.md` only | Invalid; plan skill always writes both active files |
|
||||
| `PLAN-*-G??.md` + `CODE_REVIEW-*-G??.md` stub | Implementation is pending/in progress |
|
||||
| `PLAN-*-G??.md` + filled `CODE_REVIEW-*-G??.md` | Ready for code-review skill |
|
||||
| `complete.log` + `*.log` files | Task complete (PASS), before final task-directory archive move |
|
||||
| `agent-task/archive/YYYY/MM/{task_name}/complete.log` + `*.log` files | Archived completed task (PASS); not active |
|
||||
| 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-*-G??.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 | If the user/runtime named a task directory, use that directory. Otherwise list paths and ask which task to use; do not choose by agent judgment. |
|
||||
|
||||
The routed plan file is the loop entry point. A missing active plan 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`.
|
||||
|
||||
When the work must be split into multiple plans, choose directory names using the task directory naming rules above. Do not put multiple active plan files in one task directory.
|
||||
|
||||
## 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.
|
||||
|
||||
- [ ] **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.
|
||||
- [ ] **Assess test coverage** — for each behavior change, explicitly record whether existing tests cover it.
|
||||
- [ ] **Grep all symbol references** — for any renamed or removed symbol, find every call site and import chain.
|
||||
- [ ] **Check dependency manifests** — before adding any new package, verify its presence in go.mod / package manifest.
|
||||
- [ ] **Pre-check compile issues** — identify missing interface implementations, type mismatches, and broken imports.
|
||||
- [ ] **Verify verification commands** — confirm that the final verification commands actually run in this repository layout.
|
||||
- [ ] **Stabilize fragile verification** — for search or generated-output checks, choose deterministic commands up front, such as `rg --sort path`, and decide whether cached test output is acceptable or `-count=1` is required.
|
||||
|
||||
## Step 3 - Determine GXX Grade
|
||||
|
||||
GXX is an output of analysis, not an input. Determine lane and grade only after Step 2 is fully complete.
|
||||
|
||||
- [ ] **Assess change scope** — count affected files, interface impact, and call-site count.
|
||||
- [ ] **Check risk factors** — mark any that apply: concurrency, storage/migration, protocol/schema, auth, irreversible behavior.
|
||||
- [ ] **Evaluate test confidence** — judge whether existing tests sufficiently verify the changed behavior.
|
||||
- [ ] **Decide lane** — use `local` if the plan is explicit and tests are sufficient; use `cloud` if any of the following apply:
|
||||
- Tests are weak or do not cover the changed behavior
|
||||
- Broad API/call-site impact
|
||||
- Concurrency, storage, protocol, or auth risk
|
||||
- Prior local build failure on this task
|
||||
- Terminal-agent work: shell/CLI workflow implementation, bin script orchestration, process control, stdout/stderr parsing, exit-status contracts, long-running command diagnosis, or terminal benchmark-style tasks
|
||||
- Real bin/smoke/integration verification failed after unit tests passed
|
||||
- Interactive TUI/PTY/browser/external CLI automation or screen-rendered output is part of the success condition
|
||||
- A prior review marked verification trust Fail/Warn because recorded command output did not match a rerun
|
||||
- [ ] **Decide GNN** — assign a higher grade as scope, ambiguity, irreversibility, and blast radius increase. Grade is complexity-based, not model-name-based.
|
||||
|
||||
## Step 4 - 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-*-G??.md` exists, rename `PLAN-{build_lane}-GNN.md` to `plan_{build_lane}_GNN_N.log`.
|
||||
- Count existing `agent-task/{task_name}/code_review_*.log`; call it `M`. If `CODE_REVIEW-*-G??.md` exists, rename `CODE_REVIEW-{review_lane}-GNN.md` to `code_review_{review_lane}_GNN_M.log`.
|
||||
|
||||
The new plan number is the count of `plan_*.log` after archiving.
|
||||
|
||||
## Step 5 - Write Plan File
|
||||
|
||||
Header line must be exactly:
|
||||
|
||||
```markdown
|
||||
<!-- task={task_name} plan={N} tag={TAG} -->
|
||||
```
|
||||
|
||||
Required sections:
|
||||
|
||||
- Title.
|
||||
- `이 파일을 읽는 구현 에이전트에게`: open with a bold warning that filling in implementation-owned sections of `CODE_REVIEW-*-G??.md` is a mandatory final step — the task is NOT complete until every implementation-owned section of that file is filled. Tell the implementer to work from the implementation checklist, complete every checklist item in both the plan and review stub, run intermediate/final verification, and fill implementation-owned `CODE_REVIEW-*-G??.md` sections with actual implementation notes and command output. Explicitly state that the implementing agent must NOT execute the archiving instructions in the review file's `이 파일을 읽는 리뷰 에이전트에게` section and must NOT modify or check the `코드리뷰 전용 체크리스트` — those instructions/checklists are for the code-review skill only.
|
||||
- `배경`: 2-4 sentences explaining why the work is needed.
|
||||
- `분석 결과`: 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 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 which files or areas were explicitly excluded from this change and why. This is the boundary justification — the implementing agent must not silently expand scope beyond what is recorded here.
|
||||
- `빌드 등급`: state the decided lane and GNN grade with a one-line rationale.
|
||||
- `구현 체크리스트`: a top-level checklist the implementing agent must follow while coding. Include one item per plan item, one item for all intermediate/final verification, 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`의 구현 에이전트 소유 섹션을 채운다. 이 파일 작성이 구현의 마지막 단계다."**
|
||||
|
||||
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.
|
||||
|
||||
For split multi-plan work, `의존 관계 및 구현 순서` is mandatory in every generated plan. If a plan has a `NN+...` directory name, state which `NN_...` predecessor must produce `complete.log` before implementation starts.
|
||||
|
||||
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.
|
||||
- Be concise. Write the minimum words needed to convey the decision or fact. No preamble, no restatement of context already in the plan, no closing summaries.
|
||||
|
||||
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 |
|
||||
|
||||
Verification fidelity rules:
|
||||
|
||||
- Plan verification commands are a contract. The implementing agent must run them exactly as written.
|
||||
- If a command must be changed, the implementing agent must record the replacement command and reason in `계획 대비 변경 사항`, then paste the replacement command's actual stdout/stderr.
|
||||
- Before claiming a tool is unavailable, run and record `command -v <tool>` or the project-equivalent check.
|
||||
- Do not download, generate, or leave verification tools inside the repository. Temporary tools belong outside the repo, such as under `/tmp`, and must not become task artifacts.
|
||||
- For search commands whose output order may vary, specify deterministic options in the plan, for example `rg --sort path`.
|
||||
- `검증 결과` must contain actual stdout/stderr, not summarized or reconstructed output. If output is too long, record the saved output file path and the exact command used to create it.
|
||||
- If the plan's pass condition says all leftovers must be intentional exceptions, any `변경 필요` item forces FAIL until resolved or explicitly reclassified with evidence.
|
||||
- Decide in the plan whether Go test cache output is acceptable. If fresh execution matters, use `go test -count=1 ...`.
|
||||
|
||||
## Step 6 - Write Review 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
|
||||
<!-- task={task_name} plan={N} tag={TAG} -->
|
||||
|
||||
# Code Review Reference - {TAG}
|
||||
|
||||
> **[IMPLEMENTING AGENT — READ FIRST] Filling in this file is the mandatory final step of implementation.**
|
||||
> The task is NOT complete until every implementation-owned section below is filled in.
|
||||
> Complete the `구현 체크리스트`; the final checklist item is mandatory before saving.
|
||||
> Do not modify or check the `코드리뷰 전용 체크리스트`; it is owned by the review agent only.
|
||||
> Follow the ownership table at the bottom of this file for which sections you own.
|
||||
|
||||
## 개요
|
||||
|
||||
date={YYYY-MM-DD}
|
||||
task={task_name}, plan={N}, tag={TAG}
|
||||
|
||||
## 이 파일을 읽는 리뷰 에이전트에게
|
||||
|
||||
각 항목의 구현을 실제 소스 파일과 대조하고, `검증 결과` 섹션의 출력이 코드와 일치하는지 확인하세요.
|
||||
review 완료 후 반드시 아래 순서로 아카이브하세요.
|
||||
|
||||
1. `CODE_REVIEW-{review_lane}-GNN.md` → `code_review_{review_lane}_GNN_N.log` (N = 기존 code_review_*.log 수)
|
||||
2. `PLAN-{build_lane}-GNN.md` → `plan_{build_lane}_GNN_M.log` (M = 기존 plan_*.log 수)
|
||||
3. PASS인 경우 `complete.log` 작성 후 `agent-task/archive/YYYY/MM/{task_name}/`로 task 디렉터리 이동. WARN/FAIL인 경우 새 routed plan + review 스텁 작성.
|
||||
|
||||
어떤 판정에서도 아카이브를 건너뛰지 마세요. PASS/WARN/FAIL 모두 `코드리뷰 결과` append 후 active plan/review 파일을 먼저 아카이브하고, 그 다음 `complete.log` 또는 다음 plan/review 파일을 작성해야 합니다.
|
||||
PASS에서는 `agent-ops/skills/common/code-review/templates/complete-log-template.md`의 섹션 순서와 필수 항목을 기준으로 `complete.log`를 작성하세요. 작성 후 현재 날짜의 `YYYY/MM` 기준으로 task 디렉터리를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동하고, 최종 archive 경로의 `code_review_*.log`에서 `코드리뷰 전용 체크리스트`를 갱신한 다음 보고하세요.
|
||||
WARN/FAIL에서는 다음 상태 파일 작성 후 현재 task 경로의 archived `code_review_*.log`에서 적용 가능한 `코드리뷰 전용 체크리스트` 항목을 체크한 다음 보고하세요.
|
||||
|
||||
---
|
||||
|
||||
## 구현 항목별 완료 여부
|
||||
|
||||
| 항목 | 완료 여부 |
|
||||
|------|---------|
|
||||
| [{TAG}-1] {item description} | [ ] |
|
||||
| [{TAG}-2] {item description} | [ ] |
|
||||
|
||||
## 구현 체크리스트
|
||||
|
||||
{copy the plan's 구현 체크리스트 items exactly, preserving order and checkbox text}
|
||||
|
||||
## 코드리뷰 전용 체크리스트
|
||||
|
||||
> **[REVIEW AGENT ONLY]** 이 체크리스트는 코드리뷰 에이전트만 사용한다.
|
||||
> 구현 에이전트는 이 섹션을 수정하거나 체크하지 않는다.
|
||||
|
||||
- [ ] `코드리뷰 결과`에 `PASS`, `WARN`, `FAIL` 중 하나의 판정을 append한다.
|
||||
- [ ] 판정과 `차원별 평가`, Required/Suggested/Nit 분류가 서로 일치한다.
|
||||
- [ ] active `CODE_REVIEW-*-G??.md`를 `code_review_{review_lane}_GNN_N.log`로 아카이브한다.
|
||||
- [ ] active `PLAN-*-G??.md`를 `plan_{build_lane}_GNN_M.log`로 아카이브한다.
|
||||
- [ ] PASS이면 `agent-ops/skills/common/code-review/templates/complete-log-template.md` 기준으로 `complete.log`를 작성하고 active `.md` 파일을 남기지 않는다.
|
||||
- [ ] PASS이면 `agent-task/{task_name}/`를 `agent-task/archive/YYYY/MM/{task_name}/`로 이동하고 최종 archive 경로에서 이 체크리스트를 갱신한다.
|
||||
- [ ] WARN/FAIL이면 다음 active `PLAN-{build_lane}-GNN.md`와 `CODE_REVIEW-{review_lane}-GNN.md`를 작성하고 `complete.log`를 작성하지 않는다.
|
||||
|
||||
## 계획 대비 변경 사항
|
||||
|
||||
_구현 에이전트가 계획과 다르게 구현한 부분을 이유와 함께 기록한다._
|
||||
|
||||
## 주요 설계 결정
|
||||
|
||||
_구현 에이전트가 주요 설계 결정 사항을 기록한다._
|
||||
|
||||
## 리뷰어를 위한 체크포인트
|
||||
|
||||
{pre-filled from plan — one bullet per review focus area}
|
||||
|
||||
## 검증 결과
|
||||
|
||||
_구현 에이전트가 각 중간 검증 및 최종 검증 명령 실행 후 출력을 여기에 붙여 넣는다._
|
||||
|
||||
필수 규칙:
|
||||
- 검증 명령은 고정된 계약이다. 임의로 대체하지 않는다.
|
||||
- 대체가 필요하면 `계획 대비 변경 사항`에 이유와 대체 명령을 기록한다.
|
||||
- `검증 결과`에는 실제 stdout/stderr를 붙여 넣는다.
|
||||
|
||||
### {TAG}-1 중간 검증
|
||||
```
|
||||
$ {verification command from plan}
|
||||
(output)
|
||||
```
|
||||
|
||||
### 최종 검증
|
||||
```
|
||||
$ {final verification command from plan}
|
||||
(output)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> **[IMPLEMENTING AGENT — BEFORE SAVING] Have you filled in every implementation-owned section: completion table, implementation checklist, changes from plan, design decisions, and verification output?**
|
||||
> If anything is blank, go back and fill it in before saving this file.
|
||||
> Leave the review-agent-only checklist unchanged.
|
||||
```
|
||||
|
||||
Sections and their ownership:
|
||||
|
||||
| Section | Owner | Note |
|
||||
|---------|-------|------|
|
||||
| Header comment, 개요, 리뷰 에이전트 지시 | Fixed at stub creation | Implementing agent must not modify or execute these (archive, complete.log, and task-directory archive move are review-agent only) |
|
||||
| 구현 항목별 완료 여부 (item names) | Fixed at stub creation | Implementing agent checks `[ ]` → `[x]` only |
|
||||
| 구현 체크리스트 (item text/order) | Fixed at stub creation from plan | Implementing agent checks `[ ]` → `[x]` only; final checkbox is mandatory before saving |
|
||||
| 코드리뷰 전용 체크리스트 | Review agent only | Implementing agent must not modify or check this section |
|
||||
| 계획 대비 변경 사항, 주요 설계 결정 | Implementing agent | Replace placeholder text with actual content |
|
||||
| 리뷰어를 위한 체크포인트 | Fixed at stub creation | Pre-filled from plan |
|
||||
| 검증 결과 (section headings + commands) | Fixed at stub creation | Implementing agent fills in command output only; command changes require a `계획 대비 변경 사항` entry |
|
||||
| 코드리뷰 결과 | Review agent appends | Not included in stub |
|
||||
|
||||
## Naming
|
||||
|
||||
| Tag | Use for |
|
||||
|-----|---------|
|
||||
| `API` | Public API changes |
|
||||
| `REFACTOR` | Internal refactoring |
|
||||
| `TEST` | Test additions/fixes |
|
||||
| `REVIEW_<TAG>` | Follow-up fixes after review |
|
||||
|
||||
## Final Checklist
|
||||
|
||||
- `PLAN-{build_lane}-GNN.md` and `CODE_REVIEW-{review_lane}-GNN.md` both exist under `agent-task/{task_name}/`.
|
||||
- Split work, if any, uses one task directory per plan/review pair with `01_...`, `02_...`, or dependency-marked `NN+...` names.
|
||||
- Both first lines match `<!-- task={task_name} plan={N} tag={TAG} -->`.
|
||||
- Previous active files, if any, were archived with correct numeric suffixes.
|
||||
- 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 review stub has a clearly marked `코드리뷰 전용 체크리스트` owned only by the review agent.
|
||||
- Routed review file completion table lists every plan item.
|
||||
4
agent-ops/skills/common/plan/agents/openai.yaml
Normal file
4
agent-ops/skills/common/plan/agents/openai.yaml
Normal file
|
|
@ -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."
|
||||
13
agent-ops/skills/common/router.md
Normal file
13
agent-ops/skills/common/router.md
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
# 공통 스킬 라우터
|
||||
|
||||
| 요청 키워드 | SKILL.md |
|
||||
|------------|----------|
|
||||
| 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 싱크해, agent-ops 동기화해, agentic-framework에 올려줘, agent-ops를 [프로젝트]로 싱크해 | `agent-ops/skills/common/sync-push/SKILL.md` |
|
||||
| agent-ops pull해, agent-ops 가져와, agentic-framework에서 가져와, agent-ops 내려받아 | `agent-ops/skills/common/sync-pull/SKILL.md` |
|
||||
| 도메인 업데이트, domain rule 갱신, 도메인 검토, domain 스캔 | `agent-ops/skills/common/update-domain-rule/SKILL.md` |
|
||||
36
agent-ops/skills/common/sync-pull/SKILL.md
Normal file
36
agent-ops/skills/common/sync-pull/SKILL.md
Normal file
|
|
@ -0,0 +1,36 @@
|
|||
---
|
||||
name: sync-pull
|
||||
description: agentic-framework에서 현재 프로젝트로 agent-ops를 내려받는다. "agent-ops pull해", "agentic-framework에서 가져와" 요청 시 사용한다.
|
||||
---
|
||||
|
||||
# sync-pull
|
||||
|
||||
## 목적
|
||||
|
||||
`agent-ops/bin/sync.sh --pull`을 호출해 agentic-framework → 현재 프로젝트 방향으로 agent-ops를 내려받는다.
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
- "agent-ops pull해", "agent-ops 가져와" 요청 시
|
||||
- "agentic-framework에서 가져와" 요청 시
|
||||
- "agent-ops 내려받아" 요청 시
|
||||
|
||||
## 실행 절차
|
||||
|
||||
1. 현재 프로젝트의 **상위 폴더(`../`)** 에 `agentic-framework` 폴더가 있는지 확인한다 (현재 폴더 내부가 아님)
|
||||
2. **있으면**: `agent-ops/bin/sync.sh --pull agentic-framework` 실행
|
||||
3. **없으면**: 사용자에게 agentic-framework 경로 입력을 안내하고, 입력받은 경로로 실행
|
||||
|
||||
```bash
|
||||
agent-ops/bin/sync.sh --pull <target>
|
||||
```
|
||||
|
||||
## 실행 결과 검증
|
||||
|
||||
- [ ] sync.sh 가 오류 없이 완료됐는가
|
||||
- [ ] 현재 프로젝트 버전이 framework 버전과 일치하는가
|
||||
- [ ] `agent-ops/bin/entry-files.sh`의 모든 진입 파일이 갱신됐고, 내용이 framework의 `agent-ops/rules/common/rules.md`와 일치하는가
|
||||
|
||||
## 금지 사항
|
||||
|
||||
- sync.sh 를 거치지 않고 직접 파일을 복사하지 않는다
|
||||
60
agent-ops/skills/common/sync-push/SKILL.md
Normal file
60
agent-ops/skills/common/sync-push/SKILL.md
Normal file
|
|
@ -0,0 +1,60 @@
|
|||
---
|
||||
name: sync-push
|
||||
description: 현재 프로젝트의 agent-ops를 agentic-framework로 올리거나, agentic-framework의 공통 agent-ops를 대상 프로젝트로 push한다. "agent-ops 싱크해", "agent-ops 동기화해", "agentic-framework에 올려줘" 요청 시 사용한다.
|
||||
---
|
||||
|
||||
# sync-push
|
||||
|
||||
## 목적
|
||||
|
||||
`agent-ops/bin/sync.sh`를 호출해 agent-ops 공통 파일을 push 방향으로 동기화한다.
|
||||
|
||||
- 일반 프로젝트에서는 현재 프로젝트 → agentic-framework 방향으로 올린다.
|
||||
- agentic-framework 원본 프로젝트에서는 agentic-framework → 대상 프로젝트 방향으로 보낸다.
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
- "agent-ops 싱크해", "agent-ops 동기화해" 요청 시
|
||||
- "agentic-framework에 올려줘" 요청 시
|
||||
- "agent-ops를 [프로젝트]로 싱크해" 요청 시
|
||||
|
||||
## 실행 절차
|
||||
|
||||
### 현 프로젝트가 일반 프로젝트인 경우 (`.agent-ops-source` 없음)
|
||||
|
||||
1. 현재 프로젝트의 **상위 폴더(`../`)** 에 `agentic-framework` 폴더가 있는지 확인한다 (현재 폴더 내부가 아님)
|
||||
2. **있으면**: `agent-ops/bin/sync.sh agentic-framework` 실행
|
||||
3. **없으면**: 사용자에게 agentic-framework 경로 입력을 안내하고, 입력받은 경로로 실행
|
||||
|
||||
### 현 프로젝트가 agentic-framework인 경우 (`.agent-ops-source` 있음)
|
||||
|
||||
1. 사용자 요청에서 target 프로젝트명 또는 경로를 추출한다
|
||||
2. **명시된 경우**: `agent-ops/bin/sync.sh <target>` 실행
|
||||
3. **명시되지 않은 경우**: 사용자에게 대상 프로젝트 입력을 요청한다
|
||||
4. `sync.sh`는 현재 agentic-framework의 `agent-ops/rules/common/rules.md` 내용을 대상 프로젝트 루트의 진입 파일에 덮어쓴다
|
||||
|
||||
덮어쓰기 대상은 `init-agent-ops` 초기 세팅과 동일하며, 실제 목록은 `agent-ops/bin/entry-files.sh`의 `AGENT_OPS_ENTRY_FILES`를 단일 기준으로 사용한다.
|
||||
|
||||
| 에이전트 | 파일명 |
|
||||
|---------|--------|
|
||||
| Gemini | `GEMINI.md` |
|
||||
| Claude | `CLAUDE.md` |
|
||||
| Kilo Code / OpenCode | `AGENTS.md` |
|
||||
| Cursor | `.cursorrules` |
|
||||
| Cline | `.clinerules` |
|
||||
|
||||
대상 프로젝트에 기존 진입 파일이 있어도 보존하거나 병합하지 않고 `agent-ops/rules/common/rules.md` 내용으로 교체한다.
|
||||
|
||||
```bash
|
||||
agent-ops/bin/sync.sh <target>
|
||||
```
|
||||
|
||||
## 실행 결과 검증
|
||||
|
||||
- [ ] sync.sh 가 오류 없이 완료됐는가
|
||||
- [ ] 버전 충돌 경고가 없었는가 — 있었다면 사용자에게 수동 머지 필요함을 알린다
|
||||
- [ ] agentic-framework에서 대상 프로젝트로 push한 경우, `agent-ops/bin/entry-files.sh`의 모든 진입 파일 내용이 현재 agentic-framework의 `agent-ops/rules/common/rules.md`와 일치하는가
|
||||
|
||||
## 금지 사항
|
||||
|
||||
- sync.sh 를 거치지 않고 직접 파일을 복사하지 않는다
|
||||
100
agent-ops/skills/common/update-domain-rule/SKILL.md
Normal file
100
agent-ops/skills/common/update-domain-rule/SKILL.md
Normal file
|
|
@ -0,0 +1,100 @@
|
|||
---
|
||||
name: update-domain-rule
|
||||
version: 1.0.0
|
||||
description: 기존 도메인 rules.md를 코드 현황에 맞게 갱신. 전체 스캔(full) 또는 지정 도메인(targeted) 두 모드 지원
|
||||
---
|
||||
|
||||
# update-domain-rule
|
||||
|
||||
## 목적
|
||||
|
||||
프로젝트 코드가 변경되면서 기존 domain rule이 실제 구조와 어긋날 수 있다.
|
||||
이 스킬은 실제 파일 구조를 탐색하여 기존 `rules.md`와 비교하고, 누락·오류·구식 항목을 수정한다.
|
||||
|
||||
## 언제 호출할지
|
||||
|
||||
- 대규모 리팩터링 또는 외부 패키지 내재화 후 domain rule 동기화가 필요할 때
|
||||
- 특정 도메인 파일 구조가 바뀌어 기존 rule이 맞지 않을 때
|
||||
- 사용자가 "도메인 업데이트", "domain rule 갱신", "domain 검토" 등을 요청할 때
|
||||
- agent-ops 초기 scaffold 이후 코드가 많이 달라진 경우
|
||||
|
||||
## 입력
|
||||
|
||||
- `mode`: `full`(전체 도메인 스캔) | `targeted`(지정 도메인만) (필수)
|
||||
- `domain-name`: 업데이트할 도메인 이름 — `targeted` 모드에서만 필수
|
||||
|
||||
## 먼저 확인할 것
|
||||
|
||||
- [ ] `agent-ops/rules/project/domain/` 하위 기존 도메인 목록 확인
|
||||
- [ ] `agent-ops/rules/common/_templates/domain-rule-template.md` 읽어 최신 템플릿 형식 파악
|
||||
- [ ] `targeted` 모드이면 `agent-ops/rules/project/domain/<domain-name>/rules.md` 존재 여부 확인
|
||||
- 존재하지 않으면 `create-domain-rule` 스킬을 사용하도록 안내하고 중단
|
||||
|
||||
## 실행 절차
|
||||
|
||||
1. **대상 목록 결정**
|
||||
- `full`: `agent-ops/rules/project/domain/` 하위 모든 도메인 디렉터리를 대상으로 한다
|
||||
- `targeted`: 지정된 `domain-name` 하나만 대상으로 한다
|
||||
|
||||
2. **도메인별 코드 탐색**
|
||||
- 기존 `rules.md`의 **포함 경로** 목록을 기준으로 실제 파일 구조 탐색
|
||||
- 포함 경로에 없지만 도메인 이름과 연관된 경로도 함께 탐색
|
||||
- 탐색 시 실제로 존재하는 경로만 수집한다
|
||||
|
||||
3. **비교 및 변경 항목 식별**
|
||||
다음 항목 각각을 현재 `rules.md`와 비교한다:
|
||||
- **포함 경로**: 실제로 존재하지 않는 경로 제거, 새로 생긴 경로 추가
|
||||
- **주요 구성 요소**: 파일/클래스 삭제·이름 변경·신규 추가 반영
|
||||
- **유지할 패턴**: 코드에서 더 이상 사용되지 않는 패턴 제거, 새 패턴 추가
|
||||
- **다른 도메인과의 경계**: 도메인 간 import 관계가 바뀐 경우 반영
|
||||
- **목적/책임**: 도메인 책임이 실질적으로 변경된 경우에만 수정
|
||||
|
||||
4. **rules.md 업데이트**
|
||||
- 변경이 필요한 항목만 수정한다 — 변경 불필요한 섹션은 그대로 둔다
|
||||
- 확인된 사실만 기재한다; 불확실하면 `<!-- TODO: 확인 필요 -->` 주석 처리
|
||||
- `domain-rule-template.md`의 섹션 구조를 유지한다
|
||||
|
||||
5. **도메인 매핑 테이블 검토** (`full` 모드 시)
|
||||
- `agent-ops/rules/project/rules.md`의 도메인 매핑 테이블과 실제 포함 경로 비교
|
||||
- 누락된 경로 패턴은 추가, 존재하지 않는 경로 패턴은 제거
|
||||
- 기존 항목 순서는 변경하지 않는다
|
||||
|
||||
6. **결과 보고**
|
||||
- 도메인별로 수정한 항목 목록
|
||||
- `TODO`로 남긴 항목 (해당 시)
|
||||
- 도메인 매핑 테이블 변경 내용 (full 모드 시)
|
||||
|
||||
## 실행 결과 검증
|
||||
|
||||
- [ ] 수정된 `rules.md`의 포함 경로가 모두 실제 프로젝트에 존재하는가
|
||||
- [ ] 섹션 구조가 `domain-rule-template.md` 형식을 유지하는가
|
||||
- [ ] 변경하지 않아도 되는 섹션이 의도치 않게 바뀌지 않았는가
|
||||
- [ ] `full` 모드에서 도메인 매핑 테이블이 실제 포함 경로와 일치하는가
|
||||
- 검증 실패 시: 실제 존재하지 않는 경로나 누락된 섹션을 사용자에게 알리고 해당 항목만 보완한다
|
||||
|
||||
## 출력 형식
|
||||
|
||||
```
|
||||
## 업데이트 완료
|
||||
|
||||
### <domain-name>
|
||||
- 변경: <수정된 항목 요약>
|
||||
- 추가: <새로 추가된 경로/구성 요소>
|
||||
- 제거: <삭제된 경로/구성 요소>
|
||||
- 유지: 변경 없음 (해당 섹션)
|
||||
|
||||
### 도메인 매핑 테이블 (full 모드 시)
|
||||
- 추가: <새 경로 패턴>
|
||||
- 제거: <삭제된 경로 패턴>
|
||||
|
||||
## TODO 항목 (확인 필요)
|
||||
- <불확실하여 직접 확인이 필요한 항목> (해당 시)
|
||||
```
|
||||
|
||||
## 금지 사항
|
||||
|
||||
- 실제 존재하지 않는 경로를 포함 경로에 기재하지 않는다
|
||||
- 추측으로 패턴·금지 사항을 추가하지 않는다 — 코드에서 확인된 내용만 기재한다
|
||||
- 신규 도메인 생성이 필요한 경우 직접 생성하지 않고 `create-domain-rule` 스킬 사용을 안내한다
|
||||
- `rules/project/rules.md`의 기존 항목을 삭제하거나 재정렬하지 않는다
|
||||
- 코드 파일을 수정하지 않는다 — 이 스킬은 rule 파일 갱신만 담당한다
|
||||
Loading…
Reference in a new issue