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 (PostToolUse verify-refs hook blocks instead of warns). New projects on or after 2026-04-24 should pass --ssot. Legacy in-flight projects stay on project.yaml until /manage-project migrate-ssot is run.
• --zotero-collection NAME -- Optional. Create a new Zotero collection with NAME via pyzotero and populate library_id + collection_key in the contract. Requires env vars ZOTERO_API_KEY + ZOTERO_LIBRARY_ID (and optionally ZOTERO_LIBRARY_TYPE, default user). Graceful degrade: if pyzotero is not installed or credentials are missing, the contract is scaffolded with library_id: null / collection_key: null and a WARN is printed.

SSOT template substitutions: {{PROJECT_ID}} → {name}, {{PROJECT_TYPE}} → 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 — populated manually when the owner links an existing Zotero collection.

Implementation: /manage-project init is backed by scripts/init_project.py. Invoke directly when running outside the skill harness:

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

(Run from the medsci-skills repo root.)

The helper writes the contract file (SSOT.yaml with --ssot, otherwise legacy project.yaml), the directory scaffold, minimal stubs required by scripts/validate_project_contract.py (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 — the migrate pipeline is responsible for that marker.

What it creates:

{name}/
├── paper/
│   ├── main.qmd               <- Main manuscript (Quarto)
│   ├── sections/
│   │   ├── abstract.qmd
│   │   ├── introduction.qmd
│   │   ├── methods.qmd
│   │   ├── results.qmd
│   │   ├── discussion.qmd
│   │   └── conclusion.qmd
│   ├── figures/
│   │   └── .gitkeep
│   ├── tables/
│   │   └── table_shells.md    <- Table structure designed before prose
│   └── supplementary/
│       └── .gitkeep
├── analysis/
│   ├── scripts/
│   │   └── .gitkeep
│   └── outputs/
│       └── .gitkeep
├── references/
│   ├── library.bib
│   └── checklist_{GUIDELINE}.md  <- Loaded from /check-reporting
├── revision/
│   └── .gitkeep
├── submission/
│   └── .gitkeep
├── PROJECT.md                <- Project identity and scope
├── STATUS.md                 <- Current phase, blockers, next actions
├── CLAIMS.md                 <- Claim-to-result map
├── DATA_DICTIONARY.md        <- Variable and outcome definitions
├── ANALYSIS_PLAN.md          <- Primary/secondary analyses
├── REVIEW_LOG.md             <- Reviewer comments and responses
├── project_state.json         <- Progress tracking
└── README.md                  <- Project overview

Also creates project_state.json:

{
  "name": "{name}",
  "type": "{type}",
  "journal": "{journal}",
  "created": "YYYY-MM-DD",
  "target_submission": null,
  "current_phase": 0,
  "phases": {
    "0_init": "complete",
    "1_outline": "pending",
    "2_tables_figures": "pending",
    "3_methods": "pending",
    "4_results": "pending",
    "5_discussion": "pending",
    "6_intro_abstract": "pending",
    "7_polish": "pending"
  },
  "word_counts": {
    "abstract": 0,
    "introduction": 0,
    "methods": 0,
    "results": 0,
    "discussion": 0,
    "total": 0
  },
  "checklist_status": "pending",
  "citation_status": "unverified",
  "revision_round": null,
  "memory_files": {
    "PROJECT.md": true,
    "STATUS.md": true,
    "CLAIMS.md": true,
    "DATA_DICTIONARY.md": true,
    "ANALYSIS_PLAN.md": true,
    "REVIEW_LOG.md": true
  }
}

/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.

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

Generate a pre-submission checklist covering all quality dimensions.

Output: submission/pre_submission_checklist.md

Read and output the pre-submission checklist from ${CLAUDE_SKILL_DIR}/references/pre_submission_checklist.md.

`/manage-project timeline {submis