/setup-project-management

name: setup-project-management
description: Set up or repair a project's local context, source index, and optional dashboard. Use for a new project or an existing folder that needs organization for human and AI collaboration.

Setup Project Management

Public adaptation v1.2, 2026-11-10. Derived from the shared setup workflow v1.1 (2026-02-28), with a portable configuration and explicit local/Google Docs boundaries. This is an instruction workflow to adapt to available tools, not a bundled document API client or scheduler.

Scope and modes

Use the user's existing project folder and naming when possible. Handle research, writing, professional, and personal projects. Preserve explicit choices and approvals already made in the conversation.

• `discover`: inspect and report; no writes, including configuration or state.
• `plan`: discovery plus a proposed setup; no writes.
• `minimal`: establish the index, overview or link to its authority, and instructions needed to resume.
• `full` or an ordinary setup request: implement the agreed local structure and optional dashboard within the user's authorization.
• `dashboard`: initialize or configure the dashboard for an existing project; don't repeat unrelated folder setup.

An ordinary setup request combines discovery, structure choice, and initialization. Present the relevant structure and settle important open choices with the user before dependent changes: project type, naming, folders to initialize, and output destinations. Reuse choices already made in the conversation; do not repeat a questionnaire.

An answer to a discovery or scope question is not, by itself, approval of the implementation plan. Present the concrete files and destinations and obtain agreement before initialization, unless that plan is already authorized in the conversation.

A request to inspect does not authorize organization. A request to set up the project authorizes routine local additions needed for the agreed outcome; do not add approval gates for every file. Ask about consequential ambiguity, competing authoritative versions, moves affecting collaborators, or an unspecified shared destination before those dependent changes.

Discover the actual project

Read existing project instructions first. Inventory the bounded project folder, current drafts, source notes, handoffs, task lists, and linked documents. Identify who uses them, the current deliverable, and whether work is exploratory, active execution, or finishing. Different workstreams may be at different stages.

A project may span several folders named by the user. Inventory each selected location, retain the source path for each candidate current file, and distinguish the proposed project home from sources that will stay elsewhere. Record the repository URL and existing local checkout path where relevant; leave code in its established location unless the user requests a separate move.

Include early email correspondence in discovery. Ask: "Are there any names or email addresses I should search for correspondence about this project, including early discussions before it had a settled name?" Gather useful project aliases, subject lines, date range, and exclusions; reuse answers already supplied. Wait for the answer before searching email while continuing independent local discovery. Use available connected tools for a bounded, read-only search. Identify aims, participants, decisions, commitments, deadlines, and linked resources, with message dates and source links or IDs. Distinguish proposals from agreed decisions and verify project relevance when collaborators overlap. If the user declines or access is unavailable, report that gap and continue. Discovery does not send, draft, or modify messages.

Check actual access. For synced storage, verify selected working files can be opened; placeholders and document shortcuts aren't necessarily readable content. Record external locations and access gaps. Don't scan unrelated accounts, download an entire shared drive, move restricted data, or treat an inaccessible source as empty.

For a messy existing project, compare competing drafts and recover accepted decisions from available records. Distinguish suggestions, agreed plans, and completed work. Retain original files; propose moves and an archive map before reorganizing. When the authority is unclear, leave it unresolved for the user rather than using modification time as proof.

End a discovery report with unresolved decisions that need the user's judgment. When consolidation is requested, show a source-to-destination map before reorganizing; distinguish copies, moves, and archival, and identify filename collisions and competing versions. Apply the agreed changes only in an implementation mode, retain recoverable originals, and update affected links and the index. Reuse discovery findings and decisions already available in the conversation; recover missing findings before making changes that depend on them. Discovery itself saves no report or state. A separate request to save the findings authorizes that record only, not reorganization.

Choose a small structure

Read the bundled [project instructions template](assets/templates/project-instructions-template.md) and [TODO template](assets/templates/project-todo-template.md) when proposing the setup. Resolve these paths from the skill directory. The instructions template is a sanitized adaptation of an archived field checklist; map settings to the existing configuration or the shared project-config contract rather than maintaining duplicate authorities. The TODO template is a newly designed replacement, not a recovered original or a verified interface for other task-management skills. Populate either only within the agreed setup plan.

Prefer useful existing organization. Offer the relevant pattern and initialize the small set of empty folders the user expects to use soon. Let other workflows create additional destinations when needed:

• General proj