Skip to content
Back to skills

Amazon Sixpager Reviewer

ASecurity

Review Markdown 기반 Amazon 6-pager(6pager/six pager) 문서의 Context/Goal/Tasks 구성이 원칙에 맞는지 점검하고, 실험/서브태스크의 가설·검증 설계·결정 규칙, 커뮤니케이션 싱크 리스크(정의/범위/의사결정 공백), 문서 검색/추적 앵커(지표명/ID/링크)까지 포함해 5 Whys로 모호함을 제거한 리뷰 문서(`{filename}_reivew.md`)를 생성해야 할 때 사용한다.

  • 57 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added October 17, 2026
researchgorails

Security analysis

A100/100

Scanned October 17, 2026

npx -y skills add diegosouzapw/awesome-omni-skill --skill amazon-sixpager-reviewer --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Amazon Sixpager Reviewer?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Amazon Sixpager Reviewer
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/diegosouzapw-amazon-sixpager-reviewer/badge)](https://www.skillsdirectory.com/skills/diegosouzapw-amazon-sixpager-reviewer)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: amazon-sixpager-reviewer
description: Review Markdown 기반 Amazon 6-pager(6pager/six pager) 문서의 Context/Goal/Tasks 구성이 원칙에 맞는지 점검하고, 실험/서브태스크의 가설·검증 설계·결정 규칙, 커뮤니케이션 싱크 리스크(정의/범위/의사결정 공백), 문서 검색/추적 앵커(지표명/ID/링크)까지 포함해 5 Whys로 모호함을 제거한 리뷰 문서(`{filename}_reivew.md`)를 생성해야 할 때 사용한다.
---

# Amazon Sixpager Reviewer (Markdown)

## Overview

제공된 6pager 마크다운 문서를 읽고, (1) Context에 “왜 이 목표가 필요한가”가 수치로 드러나는지, (2) Goal이 측정 가능한 지표/기준선/기한으로 정의되는지, (3) Tasks가 완료되면 Goal 달성으로 이어지는 인과 사슬이 성립하는지, (4) 실험/서브태스크의 가설·검증·결정 규칙이 재현 가능하게 정의되는지, (5) 문서로 소통할 때 싱크가 어긋날 수 있는 정의/범위/의사결정 공백이 없는지, (6) 5 Whys 관점에서 모호한 문장이 남아있지 않은지, (7) 추후 검색/추적이 가능한 앵커(지표명/ID/링크)가 있는지를 리뷰한다.

## Workflow

### Step 0: Inputs 확인

1) 사용자가 준 파일 경로(들)를 확인한다. 파일이 없거나 내용이 대화에 포함되지 않았다면, “리뷰할 `.md` 파일 경로를 알려달라”고 요청한다.  
2) 파일이 여러 개라면 각 파일별로 리뷰를 별도 생성한다(파일명 기반).

### Step 1: 문서 구조 파악(섹션 매핑)

문서의 섹션 헤더가 정확히 `Context/Goal/Tasks`가 아니어도 의미적으로 매핑한다.

- Context 후보: Background, Problem, 현황, Why now, 고객/시장 문제, 데이터 현황
- Goal 후보: 목표, Objective, Success Metrics, North Star, KPI
- Tasks 후보: Plan, Execution, Actions, Roadmap, Initiatives, To-do

### Step 2: Context 점검(수치로 “왜 필요한가”가 보이는가)

Context는 “현상”과 “중요도”를 수치로 보여야 한다. 아래 질문에 숫자/기간/범위로 답이 나오는지 점검하고, 없으면 “추정치/측정 계획/필요 데이터”를 명시한다.

- 무엇이(어떤 지표가) 얼마나 변했는가? (기준선→현재, 변화율, 기간)
- 어디서/누가 영향받는가? (세그먼트, 채널, 제품/지역, 신규/기존 등)
- 왜 지금인가? (추세, 임계점, 기회비용, 리스크)
- 데이터 정의/출처/산식이 있는가? (측정 신뢰도)

Context에서 흔히 실패하는 문장 유형:
- “상황이 좋지 않다/문제가 있다/개선이 필요하다”처럼 재질문(왜?)을 유발하는 일반론
- “매출이 줄었다”만 있고 기준선/기간/세그먼트/정의가 없는 주장
- “고객이 불만이다”만 있고 NPS/CS/리뷰/이탈/전환 등 측정치가 없는 주장

### Step 3: Goal 점검(측정 가능한가, Context로부터 정당화되는가)

Goal은 최소한 다음을 포함해야 한다(하나라도 빠지면 “작성 보완 포인트”로 지적한다).

- Metric(지표명) / Baseline(기준선) / Target(목표치) / Timeframe(기한) / Scope(범위)
- Leading vs Lagging: 선행지표(활동/품질/전환 등)와 결과지표(매출/유지 등) 연결
- Guardrail(부작용 방지): 목표 달성 과정에서 지키면 좋은 제약(품질/비용/CS 등)

