pm-seed

Runtime Configuration (Step 0)

Read ops/derivation-manifest.md for vocabulary. Read ops/config.yaml for processing depth.

EXECUTE NOW

Target: $ARGUMENTS

Parse immediately:

• If empty: seed from all known project documentation sources
• If path provided: seed from that specific file
• If "issues": seed from KNOWN_ISSUES.md only
• If "review": seed from the PROJECT_STATE_REVIEW report only
• If "security": seed from security audit reports only

START NOW.

Philosophy

The vault is only useful if it contains knowledge. /pm-seed closes the gap between "vault exists" and "vault is valuable."

When the PM knowledge system is first created, it is structurally complete but epistemically empty. The project has history — decisions were made, issues were discovered, sprints were run, architectural choices were documented — but none of it is in the vault yet. Every session without seeding is a session where the PM agent operates without institutional memory.

/pm-seed is the bootstrap operation. It reads existing project documentation and runs the same extraction logic as /pm-document, but with awareness that it is creating the initial corpus rather than enriching an existing one. The seeding process should be comprehensive — it is acceptable to err toward over-extraction here, since the /pm-retrospect loop will trim what doesn't prove useful.

/pm-seed is not a one-time operation. Run it whenever a major new source of project knowledge is added (a new audit report, a milestone post-mortem, a major architecture documentation).

Known Seed Sources

For this project, the following sources contain extractable decisions:

Workflow

1. Inventory Existing Decisions

Before seeding, understand what already exists to avoid duplicates:

for f in decisions/*.md; do
  [[ -f "$f" ]] && rg "^description:" "$f" | head -1
done

2. Read Each Source Fully

For each source file, read the entire content. Do not skim.

3. Extract with PM Categories

Apply the same extraction logic as /pm-document:

• Architectural decisions → decisions/ (type: architectural)
• Technology facts → decisions/ (type: tech-fact)
• Enforcement lessons → decisions/ (type: enforcement)
• Issue states → decisions/ (type: issue)
• Sprint records → decisions/ (type: sprint-record)
• Team patterns → ops/observations/
• Tensions → ops/tensions/

4. Batch Present for Approval

Since seeding can produce 20-50 decisions from a single source, group them by type and present in batches. Do not auto-create.

5. Create Approved Decisions

Use templates/decision-note.md for all decision types. Use templates/sprint-record.md for sprint records. Use templates/observation-note.md for observations.

6. Seed the Health Log

After seeding sprint records, populate ops/health/health-log.md with the health trajectory:

## Health Log

| Sprint | Health Before | Health After | Delta | Key Change |
|--------|--------------|-------------|-------|------------|
| 1 | 31 | 45 | +14 | Security remediation |

Output Format

## Seed Extraction Complete — [source file]

### Found
- Architectural decisions: N
- Technology facts: N
- Enforcement lessons: N
- Issue states: N (open: N, resolved: N)
- Sprint records: N
- Team patterns: N
- Tensions: N

[Grouped presentation by type — same format as /pm-document]

---
APPROVE batch? (yes/select/reject)

Seed Quality Standards

The same quality gates as /pm-document apply:

• Skip rate < 10% for project state reviews
• Every issue in KNOWN_ISSUES.md becomes an issue decision
• Every sprint mentioned in any document becomes a sprint-record decision
• Tech facts (QFTest casing, class names, Docker patterns) become tech-fact decisions

The vault after seeding should be immediately useful — a new session should be able to read decisions/ and understand the full project history without reading the raw source documents.