tool-foundation-sprint-brief
정보
이 스킬은 파운데이션 스프린트의 범위, 핵심 결정 사항, 역할, 로지스틱을 정의하고 확정하기 위한 1페이지 분량의 사전 스프린트 브리프를 생성합니다. 이는 준비 상태 점검 이후, 스프린트 시작 전에 사용되며, 팀의 계약서 역할을 하는 서명된 산출물을 만들어 냅니다. 주요 결과물에는 이니셔티브 명세서, 해결해야 할 중대 결정 사항, 그리고 지정된 팀 역할이 포함됩니다.
빠른 설치
Claude Code
추천npx skills add product-on-purpose/pm-skills -a claude-code/plugin add https://github.com/product-on-purpose/pm-skillsgit clone https://github.com/product-on-purpose/pm-skills.git ~/.claude/skills/tool-foundation-sprint-briefClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Foundation Sprint Brief
Produce the one-page brief that aligns the team on scope, decision target, participants, logistics, and success criteria before Day 1 begins. A well-built brief prevents Day 1 from opening with re-litigation of why-are-we-here; a missing or vague brief almost guarantees it.
Family contract: docs/reference/skill-families/foundation-sprint-skills-contract.md. This skill is a member of foundation-sprint-skills.
When to Use
- The readiness verdict from
tool-foundation-sprint-readinessis Go (or Conditional Go with preconditions cleared). - The sprint has dates blocked on calendars and you need the artifact that names what the sprint is for.
- The team has prep activities scheduled and you need a written reference for what to bring.
- A skeptical exec wants to know "what is the team doing for two days?" and you need an answer that fits on one page.
When NOT to Use
- The sprint has already started. The brief is a prep artifact, not an in-sprint deliverable. If Day 1 is happening, run
tool-foundation-sprint-basicsinstead. - The readiness verdict is Wait. The brief cannot fix an unready team; close the preconditions first, then re-run readiness, then invoke this skill.
- The team wants a strategy document. The brief is internal prep, not a stakeholder deliverable. If a stakeholder document is needed, that is a downstream artifact.
- The brief threatens to become a multi-page strategic document. Stop and reframe: the canonical brief is one page.
What This Skill Produces
A single bundled artifact with six sections:
- Initiative statement and stakes: one paragraph naming what the team is sprinting on and why a wrong direction would be costly.
- Decision the sprint must unlock: the open strategic question the sprint resolves. Single sentence.
- Team roster with role assignments: who is in the room and what role each person plays per section of the sprint.
- Logistics plan: dates, hours, location, format (in-person, remote, hybrid), tools, daily rhythm.
- Existing inputs to bring: the research, customer examples, competitor notes, metrics, and constraints the team should reference during the sprint.
- Readiness reaffirmation: a final check that the Go verdict from
tool-foundation-sprint-readinessstill holds.
See references/TEMPLATE.md for the canonical structure and references/EXAMPLE.md for the Brainshelf book-catalog brief.
Inference Inputs
| Input | What the skill does with it |
|---|---|
Readiness verdict and recommendations (from tool-foundation-sprint-readiness) | Pulls the recommended attendees, preconditions, and pre-sprint activities into the brief; flags any precondition that has not been closed |
| Initiative description | Compresses into one paragraph for the Initiative Statement section |
| Team roster | Maps people to the required Foundation Sprint roles (Decider, Facilitator, PM, Design, Engineering, Customer Expert) |
| Logistics constraints | Produces the dates/hours/location/format/tools matrix; flags any constraint that would force the sprint to extend beyond two days |
| (Optional) Skeptical-exec talking points | Tightens the Stakes paragraph to address why-now and why-this concerns |
Brief Length Discipline
The brief MUST fit on one page (or one screen). The skill enforces this through structural choices, not raw character counts:
- Initiative Statement: one paragraph, four sentences maximum.
- Decision the sprint must unlock: one sentence.
- Team Roster: table with one row per person.
- Logistics: table.
- Inputs to Bring: bulleted list, five items maximum.
- Readiness Reaffirmation: checklist.
If the brief expands beyond this scope, the sprint is being over-engineered before it starts. The fix is not a longer brief; the fix is a clearer decision target.
Common Pitfalls
- Over-engineering the brief. The brief is a prep artifact, not a strategy doc. If it has an executive summary, an appendix, or a "background" section longer than one paragraph, it has drifted.
- Treating the brief as a deliverable to stakeholders. Stakeholders do not read the brief; they read the Founding Hypothesis at the end. The brief is for the team. Sharing it publicly invites pre-sprint debate, which the sprint is supposed to resolve.
- Vague decision target. "We will figure out our strategy" is not a decision. "We will commit to a top bet between [option A] and [option B]" is.
- Logistics drift. "We'll figure out dates" or "we'll meet hybrid sometimes" telegraphs that the team has not actually committed to the sprint. Either dates and format are locked, or the readiness verdict was wrong.
- Skipping readiness reaffirmation. The readiness verdict was a snapshot. If a precondition has slipped or the Decider's availability has changed since readiness, the brief needs to surface that, not paper over it.
Canonical Sources
- Character Capital. "Foundation Sprint guide." Section on pre-sprint preparation and team scoping.
- Knapp, J., and Zeratsky, J. Click: How to Make What People Want. Pre-sprint prep recommendations.
- pm-skills
foundation-meeting-briefprecedent: brief-structure pattern adapted for the strategic context of a Foundation Sprint rather than a meeting.
Cross-Skill Usage
Prerequisites: tool-foundation-sprint-readiness. The brief expects the readiness output as its primary input. When prerequisites is honored, the brief inherits the readiness verdict, attendee recommendations, and pre-sprint activities; the skill then refines and commits them.
If the team has done equivalent prep without running the readiness skill explicitly (e.g., experienced sprint facilitator who knows the readiness criteria), the brief skill can be invoked directly. In that case, the skill body prompts the team to confirm the readiness criteria are met before generating the brief.
Next invocation in the sprint: tool-foundation-sprint-basics on Day 1 morning.
Decider Checkpoint
This skill ends with a Decider Checkpoint in references/TEMPLATE.md. The Decider signs off on scope (the decision target), team (the roster and role assignments), success criteria (what makes the sprint successful or not), and the explicit tradeoff that the sprint will force a top bet rather than preserve all directions. Without sign-off, the brief is advisory; with sign-off, it is the contract for the next two days.
GitHub 저장소
연관 스킬
executing-plans
디자인executing-plans 스킬은 검토 체크포인트가 포함된 통제된 배치로 실행할 완전한 구현 계획이 있을 때 사용합니다. 이 스킬은 계획을 불러와 비판적으로 검토한 후, 소규모 배치(기본값 3개 작업)로 작업을 실행하면서 각 배치 사이에 진행 상황을 아키텍트 검토를 위해 보고합니다. 이를 통해 내재된 품질 관리 체크포인트를 갖춘 체계적인 구현이 보장됩니다.
requesting-code-review
디자인이 스킬은 코드 변경 사항을 요구 사항에 따라 분석하기 위해 코드 리뷰어 하위 에이전트를 호출합니다. 작업 완료 후, 주요 기능 구현 후, 또는 메인 브랜치에 병합하기 전에 사용해야 합니다. 이 리뷰는 현재 구현체와 원래 계획을 비교하여 문제를 조기에 발견하는 데 도움이 됩니다.
connect-mcp-server
디자인이 스킬은 개발자들이 HTTP, stdio 또는 SSE 전송 방식을 통해 MCP 서버를 Claude Code에 연결하는 포괄적인 가이드를 제공합니다. GitHub, Notion 및 사용자 정의 API와 같은 외부 서비스를 통합하기 위한 설치, 구성, 인증 및 보안을 다룹니다. MCP 통합 설정, 외부 도구 구성 또는 Claude의 모델 컨텍스트 프로토콜 작업 시 활용하세요.
web-cli-teleport
디자인이 스킬은 작업 분석을 기반으로 개발자가 Claude Code 웹 인터페이스와 CLI 인터페이스 중 선택할 수 있도록 돕고, 두 환경 간 원활한 세션 텔레포트를 가능하게 합니다. 웹, CLI 또는 모바일 환경 전환 시 세션 상태와 컨텍스트를 관리하여 워크플로를 최적화합니다. 다양한 단계에서 서로 다른 도구가 필요한 복잡한 프로젝트에 사용하세요.
