Project Template

{{ project }} work

The single hub for ongoing {{ project }} work: issues, ideas, open PRs, and session-to-session state, shared by every agent session and person that touches it. It is a memory surface, not a runbook: this skill records what is happening and what comes next; the work itself happens in your repo, your tools, and your data.

This body is a thin index. Don't grow it: new detail goes in a bundled file, and the body only gains a pointer.

First time here? Read SETUP.md and work through it. Delete it when done.

When resuming a session

1. Read HANDOVER.md: scan the Active workstreams table, then read only the section(s) your task touches.
2. Read issues/README.md for the backlog at a glance.
3. Pull ideas/README.md, open-prs.md, or roadmap.md only if the task touches them, and environment-notes.md before you run or query anything.

Logging work (the core job)

• Issue (bug, task, anything actionable) → new issues/NN-short-slug.md (next free NN) plus a line in issues/README.md.
• Idea (feature, improvement, someday/maybe) → new ideas/NN-short-slug.md plus a line in ideas/README.md. Promote to an issue when picked up.
• Field signal (what a user or customer actually said) → a dated block in field-feedback.md, newest first. Link the source; keep only the bullets that would change what you build.
• PR → open-prs.md while open (title and number, never a bare number); remove on merge with a CHANGELOG.md line.
• Any meaningful change → one line in CHANGELOG.md under today's date. It is a rolling {{ window_days }}-day window: trim entries older than that as you append. If a line wants a second sentence, that sentence belongs in the owning issue, idea, or notes file.
• End of session → overwrite your own section of HANDOVER.md. One ## section per active workstream; never touch another session's section; delete yours when the work lands.

Where does this fact go?

Ask in that order. The commonest failure is durable detail written into the changelog because the changelog is the file you were already editing.

Files

Pull a file with call skill-file-get {"skill_name": "<this skill's name>", "file_path": "<file>"} over the PostHog MCP.

Companions (link, don't duplicate)

• skills-best-practices (community skills store): the house patterns this layout follows, the Agent Skills spec checklist, and the write mechanics for editing store skills without losing content. Read it before restructuring this skill.
• working-with-skills and skills-store (ship with the PostHog MCP): the raw skill-* tool surface.
• Sibling hubs: when a second area of work needs its own hub, install project-template again under another name and cross-link the two here. One hub per area beats one hub that covers everything.

Posture

Tracking and memory surface only. Change code in the repo, run queries with the query tools, change configuration where it lives. This skill records the outcome and the next step.

Maintaining this skill

• Keep this body thin. New conventions or reference detail go in a bundled file.
• Use the smallest edit primitive (edits or file_edits on skill-update), chaining base_version between writes. A full-body rewrite for a one-line change silently drops content.
• Every meaningful edit gets a one-line CHANGELOG.md entry, and every changelog write also trims the window.
• Every session ends with your own HANDOVER.md section refreshed, or deleted if the work landed.
• Durable reference never goes in HANDOVER.md: nobody owns it there, so nobody prunes it. Put it in environment-notes.md or a new bundled file.