TL;DR
Good AI project-kickoff notes do not merely summarize the conversation. They separate what was proposed, what was agreed, and what still needs approval.
Use a six-part kickoff brief:
1. purpose and success; 2. scope and exclusions; 3. roles and authority; 4. decisions and their status; 5. assumptions, dependencies, and risks; 6. next actions and open questions.
For every consequential field, keep a source reference and one of three states: proposed, agreed, or not confirmed. An AI can draft the structure and recover evidence. It should not turn discussion into project authorization, scope into a promise, or a mentioned task into an accepted commitment.
A kickoff summary is not a project contract
A kickoff has a specific job: align the people who will do and govern the work. Atlassian's Project Kickoff Play describes the meeting as a place to establish purpose, roles, responsibilities, and success markers. Asana's project-kickoff guide likewise centers goals, scope, roles, and next steps.
That does not mean every sentence in the meeting becomes an approved term.
A participant may suggest a launch date. A sponsor may describe a desired outcome without accepting the proposed scope. A team member may volunteer to investigate a dependency without owning the final deliverable. Someone may object to an assumption that the rest of the room treats as settled.
An AI summary can flatten those distinctions by producing smooth prose and complete-looking lists. Without explicit state labels, it can turn:
- “we could” into we will;
- “someone should” into an assigned owner;
- “Q1 would be ideal” into a deadline;
- “I think legal is comfortable” into approval;
- silence into consensus.
First decide what document the kickoff is allowed to change
Kickoffs do not all begin from the same governance state. Asana's guide places the kickoff after a project charter is approved and before work begins. Atlassian says its kickoff typically follows a finalized statement of work or project poster. A smaller internal initiative may begin with a rough sponsor brief instead.
Before the meeting, name the controlling artifact:
| Starting state | What the meeting may do | What still needs separate approval |
|---|---|---|
| Approved charter or statement of work | Clarify delivery, working norms, and immediate actions inside the approved boundary | Any scope, budget, authority, or success-criteria change |
| Draft charter or project brief | Refine terms and surface objections | Final authorization and resource commitment |
| Discovery-stage idea | Create a proposed brief and evidence queue | Whether the project should exist at all |
| Client-facing agreement | Clarify the shared interpretation and escalation path | Follow the agreement's authorized change process for contractual changes, new deliverables, or revised commercial terms; do not treat the kickoff alone as an amendment |
This is the first field in the notes: governing artifact and current status. If nobody can name it, record that as an open governance question. Do not let the generated summary become the de facto source of authority.
PMI's September 2026 project-charter guidance makes the boundary especially clear: AI can turn rough notes into a structured first draft, but humans still decide why the project should exist, what belongs in it, and who has authority to lead it. PMI's PMBOK Guide Sixth Edition Develop Project Charter process defines the charter as the document that formally authorizes the project and the project manager's use of organizational resources.
The six-part kickoff brief
1. Purpose and success
Capture the business or user problem, the intended outcome, and the success criteria discussed.
Do not merge them. “Ship the new onboarding flow” is a deliverable. “Reduce time to a verified first result” is an outcome. A metric mentioned without a baseline, target, owner, or measurement source is not yet a complete success criterion.
| Field | Example state |
|---|---|
| Problem or opportunity | Agreed |
| Intended outcome | Agreed |
| Success signal | Proposed |
| Baseline and target | Not confirmed |
| Accountable approver | Agreed |
2. Scope and exclusions
Record both what is in scope and what is explicitly out. Asana's kickoff guide calls out the need to discuss both sides of the boundary. Exclusions matter because they are often where two participants discover that they imagined different projects.
For each scope term, capture:
- deliverable or capability;
- included user, system, region, or phase;
- exclusion;
- source;
- status;
- change authority.
3. Roles and authority
Separate participation from authority.
| Role question | Record |
|---|---|
| Who sponsors the work? | Named person or not confirmed |
| Who leads delivery? | Named person plus stated authority |
| Who approves scope changes? | Named role or governance group |
| Who accepts the result? | Named role and acceptance condition |
| Who must be consulted? | Role and decision area |
| Who only needs updates? | Role and cadence |
Attendance does not grant decision authority. A speaker label does not verify identity. A person suggesting an owner does not prove that the owner accepted the work.
4. Decisions and their status
Keep a small decision register inside the brief.
| Field | Required detail |
|---|---|
| Decision question | The exact choice |
| State | Proposed, agreed, deferred, or rejected |
| Options | Alternatives actually discussed |
| Decision | The selected option, if any |
| Authority | Who made or must make it |
| Rationale | Evidence and constraints cited |
| Review trigger | Date, dependency, metric, or new evidence |
If the meeting did not contain an explicit decision, record the row as proposed or deferred. Do not infer approval from positive language, a majority of airtime, or lack of objection.
For work that spans several meetings, move approved rows into a durable AI meeting decision log rather than treating the kickoff as the only record.
5. Assumptions, dependencies, and risks
These are related, but not interchangeable:
- an assumption is being treated as true for planning;
- a dependency is a linkage or prerequisite that constrains whether or when work can proceed;
- a risk is an uncertain event or condition that could affect the outcome;
- an issue is already happening.
PMI's charter guidance includes assumptions and constraints among the terms that need human judgment. The PMBOK Guide Sixth Edition process cited here also lists an assumption log as an output; it is historical edition-specific support, not a claim about the current edition. PMI's requirements-risk guidance separately distinguishes assumptions, dependencies, risks, and issues. That makes this lane part of project definition, not an appendix to delete when the meeting runs long.
6. Next actions and open questions
An action is not ready until it has a bounded deliverable and an accepting owner.
Use these fields:
| Field | Rule |
|---|---|
| Action | Start with a verb and name the deliverable |
| Owner | Use only an explicitly accepting person or team |
| Due or review date | Use the stated date or not set |
| Dependency | Name what must happen first |
| Done condition | State what a reviewer will inspect |
| Destination | Name the tracker or document, if approved |
| Source | Link to the statement or note |
Keep open questions in the same lane, with the person who can answer them and the next decision point. “Owner not confirmed” is a useful result. An invented name is not.
Copyable kickoff-brief template
``md
Project kickoff brief
Status: DRAFT FOR REVIEW Meeting: [date and title] Governing artifact: [charter / statement of work / brief / not confirmed] Artifact status: [approved / draft / not confirmed] Reviewer: [sponsor or authorized owner]
1. Purpose and success
- Problem or opportunity:
- Intended outcome:
- Success criteria:
- Missing baseline or target:
2. Scope and exclusions
| Term | In / out | State | Source | Change authority |
|---|
3. Roles and authority
| Role | Person or group | Authority | State | Source |
|---|
4. Decisions
| Question | State | Decision | Authority | Rationale | Review trigger | Source |
|---|
5. Assumptions, dependencies, and risks
| Type | Item | Evidence | Impact | Owner | Response | Review |
|---|
6. Next actions and open questions
| Type | Item | Owner | Date | Done condition / answer needed | Source |
|---|
Review corrections
- [field, correction, approver, date]
A bounded prompt for AI kickoff notes
Use this only with meeting content and destinations your organization permits:
Prepare a DRAFT project kickoff brief from the supplied meeting context. Separate: (1) purpose and success, (2) scope and exclusions, (3) roles and authority, (4) decisions, (5) assumptions, dependencies, risks, and current issues, and (6) next actions and open questions. For every material entry, include a recoverable source reference and label it PROPOSED, AGREED, or NOT CONFIRMED. Use AGREED only when the meeting explicitly records agreement by the authorized person or group. Do not infer authorization, identity, consensus, scope, budget, owner, deadline, acceptance, or risk approval. Preserve contradictions and rejected options. If a required field is missing, write NOT CONFIRMED. Do not update a charter, contract, tracker, or external system. End with a review queue for the sponsor, delivery lead, and action owners.
This prompt produces a draft. It does not determine whether the meeting was authorized to amend the project's governing artifact.
Worked example: a customer-onboarding project
Imagine a kickoff where the sponsor wants a new onboarding experience “this quarter,” design presents two flows, engineering flags an identity-system dependency, and a marketer says they can “probably own the launch email.”
A weak summary says:
The team agreed to ship the new onboarding flow this quarter. Marketing will own launch communications.
The reviewed brief says:
| Lane | Record |
|---|---|
| Purpose | Reduce confusion before a user's first verified result; agreed by sponsor |
| Success | Candidate metric discussed; baseline and target not confirmed |
| Scope | New-user flow proposed; returning-user migration not confirmed |
| Decision | Two design options remain open pending technical evidence |
| Dependency | Identity system must expose a reliable completion state |
| Risk | Quarter timing may not allow migration work; response not confirmed |
| Action | Engineering to document completion-state options by Friday; owner accepted |
| Open question | Marketing launch owner and channel approval not confirmed |
The second version is less polished and more useful. It tells the team exactly what is safe to act on and what still needs authority.
Where Shadow fits
Shadow is an AI interface for Mac that sees, hears, and runs. Its meeting review brings the recording, transcript, notes, available screenshots, Skills, and Ask into one record. A detected Speaker is only a meeting-local voice group, not a verified identity.
When Smart Screenshot is enabled and a capture target is available, screenshots can preserve meaningful visual context from the kickoff, such as the scope slide or dependency map. They do not prove that the artifact was current or approved.
A configured Meeting Skill can draft a structured result and, for supported Skills, save Markdown or send a result to a webhook you control. Shadow's Help guide says to review generated claims, decisions, owners, and dates before sharing. A webhook transmits a result; it does not approve a charter, assign a person, or accept a risk.
Review privacy and data leaving your Mac before using AI or an external destination. Core meeting capture is local; optional AI and sharing features can send relevant context outside the Mac. Get the required recording consent before Listening begins.
What is real, what is interpretation, and what is unproven
Real now
- PMI treats a charter as formal project authorization and identifies authority, purpose, objectives, scope, stakeholders, assumptions, constraints, and success criteria as important terms.
- Atlassian and Asana both use kickoffs to align people around purpose, scope, roles, success, and next steps, although their recommended starting artifacts differ.
- Current Shadow Help documentation describes local meeting capture and review plus optional, reviewable Meeting Skill outputs.
Interpretation
- The six-part brief and the proposed/agreed/not-confirmed state model are this article's operating framework.
- Separating evidence from approval makes a generated kickoff record easier to review and correct.
- Naming the governing artifact before the meeting helps prevent a summary from silently replacing it.
Unproven
- This article does not claim that AI improves project success, alignment, delivery speed, or decision quality.
- It does not claim that Shadow approves charters, verifies identities, assigns owners, or updates project systems automatically.
- A complete brief does not prove that the underlying project is authorized, feasible, funded, compliant, or likely to succeed.
Review the first five briefs
Before automating any destination, inspect five kickoff briefs manually.
| Check | Pass condition |
|---|---|
| Source recovery | A reviewer can find every material term in the meeting or governing artifact |
| State integrity | Proposals do not appear as agreements |
| Authority integrity | Approvals are tied to an authorized person or group |
| Scope integrity | Inclusions and exclusions survive the summary |
| Commitment integrity | Owners and dates are explicit, accepted, and not invented |
| Uncertainty retention | Assumptions, risks, dependencies, and open questions remain visible |
Track corrections by field. If authority or scope needs repeated repair, change the prompt and review process before adding automation.
If you want one reviewable record that connects what was said with what was shown on your Mac, download Shadow and test the template on one authorized kickoff. Keep the final project terms with the people who own them.
Sources and verification date
This article was researched and verified on October 13, 2026.
- PMI: The Project Charter: How to Authorize the Work and Align It to Strategy, September 23, 2026, for the boundary between AI drafting and human authority and for current charter fields.
- PMI: PMBOK Guide Sixth Edition, Develop Project Charter, for formal authorization, organizational-resource authority, and that edition's assumption-log output.
- PMI: How to uncover gaps in requirements through risk management, accessed October 13, 2026, for the assumptions, dependencies, risks, and issues distinction.
- Atlassian Team Playbook: Project Kickoff, accessed October 13, 2026, for purpose, roles, responsibilities, success markers, and its project-poster workflow.
- Asana: Project kickoff meeting: 10-step guide for success, updated September 25, 2026, for its charter-first sequence and scope, roles, actions, and central-source guidance.
- Shadow meeting review, Meeting Skills, privacy and data leaving your Mac, and recording consent, accessed October 13, 2026, for current product and data-boundary claims.
This article was written by Chad Oh, Shadow's AI writer. While we strive for accuracy, AI-generated content may contain errors. If you spot something off, let us know.