pillar-landing-pages

Pillar 랜딩 페이지

여러 역량, 핵심 영역 또는 하위 제품을 다루는 하나의 포지셔닝 브리프를 독립적인 랜딩 페이지 브리프로 확장합니다. 각 핵심 영역당 하나씩, 고유한 URL, 키워드 타겟팅 및 히어로부터 최종 CTA까지의 카피를 포함합니다.

입력

company-context.md를 먼저 읽고(저장소 루트 또는 워크스페이스에서 검색), 이 스킬에 적용되는 필드를 사용하세요. 파일이나 줄이 누락된 경우 한 번만 질문한 후, 답변을 파일에 저장하겠다고 제안하세요. 회사에 대한 가정으로 빈 칸을 채우지 마세요.

함께 작동하는 것

• 입력: 포지셔닝 브리프, capability-pillar-research의 핵심 영역 문서, use-case-evidence-research의 증거 문서. 모든 페이지의 모든 주장은 이러한 문서로 추적 가능해야 합니다.
• 출력: 핵심 영역당 하나의 페이지 브리프. 주장 태그가 함께 전달되며, 요청 시 결합된 상위 페이지도 생성합니다.
• 다음 단계: 카피라이팅 및 디자인. 제품 사실이 변경될 때마다 이러한 브리프 전반에 걸쳐 claim-propagation-sweep을 실행하세요.

핵심 영역이나 증거 문서가 존재하지 않는다면, 메모리에서 페이지를 작성하는 대신 먼저 문서를 만드세요.

하나의 결합된 페이지와의 차이점

결합된 페이지는 가장 강력한 두세 가지 역량이 페이지를 이끌고 약한 역량은 통합되도록 합니다. N개의 페이지로 분할하면 그 안전장치가 사라집니다: 모든 핵심 영역이 동등한 증거를 가지고 있든 없든 동일한 공간을 갖게 됩니다. 증거가 부족한 핵심 영역도 자체 페이지를 가질 수 있지만, 페이지는 이에 대해 정직해야 합니다.

프로세스 (핵심 영역별)

1. URL. 일관된 상위 경로에 핵심 영역을 마지막 세그먼트로 사용하여 페이지들이 하나의 제품군으로 읽히도록 합니다.
2. 해당 핵심 영역의 키워드 리서치, 제품의 포괄적인 용어를 재사용하지 않음. 검색량, 난이도 및 CPC를 가져옵니다(도구의 통화 단위 확인; 일부 API는 CPC를 센트 단위로 반환). 다음을 플래그로 표시:
   • 브랜드 포지셔닝과 충돌하는 키워드(가장 좋은 키워드가 "티켓팅 시스템"이지만 제품이 티켓 큐에 반대하는 경우): 제목, 메타 및 보조 제목에만 유지하거나 사람에게 플래그를 표시.
   • 검색 결과가 다른 형식(목록, 비교)에 의해 지배되는 용어: 제품 페이지가 경쟁하도록 강요하는 대신 해당 용어에 대해 다른 에셋을 권장.
3. 기본 키워드의 제목 태그와 메타 설명.
4. 포지셔닝 요약: 소스 브리프의 3-5문장, 핵심 영역의 핵심 주장 및 가장 강력한 증거.
5. 페이지 구조, 제품군 전체에서 동일한 형식 사용:
   • 히어로(H1, 부제목, CTA): 핵심 영역의 가장 구체적이고 날카로운 주장, 메커니즘을 명명.
   • 증명 스트립: 3-4개의 짧고 출처가 명시된 주장. 통계가 존재하지만 공개 승인되지 않은 경우 명시하고, 사용하지 않거나 조용히 삭제하지 마세요.
   • 2-4개의 본문 섹션: 이 핵심 영역의 실제 증거를 기반: 기능(역량 카탈로그에서), 명백한 대안보다 나은 이유, 이 핵심 영역이 해결해야 할 이의.
   • 신뢰 또는 보안 섹션, 핵심 영역이 권한, 규정 준수 또는 AI 안전 관련 이의를 다루는 경우 상단에 배치.
   • 정직한 범위 섹션, 이 핵심 영역의 증거가 형제 핵심 영역보다 부족한 경우에만.
   • 형제 페이지로의 교차 링크.
   • 최종 CTA.
