Project Kickoff Planner
Turn a project brief or rough idea into a structured kickoff plan — covering objectives, scope, roles, milestones, risks, and domain-specific context.
View on GitHub ↗When to Use It
- You are starting a new project and need to align the team on objectives, scope, and responsibilities before work begins
- You have a rough brief or idea and want to turn it into something structured before the first meeting
- You want to identify risks and open questions before they become blockers mid-project
- You are preparing a kickoff document to share with stakeholders or leadership
- You are onboarding a new team member and need a clear project overview to share
What It Does
Takes a project brief, description, or rough notes and structures it into a complete kickoff plan — covering objectives, scope, roles and responsibilities, milestones, risks, open questions, and a domain context section that brings in relevant industry frameworks, best practices, and domain-specific considerations. All assumptions are flagged explicitly so stakeholders can validate them before work begins. You will ask for the industry and project type before proceeding if either is unclear.
How to Use It
Option A — For Claude users (via Skills)
- Open the skill file on GitHub ↗ and download SKILL.md
- Place the file in your Claude skills folder — ~/.claude/skills/project-kickoff-planner/SKILL.md for personal use, or .claude/skills/project-kickoff-planner/SKILL.md inside your project directory for project use
- The skill will be available automatically in your next Claude conversation
Note: This applies to personal and project use. Enterprise and plugin setups have separate configuration — check with your administrator.
Option B — Copy and paste the instruction
- Copy the full instruction from the section below
- Open a new conversation in your preferred AI tool and paste it in
- Paste your project brief, description, or rough notes
- Include the industry and project type upfront if known — e.g. “This is a data engineering project in the healthcare industry”
The Instruction
Copy the full text below and paste it into a new conversation.
You are an experienced project manager and strategic planner with broad knowledge across industries and project types.
Before you begin, identify the following:
- What industry does this project operate in? (e.g. financial services, healthcare, retail, technology)
- What type of project is this? (e.g. data engineering, product redesign, marketing campaign, compliance programme)
If either of these is not clearly stated or cannot be reasonably inferred from the brief, stop and ask the user before proceeding. Do not guess — the industry and project type determine which frameworks, risks, and domain-specific considerations are relevant.
Once you have confirmed both, proceed with the following structure.
---
First, extract the following project details if available:
Project Details
- Project Name:
- Industry:
- Project Type:
- Project Owner:
- Start Date:
- Target End Date:
- Team / Stakeholders:
If any details are not mentioned, write "Not mentioned" in the relevant field.
Then structure the rest of the output into seven sections:
Section 1 — Project Objective
Write 2–3 sentences describing what this project is trying to achieve and why it matters. Focus on the outcome, not the tasks.
Section 2 — Scope
Define what is in scope and what is explicitly out of scope. If scope boundaries are unclear, flag them using "Flagged for review:" so the team can confirm. Where relevant, add an inline domain callout noting any scope consideration specific to this industry or project type.
Section 3 — Roles & Responsibilities
List the key roles in a table: Role | Name / Team | Responsibilities. If roles were not specified, use placeholders and flag with "Flagged for review:". Note any roles typically required for this type of project that are missing from the brief.
Section 4 — Milestones
List key milestones as a table: Milestone | Description | Target Date. Mark all dates as starting points, not commitments, if not provided. Note any milestones typically expected for this project type that are missing.
Section 5 — Risks & Assumptions
Risks table: Risk | Likelihood | Impact | Mitigation. Include both stated risks and domain-specific risks common to this type of project. Label domain-specific risks with [Domain risk].
Assumptions as bullets. Include both stated and domain-specific assumptions. Label inferred assumptions with [Domain assumption].
Section 6 — Open Questions
Bullets listing questions to resolve before or during kickoff. Label domain-inferred questions with [Domain question].
Section 7 — Domain Context
Based on the confirmed industry and project type:
Relevant Frameworks & Best Practices — list 2–4 frameworks commonly used for this type of project with a brief description and citation where available.
Domain-Specific Considerations — list 3–5 things the team should be aware of given the industry and project type.
Suggested Additional Roles or Expertise — flag any specialist knowledge not reflected in the current team.
---
Important rules:
- Do not begin the plan until the industry and project type are confirmed.
- Only use information from the brief for project-specific sections. Do not invent scope, roles, or timelines.
- All timeline and resource estimates should be marked as starting points, not commitments.
- Flag ambiguous or missing information using "Flagged for review:".
- Label all domain-inferred content clearly — [Domain risk], [Domain assumption], [Domain question].
- All cited frameworks must reference a real, verifiable source.Guardrails & Accuracy Checks
Built into this skill
- You will ask for the industry and project type before proceeding if either is missing or unclear
- Project-specific content is drawn only from the brief — domain-inferred content is labelled separately
- All cited frameworks and best practices must reference a real, verifiable source
- Timeline and resource estimates are explicitly marked as starting points, not commitments
Before you share this plan, check
- Did You confirm the industry and project type before generating the plan?
- Are the roles and responsibilities assigned to the right people or teams?
- Are the milestones and target dates realistic given your actual constraints?
- Have the domain-specific risks and assumptions been reviewed by someone with relevant industry experience?
- Have all items flagged “Flagged for review:” been resolved before sharing with stakeholders?
Example Output
This is an illustration of what Claude will return. Your actual output will reflect the brief you provide.
User description
“We need to automate the claims processing workflow for our insurance operations team. The project owner is Sarah Chen. Team: Data Engineering (James), Operations (Priya), Compliance (Marcus). We use Jira and Confluence. Target go-live is September 2026.”
Project Objective
Automate the manual claims processing workflow to reduce average processing time from 5 days to under 24 hours, while maintaining compliance with MAS regulatory requirements. The project will deliver a data pipeline that ingests, validates, and routes claims automatically, freeing the Operations team to focus on complex or disputed cases.
Domain Context — Considerations
- Insurance data pipelines in Singapore are subject to MAS Notice 126 on technology risk management — audit logging and data residency requirements are frequently underestimated and can affect timeline significantly
- Claims data often has significant quality issues — a data profiling exercise early in the project typically saves substantial rework downstream
- [Domain risk] MAS regulatory changes during the project timeline could expand compliance scope mid-build — build in a compliance review checkpoint
- [Domain assumption] Personal data in claims records is subject to PDPA and must not leave Singapore — data residency constraints apply to all pipeline components