toki/workspace-manager
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

문서: 작업 평가 기준을 보정한다

Browse source
This commit is contained in:
toki 2026-05-24 12:36:35 +09:00
parent 6bef63e97c
commit 3e12835289
12 changed files with 76 additions and 28 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
.clinerules
View file

@ -12,6 +12,8 @@
- 분석 요청에서는 기본적으로 읽기 전용으로 진행하고, 파일 수정은 사용자가 명시적으로 요청한 경우에만 한다.
- 작업 평가에서는 제품 기능 구현뿐 아니라 표준화/하네싱, 공통 규칙 전파, drift 방지, 실행 재현성 개선을 핵심 품질 성과로 본다.
- AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙, 스킬 라우팅, ignore 정책, 출력 형식, sync 절차를 제품 개발 인프라 품질로 본다.
- sync 커밋은 평가 항목으로 세지 않고, sync로 반영된 실제 내용을 기준으로 평가한다.
- 미커밋 변경은 작업 중인 유효 payload로 보고, 미커밋 상태 자체를 위험/누락/감점 사유로 언급하지 않는다.
- git 작업 중 기존 변경을 되돌리지 않는다.
## 스킬 라우팅

2
.cursorrules
View file

@ -12,6 +12,8 @@
- 분석 요청에서는 기본적으로 읽기 전용으로 진행하고, 파일 수정은 사용자가 명시적으로 요청한 경우에만 한다.
- 작업 평가에서는 제품 기능 구현뿐 아니라 표준화/하네싱, 공통 규칙 전파, drift 방지, 실행 재현성 개선을 핵심 품질 성과로 본다.
- AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙, 스킬 라우팅, ignore 정책, 출력 형식, sync 절차를 제품 개발 인프라 품질로 본다.
- sync 커밋은 평가 항목으로 세지 않고, sync로 반영된 실제 내용을 기준으로 평가한다.
- 미커밋 변경은 작업 중인 유효 payload로 보고, 미커밋 상태 자체를 위험/누락/감점 사유로 언급하지 않는다.
- git 작업 중 기존 변경을 되돌리지 않는다.
## 스킬 라우팅

23
.workspace-skills/daily-subproject-review/SKILL.md
View file

