haipipe-project

name	haipipe-project
description	Run any project-level work in the haipipe workspace. Parses intent (build vs read vs modify) and dispatches to the right specialist (/haipipe-task for scaffolding tasks under examples/, /haipipe-project-inspect for review/summary/inventory/overview, /haipipe-project-organize for reorganizing files). Use for creating new projects/task-groups/task-folders (data / algo / training / eval / display / individual / agent) under examples/, auditing structure, generating docs, reorganizing. Trigger: project scaffold, new task, new figure task, new evaluation task, project review, project summary, organize project, reorganize files, /haipipe-project.
argument-hint	[function] [project_id] [args...]
allowed-tools	Bash, Read, Write, Edit, Grep, Glob, Skill
metadata	{"version":"1.0.0","last_updated":"2026-05-31","summary":"Run any project-level work in the haipipe workspace.","changelog":["1.0.0 (2026-05-31): baseline metadata added."]}

Skill: haipipe-project (orchestrator)

User-facing entry for project-level work. Routes by risk profile (build / read / modify) — the three specialists differ in allowed-tools and blast radius.

/haipipe-project                                          overview of all projects under examples/
/haipipe-project task                                     scaffold (asks: project / task-group / task-folder)
/haipipe-project task project <project_id>                scaffold a new project
/haipipe-project task task-group                          scaffold a new task-group
/haipipe-project task task-folder                         scaffold a new task-folder (asks task-type, dispatches)
/haipipe-project task task-folder <type> [args...]        scaffold task-folder of given task-type directly:
                                                            type ∈ {data, algo, training, eval,
                                                                    display, individual, agent}
/haipipe-project task run [task-path] [name]              scaffold a new run (asks _meta)
/haipipe-project review <project_id>                      structural audit
/haipipe-project summarize <project_id>                   generate summary doc
/haipipe-project inventory [project_id]                   file inventory
/haipipe-project overview [project_id]                    overview of one or all projects
/haipipe-project organize <project_id>                    reorganize files (modifies!)
/haipipe-project scan-status <task_dir> [key] [out_txt]   scan B01 eval, update status.json + txt
/haipipe-project "<natural language>"                     infer function, dispatch

---

Specialists

Lives in project/  (project-scope work):

  haipipe-project-inspect    READ:   review, summarize, inventory, overview (no writes)
  haipipe-project-organize   MODIFY: reorganize files (mv/rename, dry-run supported)

Lives in task/  (task-scope work — sibling section):

  haipipe-task               BUILD orchestrator: task-folder lifecycle + run scaffold +
                                     task-folder dispatch to the 7 type specialists below.
  haipipe-task-for-data          data-pipeline (Stage 1-4)           D-series  → /haipipe-data
  haipipe-task-for-algo          algo-dev smoke-test                 X_algo    → /haipipe-nn-algo
  haipipe-task-for-training      model training (Stage 5)            A-series  → /haipipe-nn-tuner+instance
  haipipe-task-for-eval          evaluation                          B-series  → (project-local; future)
  haipipe-task-for-display       paper figures / tables              C-series  → (independent)
  haipipe-task-for-individual    individual-centric query               E-series  → /haipipe-individual
  haipipe-task-for-agent         LLM agent call                      F-series  → (none yet)

