toki/workspace-manager
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
workspace-manager/.workspace-ops/skills/weekly-subproject-review/SKILL.md

8.6 KiB
Raw Blame History

name version description
weekly-subproject-review 1.0.0 workspace root 아래 여러 하위 Git repository의 최근 1주 흐름, 작업 속도, AI-first 표준화/하네싱 품질, cross-repo 의존성, 로드맵/구현 불일치, 책임 경계 위험을 평가하는 주간 분석 스킬. 사용자가 "이번주 작업 평가해줘", "주간 분석", "weekly review", "cross-repo 점검"을 요청할 때 사용한다.

Weekly Subproject Review

목적

하위 repository들의 최근 1주 흐름을 묶어서 평가한다. 일간 분석보다 cross-repo 의존성, 작업 속도, AI-first 작업 가능성, 중복 계획, 책임 경계 충돌, 오래 남은 잠금/보류 항목을 더 깊게 본다.

언제 호출할지

  • 사용자가 주간 하위 프로젝트 분석을 요청할 때
  • 사용자가 "이번주 작업 평가해줘", "이번주 평가해줘"처럼 짧게 요청할 때
  • 여러 repository의 로드맵이 같은 방향을 보고 있는지 확인해야 할 때
  • 다음 주 구현 우선순위를 정하기 전에 전체 흐름을 점검할 때
  • cross-repo 경계나 중복 작업이 늘어난 것 같을 때

입력

  • workspace-root: 분석할 workspace root. 없으면 현재 작업 디렉터리
  • since: 분석 시작일. 없으면 7일 전
  • until: 분석 종료일. 없으면 현재 시각
  • focus: 특정 repo, 기능, 경계. 선택
  • include-archives: archive 디렉터리 읽기 여부. 기본값은 false

먼저 확인할 것

  • .workspace-ops/shared/target-discovery.md의 제외 규칙
  • .workspace-ops/shared/speed-evaluation.md의 속도 평가 기준
  • .workspace-ops/shared/quality-evaluation.md의 품질 평가 기준
  • 하위 repository 목록과 branch tracking 상태
  • 최근 1주 커밋과 큰 변경 파일
  • 관련 agent-roadmap/current.md와 활성 milestone