@ -16,7 +16,7 @@ workspace root의 하위 Git repository를 대상으로 오늘의 작업 내용
- 사용자가 오늘 작업 내용 평가를 요청할 때
- 사용자가 "오늘 작업 평가해줘", "오늘 평가해줘"처럼 짧게 요청할 때
- 여러 하위 프로젝트의 일간 진행 상황을 요약해야 할 때
- cross-repo 동기화나 책임 경계 변화가 있었는지 빠르게 확인해야 할 때
- cross-repo 반영 내용이나 책임 경계 변화가 있었는지 빠르게 확인해야 할 때
- 다음 작업 우선순위를 하루 단위로 정리해야 할 때
## 입력
@ -33,7 +33,7 @@ workspace root의 하위 Git repository를 대상으로 오늘의 작업 내용
- [ ] `.workspace-skills/shared/target-discovery.md`의 제외 규칙
- [ ] `.workspace-skills/shared/speed-evaluation.md`의 속도 평가 기준
- [ ] `.workspace-skills/shared/quality-evaluation.md`의 품질 평가 기준
- [ ] 하위 repository별 working tree 상태
- [ ] 하위 repository별 working payload 파일 목록
## 실행 절차
@ -47,14 +47,17 @@ workspace root의 하위 Git repository를 대상으로 오늘의 작업 내용
3. **기본 git 상태 수집**
- 각 repository에서 `git status --short --branch`, `git branch -vv`, 오늘 커밋 로그와 shortstat을 확인한다.
- working tree 변경은 미커밋 위험이 아니라 작업 중인 유효 payload로 보고 변경 파일 내용을 평가에 포함한다.
- 필요하면 `.workspace-skills/shared/scripts/collect-subprojects.sh`를 실행한다.
4. **변경 의미 평가**
- 커밋을 동기화, 표준화/하네싱, 문서/로드맵, 실제 코드 구현, 테스트/검증, 운영 설정으로 분류한다.
- 반복 sync 커밋은 실제 진척과 분리해서 본다.
- 커밋을 표준화/하네싱, AI 작업 가능성, 문서/로드맵, 실제 코드 구현, 테스트/검증, 운영 설정으로 분류한다.
- sync 커밋은 평가 항목으로 세지 않고, 변경 파일과 원천 변경을 확인해 실제 반영 내용으로 분류한다.
- 원천 repository의 변경은 설계 품질로, downstream repository의 반영은 적용 품질과 일관성 품질로 구분한다.
- repo별 평가를 `sync only`로 끝내지 말고, sync된 내용이 규칙/진입 파일/ignore/output/version/roadmap 중 무엇인지 쓴다.
5. **작업 속도 평가**
- `.workspace-skills/shared/speed-evaluation.md`의 기준으로 속도 종합평가, 운영 전파, 표준화/하네싱, AI 작업 가능성, 제품 진척, 정렬/기획 속도를 나눠 본다.
- `.workspace-skills/shared/speed-evaluation.md`의 기준으로 속도 종합평가, 표준화/하네싱, AI 작업 가능성, 제품 진척, 정렬/기획 속도를 나눠 본다.
- 작업 속도 표의 첫 행은 반드시 `속도 종합평가`로 작성한다.
- `속도 종합평가`의 판단 칸에는 속도 등급, 10점 만점 점수, 보정 이유를 한 문장으로 쓴다.
- 일반 개발자 AI 미사용 대비와 시니어 개발자 AI 미사용 대비 추정 배율을 표로 제시한다.
@ -62,7 +65,7 @@ workspace root의 하위 Git repository를 대상으로 오늘의 작업 내용
- 제품 구현 근거가 약하면 `제품 진척` 축만 판정 보류로 두고, 표준화/하네싱 속도는 별도 성과로 인정한다.
6. **작업 품질 평가**
- `.workspace-skills/shared/quality-evaluation.md`의 기준으로 표준화/하네싱, AI 작업 가능성, 일관성/드리프트 방지, 실행 가능성, 구현/제품 품질, 검증/감사 가능성을 평가한다.
- `.workspace-skills/shared/quality-evaluation.md`의 기준으로 표준화/하네싱, AI 작업 가능성, 일관성/드리프트 방지, 실행 가능성, 구현/제품 품질, 검증/감사 가능성, 원천/반영 구분을 평가한다.
- AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙/스킬/라우팅/ignore/output 기준을 제품 개발 인프라 품질로 평가한다.
- 제품 기능 구현이 없다는 이유만으로 표준화/하네싱 작업의 품질 점수를 낮추지 않는다.
- 작업 품질 표의 첫 행은 반드시 `작업 품질 종합평가`로 작성한다.
@ -70,6 +73,7 @@ workspace root의 하위 Git repository를 대상으로 오늘의 작업 내용
7. **위험과 누락 확인**
- 공통 정책이 각 repository에 반영되지 않은 항목을 찾는다.
- 로드맵과 실제 코드 상태가 충돌하는지 확인한다.
- 미커밋 상태 자체는 위험/누락으로 언급하지 않는다.
- archive 디렉터리는 사용자가 명시적으로 요청하지 않으면 읽지 않는다.
8. **결과 작성**
@ -106,6 +110,7 @@ workspace root의 하위 Git repository를 대상으로 오늘의 작업 내용
| 일관성/드리프트 방지 | <repo 간 동일 기준 반영 근거> | <평가> | <판단> |
| 구현/제품 품질 | <코드/테스트 근거> | <평가 또는 판정 보류> | <판단> |
| 검증/감사 가능성 | <검증/추적 근거> | <평가> | <판단> |
| 원천/반영 구분 | <source 변경과 downstream 적용 근거> | <평가> | <판단> |
## 위험/누락
@ -121,9 +126,9 @@ workspace root의 하위 Git repository를 대상으로 오늘의 작업 내용
## 실행 결과 검증
- [ ] `.workspace-skills/**`가 분석 대상 repository로 포함되지 않았는가
- [ ] 모든 하위 repository의 working tree 상태를 확인했는가
- [ ] 오늘 커밋이 없는 repository도 누락하지 않았는가
- [ ] sync 커밋과 실질 변경을 구분했는가
- [ ] 모든 하위 repository의 working payload 파일 목록을 확인했는가
- [ ] 오늘 커밋 또는 working payload가 있는 repository를 누락하지 않았는가
- [ ] sync 커밋을 별도 평가 항목으로 삼지 않고, sync된 내용을 기준으로 분류했는가
- [ ] 작업 속도를 일반 개발자/시니어 개발자 AI 미사용 대비 표로 제시했는가
- [ ] 작업 속도 표 첫 행에 `속도 종합평가`를 포함하고 판단 칸에 등급/점수/보정 이유를 썼는가
- [ ] 작업 품질 표에 `작업 품질 종합평가`, 표준화/하네싱, AI 작업 가능성 평가를 포함했는가

