personal-project-planner

Files (1)

• SKILL.md

SKILL.md (first lines)

# Personal Project Planner

Use this skill when the user wants to build a personal tool, script,
automation, bot, dashboard, extension, or other side project for their own
use rather than as a business.

This is an early-stage skill.
It fits best inside:
- `Opportunity framing`
- `Solution shaping`
- early `Prototype`

This skill should bias toward simplicity and actual shipping.

## Output modes

Choose one output mode before writing back.

### `Status-surface`
Use when:
- there is no repo yet
- the user wants comments and lightweight feedback
- the project is still being scoped

Write to one canonical status surface. That surface may be Notion, Confluence,
markdown, a tracker record, or another durable workspace. Do not treat the tool
choice as the operating model.

Minimum top block:
- `Status`
- `Stage`
- `Freshness`
- `Last reviewed`
- `Next decision`
- `Owner`
- `Canonical repo`
- `Execution surface`

Recommended sections:
1. `Summary`
2. `What this is`
3. `Who it is for`
4. `Why it matters now`
5. `Simplest version`
6. `Dependencies and blockers`
7. `Scope cuts`
8. `Current recommendation`
9. `Next decision`
10. `Next action`

If the chosen status-surface tool is unavailable, produce structured markdown so
it can be pasted into the canonical concept surface.

### `Repo-writeback`
Use when:
- a repo exists
- a bounded first build slice exists
- implementation is starting

Write to the repo's live project-doc surface and keep the external status
surface as summary, review, comment, run-dispatch, and human-decision support
rather than a second execution surface.

## Read path

Use the repo's live project-doc surface.
The default layout is `docs/`, but follow any repo-local override declared in
`AGENTS.md`.

Read only the smallest sufficient context:
1. `project-spine.md` on the live project-doc surface if it exists
2. `current-milestone.md` on the live project-doc surface if it exists
3. `open-questions.md` on the live project-doc surface only if needed
4. `session-brief.md` on the live project-doc surface only if needed

If the repo is not yet initialized:
- use the user's prompt as the working source
- prefer `Status-surface` output mode
- switch to `Repo-writeback` once the repo exists

## Goal

Turn a personal itch into:
1. the simplest version worth building
2. a clear technical approach
3. a bounded build spec or first milestone that can be handed off cleanly

## Phase 1 — Clarify and cut scope

Trigger:
- the user describes something they want to build for themselves
- the user describes a workflow problem they want to automate

Do:
- restate what is actually being built
- choose the most likely interpretation if the prompt is ambiguous
- define the simplest version that would genuinely solve the problem
- identify needed data, APIs, permissions, runtime, and setup
- identify blockers and likely showstoppers early
- list explicit scope cuts for version one

Keep this lean.
Do not let a personal tool inflate into a product roadmap.

## Phase 2 — Approach and components

Trigger:
- the user confirms the interpretation
- or says to proceed

Do:
- recommend a stack and runtime based on speed and simplicity
- define a one-sentence architecture
- identify a credible alternative only if it materially changes effort
- break the build into small components
- identify the few design decisions that actually matter

Prefer local, simple, and low-ops defaults unless the user clearly needs more.

From armin-haghi/llm-os, MIT.

More from armin-haghi/llm-os