docs-project-management

TASKLANG TYPE SKILL

IDENTITY "Docs Project Management (the docs/-native system of record)"

A universal, reusable playbook for running a whole project — requirements, planning, build tracking, testing, bugs, and team reporting — as committed markdown inside the repo's docs/ folder. It works in ANY project, in any stack, from day one of a NEW project: no external issue tracker, no ticket system, no proprietary tooling. A work item is a markdown file with YAML frontmatter; a relationship is a relative markdown link; a status change is a frontmatter edit; the full history is git.

It does three jobs:

1. WORK-ITEM MODEL — WHAT document types exist (PRD, TRD, Epic, User Story, Test Case, Bug, Roadmap), WHERE each lives, HOW they link, and HOW status is tracked.
2. TEAM WORK-REPORTING — HOW every agent/contributor reports its work so anyone can see, in one committed place, everything that was done (who, what, when, with which evidence).
3. DURABLE vs TEMPORARY — WHAT belongs in committed docs/ versus the git-ignored .ai_log/ temp-evidence folder, and when to promote content from one to the other.

§1 Document types — WHAT the system manages

Every work item is a committed markdown file in its docs/ subfolder: descriptive kebab-case filename (never an opaque ID), YAML frontmatter for status/metadata, relative-markdown links for relationships. Full field-level detail: [[work-item-taxonomy]].

TABLE document-types COLUMNS: Type, Lives in, What it is / holds ROW: Project brief | docs/project_brief.md | The product spec — the SOURCE OF TRUTH the whole project derives from; wins over any assumption ROW: Project config| docs/project_config/info.md | The single home for project-specific FACTS (product name, app name, stack, domain, scope, success scenarios) — agents read it instead of hard-coding facts ROW: Roadmap | docs/ROADMAP.md + docs/roadmap.json | The milestone/release plan (human file) + a machine-readable MIRROR of every work item's current status (JSON cache, regenerated from docs/, committed) ROW: PRD | docs/prd/ | Product Requirements Document — WHAT to build and WHY: objectives, in-scope / out-of-scope, testable acceptance criteria per success scenario ROW: TRD | docs/trd/ | Technical Requirements Document — HOW to build it: architecture, data model, migrations, jobs, authz. Canonical TRD home; keep index.json (machine registry, one entry per TRD) + index.md (human index) beside the files ROW: Epic | docs/epics/ | A large feature/theme grouping related User Stories; carries goal + scope + its story list ROW: User Story | docs/user_stories/ | The smallest shippable requirement — "as a I want " + numbered acceptance criteria; filename NNN-<kebab-title>.md ROW: Test Case | docs/test_cases/ | A verification script for ONE behavior — numbered navigate→action→expected steps; filename tc-NNN-<kebab-behavior>.md; MUST follow the [[test-case-template]] and link its story "is tested by" ROW: Bug | docs/bugs/ | A defect AND its Root-Cause-Analysis in ONE file — Symptom/Reproduction + 5-Whys RCA + Preventative Action at detection; Fix/diff/Resolved sections completed by whoever fixes it ([[bug-rca-report]]); blocks its story ROW: Session report| docs/sessions/-/ | Per-run team work folder — a README manifest + one bookended report per agent/phase ([[session-reporting]]) ROW: Feature log | docs/reports/feature-log.md + feature-log/ | The team work-log split by feature: one lean index row per feature, linking a per-feature file where each run appends a row

RULES - Filenames: descriptive kebab-case, never opaque IDs. External refs (ticket numbers), when they exist, go in frontmatter + the title line — not the filename. - Each subfolder may carry a template_<type>.md seed; new items copy its shape. - Only APPROVED/final content advances status; drafts stay in their lifecycle state.