manage-project

# Manage-Project Skill -- Research Project Management

## Purpose

Scaffold new research projects, track manuscript writing progress, maintain lightweight project memory, generate pre-submission checklists, and create backwards submission timelines. Integrates with all other writing skills and the project-manager agent.

---

## Commands

### `/manage-project init {name} --type {type} --journal {journal} [--ssot] [--zotero-collection NAME]`

Create a complete project scaffold for a new research paper.

**Parameters:**
- `{name}` -- Project identifier (e.g., `nnunet-skull-fracture`, `rfa-meta-analysis`)
- `--type` -- Paper type: `original | meta | case | animal | technical | ai_validation | letter`
- `--journal` -- Target journal: `RYAI | AJR | Radiology | European_Radiology | KJR | INSI | AJNR | generic`
- `--ssot` -- Emit `SSOT.yaml` (schema v1) from `templates/SSOT.yaml.template` instead of legacy `project.yaml`. Required for Phase 1C auto-enforce (the PostToolUse verify-refs hook blocks instead of warns). New projects should pass `--ssot`; legacy in-flight projects stay on `project.yaml` until `/manage-project migrate-ssot` is run.
- `--zotero-collection NAME` -- Optional. Create a Zotero collection via pyzotero and populate `library_id` + `collection_key` in the contract. Requires `ZOTERO_API_KEY` + `ZOTERO_LIBRARY_ID` (optionally `ZOTERO_LIBRARY_TYPE`, default `user`). **Graceful degrade:** with pyzotero missing or credentials absent, the contract is scaffolded with `library_id: null` / `collection_key: null` and a WARN is printed.

**SSOT template substitutions:** `{{PROJECT_ID}}` → `{name}`; `{{PROJECT_TYPE}}` → the SSOT
`project_type` enum mapped from `--type` (`original → original_research`, `meta → meta_analysis`,
`case → case_report`, `ai_validation → ai_validation`, else `other`). Without
`--zotero-collection`, `library_id` / `collection_key` stay `null` until the owner links an
existing collection.

**Implementation:** backed by `scripts/init_project.py`. Invoke it directly when running outside
the skill harness (from the `medsci-skills` repo root):

```bash
python3 scripts/init_project.py \
    --name {name} --type {type} --journal {journal} [--ssot] \
    --project-root {target_dir}
```

The helper writes the contract file (`SSOT.yaml` with `--ssot`, else legacy `project.yaml`), the
directory scaffold, the minimal stubs `scripts/validate_project_contract.py` requires
(`manuscript/index.qmd`, `artifact_manifest.json`, `qc/status.json`), the memory-file templates,
and `project_state.json`. **`qc/migration_complete` is NOT written by init** — that marker belongs
to the migrate pipeline.

**Do not hand-build the scaffold.** The script is the source of truth for the tree and for
`project_state.json`; a hand-built one drifts from what the contract validator expects.

**Read on demand:**

| File | Read it when | Cost if read blindly |
|---|---|---|
| `references/init_scaffold.md` | you need to know where a scaffolded file lands, or what a `project_state.json` field means | ~1,400 tokens describing output the script already produces for you |

---
### `/manage-project migrate-ssot [--no-mark-complete]`

Thin wrapper over `scripts/migrate_project_to_ssot.py` that converts a legacy `project.yaml` project into SSOT.yaml form and, by default, touches `qc/migration_complete` so Phase 1C `auto` mode switches from `warn` to `enforce`.

```bash
python3 scripts/migrate_project_to_ssot.py \
    --project-root . --write --mark-complete
```

- Default: `--write --mark-complete` (enforce-ready).
- `--no-mark-complete` flag form: run with `--write` only. Use when the project still has open QC failures — enforcement is deferred until the migration is validated.
- The migrate script refuses to touch `qc/migration_complete` unless the generated SSOT.yaml passes `validate_project_contract.py` AND `contract_mode=ssot`. Do not `touch qc/migration_complete` manually.

Re-run after resolving failures; the script is idempotent.

---

### `/manage-project status`

Report current progress. Reads `project_state.json`, scans existing files, and checks whether key project memory files are present and aligned.

**Output format:**

```
## Project Status: {name}
Journal: {journal} | Type: {type} | Created: {date}
Target submission: {date or "not set"}

### Phase Progress
[check] Phase 0: Project Init (complete)
[check] Phase 1: Outline (complete)
[check] Phase 2: Tables & Figures (complete)
[work]  Phase 3: Methods (IN PROGRESS)
[wait]  Phase 4: Results (pending)
[wait]  Phase 5: Discussion (pending)
[wait]  Phase 6: Introduction & Abstract (pending)
[wait]  Phase 7: Polish (pending)

### Word Counts
Abstract:     0 / 250 words
Introduction: 0 / 600 words
Methods:      847 / 1000 words  85%
Results:      0 / 900 words
Discussion:   0 / 800 words
Total:        847 / 3500 words (journal limit)

### Quality Gates
Critic score (Methods): 87/100 PASS
Citations verified: 12/12
Reporting guideline: pending

### Project Memory
PROJECT.md: present
STATUS.md: stale (last updated 12 days ago)
CLAIMS.md: missing
DATA_DICTIONARY.md: present
ANALYSIS_PLAN.md: missing
REVIEW_LOG.md: n/a (not in revision)

### Next Steps
1. Complete Methods draft (150 words remaining)
2. Run /analyze-stats for Table 1 and diagnostic accuracy
3. Begin Results (Phase 4)
```

### `/manage-project sync-memory`

Audit and refresh project memory files so other agents can work with less ambiguity.

**What it does:**
- checks for presence of `PROJECT.md`, `STATUS.md`, `CLAIMS.md`, `DATA_DICTIONARY.md`, `ANALYSIS_PLAN.md`, `REVIEW_LOG.md`
- identifies stale or contradictory project metadata
- proposes the minimum files to create or update
- aligns `project_state.json` with the current manuscript phase

**Suggested use cases:**
- before handing the project to `project-manager`
- before a large revision cycle
- when returning to an old folder after weeks or months
- when multiple collaborators are editing in parallel

---

### `/manage-project checklist