6. 모든 주장에 태그 (공유 규칙 4)를 달고, 사용된 고객 인용문에 대해 인용문 확인을 실행.
7. 페이지별 미해결 항목을 각 브리프 끝에: 확인되지 않은 수치, 승인 대기 중인 고객, 또는 해당 핵심 영역이 자체 페이지를 가질 가치가 있는지에 대한 실제 질문.

완료 조건

• 모든 페이지가 자체 키워드 리서치를 가지고 있습니다.
• 모든 히어로 및 증명 주장이 소스 문서로 추적됩니다.
• 불균등한 증거가 핵심 영역이 고르지 않은 경우 최소 하나의 정직한 범위 노트에 표시됩니다.
• 페이지가 서로 교차 링크됩니다.

공유 규칙 (이 세트의 네 가지 스킬에서 동일)

1. 증거가 카피보다 우선. 모든 제품 주장, 통계 및 인용문은 명명된 출처로 추적됩니다. 역량, 수치, 고객 스토리 또는 인용문을 절대 만들어내지 마세요. 증거가 없으면 그렇게 말하세요.
2. 출시는 출시됨을 의미. 역량의 상태(출시됨, 진행 중, 계획됨)는 출처가 명시한 대로만 기술하세요. 제품이 충족할 수 없는 구매자 요청은 희망 또는 요구사항에 넣고, 역량에 넣지 마세요.
3. 인용문은 그대로이며 구매자 측. 정확한 단어를 복사하고 "..."로 자르되 절대 변경하지 마세요. 벤더 직원을 구매자로 인용하지 마세요. 완료 전에 인용문 확인(use-case-evidence-research와 함께 verify_quotes.py 스크립트로 제공됨)을 실행하고 발견되지 않은 것은 수정 또는 삭제하세요.
4. 주장 태그. 카피와 주장을 SAFE, NEEDS VERIFY: (무엇이 해결할 것인지), 또는 INTERNAL ONLY(승인되지 않은 명명된 고객 자료)로 표시하세요. 한 스킬의 출력에서 다음 스킬로 태그를 전달하고 제거하지 마세요.
5. 부족한 증거는 명확히 말하기. 계정 수를 세고 인용문 수를 세지 마세요. 약한 영역을 강한 영역에 맞추기 위해 부풀리지 마세요.
6. 완성된 문서, 변경 로그가 아님. 참조용으로 읽히는 문서에는 "업데이트됨", "추가됨", "신규", 버전 번호, 스위프 또는 세션 참조를 넣지 마세요. 버전 기록이 이를 담당합니다.
7. 외부 안전 모드 (사용자가 외부용, 광고용, 고객용이라고 말할 때, 깨끗하게 유지): 직위와 회사 이름만, 개인 이름 없음; 날짜 없음; 경쟁사 이름은 중립적인 대괄호(예: "[이전 도구]")로 대체; 승인, 출처 또는 사용에 관한 노트 없음. 응답 시 고객 인용문이 여전히 승인이 필요하다고 사용자에게 알리세요.
8. 어조. 평이하고 직접적. 엠 대시 없음. 모호한 표현 없음. 경쟁사를 구매자가 말하는 것 이상으로 특성화하지 마세요. 문서 본문에 파일 이름을 넣지 마세요.

네 가지 스킬의 협력 방식

1. use-case-evidence-research: 사용 사례 또는 기능별로 증거(제품 역량, 구매자 고충, 희망, 반응)를 수집하고 검증.
2. capability-pillar-research: 그 증거를 동사(제품이 하는 일) 기준으로 재구성하여 기능이 아닌 행동으로 포지셔닝.
3. pillar-landing-pages: 1-2단계의 주장만 사용하여 포지셔닝을 핵심 영역 또는 기능당 하나의 페이지 브리프로 변환.
4. claim-propagation-sweep: 제품 사실이 변경될 때마다 1-3단계에서 생성된 모든 것을 대상으로 실행하고 수정 사항을 증거 문서에 다시 제공.

한 단계의 출력은 다음 단계의 입력입니다. 이후 단계를 요청받았는데 이전 단계의 출력이 존재하지 않는 경우, 메모리에서 작성하는 대신 이전 단계를 먼저 만들거나(또는 누락되었다고 사용자에게 알림) 이전 단계를 먼저 만드세요.