project · git:20261014.67a9e0a · 2026-10-14 · sha256 46f3fe72efcb7db9

project git:20261014.67a9e0aA

Immutable. This exact content never changes and is served at /api/v1/blob/46f3fe72efcb7db9.

---
name: project
description: >-
  Create or revise Obsidian Project notes for goals, decisions, open questions, and lessons. Use
  when the user wants a project thinking notebook or wants to close and archive one. Keep task
  tracking in its existing system; use only when a vault artifact is requested.
user-invocable: true
---

# Project

Keep a thinking record for a finite effort in the vault's live Projects location. Use it for goals,
decisions, questions, and lessons; link to the task tracker instead of duplicating it. Apply deadline
and metadata requirements only when the live schema defines them.

## Choose a mode

- Create: start a project thinking notebook.
- Update: capture a decision, question, thought, or lesson.
- Complete: done, stopped, or archive.

Ask when the mode is ambiguous.

## Create

### 1. Search and validate

Read `../vault/SKILL.md` and `AGENTS.md`, then discover and read the active Project template.
Search the live Projects location and inspect close matches before proposing a duplicate.

Confirm the work is a Project rather than an Area: it must be an active finite effort with a
checkable outcome. If it is an ongoing standard, propose an Area instead.

### 2. Understand the project

Ask no more than four concise questions in one structured batch when needed:

1. What are you trying to finish?
2. What have you decided, and why?
3. What questions are still open?
4. What thoughts or lessons are worth keeping?

Use answers already present in the conversation instead of asking again. Gather additional detail
only when the schema requires it.

### 3. Choose structure and preview

Default to one project file. Use a project folder only when the work already needs durable supporting
notes. Fill the live template with supported content; leave unanswered sections open rather than
inventing progress or commitments. Show the path, metadata, and complete draft before writing.

After approval, create through the `vault` safe-write flow, then verify the page and any separately
approved project-index link.

## Update

Resolve and read the canonical project note. Compare its recorded state with user-provided evidence.
Draft only the sections that changed and distinguish observed staleness from assumptions.

Show the exact change, obtain approval, update safely, and reread. Do not rewrite supporting or
human-owned notes without permission from `AGENTS.md` and the user.

## Complete

Confirm whether the outcome was achieved, deliberately stopped, or superseded. Offer a concise
retrospective before archiving. Preview:

- final status and outcome;
- lessons or decisions worth retaining;
- the live schema-defined archive destination;
- affected project-index links.

Approval to record completion is separate from approval to archive. Write the approved final state;
move the note only after the archive destination is explicitly confirmed. Update approved links and
verify both source absence and destination presence when a move occurs. Reusable knowledge stays in
Knowledge; project completion does not archive it.

## Completion

Report the canonical path, mode, confirmed outcome/state, writes performed, index changes, and any
unresolved schema or evidence gap.