Skill Claude

Docs Project Management

docs-project-management/

2 views 0 downloads

Manage a whole project inside the repo's docs/ folder: roadmap, PRDs, epics, user stories, test cases and bugs as linked Markdown files with a status lifecycle. No issue tracker needed.

Docs Project Management: Brain Lab skill for Claude Code

Run an entire project from the repo's docs/ folder, no external issue tracker, no ticket system.

Why use it

Project state lives in a tracker the code doesn't know about, and the two drift apart the day after kickoff.
Agents invent their own folders, link wording and status values, so nothing cross-references.
"What was actually done?" has no answer that a reviewer can read in the diff.

What it does

The work-item taxonomy: roadmap → PRD → TRD → epics → user stories → test cases → bugs, each in its own docs/ folder.
The link graph as relative markdown links, user story part of epic, test case is tested by story, bug blocks story, PRD↔TRD.
The YAML-frontmatter status lifecycle + the bookend rule: move status: forward when you start, again when you finish.
The mandatory test-case template and the bug + RCA report format.
The team work-reporting convention: one session folder per run, every agent bookends a start/completion report there.

Benefits

Your tracker ships with your code. Work item = markdown file. Status = a diff. History = git.
Nothing drifts. Requirements, tests and bugs live next to what they describe.
Reviewable progress. "What got done?" is answered by the PR itself.
Still navigable at 300 files, because every agent writes to the same model.
Zero tooling cost. No tracker, no license, no sync job, day one of a new project.

Install

Download this skill and copy the docs-project-management folder to .claude/skills/docs-project-management/ in your project, or to ~/.claude/skills/docs-project-management/ to use it in every project. Claude Code finds it on its own; you can also call it with /docs-project-management.

Part of the Agent Engineering bundle. To get the whole set as a Claude Code plugin: /plugin marketplace add endorphin-ai/hasbrains-agent-kit, then /plugin install agent-engineering@hasbrains-agent-kit.

Source: endorphin-ai/hasbrains-agent-kit. License: MIT.

Files (16)

---
id: status-lifecycle
title: Status Lifecycle + the Bookend Rule (docs/-native)
summary: The frontmatter status lifecycle, the bookend rule (transition forward before + after work), required frontmatter fields, and the passport signature.
tags: [docs-pm/status, docs-pm/frontmatter, docs-pm/model]
load_when: When starting or finishing work on a work item, setting its status, or filling required frontmatter fields.
links: [[work-item-taxonomy]], [[link-graph]], [[session-reporting]], [[conventions-recap]]
---

# Status Lifecycle + the Bookend Rule (docs/-native)

> Status lives in the file's YAML frontmatter `status:` field. There is no tracker transition —
> changing status = EDITING that field. Bookend BOTH ends of work: forward before starting, again
> when done.

LIFECYCLE status
  VALUES: backlog → ready → in_progress → in_review → qa → done   (blocked is an orthogonal flag)
  > Pick the closest value for the item type; not every item walks every step. A Bug uses
  > open → in_progress → fixed → verified → closed. A Test Case uses draft → ready → automated.

BOOKEND both-ends
  - ON START — set `status: in_progress` (forward) on the work item(s) you are about to touch, BEFORE
    doing the work; record the date in `updated:`.
  - ON COMPLETION — set `status:` to the next appropriate state for your role (e.g. `in_review`,
    `qa`, `done`), and stamp `updated:`.
  - NEVER leave the status unchanged across a phase — a file you worked that still reads its old
    status is an incomplete bookend.

REQUIRED FRONTMATTER (per item type — fill all; mark n/a only where genuinely inapplicable)
```yaml
---
title: "001 User Registration"        # human title; carry the external ref when one exists
type: user_story                       # epic | prd | trd | user_story | bug | test_case
status: in_progress                    # per the lifecycle above
ref: TICKET-15                         # external work-item ref when one exists, else n/a
assignee: <agent-or-person>            # who is currently responsible
created: 2026-06-27
updated: 2026-06-27
links:                                 # relative-markdown links per the link graph (epic / prd / trd / tests / blocks …)
  epic: ../epics/membership-billing.md
  is_tested_by: ../test_cases/tc-001-registration-flow.md
---
```

SIGNATURE (every update)
  - Sign every file update / report entry with the passport line:
    `— <agent-name> v<version> (<passport-id>)`   e.g. `— qa v2.0 (qa-agent-001)`.

> The `links:` field follows the [[link-graph]] semantics; the items themselves live per
> [[work-item-taxonomy]]. The status bookend pairs with the per-run report bookend in
> [[session-reporting]].