| name | mushanghai-experiment-leader |
| description | muShanghai Longevity Month 2026 experiment workflow. Use when a user needs proposal bootstrap, Track Leader review, approved-proposal participant SOP, consent + disclaimer document, or mid-experiment status handoff. Routes five modes: (A) Proposal Bootstrap, (B) TL Review, (C) SOP, (D) Consent, (E) Mid-experiment Status. Supports Longevity Month and BioBloom with unified May 19 proposal deadline. |
| when_to_use | Trigger phrases: 'draft my experiment proposal', 'help me write a proposal', 'Four Musts check', 'review this proposal', 'BioBloom proposal', 'seed hypothesis', 'Track Leader review', 'mushanghai proposal', 'longevity month experiment', 'experiment design help'. Do not trigger for participant daily-logging or daily reflection — those use mushanghai-participant-log. |
| allowed-tools | Read Write Glob |
muShanghai Experiment Leader
Valid for: May 2026 cycle. Update dates and track leads before any later reuse.
Prerequisite: Before doing anything else, read ../mushanghai-canon/references/safety.md and ../mushanghai-canon/references/four-musts.md. These hold the canonical safety policy and Four Musts text used by this skill. If they conflict with the repo's */ROLE.md files, the ROLE.md files win.
Mode router
When this skill triggers, FIRST surface the Safety + consent guardrails banner, then ask the user one routing question:
Which mode? (A) Proposal Bootstrap - draft a new experiment proposal from a seed hypothesis; (B) TL Review - review an existing proposal as a Track Leader; (C) SOP - Generate Participant SOP from an approved proposal; (D) Consent - Generate consent + disclaimer document; (E) Mid-experiment Status - prepare a traffic-light handoff for the Track Leader.
- If user says A / draft / propose / build -> run Mode A: Experiment Leader - Proposal Bootstrap
- If user says B / review / approve -> run Mode B: Track Leader - Proposal Review
- If user says C / SOP / participant script / approved proposal -> run Mode C: Participant SOP
- If user says D / consent / disclaimer -> run Mode D: Consent + Disclaimer
- If user says E / mid-experiment / status / blocker / revision ask -> run Mode E: Mid-experiment Status
After the banner, ask the routing question and enter the selected mode.
Mode A: Experiment Leader - Proposal Bootstrap
Guided Q&A. One question at a time. Goal: produce a proposal draft that survives Track Leader review.
Step 1 - Cohort + Track selection
Ask in one message:
Two questions before we dive in:
- Which cohort? (a) Longevity Month Experiment, May 19 - June 5, 5-14 day protocol max; (b) BioBloom Hackathon, May 17 - May 22, ~3-day sprint.
- Which track? (a) Decoding TCM (lead: Frank + Buddy); (b) Lifestyle (lead: Xiao He + Rebecca); (c) Proof of Living (Track Leaders: Natalia + Mariam; program-wide Build in Public leads: Sunny + Tang Ming).
If user picks BioBloom (1b), load and apply references/biobloom-variant.md - compresses Four Musts to fit ~3-day build window.
Step 2 - Capture the seed hypothesis
Ask:
What's your seed hypothesis or question? Plain English, one sentence. Example: "I think a 14-day evening Baduanjin protocol will measurably reduce my sleep latency."
If user gives a vague answer (<20 chars, no verb, just a topic like "TCM and sleep"), push back ONCE: "That's a topic, not a hypothesis. Can you give me a specific cause -> effect statement?"
Step 3 - Walk the Four Musts (one at a time)
Load ../mushanghai-canon/references/four-musts.md. Then ask each Must as a separate question:
- Problem - "What exactly are we answering? What pain point are we addressing?"
- Monitoring / Observation - "What will you measure or observe? With what instrument, framing, or lens?"
- Intervention / Interaction - "What is the simplest action you'll take?" - if user picked Proof of Living, accept "Interaction" in place of a scientific intervention. Populate Interaction with all four required hashtags + platform handles + weekly cadence per
../mushanghai-canon/references/proof-of-living.md.
- Deliverables - "What exactly will be produced and shown on Demo Day?"
After each answer, do a sanity check: is the answer concrete enough that a stranger could execute it? If not, ask ONE follow-up. Do not interrogate.
Step 4 - Assemble the proposal draft
Load assets/proposal-template.md. Fill it in with the user's answers. Default output path: experiments/<track>/<seed-name>.md in the user's working directory.
If user picked BioBloom cohort: before writing, ask one more question — "BioBloom requires every project to keep ≥ 3 open seats for newcomers through May 17–19. How many seats will you reserve, and how will you signal availability at the Recruitment Night?" — and append the answer to the proposal Operational Blueprint B1 (Roles).
Before writing the file, show the user the proposed file path and content for confirmation. Do not silently write.
Step 5 - Hand off to Track Leader
Output a 1-line message the user can copy into a chat / email to their Track Leader:
"My proposal for [track] is ready: [path]. Submitting by May 19 (unified deadline). Cohort: [Longevity Month | BioBloom]."
Remind user: Track Leader has final approve / revise / reject authority. This draft is a starting point, not a guarantee.
Mode B: Track Leader - Proposal Review
Used by Track Leaders to apply the canonical review checklist against a submitted proposal.
Step 1 - Locate the proposal
Ask:
Paste the proposal text, or give me a file path (e.g., experiments/decoding-tcm/baduanjin-sleep.md).
If file path given, use Read to load it. If pasted text, work directly with it.
Step 2 - Apply review checklist
Load assets/review-checklist.md. Walk every item. For each, mark green / yellow / red with a one-line reason.
Step 3 - Output decision
Produce a structured review in this format:
## Track Leader Review - [Proposal Name]
**Cohort:** [Longevity Month | BioBloom]
**Track:** [Decoding TCM | Lifestyle | Proof of Living]
**Reviewer:** [Track Leader name - user fills in]
**Date:** [today]
### Four Musts check
- Problem: 🟢 / 🟡 / 🔴 — [one-line reason]
- Monitoring/Observation: 🟢 / 🟡 / 🔴 — [one-line reason]
- Intervention/Interaction: 🟢 / 🟡 / 🔴 — [one-line reason]
- Deliverables: 🟢 / 🟡 / 🔴 — [one-line reason]
### Safety + consent
- [pass / flag + reason]
### Decision: APPROVE / REVISE / REJECT
[1-3 sentences explaining decision]
### Revision asks (if applicable)
1. [specific, actionable]
2. [specific, actionable]
Step 4 - Do not approve health-risky proposals
If proposal involves anything beyond lifestyle, breath, movement, or off-the-shelf wearables, automatically mark red on safety and require Track Leader to escalate to Month organizer or external mentor before approving. Do not rubber-stamp.
Mode C: Participant SOP
Generate Participant SOP from an approved proposal. Use only after a Track Leader has approved the proposal.
Step 1 - Confirm approval
Ask the EL to provide the approved proposal path/text and the Track Leader approval note. Confirm the proposal has TL green / approved status before generating participant instructions. If approval is missing, stop and route back to Mode B or the Track Leader.
Step 2 - Extract protocol details
Read the approved proposal and extract: cohort, track, dates, participant list or participant codes, monitoring signal, intervention/interaction, exact daily timing, devices, baseline needs, and deliverable. Load assets/preflight-checklist.md and flag any launch item that remains incomplete.
Step 3 - Generate per-participant daily script
Load assets/sop-template.md. Fill timing, who does what, and logging instructions for each participant. Include concrete timing such as 20:30 Baduanjin start when the proposal specifies it. Assign EL duties separately from participant duties. Tell participants to log daily with the mushanghai-participant-log daily template.
Step 4 - Output SOP file
Produce a participant-facing SOP for EL review at experiments/<track>/<seed-name>-sop.md. Before writing, show the proposed path and content for confirmation. The SOP must be operational, not motivational: timing, roles, logging, stop rule, and escalation path.
Mode D: Consent + Disclaimer
Generate consent + disclaimer document for an approved experiment before any participant data is collected.
Step 1 - Extract experiment-specific details
Ask for or extract: participant name/code, EL name, EL contact line, experiment title, cohort, track, dates, protocol action, what data is collected, what data is excluded, public-posting opt-in/opt-out, and withdrawal handling. If the withdrawal procedure is missing, use the no-questions-asked default from the template and ask the EL to confirm.
Step 2 - Add canonical disclaimer
Load assets/consent-template.md. Include the canonical disclaimer exactly: "This is for education, exploration, and self-observation. Not medical diagnosis or treatment." Keep public posting opt-in even for Proof of Living.
Step 3 - Output consent file
Produce the consent document at experiments/<track>/<seed-name>-consent.md. Before writing, show the proposed path and content for confirmation. Remind the EL that consent must be signed or explicitly confirmed by every participant before launch.
Mode E: Mid-experiment Status
Prepare a concise mid-experiment status handoff for the EL to send to their Track Leader.
Step 1 - Confirm timing and scope
Load references/mid-experiment-status.md. Confirm this is an active approved experiment. Use Mode E around day 3 of a 5-day sprint or day 7 of a 14-day protocol. For BioBloom, usually skip Mode E and use daily TL traffic-light checks instead.
Step 2 - Assess the Four Musts
Ask the EL for current state across the Four Musts: Problem still clear, Monitoring working, Intervention/Interaction adherence, and Deliverables on track. Assign 🟢 / 🟡 / 🔴 to each with a one-line reason. Do not downgrade safety, consent, or failed-monitoring concerns to green.
Step 3 - Surface blockers and revision asks
Load assets/mid-experiment-status.md. Capture current state, blockers, and revision asks. Revision asks must be specific decisions the Track Leader can approve, reject, or help unblock.
Step 4 - Output Track Leader handoff
Produce a completed status note for the EL to hand to their Track Leader. Include the overall 🟢 / 🟡 / 🔴, the Four Musts self-assessment, blockers, and the EL recommendation: continue, minor revision, pause and redesign, or stop.
Safety + consent guardrails (always active)
At the start of every session, BEFORE the first question, show this banner verbatim:
Before we start, do NOT paste:
- Identifiable health data (HRV with timestamps + location, blood labs, body weight, sleep records)
- Real names of other participants
- Other people's data without their explicit consent
- Details of medical conditions, pregnancy, or current medication
This skill helps you draft a proposal. It does not provide medical advice. All experiments under muShanghai Longevity Month are for education, exploration, and self-observation only - not diagnosis or treatment. High-risk interventions (anything beyond lifestyle, breath, movement, or off-the-shelf wearables) require Track Leader approval AND escalation to the Month organizer.
Load ../mushanghai-canon/references/safety.md for the full canonical safety + consent text. If the user pastes anything from the NEVER list, ask them to redact and continue.
References
Assets
