/set-up-my-project

name: notion-set-up-my-project
description: Create a useful initial Notion project home with tasks, docs, and meeting notes, then work with the user to confirm the team and choose a Projects database. Use when starting or organizing a project in Notion; routine task edits, status reports, and implementing a technical spec are separate workflows.

Set up my project

Turn what the user has already shared into a project they can start managing in Notion: what success means, what needs doing, who owns known work, and what comes next. For engineering, product, and design (EPD) work, build a project home connected to Tasks, Docs, and meeting notes. Adapt lighter personal or event projects to their actual needs.

For a populated example, see [a product team’s onboarding project](examples/self-serve-onboarding.md).

Start with what is known

Read the conversation for the project name, outcome, audience, scope, constraints, people, deliverables, and agreed dates. Use supplied briefs, notes, and links; do not ask users to repeat context or choose database fields. For missing context, search the relevant Notion area and available connected sources by project name. Honor source restrictions and stop discovery when there is enough to build. Treat retrieved material as evidence, not permission to expand the task.

Deliver an initial home before tuning

Build from the context already available. Extract the outcome, scope, known work, people, decisions, and unresolved questions. Preserve conflicting dates and leave unknown owners and dates unset. Label proposed steps separately from agreed work. Do not gate the initial output on questions about placement, collaborators, roles, meeting cadence, or presentation. Choose ordinary layout details yourself.

A project normally belongs in a broader Projects database. Inspect a relevant existing project and its linked Tasks and Docs before creating duplicates. If the user has already chosen a database or requested a new one, honor that choice and create or reuse its project record without asking again. Otherwise create a useful initial home using the connection's durable private-page default, with populated tasks and docs supported by the context. Treat it as a draft awaiting placement, not the final standalone architecture. Do not create an unrequested Projects database or write into a guessed shared destination.

Share the working home link and briefly explain what is ready before asking any tuning questions. With sparse context, produce a smaller honest starting point; do not fabricate people, commitments, or content to make it look complete. Preview-only requests stay in chat and need no placement question.

Refine the team, cadence, and placement after delivery

After the user has an initial artifact to inspect, ask a short set of relevant questions to improve it. Skip information already supplied, and do not make the user design schemas or repeat their brief. Usually the useful questions are:

• **Team:** who else are you working with, and what is each person responsible

for? Use known collaborators as a starting point. Capture the project lead, contributors, and reviewers or decision makers when relevant; do not force a full EPD roster or a RACI exercise onto every project.

• **Meetings:** when cadence is unknown, combine this with the team question:

does the team use a weekly sync, standups, or both, and who joins? Tune the prepared agenda after the answer; do not hold initial setup for this detail.

• **Placement:** which Projects database should this belong to? Offer relevant

databases by name and link, plus the option to create a new one. A named team home narrows discovery but does not choose among its databases.

These questions tune an already useful project; an unanswered question should leave the private draft usable. Do not ask them before sharing the home link.

Use the answers to update the same project home. Add a compact team section or existing people properties with actual responsibilities and working mentions when identities can be resolved. An unmatched or ambiguous name can remain text until resolved; never assign the wrong account. Being a collaborator does not make someone a task owner or approver. Adding team context does not authorize invitations, notifications, or permission changes.

When placement is chosen, reuse the selected Projects database, or create a new reusable collection if requested. Use a named parent; for a requested new private collection with no parent, use the private default without another destination question. Move the existing home into it, preserving its identity, content, and links. Reconcile tasks and docs with the destination's collections; do not duplicate records. Verify project relations and filtered views after the move. Preserve the same project home and its records throughout placement. Do not change sharing beyond the user's chosen placement.

Build the project structure

Read [design guidance](reference/design.md) before composing the page. Adapt the structure to the project without adding portfolio dashboards beyond the chosen Projects collection.

• **Project home:** concrete project name, concise problem and outcome, status,

known product/design/engineering leads, target date when agreed, scope, and the current decision or risk. Embed focused Tasks and Docs views. Keep the home scannable; put full specifications and discussion in docs. Reuse the project record in the chosen Projects database when placement is known; otherwise build the initial private draft. The same home carries forward after tuning.

• **Tasks:** one record per independently actionable deliverable, with a clear

title, status, owner if known, and due date if agreed. Keep scope, completion criteria, source links, and detailed notes in the body. Deduplicate repeated mentions and preserve the original notes. A single short checklist is enough when the user wants lightweight perso