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

8.5 KiB
Raw Blame History

name version description
daily-subproject-review 1.0.0 workspace root 아래 여러 하위 Git repository의 오늘 작업 내용, 작업 속도, AI-first 표준화/하네싱 품질을 짧게 평가하는 일간 분석 스킬. 사용자가 "오늘 작업 평가해줘", "오늘 작업 평가", "하위 프로젝트 분석", "일간 리뷰", "daily review"를 요청할 때 사용한다.

Daily Subproject Review

목적

workspace root의 하위 Git repository를 대상으로 오늘의 작업 내용을 짧게 평가한다. 커밋 수보다 변경의 의미, cross-repo 영향, 작업 속도, AI-first 작업 가능성, 위험/누락, 다음 액션을 우선한다.

언제 호출할지

  • 사용자가 오늘 작업 내용 평가를 요청할 때
  • 사용자가 "오늘 작업 평가해줘", "오늘 평가해줘"처럼 짧게 요청할 때
  • 여러 하위 프로젝트의 일간 진행 상황을 요약해야 할 때
  • cross-repo 반영 내용이나 책임 경계 변화가 있었는지 빠르게 확인해야 할 때
  • 다음 작업 우선순위를 하루 단위로 정리해야 할 때

입력

  • workspace-root: 분석할 workspace root. 없으면 현재 작업 디렉터리
  • date: 분석 기준 날짜. 없으면 현재 날짜
  • timezone: 날짜 경계 기준 timezone. 없으면 현재 shell timezone
  • include-archives: archive 디렉터리 읽기 여부. 기본값은 false

먼저 확인할 것

  • 현재 날짜와 timezone
  • workspace root가 제품 repository인지, 여러 하위 repository를 품은 상위 폴더인지
  • .workspace-ops/shared/target-discovery.md의 제외 규칙
  • .workspace-ops/shared/speed-evaluation.md의 속도 평가 기준
  • .workspace-ops/shared/quality-evaluation.md의 품질 평가 기준
  • 하위 repository별 working payload 파일 목록

실행 절차

  1. 기준 시각 확인

    • date -Is로 현재 날짜와 timezone을 확인한다.
    • 사용자가 날짜를 지정하지 않았으면 오늘 00:00부터 다음 날 00:00 전까지를 기준으로 한다.

  2. 대상 repository 탐색

    • .workspace-ops/shared/target-discovery.md의 규칙으로 하위 .git 디렉터리를 찾는다.
    • .workspace-ops/**는 분석 대상에서 제외한다.

  3. 기본 git 상태 수집

    • 각 repository에서 git status --short --branch, git branch -vv, 오늘 커밋 로그와 shortstat을 확인한다.
    • repo별 오늘 커밋 수를 세고 합산한다.
    • working tree 변경은 미커밋 위험이 아니라 작업 중인 유효 payload로 보고 변경 파일 내용을 평가에 포함한다.
    • 필요하면 .workspace-ops/shared/scripts/collect-subprojects.sh를 실행한다.

  4. 변경 의미 평가

    • 커밋을 표준화/하네싱, AI 작업 가능성, 문서/로드맵, 실제 코드 구현, 테스트/검증, 운영 설정으로 분류한다.
    • sync 커밋은 평가 항목으로 세지 않고, 변경 파일과 원천 변경을 확인해 실제 반영 내용으로 분류한다.
    • 원천 repository의 변경은 설계 품질로, downstream repository의 반영은 적용 품질과 일관성 품질로 구분한다.
    • repo별 평가를 sync only로 끝내지 말고, sync된 내용이 규칙/진입 파일/ignore/output/version/roadmap 중 무엇인지 쓴다.

  5. 작업 속도 평가

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

  6. 작업 품질 평가

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

  7. 위험과 누락 확인

    • 공통 정책이 각 repository에 반영되지 않은 항목을 찾는다.
    • 로드맵과 실제 코드 상태가 충돌하는지 확인한다.
    • 미커밋 상태 자체는 위험/누락으로 언급하지 않는다.
    • archive 디렉터리는 사용자가 명시적으로 요청하지 않으면 읽지 않는다.

  8. 결과 작성

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

출력 형식

## 총평

<오늘 작업의 의미와 짧은 평가>

## repo별 요약

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

## 작업 속도

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

## 작업 품질

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

## 위험/누락

- <확인할 항목>

## 다음 액션

1. <다음 작업>
2. <다음 작업>
3. <다음 작업>

실행 결과 검증

  • .workspace-ops/**가 분석 대상 repository로 포함되지 않았는가
  • 모든 하위 repository의 working payload 파일 목록을 확인했는가
  • 오늘 커밋 또는 working payload가 있는 repository를 누락하지 않았는가
  • repo별 요약 표 최상단에 커밋 총합 row를 넣고 repo별 커밋 수 합계를 썼는가
  • sync 커밋을 별도 평가 항목으로 삼지 않고, sync된 내용을 기준으로 분류했는가
  • 작업 속도를 일반 개발자/시니어 개발자 AI 미사용 대비 표로 제시했는가
  • 작업 속도 표 첫 행에 속도 종합평가를 포함하고 판단 칸에 등급/점수/보정 이유를 썼는가
  • 작업 품질 표에 작업 품질 종합평가, 표준화/하네싱, AI 작업 가능성 평가를 포함했는가
  • archive 디렉터리를 명시 요청 없이 읽지 않았는가

금지 사항

  • 분석 요청만 받은 상태에서 하위 repository 파일을 수정하지 않는다.
  • 커밋 수나 라인 수만으로 생산성을 평가하지 않는다.
  • 제품 기능 구현만을 진척 또는 품질의 기준으로 삼지 않는다.
  • AI 미사용 대비 배율을 개인 성과나 확정 소요 시간처럼 단정하지 않는다.
  • .workspace-ops/**를 하위 프로젝트 작업량에 포함하지 않는다.
  • agent-task/archive/**와 agent-roadmap/archive/**를 명시 요청 없이 읽지 않는다.