2
.workspace-skills/rules/common/rules.md
View file

@ -12,6 +12,8 @@
- 분석 요청에서는 기본적으로 읽기 전용으로 진행하고, 파일 수정은 사용자가 명시적으로 요청한 경우에만 한다.
- 작업 평가에서는 제품 기능 구현뿐 아니라 표준화/하네싱, 공통 규칙 전파, drift 방지, 실행 재현성 개선을 핵심 품질 성과로 본다.
- AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙, 스킬 라우팅, ignore 정책, 출력 형식, sync 절차를 제품 개발 인프라 품질로 본다.
- sync 커밋은 평가 항목으로 세지 않고, sync로 반영된 실제 내용을 기준으로 평가한다.
- 미커밋 변경은 작업 중인 유효 payload로 보고, 미커밋 상태 자체를 위험/누락/감점 사유로 언급하지 않는다.
- git 작업 중 기존 변경을 되돌리지 않는다.
## 스킬 라우팅

3
.workspace-skills/rules/project/rules.md
View file

@ -36,9 +36,10 @@
- 커밋 수와 라인 수는 보조 지표로만 사용한다.
- 실제 평가는 변경의 의미, 작업 속도, cross-repo 영향, 책임 경계, 위험/누락, 다음 액션을 기준으로 한다.
- 작업 속도는 일반 개발자/시니어 개발자 AI 미사용 대비 추정 배율을 표로 제시하되, 제품 구현과 운영 sync를 분리한다.
- 작업 속도는 일반 개발자/시니어 개발자 AI 미사용 대비 추정 배율을 표로 제시하되, sync 자체가 아니라 sync로 반영된 실제 내용을 기준으로 평가한다.
- 표준화/하네싱, 공통 규칙 전파, drift 방지, 실행 재현성 개선은 제품 기능 구현과 별개의 핵심 품질 성과로 평가한다.
- AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙, 스킬 라우팅, ignore 정책, 출력 형식, sync 절차를 제품 개발 인프라 품질로 평가한다.
- 제품 기능 구현만을 진척 또는 품질의 기준으로 삼지 않는다.
- 미커밋 변경은 작업 중인 유효 payload로 보고, 미커밋 상태 자체를 위험/누락/감점 사유로 언급하지 않는다.
- 최종 답변에는 사용자가 바로 행동할 수 있는 다음 액션을 포함한다.
- 단순 분석 요청에서는 파일을 수정하지 않는다.

2
.workspace-skills/shared/output-format.md
View file

@ -32,6 +32,7 @@
| 일관성/드리프트 방지 | <repo 간 동일 기준 반영 근거> | <평가> | <판단> |
| 구현/제품 품질 | <코드/테스트 근거> | <평가 또는 판정 보류> | <판단> |
| 검증/감사 가능성 | <검증/추적 근거> | <평가> | <판단> |
| 원천/반영 구분 | <source 변경과 downstream 적용 근거> | <평가> | <판단> |
## 좋은 점
@ -80,6 +81,7 @@
| 일관성/드리프트 방지 | <repo 간 동일 기준 반영 근거> | <평가> | <판단> |
| 구현/제품 품질 | <코드/테스트 근거> | <평가 또는 판정 보류> | <판단> |
| 검증/감사 가능성 | <검증/추적 근거> | <평가> | <판단> |
| 원천/반영 구분 | <source 변경과 downstream 적용 근거> | <평가> | <판단> |
## 불일치/중복