(Per-run logging is automatic via runs/<NAME>.sh → results/<NAME>/runtime.yaml.
 For probe-level claims + aggregation, see probe/* skills.)

Conceptual layering — a project is the umbrella, containing five parallel worlds. Each world has its own specialist family:

📦 project (umbrella)            /haipipe-project              ← this skill
   │
   ├── 💼 tasks/                  /haipipe-task-*               (task/)
   │       "did THIS run work?"   — code + runs + per-run metrics
   │
   ├── 📊 probes/            /haipipe-probe           (probe/)
   │       "does the HYPOTHESIS   — steering state; NO code, only
   │        hold?"                  arms[] pointers into tasks/
   │
   ├── 💡 insights/               /haipipe-insight              (insight/)
   │       "what does the         — cross-probe synthesis
   │        PROJECT know?"          D/I/K/W markdown layers
   │
   ├── 📰 paper/                   /paper-*                     (separate section)
   │       "what claims ship      — consumes K/W from insights/
   │        to academia?"
   │
   └── 📬 applications/           /haipipe-application-*         (application/)
           "what do we deliver    — patient/clinician messages,
            to non-academic         UI sketches, stakeholder reports;
            audiences?"            reads insights/K + W (NEVER writes back);
                                   can TRIGGER /haipipe-insight ask to
                                   close knowledge gaps mid-draft

For the boundary between task and probe (the most-confused pair, since both touch results/), see probe/MENTAL_MODEL.md — onboarding doc with FAQ + "rules of thumb" + walkthrough of one probe's full lifecycle.

---

Two Structural Rules (cross-cutting; ref'd by all specialists)

Rule 1 — Three-level hierarchy (project → task-group → task-folder): examples/{PROJECT_ID}/tasks/ contains task-groups: {G}{NN}_{group_name}/ (e.g., A01_pretraining_clm/, B01_evaluation_clm/, C01_paper_figures/). Each task-group contains task-folders: {NN}_{task_name}/ (e.g., 01_train_clm_num_modelsize/ inside A01_pretraining_clm/). Each task-folder is self-contained: *.py, configs/, runs/, results/, notebooks/ (NO README.md — doc surface is diagram/). No flat task folders directly in tasks/ — they must be inside a task-group. Group letter convention: A=training (model-run), B=evaluation, C=display, D=data-pipeline, E=individual, F=agent, X=algo-dev (X_algo).

Rule 2 — Code always has a paired example: Every new pipeline Fn stub or ML model stub in Track A auto-generates a paired example task in tasks/.

These rules live in ref/project-structure.md and ref/code-structure.md, which all three specialists read.

---

Function Verb Map

project, new project, scaffold project        -> this skill, fn/project.md (project-scope)
task-group, new group, scaffold group         -> this skill, fn/task-group.md (project-scope)
task, task-folder, new task, scaffold task     -> haipipe-task (task/) — task-folder + below only
  (for scope=task-folder, -task dispatches to one of:
     haipipe-task-{data,algo,training,eval,display,individual,agent})
run, new run                                  -> haipipe-task (task/) — run scaffold
review, audit, check, validate, lint          -> haipipe-project-inspect (review)
summarize, summary, docs                      -> haipipe-project-inspect (summarize)
inventory, list files, files                  -> haipipe-project-inspect (inventory)
overview, show, status                        -> haipipe-project-inspect (overview)
organize, reorganize, fix structure, move     -> haipipe-project-organize
scan-status, scan eval, eval status           -> haipipe-project-inspect (scan-status)

(claims / probes / comparison: → /haipipe-probe under probe/)

---

Routing Logic

Step 1: Parse $ARGUMENTS.

Step 2: Resolve function via verb map.
  - If verb is unambiguous -> done.
  - If first positional looks like a project_id (matches an existing
    examples/{X}/) and no verb -> default to overview for that project.
  - If no args at all -> overview across ALL projects (umbrella inline).

Step 3: Decide specialist:
  - project / task-group scaffold        -> this skill (fn/project.md, fn/task-group.md)
  - task-folder / run scaffold           -> haipipe-task (in task/)
  - review/summarize/inventory/overview  -> haipipe-project-inspect
  - organize                             -> haipipe-project-organize

Step 4: Dispatch:
    Skill("haipipe-project-<specialist>", args="<verb> <remaining_args>")

Step 5: Capture the structured tail and present.

---

Cross-Project Overview (no-arg case)

When invoked with no arguments, list all projects under examples/ with a one-line status per project (task count, last-modified, violations flagged). Inline (no specialist dispatch needed for this lightweight view).

---

Disambiguation Rules

• Verb missing, project_id present -> default to overview for that id.
• Verb missing, no args -> cross-project overview (inline).
• organize without project_id -> ASK which project. Don't guess.
• Multi-project ops (e.g. "review all") -> dispatch sequentially per project.

---

Specialist Return Contract

status:    ok | blocked | failed
summary:   2-3 sentences on what was done
artifacts: [paths created / read / moved]
next:      suggested next command

---

Files Owned by This Umbrella

ref/project-structure.md   Track B layout (tasks/, configs/, runs/, results/, paper)
ref/code-structure.md      Track A layout (code-dev/, hainn/, haifn/) + paired-example rule

These ref files are SHARED across specialists. Each specialist reads them when its function depends on the rules. The inventory helper scripts (ref/inventory/*.py) live with haipipe-project-inspect since only that specialist uses them.

---

Feedback

/haipipe-project feedback "<text>" captures a complaint / confusion / wish about THIS skill into feedback/ (one dated file per item, status: open) to fix in a later revision pass. /haipipe-project feedback list shows the open items. This is feedback about the tool, not the work it produces. Route a feedback first-token here before other parsing. Full convention: feedback/README.md.