beedle은(는) 무엇을 하나요?
검색 엔진과 AI 크롤러가 읽을 수 있고, 낯선 사람이 10초 안에 이해할 수 있으며, 증명할 수 있는 것만 주장하는 마케팅 페이지를 구축하세요. 적을수록 좋습니다: 모든 섹션은 자신의 자리를 증명해야 합니다. 모든 라운드는 독립적인 검토로 끝납니다.
교훈: 1단계 이전에 프로젝트의 design/LESSONS.md 파일이 있다면 읽고, 마케팅 사이트에 관한 내용을 따르세요. 해당 파일은 소유자의 수정 사항입니다.
1. 프로젝트 읽기
아무것도 묻기 전에 먼저 존재하는 것을 파악하세요: 스택과 호스트, 현재 사이트, 제품의 실제 이름, 저장소, 스토어 목록, 가격, 스크린샷, 디자인 토큰 또는 테마, 분석, 그리고 docs/marketing/page-brief.md.
프로젝트가 이미 사용하는 스택으로 구축하세요. 새 사이트의 경우 reference/seo.md ("스택 선택")를 따르세요. 마케팅 콘텐츠는 절대 Flutter Web이나 클라이언트 렌더링을 사용하지 않습니다. 크롤러가 이를 보지 못할 수 있기 때문입니다.
프로젝트에 테마가 있다면 (design/THEME.md, *.tokens.json) 사용하세요. 없으면 앱에서 토큰을 가져오세요. 앱도 없다면 reference/small-theme.md에 있는 작은 파일 하나를 작성하세요. 한 페이지에 디자인 시스템이 필요하지 않기 때문입니다. 여러 사이트나 앱이 공유해야 할 테마가 필요할 때만 ultrahand:theme 스킬을 사용하세요.
2. 유형과 런칭 상태 선택하기
reference/page-types.md를 읽으세요. 하나의 유형과 하나의 상태(프리런칭 또는 라이브)를 선택하고, 사이트에 필요한 지원 페이지를 기록하세요.
3. 브리프 작성하기
다음 템플릿을 사용하여 프로젝트에 docs/marketing/page-brief.md를 저장하세요. 이는 리뷰어가 페이지를 검토하는 기준이 되는 계약서이며, 다음 세션의 시작점입니다.
# 페이지 브리프
- 유형 및 상태:
- 대상: (누구이며, 그들이 이미 알고 있는 것)
- 페이지의 단 하나의 임무:
- 기본 CTA: (정확한 단어와 목적지)
- 보조 액션: (하나, 더 가벼운 것, 또는 "없음")
- 검색 구문: (이 대상이 실제로 입력하는 3-5개)
- 반론: (사람들이 떠나는 진짜 이유)
- 분석 및 쿠키: (로드되는 것, 또는 "없음")
## 주장
| 페이지의 주장 | 증거 |
| --- | --- |
| <모든 숫자, 인용, 비교, "최초", "가장 빠른", ...> | <파일, 링크 또는 측정값(날짜 포함)> |
| <제품이나 기능에 대한 일반 설명> | <파일 또는 링크, 또는 그것이 전부라면 `README only`> |
## 사람을 기다리는 중
- <누가: 그들이 해야 할 일, 또는 "없음">
프로젝트가 답할 수 없는 것만 사용자에게 물으세요. 보통 대상과 증거입니다. 절대 증거를 지어내지 마세요. 누락된 사용 후기는 채워야 할 빈칸이 아니라 누락된 섹션입니다. APP_STORE_ID_TODO와 같이 명확하게 실패하는 센티널을 사용하고, 그럴듯한 가짜 값은 사용하지 마세요.
README만 있을 때도 페이지를 구축할 수 있습니다. 제품이 무엇이고 무엇을 하는지 명확하게 말할 수 있습니다: 해당 행은 README only로 표시하세요. 숫자, 날짜, 버전, 라이선스, 가격, 보안, 개인정보, 가용성은 증명할 수 없으므로 각각에 대해 기본 출처를 찾으세요: 코드, LICENSE 파일, 릴리스 페이지, 레지스트리나 스토어 목록, 측정값, 또는 소유자의 날짜가 있는 말. 해당 출처를 인용하세요. 없으면 페이지에서 주장을 제외하세요.
오직 사람만이 제공할 수 있는 것은 알게 되는 즉시 사람을 기다리는 중에 넣으세요: 실제 스크린샷, 도메인, 확인할 가격 등. 사용자가 완료할 때까지 그대로 둡니다.
4. 먼저 단어를 작성하세요
reference/message.md를 따르세요. 레이아웃 전에 카피를 먼저 작성하세요. 거기에 있는 다섯 개의 블록부터 시작하세요. 섹션은 그 섹션이 답하는 반론을 명명할 수 있을 때만 추가하고, 그 반론을 브리프에 기록하세요.
5. 구축하기
페이지에 포함될 내용과 함께 들어갈 내용에 대해 reference/seo.md를 따르세요. 실제 제품 스크린샷이나 영상을 사용하고, 재구성한 것을 스크린샷이라고 절대 표시하지 마세요. 실제 앱이 예제 데이터를 실행하는 캡처는 실제입니다: 페이지에서 예제라고 말하고, 주장 표에서 어떻게 만들었는지 설명하세요. 보여줄 실제 것이 없으면 이미지를 생략하거나, 페이지 유형에 필요하다면 센티널을 남겨두세요. 메시지 참고에 나열된 디자인 힌트를 피하세요. 누군가가 읽기 전에 페이지가 생성된 것처럼 보이게 하기 때문입니다.
6. 자체 점검
사이트를 빌드하고 빌드된 출력물에 대해 감사를 실행한 후, 수정할 수 있는 모든 오류를 수정하세요:
beedle audit --dir <빌드된 사이트>
마케팅이 아닌 각 섹션에 대해 --exclude docs를 추가하세요 (반복 가능). beedle이 PATH에 없으면 감사가 실행되지 않았다고 사용자에게 알리고 INSTALL.md에 추가 방법이 나와 있다고 말하세요.
오직 사람만이 해결할 수 있는 오류는 그대로 둡니다. 예: 아무도 구매하지 않은 도메인에 대한 DOMAIN_TODO 센티널. 깔끔한 실행을 위해 가짜 값을 절대 바꿔 넣지 마세요. 사람을 기다리는 중에 있는지 확인한 후, 리뷰로 넘어가세요.
7. 라운드 리뷰하기
모든 라운드는 사용자에게 페이지가 준비되었다고 말하기 전에, 자체 세션에서 새로운 리뷰어가 검토하는 것으로 끝납니다. 라운드는 첫 번째 빌드와 이후 페이지를 변경하는 모든 프롬프트입니다. 따라서 한 줄짜리 카피 변경도 검토 대상입니다. 사용자가 이번 라운드에서 건너뛰라고 말할 때만 건너뛰고, 건너뛰었다고 말하세요.
요청 없이 직접 시작하세요. 자신의 페이지를 공정하게 검토할 수 없습니다: 당신은 의도한 것을 봅니다. review/round.md를 따르세요. 요약하면, 브리프를 작성하고, 백그라운드에서 beedle review --brief <brief> --add-dir <프로젝트>를 실행한 후, 결과에 따라 조치하세요. 이 작업 전에 게시, 배포 또는 페이지 완료를 선언하지 마세요.
8. 보고하기
무엇을 구축했는지, 유형과 상태, 평결, 리뷰에서 발견되고 수정된 사항과 열려 있는 사항, 그리고 비용을 말하세요.
평결이 사람이 행동할 때까지 출시 불가이면, 그 말로 시작하세요: 페이지가 준비되지 않았으며, 누가 무엇을 해야 하는지, 다음 라운드에서 그들이 완료하면 무엇을 확인할지. 절대 "거의 다 됨"으로 순화하지 마세요.
런칭 후 소유자가 해야 할 일을 항상 나열하세요: Search Console 및 Bing Webmaster 인증, 배포된 페이지에 대한 Rich Results Test.
사용자가 요청하지 않으면 배포하지 마세요.
9. 배우기
소유자가 결과를 수정하거나 지속적인 선호도를 명시하면, 프로젝트의 design/LESSONS.md에 한 줄을 추가하세요 (필요하면 생성). 수정 사항이 이 규칙이 모든 프로젝트에 대해 잘못되었음을 보여주면, 여기서도 규칙을 수정하세요.