16
.workspace-skills/shared/quality-evaluation.md
View file

@ -9,8 +9,12 @@ AI-first 개발에서는 여러 repository에 걸친 표준화, 하네싱, 규
- 제품 코드 구현은 품질 항목 중 하나일 뿐이며, 유일한 진척 기준이 아니다.
- AI-first 개발에서 cross-repo 표준화/하네싱은 반복 작업 비용과 운영 위험을 낮추는 정도를 넘어, agent 작업의 안전성/재현성/지속성을 결정하는 1급 품질 작업으로 본다.
- 진입 파일, skill routing, ignore 정책, sync 절차, version propagation은 agent-operable surface로 평가한다.
- 단순 sync와 의미 있는 하네싱 개선을 구분한다.
- 진입 파일, skill routing, ignore 정책, 동기화 절차, version propagation은 agent-operable surface로 평가한다.
- sync 여부 자체는 품질 항목으로 평가하지 않는다. sync로 반영된 내용이 agent-operable surface를 개선했는지 평가한다.
- 원천 repository에서 만든 변경은 설계 품질로, downstream repository에 반영된 변경은 적용 품질과 일관성 품질로 구분한다.
- 미커밋 변경은 작업 중인 유효 payload로 보고 커밋된 변경과 함께 평가한다.
- 미커밋 상태 자체를 위험/누락/감점 사유로 언급하지 않는다. 필요한 경우 변경 파일의 내용만 평가 축에 반영한다.
- version-only 반영은 낮은 품질 변화가 아니라 감사 가능성/version alignment 근거로 제한해 평가한다.
- 문서/roadmap 변경도 실행 절차, 책임 경계, 재현성, 의사결정 품질을 높이면 품질 개선으로 본다.
- 테스트/CI 근거가 없으면 검증 품질은 낮게 보되, 그 이유로 표준화/하네싱 품질 전체를 무효화하지 않는다.
- 전통적 구현 중심 기준으로 AI-first 하네싱 작업을 보조 업무처럼 낮게 평가하지 않는다.
@ -19,13 +23,14 @@ AI-first 개발에서는 여러 repository에 걸친 표준화, 하네싱, 규
| 축 | 의미 | 주요 근거 |
|----|------|-----------|
| 작업 품질 종합평가 | 오늘/이번 주 변경이 장기 유지보수성과 실행 품질을 얼마나 높였는지 | 변경 범위, repo 확산도, 표준화 수준, 미검증 위험 |
| 표준화/하네싱 품질 | 여러 프로젝트가 같은 규칙, 스킬, 스크립트, 진입 파일, sync 절차를 공유하게 만든 정도 | agent-ops, rules, entry files, sync scripts, version propagation |
| 작업 품질 종합평가 | 오늘/이번 주 변경이 장기 유지보수성과 실행 품질을 얼마나 높였는지 | 변경 범위, repo 확산도, 표준화 수준, 검증 근거 |
| 표준화/하네싱 품질 | 여러 프로젝트가 같은 규칙, 스킬, 스크립트, 진입 파일, 동기화 절차를 공유하게 만든 정도 | agent-ops, rules, entry files, synchronization scripts, version propagation |
| AI 작업 가능성 | agent가 암묵지 없이 안전하게 탐색, 수정, 평가, 이어받기를 할 수 있게 된 정도 | AGENTS/GEMINI/CLAUDE, skill routing, target discovery, ignore policy, output format |
| 일관성/드리프트 방지 | repo별 운영 규칙 차이를 줄이고 이후 차이를 감지/방지하기 쉬워졌는지 | 공통 파일 동기화, 버전 정책, ignore 정책, routing 규칙 |
| 실행 가능성 | 문서가 실제 실행 절차, 다음 액션, 책임 경계로 이어지는지 | GUIDE, README, roadmap/current, milestone, checklist |
| 구현/제품 품질 | 사용자 기능, 제품 코드, 테스트가 실제로 좋아졌는지 | code diff, test diff, CI/local verification |
| 검증/감사 가능성 | 변경 근거와 완료 상태를 추적하고 재검증하기 쉬운지 | 커밋 메시지, shortstat, version, CI, archive/current 연결 |
| 검증/감사 가능성 | 변경 근거와 완료 상태를 추적하고 재검증하기 쉬운지 | 커밋 메시지, shortstat, version, CI, archive/current 연결, working payload file set |
| 원천/반영 구분 | 원천 설계 변경과 downstream 적용이 각각 어떤 품질을 높였는지 | source repo commits, downstream reflected files, version alignment |
## 출력 표
@ -39,3 +44,4 @@ AI-first 개발에서는 여러 repository에 걸친 표준화, 하네싱, 규
| 일관성/드리프트 방지 | <repo 간 동일 기준 반영 근거> | <평가> | <판단> |
| 구현/제품 품질 | <코드/테스트 근거> | <평가 또는 판정 보류> | <판단> |
| 검증/감사 가능성 | <검증/추적 근거> | <평가> | <판단> |
| 원천/반영 구분 | <source 변경과 downstream 적용 근거> | <평가> | <판단> |