Goal 문장 작성 체크(5 Whys 방지):
- “~을 개선한다” 대신 “지표 X를 Y에서 Z로(기간 T 내) 개선한다”
- “성공한다/정상화한다” 대신 “성공 기준(컷라인)”을 명시한다

### Step 4: Tasks 점검(완료되면 Goal 달성으로 이어지는가)

Tasks는 “할 일 목록”이 아니라 “목표 달성 메커니즘”이어야 한다. 다음을 검토한다.

- 각 Task가 어떤 driver(전환율/재구매/가격/노출/품질 등)를 어떻게 바꿔 Goal 지표에 영향을 주는가?
- 각 Task에 Deliverable / Owner / Due date / 성공 기준(측정 방법)이 있는가?
- Task들 전체가 “충분 조건”에 가까운가? (측정·실험·출시·운영·리스크 관리가 누락되지 않았는가)
- 전제(Assumption)가 Task로 검증되는가? (가정 검증 계획이 있는가)

Task가 Goal과 분리되어 흔히 실패하는 패턴:
- “현황 분석/회의/커뮤니케이션”만 있고 실제 지표 변화를 만드는 실행이 없는 경우
- “기능 개발”만 있고 출시/측정/롤백/운영/CS 대응이 없는 경우
- “마케팅 집행”만 있고 타겟/채널/예산/크리에이티브/실험 설계가 없는 경우

### Step 5: Hypothesis / Experiment 점검(가설-검증-결정)

실험이나 “분석으로 검증한다”는 표현이 등장하면, 아래가 문서에 드러나는지 점검한다. 없으면 “추가해야 할 명시 항목”으로 리뷰에 포함한다.

- 가설 문장에 **세그먼트/메커니즘/지표/방향/기간**이 포함되는가?
- 검증 계획에 **primary metric / baseline / target / guardrails**가 포함되는가?
- 실험(또는 분석) 방법이 구체적인가? (대조/비교, 기간, 표본, 계측/대시보드)
- 결과 해석과 다음 액션이 합의되는가? (launch/iterate/rollback의 결정 규칙)

### Step 6: Communication / Alignment / Searchability 점검

문서만 보고 일할 때, 추후에 “정의가 달라서” 또는 “의사결정 공백” 때문에 싱크가 안 맞을 지점을 찾는다.

- 정의: 지표/세그먼트/퍼널 단계/용어가 팀별로 다르게 해석될 여지가 있는가?
- 범위: Scope/Non-goals/제약/트레이드오프가 빠져 있지는 않은가?
- 의사결정: Owner/Approver/릴리즈 게이트가 불명확하지 않은가?
- 검색: 지표명(정확한 표기), 정의/산식, 대시보드/링크, `HYP-###`/`EXP-###` 같은 ID가 있는가?

### Step 7: 5 Whys 기반 문장/논리 취약점 탐지

아래 방식으로 문장들을 점검한다.

1) Context/Goal/Tasks의 핵심 주장 문장들을 뽑는다(각 섹션 3~8개).  
2) 각 문장에 대해 “왜?”를 최소 2~4번 반복한다.  
3) 답이 “좋지 않다/필요하다/중요하다/문제가 있다”류의 추상어로 끝나면, 수치·기간·범위·정의·원인 사슬(원인→메커니즘→결과)로 문장을 다시 쓰도록 제안한다.  
4) 인과가 불명확하면 “확인해야 할 데이터/실험”을 Task로 추가 제안한다.

### Step 8: 출력물 생성 규칙(`{filename}_reivew.md`)

각 입력 파일 `X.md`에 대해, 같은 폴더에 `X_reivew.md`를 생성한다(여기서 `X`는 확장자를 제외한 파일명; 사용자가 다른 규칙을 요구하면 그 요구를 따른다).

리뷰 문서는 `assets/review-template.md`를 기반으로 작성하되, 반드시 아래를 포함한다.

- Executive summary: 가장 치명적인 3가지 결함 + 가장 효과적인 3가지 개선
- Context/Goal/Tasks 평가: 무엇이 부족한지, 어떤 추가 정보/재작성/재구성이 필요한지
- Hypothesis/Experiment 평가: 가설·검증·결정 규칙의 구체성/재현성 부족분과 보강안
- Alignment/Searchability 평가: 싱크 불일치 리스크와 검색/추적 앵커 보강안
- “Task 완료 ⇒ Goal 달성” 논리 체크: 부족하면 어떤 Task가 추가되어야 하는지
- 5 Whys 결과: 모호한 문장 목록 + 구체화된 대체 문장 제안
- 멘탈모델/프레임: 재작성에 도움이 되는 모델(예: metrics tree, working backwards, theory of change)

## References / Assets

- Rubric & 체크리스트: `references/sixpager-review-checklist.md`
- 리뷰 출력 템플릿: `assets/review-template.md`

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.