| name | update-docs |
| description | Use when the user asks to update README, docs, API documentation, usage guides, or changelog-like documentation. |
Documentation Updater
When to use
- README 업데이트를 요청할 때
- 사용법, API 문서, 개발 가이드 작성이 필요할 때
When not to use
Goal
Update documentation so it accurately reflects the current project behavior.
Workflow
- 관련 코드와 기존 문서를 확인한다.
- 독자와 목적을 판단한다.
- 설치, 설정, 실행, 예시를 필요한 만큼 추가한다.
- 낡은 내용을 제거한다.
- 명령어와 경로를 검증한다.
Verification
Do not
Output format
- Audience
- Updated sections
- Examples
- Validation
- Follow-ups
Prompt quality guide
A good prompt for this skill should include:
- Goal: Update documentation so it accurately reflects the current project behavior.
- Target/input: 작업 대상 파일, diff, 로그, URL, 문서, 이슈 또는 저장소 범위
- Constraints: scope limits, non-goals, style, and compatibility requirements
- Workflow: a repeatable step-by-step process
- Verification: 문서 명령어가 현재 구조와 맞는지 확인한다.
- Output: Audience, Updated sections, Examples, Validation, Follow-ups
Task contract
- Archetype:
document
- Intent invariant: Update documentation so it accurately reflects the current project behavior.
Variable slots
target (required): 작업 대상 파일, diff, 로그, URL, 문서, 이슈 또는 저장소 범위 → [작업 대상]constraints: 수정 범위, 금지사항, 스타일, 호환성 조건, 제외 범위 → [제약사항]verification (required): 테스트, lint, 빌드, 수동 확인 등 완료 여부를 판단할 기준 → [검증 기준]output_format (required): 결과 응답에 포함해야 할 섹션과 형식 → [출력 형식]
Better prompt templates
Minimal
Update documentation so it accurately reflects the current project behavior. 대상은 [작업 대상]입니다. 완료 후 문서 명령어가 현재 구조와 맞는지 확인한다. 기준으로 확인하고 Audience, Updated sections, Examples, Validation, Follow-ups 형식으로 요약해줘.
High-signal
Update documentation so it accurately reflects the current project behavior.
대상:
- [작업 대상]
제약:
- [수정 범위와 금지사항]
- 확인하지 않은 사실은 단정하지 않기
절차:
1. 먼저 목표, 입력, 현재 상태를 확인해줘.
2. 필요한 최소 범위로 작업해줘.
3. 문서 명령어가 현재 구조와 맞는지 확인한다. 기준으로 검증해줘.
4. 실패나 불확실성이 있으면 원인과 후속 조치를 적어줘.
출력:
- Audience, Updated sections, Examples, Validation, Follow-ups
Clarifying
이 요청은 `document` 유형으로 보입니다. 작업 전에 대상, 제약, 검증 기준, 출력 형식이 불명확하면 먼저 질문해줘.
Ask when unclear
- 작업 대상 파일, diff, 로그, URL, 문서는 무엇인가요?
- 반드시 지켜야 할 범위, 금지사항, 스타일 또는 호환성 조건이 있나요?
- 완료 여부는 어떤 테스트, lint, 빌드, 수동 확인으로 검증하면 되나요?
- 불확실한 정보가 있으면 작업 전에 질문해도 되나요?
Quality checklist
- 목표가 한 문장으로 명확한가?
- 작업 대상 또는 입력 자료가 명시됐는가?
- 수정 범위와 하지 말아야 할 일이 분리됐는가?
- 반복 가능한 절차가 순서대로 정의됐는가?
- 검증 방법과 완료 기준이 포함됐는가?
- 결과 출력 형식이 정해졌는가?
- 특정 파일명/브랜치/고객명에 과적합되지 않았는가?
Generalization notes
- 예시 프롬프트는 evidence로만 사용하고 Skill 본문에는 일반화된 패턴을 남긴다.
- 특정 파일명, URL, 브랜치, 날짜는 가능한 variable slot으로 취급한다.
- 한 번만 등장한 세부 조건은 고정 규칙이 아니라 확인 질문으로 전환한다.
Prompt quality score
- Overall: 77
- intent_clarity: 90
- input_specificity: 70
- constraint_clarity: 60
- workflow_reusability: 90
- verification_strength: 55
- output_specificity: 85
- generalization_safety: 88
Install readiness
- Grade: review_recommended
- Recommendation: preview에서 변수/검증 기준을 확인한 뒤 promote하세요.
- Blocker: 검증 기준이 부족합니다.
Diagnostics
- 수정 범위와 금지사항을 더 명확히 하는 것이 좋습니다.
- 검증 기준이나 실행 명령이 부족합니다.
Evidence
- README 문서 업데이트하고 사용법 가이드 정리해줘
- docs documentation 사용법을 README에 추가하고 changelog 정리
- 문서 설명 추가하고 설치 실행 예시를 최신 상태로 맞춰줘