34
.workspace-skills/shared/speed-evaluation.md
View file

@ -8,8 +8,11 @@
## 기본 원칙
- 속도 평가는 생산성 단정이 아니라 관측 가능한 git 기록 기반의 추정치다.
- `agent-ops` sync, 표준화/하네싱, 문서/roadmap 정리, 제품 코드 구현, 테스트/검증을 분리한다.
- 자동화된 sync와 표준화/하네싱은 제품 구현 속도와 분리하고, 운영 전파 및 플랫폼 정렬 속도로 평가한다.
- sync 커밋은 그 자체를 평가 항목으로 삼지 않고, sync로 반영된 실제 내용을 확인해 표준화/하네싱, AI 작업 가능성, 정렬/기획, 검증 등의 축에 반영한다.
- `agent-ops`, 표준화/하네싱, 문서/roadmap 정리, 제품 코드 구현, 테스트/검증을 변경 내용 기준으로 분리한다.
- 미커밋 변경은 작업 중인 유효 payload로 보고 커밋된 변경과 함께 속도/품질 평가에 반영한다.
- 미커밋 상태 자체를 위험, 누락, 감점 사유로 언급하지 않는다.
- 자동화된 반영 자체가 아니라 반영된 공통 규칙, 진입 파일, 스크립트, 출력 형식, ignore 정책의 의미를 평가한다.
- AI-first 개발에서 agent가 안전하게 작업할 수 있는 하네싱을 빠르게 구축하는 것은 제품 구현 이전의 보조 작업이 아니라 속도 기반 자체를 만드는 작업이다.
- 배율은 넓은 범위로 제시하고, 근거가 약하면 신뢰도를 `낮음`으로 둔다.
- archive 디렉터리는 사용자가 명시적으로 요청하지 않으면 읽지 않는다.
@ -18,9 +21,8 @@
| 축 | 의미 | 주요 근거 |
|----|------|-----------|
| 속도 종합평가 | 전체 작업 흐름이 AI 미사용 대비 얼마나 빠르게 진행됐는지의 최종 평가 | 전체 커밋 범위, repo 확산도, 실질 변경 비율, 미완료/미검증 위험 |
| 운영 전파 속도 | 공통 규칙, skill, agent-ops 변경이 여러 repo에 퍼진 속도 | 원천 repo 커밋 시각, sync 커밋 시각, 반영 repo 수 |
| 표준화/하네싱 속도 | 여러 repo에 공통 실행 레일, 규칙, 진입 파일, sync 체계를 깐 속도 | agent-ops, rules, entry files, version, sync wave |
| 속도 종합평가 | 전체 작업 흐름이 AI 미사용 대비 얼마나 빠르게 진행됐는지의 최종 평가 | 전체 커밋/working payload 범위, repo 확산도, 실질 변경 비율, 검증 근거 |
| 표준화/하네싱 속도 | 여러 repo에 공통 실행 레일, 규칙, 진입 파일, 절차 체계를 깐 속도 | agent-ops, rules, entry files, version, reflected file set |
| AI 작업 가능성 구축 속도 | agent가 암묵지 없이 작업할 수 있도록 탐색/라우팅/출력/제외 기준을 명시한 속도 | skills, target discovery, output format, entry files, ignore policy |
| 제품 진척 속도 | 실제 제품 코드, 테스트, 사용자 기능이 전진한 속도 | 코드 변경 파일, 테스트 변경, 실행 검증 |
| 정렬 속도 | roadmap, milestone, README, 책임 경계가 정리된 속도 | roadmap/current, 활성 milestone, 문서 변경 |
@ -42,10 +44,27 @@
| roadmap/milestone 재정리 | 1-3시간 | 0.5-2시간 | 2-5배 |
| cross-repo 책임 경계/계획 정렬 | 3-8시간 | 1.5-4시간 | 2-6배 |
| cross-repo 표준화/하네싱 구축 | 4-12시간 | 2-6시간 | 3-8배 |
| 공통 agent-ops/sync 전파 1개 repo | 0.5-1시간 | 0.25-0.5시간 | 3-8배 |
| 5개 이상 repo 동시 정책 전파 | 4-8시간 | 2-4시간 | 4-10배 |
| 공통 agent-ops 규칙 반영 1개 repo | 0.5-1시간 | 0.25-0.5시간 | 3-8배 |
| 5개 이상 repo 공통 정책 반영 | 4-8시간 | 2-4시간 | 4-10배 |
| 제품 코드 구현 + 테스트 | 변경 범위별 별도 산정 | 변경 범위별 별도 산정 | diff와 검증 근거 없으면 판정 보류 |
## sync 해석 원칙
- `sync:` 커밋은 별도 점수 항목으로 쓰지 않는다.
- `sync:` 커밋의 변경 파일, 원천 버전, 원천 커밋 내용을 확인해 어떤 품질 축에 기여했는지 분류한다.
- 평가 문구에서 `sync only`로 끝내지 말고, `rules/entry files/ignore 정책/output format/version`처럼 반영 내용을 쓴다.
- 내용이 단순 version bump이면 version alignment 또는 auditability 근거로만 사용한다.
## sync payload 분류
| payload | 반영할 평가 축 |
|---------|----------------|
| rules, entry files, skill routing, target discovery, ignore policy, output format | AI 작업 가능성, 표준화/하네싱 |
| scripts, sync procedure, install/init tooling | 표준화/하네싱, 실행 가능성 |
| roadmap/current/milestone/README/GUIDE | 정렬/기획, 실행 가능성 |
| version-only bump | 검증/감사 가능성, 일관성/드리프트 방지 |
| product code/test | 제품 진척, 구현/제품 품질, 검증 |
## 출력 표
분석 결과에는 다음 표를 포함한다.
@ -53,7 +72,6 @@
| 속도 항목 | 관측 근거 | 일반 개발자 AI 미사용 대비 | 시니어 AI 미사용 대비 | 판단 |
|-----------|-----------|----------------------------|------------------------|------|
| 속도 종합평가 | <전체 범위와 시간대> | <예: 4-8배> | <예: 2-4배> | <예: 빠름, 8/10. 표준화/하네싱 전파가 빠르고 검증 위험만 보정> |
| 운영 전파 | <근거> | <예: 5-8배> | <예: 3-5배> | <평가> |
| 표준화/하네싱 | <근거> | <예: 4-8배> | <예: 2-4배> | <평가> |
| AI 작업 가능성 | <근거> | <예: 4-8배> | <예: 2-4배> | <평가> |
| 제품 진척 | <근거> | <예: 판정 보류> | <예: 판정 보류> | <평가> |