실행 절차

  1. 기간 결정

    • 사용자가 기간을 지정하지 않았으면 최근 7일을 기준으로 한다.

  2. 대상 repository 탐색

    • .workspace-ops/**를 제외하고 하위 .git repository를 찾는다.
    • focus가 있으면 관련 repository를 우선하되, cross-repo 영향이 있는 sibling repository도 확인한다.

  3. 변경 흐름 수집

    • repository별 커밋, 변경 파일, branch 상태, working tree 상태를 확인한다.
    • repo별 최근 1주 커밋 수를 세고 합산한다.
    • working tree 변경은 미커밋 위험이 아니라 작업 중인 유효 payload로 보고 변경 파일 내용을 평가에 포함한다.
    • 필요하면 .workspace-ops/shared/scripts/collect-subprojects.sh를 실행한다.

  4. cross-repo 관계 분석

    • 같은 기능이 여러 repository에 분산되어 있는지 본다.
    • 책임 경계가 겹치거나 반대로 비어 있는 영역을 찾는다.
    • agent-ops sync 자체를 평가 항목으로 삼지 않고, sync로 반영된 실제 변경 내용을 표준화/하네싱, AI 작업 가능성, 정렬/기획 등으로 분류한다.
    • 원천 repository의 변경은 설계 품질로, downstream repository의 반영은 적용 품질과 일관성 품질로 구분한다.
    • 여러 repo에 걸친 표준화/하네싱이 drift 방지, 실행 재현성, AI 작업 가능성에 미친 영향을 본다.

  5. 작업 속도 평가

    • .workspace-ops/shared/speed-evaluation.md의 기준으로 속도 종합평가, 표준화/하네싱, AI 작업 가능성, 제품 진척, 정렬/기획, 검증 속도를 나눠 본다.
    • 작업 속도 표의 첫 행은 반드시 속도 종합평가로 작성한다.
    • 속도 종합평가의 판단 칸에는 속도 등급, 10점 만점 점수, 보정 이유를 한 문장으로 쓴다.
    • 일반 개발자 AI 미사용 대비와 시니어 개발자 AI 미사용 대비 추정 배율을 표로 제시한다.
    • 주간 평가는 하루 단위 피크보다 지속성, 반영 내용의 의미, repo 간 병목을 더 크게 본다.
    • 제품 구현 근거가 약하면 제품 진척 축만 판정 보류로 두고, 표준화/하네싱 속도는 별도 성과로 인정한다.

  6. 작업 품질 평가

    • .workspace-ops/shared/quality-evaluation.md의 기준으로 표준화/하네싱, AI 작업 가능성, 일관성/드리프트 방지, 실행 가능성, 구현/제품 품질, 검증/감사 가능성, 원천/반영 구분을 평가한다.
    • AI-first 개발에서는 agent가 읽고 실행할 수 있는 규칙/스킬/라우팅/ignore/output 기준을 제품 개발 인프라 품질로 평가한다.
    • 제품 기능 구현이 없다는 이유만으로 표준화/하네싱 작업의 품질 점수를 낮추지 않는다.
    • 작업 품질 표의 첫 행은 반드시 작업 품질 종합평가로 작성한다.

  7. 로드맵/구현 불일치 확인

    • 활성 milestone과 실제 변경이 맞는지 확인한다.
    • 구현 잠금이 오래 남았거나 잠금 없이 구현으로 내려간 흔적이 있는지 본다.
    • 미커밋 상태 자체는 위험/누락으로 언급하지 않는다.
    • archive 디렉터리는 명시 요청 없이 읽지 않는다.

  8. 결과 작성

    • .workspace-ops/shared/output-format.md의 주간 분석 형식을 따른다.
    • repo별 요약 표의 첫 데이터 행은 반드시 커밋 총합 row로 작성하고, 이번 주 커밋 칸에 repo별 커밋 수의 합계를 쓴다.
    • 다음 주 초점은 3개 이내로 제안한다.

출력 형식

## 주간 총평

<방향 정렬, 속도, 위험 평가>

## repo별 요약

| repo | 이번 주 커밋 | 작업 성격 | 평가 |
|------|-------------:|-----------|------|
| 커밋 총합 | <합계> | <대상 repo 수와 기간> | <전체 평가> |

## cross-repo 흐름

| 흐름 | 관련 repo | 상태 | 다음 결정 |
|------|-----------|------|-----------|

## 작업 속도

| 속도 항목 | 관측 근거 | 일반 개발자 AI 미사용 대비 | 시니어 AI 미사용 대비 | 판단 |
|-----------|-----------|----------------------------|------------------------|------|
| 속도 종합평가 | <전체 범위와 시간대> | <예: 3-6배> | <예: 2-3배> | <등급, 10점 만점 점수, 보정 이유> |
| 표준화/하네싱 | <공통 규칙과 실행 레일 전파 근거> | <예: 3-6배> | <예: 2-3배> | <평가> |
| AI 작업 가능성 | <agent 탐색/라우팅/출력/제외 기준 명시 근거> | <예: 3-6배> | <예: 2-3배> | <평가> |

## 작업 품질

| 품질 항목 | 관측 근거 | 평가 | 판단 |
|-----------|-----------|------|------|
| 작업 품질 종합평가 | <전체 변경 범위> | <예: 높음, 8/10> | <표준화/하네싱/검증 보정 이유> |
| 표준화/하네싱 | <공통 규칙과 하네싱 전파 근거> | <평가> | <판단> |
| AI 작업 가능성 | <agent가 읽고 실행할 기준이 명시된 근거> | <평가> | <판단> |
| 일관성/드리프트 방지 | <repo 간 동일 기준 반영 근거> | <평가> | <판단> |
| 구현/제품 품질 | <코드/테스트 근거> | <평가 또는 판정 보류> | <판단> |
| 검증/감사 가능성 | <검증/추적 근거> | <평가> | <판단> |
| 원천/반영 구분 | <source 변경과 downstream 적용 근거> | <평가> | <판단> |

## 불일치/중복

- <확인한 문제>

## 다음 주 초점

1. <초점>
2. <초점>
3. <초점>

실행 결과 검증

  • .workspace-ops/**가 분석 대상에 포함되지 않았는가
  • repo별 요약 표 최상단에 커밋 총합 row를 넣고 repo별 커밋 수 합계를 썼는가
  • sync 커밋을 별도 평가 항목으로 삼지 않고, sync된 내용을 기준으로 분류했는가
  • 작업 속도를 일반 개발자/시니어 개발자 AI 미사용 대비 표로 제시했는가
  • 작업 속도 표 첫 행에 속도 종합평가를 포함하고 판단 칸에 등급/점수/보정 이유를 썼는가
  • 작업 품질 표에 작업 품질 종합평가, 표준화/하네싱, AI 작업 가능성 평가를 포함했는가
  • cross-repo 책임 경계와 의존성을 최소 1회 점검했는가
  • 활성 roadmap/milestone과 실제 변경의 관계를 확인했는가
  • archive 디렉터리를 명시 요청 없이 읽지 않았는가

금지 사항

  • 주간 분석 중 근거 없이 새 roadmap 항목을 만들지 않는다.
  • 오래된 잠금 또는 보류 항목을 사용자 확인 없이 해제하지 않는다.
  • 제품 기능 구현만을 진척 또는 품질의 기준으로 삼지 않는다.
  • AI 미사용 대비 배율을 개인 성과나 확정 소요 시간처럼 단정하지 않는다.
  • .workspace-ops/**를 제품 repository로 평가하지 않는다.
  • 코드 구현 여부를 확인하지 않고 문서상 완료만으로 완료 판정을 내리지 않는다.