| name | primitive-review |
| description | primitive(skill·agent·workflow·goal·cron) 정의를 정적 validate 이후 LLM 품질 관점으로 검토. 모호한 description·불명확한 위임 경로·측정 불가 exit_criteria·cadence-prompt 불일치를 지적. 사용자나 Chief 가 "리뷰해줘" 요청 시 호출. |
| schema_version | 2 |
| tier | leader |
| team | _skill |
| category | core |
| used_by | ["chief"] |
| dev_capability | false |
| triggers | {"keyword":["asset 리뷰","리뷰해줘","asset review","에이전트 리뷰","워크플로 리뷰","cron 리뷰","스케줄 리뷰"]} |
| pm_conventions | {"anti_sycophancy":true,"hard_gate":false,"post_labeling":true,"minimum_approaches":1} |
Asset Review Skill
정적 validate(kebab id·순환·참조 무결성)가 잡지 못하는 품질·판단 문제를 LLM 관점으로 검토한다.
CLI solosquad <manager> review 를 대체하는 대화형 표면 — review 는 비결정적 출력이라 CLI/CI 게이트가
아니라 Chief 와의 대화에서 수행한다(v1.3.2 conversational-first 결정).
입력
- kind: skill | agent | workflow | goal | cron
- id/경로: 검토 대상 (예:
product/product-manager, workflows/market-research/workflow.yaml)
- (선택) 정적 validate 결과 — 이미 알려진 finding 은 반복하지 않는다.
절차
- 대상 정의를 읽는다(
solosquad agent show <id> / workflow show / 파일 직접).
- 먼저
solosquad <manager> validate 로 정적 검증을 돌려 그 결과를 컨텍스트로 둔다.
- kind 별 렌즈로 판단 문제만 짚는다(정적 규칙이 잡는 건 제외):
- skill — description 이 3인칭·구체적이라 라우팅 가능한가? process 가 실행 가능한가? 단일 목적인가?
- agent — 팀 내 다른 actor 와 역할이 구별되나? 명확한 escalation/handoff 경로가 있나? collaborator 가 과배선 아닌가?
- workflow — 각 stage 의 exit_criteria 가 실제로 측정 가능한가? handoff 순서가 합리적인가? fixed/agentic 선택이 맞나?
- goal — success metric 이 객관적·판정 가능한가? 가드레일(budget/cycles)이 적정한가? modifiable_paths 가 좁게 잡혔나?
- cron — cadence 가 prompt 의도와 맞나? channel 이 kind 에 맞나? prompt 가 무인 실행에 자족적인가?
- 제안을 severity 로 분류해 제시: blocker(고쳐야 함) / improvement(권장) / nit(사소).
출력
- 한 줄 요약 + severity 태그된 actionable 제안 목록.
- anti-sycophancy: 문제가 없으면 "문제 없음"이라고 분명히 말한다 — 억지 제안 금지.
비범위
- 정적 규칙으로 잡히는 것(id 형식·순환·깨진 참조)은
validate 의 몫. 여기서 반복하지 않는다.
- 자동 수정은 하지 않는다 — 제안만. 적용은 사용자/author 루프가 결정.