14
.workspace-skills/weekly-subproject-review/SKILL.md
View file

@ -47,24 +47,26 @@ description: workspace root 아래 여러 하위 Git repository의 최근 1주
3. **변경 흐름 수집**
- repository별 커밋, 변경 파일, branch 상태, working tree 상태를 확인한다.
- working tree 변경은 미커밋 위험이 아니라 작업 중인 유효 payload로 보고 변경 파일 내용을 평가에 포함한다.
- 필요하면 `.workspace-skills/shared/scripts/collect-subprojects.sh`를 실행한다.
4. **cross-repo 관계 분석**
- 같은 기능이 여러 repository에 분산되어 있는지 본다.
- 책임 경계가 겹치거나 반대로 비어 있는 영역을 찾는다.
- 공통 `agent-ops` sync와 실제 제품 변경을 분리한다.
- `agent-ops` sync 자체를 평가 항목으로 삼지 않고, sync로 반영된 실제 변경 내용을 표준화/하네싱, AI 작업 가능성, 정렬/기획 등으로 분류한다.
- 원천 repository의 변경은 설계 품질로, downstream repository의 반영은 적용 품질과 일관성 품질로 구분한다.
- 여러 repo에 걸친 표준화/하네싱이 drift 방지, 실행 재현성, AI 작업 가능성에 미친 영향을 본다.
5. **작업 속도 평가**
- `.workspace-skills/shared/speed-evaluation.md`의 기준으로 속도 종합평가, 운영 전파, 표준화/하네싱, AI 작업 가능성, 제품 진척, 정렬/기획, 검증 속도를 나눠 본다.
- `.workspace-skills/shared/speed-evaluation.md`의 기준으로 속도 종합평가, 표준화/하네싱, AI 작업 가능성, 제품 진척, 정렬/기획, 검증 속도를 나눠 본다.
- 작업 속도 표의 첫 행은 반드시 `속도 종합평가`로 작성한다.
- `속도 종합평가`의 판단 칸에는 속도 등급, 10점 만점 점수, 보정 이유를 한 문장으로 쓴다.
- 일반 개발자 AI 미사용 대비와 시니어 개발자 AI 미사용 대비 추정 배율을 표로 제시한다.
- 주간 평가는 하루 단위 피크보다 지속성, 반복 sync 비용, repo 간 병목을 더 크게 본다.
- 주간 평가는 하루 단위 피크보다 지속성, 반영 내용의 의미, repo 간 병목을 더 크게 본다.
- 제품 구현 근거가 약하면 `제품 진척` 축만 판정 보류로 두고, 표준화/하네싱 속도는 별도 성과로 인정한다.
6. **작업 품질 평가**
- `.workspace-skills/shared/quality-evaluation.md`의 기준으로 표준화/하네싱, AI 작업 가능성, 일관성/드리프트 방지, 실행 가능성, 구현/제품 품질, 검증/감사 가능성을 평가한다.
- `.workspace-skills/shared/quality-evaluation.md`의 기준으로 표준화/하네싱, AI 작업 가능성, 일관성/드리프트 방지, 실행 가능성, 구현/제품 품질, 검증/감사 가능성, 원천/반영 구분을 평가한다.
- AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙/스킬/라우팅/ignore/output 기준을 제품 개발 인프라 품질로 평가한다.
- 제품 기능 구현이 없다는 이유만으로 표준화/하네싱 작업의 품질 점수를 낮추지 않는다.
- 작업 품질 표의 첫 행은 반드시 `작업 품질 종합평가`로 작성한다.
@ -72,6 +74,7 @@ description: workspace root 아래 여러 하위 Git repository의 최근 1주
7. **로드맵/구현 불일치 확인**
- 활성 milestone과 실제 변경이 맞는지 확인한다.
- 구현 잠금이 오래 남았거나 잠금 없이 구현으로 내려간 흔적이 있는지 본다.
- 미커밋 상태 자체는 위험/누락으로 언급하지 않는다.
- archive 디렉터리는 명시 요청 없이 읽지 않는다.
8. **결과 작성**
@ -108,6 +111,7 @@ description: workspace root 아래 여러 하위 Git repository의 최근 1주
| 일관성/드리프트 방지 | <repo 간 동일 기준 반영 근거> | <평가> | <판단> |
| 구현/제품 품질 | <코드/테스트 근거> | <평가 또는 판정 보류> | <판단> |
| 검증/감사 가능성 | <검증/추적 근거> | <평가> | <판단> |
| 원천/반영 구분 | <source 변경과 downstream 적용 근거> | <평가> | <판단> |
## 불일치/중복
@ -123,7 +127,7 @@ description: workspace root 아래 여러 하위 Git repository의 최근 1주
## 실행 결과 검증
- [ ] `.workspace-skills/**`가 분석 대상에 포함되지 않았는가
- [ ] 공통 sync와 실제 제품 변경을 구분했는가
- [ ] sync 커밋을 별도 평가 항목으로 삼지 않고, sync된 내용을 기준으로 분류했는가
- [ ] 작업 속도를 일반 개발자/시니어 개발자 AI 미사용 대비 표로 제시했는가
- [ ] 작업 속도 표 첫 행에 `속도 종합평가`를 포함하고 판단 칸에 등급/점수/보정 이유를 썼는가
- [ ] 작업 품질 표에 `작업 품질 종합평가`, 표준화/하네싱, AI 작업 가능성 평가를 포함했는가

2
AGENTS.md
View file

@ -12,6 +12,8 @@
- 분석 요청에서는 기본적으로 읽기 전용으로 진행하고, 파일 수정은 사용자가 명시적으로 요청한 경우에만 한다.
- 작업 평가에서는 제품 기능 구현뿐 아니라 표준화/하네싱, 공통 규칙 전파, drift 방지, 실행 재현성 개선을 핵심 품질 성과로 본다.
- AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙, 스킬 라우팅, ignore 정책, 출력 형식, sync 절차를 제품 개발 인프라 품질로 본다.
- sync 커밋은 평가 항목으로 세지 않고, sync로 반영된 실제 내용을 기준으로 평가한다.
- 미커밋 변경은 작업 중인 유효 payload로 보고, 미커밋 상태 자체를 위험/누락/감점 사유로 언급하지 않는다.
- git 작업 중 기존 변경을 되돌리지 않는다.
## 스킬 라우팅

2
CLAUDE.md
View file

@ -12,6 +12,8 @@
- 분석 요청에서는 기본적으로 읽기 전용으로 진행하고, 파일 수정은 사용자가 명시적으로 요청한 경우에만 한다.
- 작업 평가에서는 제품 기능 구현뿐 아니라 표준화/하네싱, 공통 규칙 전파, drift 방지, 실행 재현성 개선을 핵심 품질 성과로 본다.
- AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙, 스킬 라우팅, ignore 정책, 출력 형식, sync 절차를 제품 개발 인프라 품질로 본다.
- sync 커밋은 평가 항목으로 세지 않고, sync로 반영된 실제 내용을 기준으로 평가한다.
- 미커밋 변경은 작업 중인 유효 payload로 보고, 미커밋 상태 자체를 위험/누락/감점 사유로 언급하지 않는다.
- git 작업 중 기존 변경을 되돌리지 않는다.
## 스킬 라우팅

2
GEMINI.md
View file

@ -12,6 +12,8 @@
- 분석 요청에서는 기본적으로 읽기 전용으로 진행하고, 파일 수정은 사용자가 명시적으로 요청한 경우에만 한다.
- 작업 평가에서는 제품 기능 구현뿐 아니라 표준화/하네싱, 공통 규칙 전파, drift 방지, 실행 재현성 개선을 핵심 품질 성과로 본다.
- AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙, 스킬 라우팅, ignore 정책, 출력 형식, sync 절차를 제품 개발 인프라 품질로 본다.
- sync 커밋은 평가 항목으로 세지 않고, sync로 반영된 실제 내용을 기준으로 평가한다.
- 미커밋 변경은 작업 중인 유효 payload로 보고, 미커밋 상태 자체를 위험/누락/감점 사유로 언급하지 않는다.
- git 작업 중 기존 변경을 되돌리지 않는다.
## 스킬 라우팅