neuroflow-core

name	neuroflow-core
description	Core rules and lifecycle for all neuroflow commands and agents. Read this whenever running any neuroflow command to understand the .neuroflow/ folder structure and the required behaviour at the start and end of every command.

neuroflow-core

Defines the shared structure and lifecycle that every neuroflow command and agent must follow.

Global ~/.neuroflow/ structure

~/.neuroflow/ (Unix/Mac) or %USERPROFILE%\.neuroflow\ (Windows) is the user-level neuroflow home. It lives on the machine, not inside any project repo. It is never committed anywhere.

~/.neuroflow/
├── user.yaml                        ← flowie_handle, global prefs
├── flowie/                          ← ONE global clone of github.com/{handle}/flowie
│   ├── profile.md
│   ├── ideas.md
│   ├── sync.json
│   ├── integrations.json            ← custom LLM, MCP tokens (never committed)
│   ├── projects/
│   ├── tasks/
│   ├── notes/
│   ├── wellbeing/
│   └── wiki/
└── hive/
    └── {org-repo}/                  ← one cache per hive membership
        ├── hive.md
        ├── members.md
        ├── ideas.md
        └── sync.json

Key rules:

• ~/.neuroflow/flowie/ is a git repo (.git/ inside) — cloned once, shared across all projects
• ~/.neuroflow/hives/{org-repo}/ is a shallow clone or fetch cache — one per hive the user belongs to
• integrations.json lives in ~/.neuroflow/flowie/ only — never in project .neuroflow/
• Neither flowie/ nor hive/ ever appears inside a project's .neuroflow/

---

.neuroflow/ folder

.neuroflow/ is project memory. It lives at the root of the user's project repo.

Rule: .neuroflow/ root contains only the files and folders explicitly listed in the tables below — nothing else. Never place any file or folder directly in .neuroflow/ unless it appears in the "Root files" or "Root folders" tables. All workflow content belongs in the appropriate phase subfolder (.neuroflow/{phase}/). External deliverables, polished reports, or any user-facing outputs go in the project root or report/.

Root files

File	Purpose
project_config.md	Short dense overview: current phase(s), research question, modality, tools, output paths, collaborators. Must include plugin_version — always mirrors the neuroflow plugin version from plugin.json. Read this first. Update when phase changes. Contains collaborators: list (name, email, handle per entry) and flowie_profiles: list — used by /phase to auto-sync phase changes to the project registry. Contains hive_repo: if project is connected to a team hive.
flow.md	Index of all subfolders: one row per folder with name, description, date of last change.
objectives.md	Project objectives/aims — one numbered sentence per objective. Cross-phase cornerstone: read at the start of every command (if it exists), keep objectives in context throughout the session, and explicitly check coverage before saving any major section. Written during /grant-proposal interview or /ideation.
sentinel.md	Sentinel's last audit report. If all clear: last run date + "all clear".
timeline.md	Milestones and deadlines.

Optional project_config.md fields

Field	Type	Description
collaborators	Optional list	Project team members. Each entry: name, email, handle (GitHub). Used by /meeting for calendar invites. Replaces legacy team.md.
flowie_profiles	Optional list	Flowie profiles linked to this project. Each entry has handle (GitHub username) and repo ({handle}/flowie). First entry = project owner; additional entries = collaborators who have run /flowie --link on this repo. Used by /phase to sync phase changes to each linked flowie registry. Example: - handle: alice\n repo: alice/flowie
hive_repo	Optional string	GitHub org/repo of the team hive this project belongs to. Example: acme-neuroscience/hive-lab

Root folders

Folder	Purpose
sessions/	One .md per day (YYYY-MM-DD.md). Local only — add to .gitignore.
reasoning/	Structured per-phase decision logs (JSON files with statement, source, reasoning). Has its own flow.md. Created on first use.
ethics/	IRB documents, consent forms.
preregistration/	Pre-registration documents (OSF, AsPredicted).
finance/	Grant documents, expense tracking.
fails/	Dissatisfaction log — three fixed files: core.md (plugin behavior problems), science.md (scientific quality problems), ux.md (interaction quality problems). Created on first /fails run.
output/	Output log — one .md per export run recording scope, format, destination, and excluded files. Created on first /output run.
{phase}/	One subfolder per pipeline command (e.g. ideation/, experiment/, data/). Each has its own flow.md and at least one .md memory file written by the command.

Rule: only command names may be used as phase subfolder names. Skills must never create their own named subfolders inside .neuroflow/. All skill memory must be written to the active command's phase subfolder (.neuroflow/{phase}/). Creating a subfolder named after a skill (e.g. .neuroflow/review-neuro/) is a structural error.

flow.md format

flow.md is a pure index table — one row per file or folder, nothing else. Never write narrative content, mappings, notes, or cross-references directly into flow.md. Add a dedicated .md file to the phase subfolder and list it as a row instead.

Every subfolder must contain a flow.md with this format:

| File / Folder | Description | Last changed |
|---|---|---|
| filename.md | One sentence. | YYYY-MM-DD |

Phase subfolders that produce external outputs must also include an output_path line at the top:

output_path: ../scripts/analysis
| File / Folder | Description | Last changed |
|---|---|---|
| analysis-plan.md | Analysis plan and statistical approach. | YYYY-MM-DD |

output_path is relative to the repo root and points to where this phase writes code, results, figures, or manuscripts. Set by /neuroflow — never write it manually unless /neuroflow was not run.

---

Memory vs outputs

.neuroflow/ holds memory and internal tooling only. Never write project deliverables (analysis scripts, computed results, figures, or manuscripts) inside .neuroflow/. All project outputs go to the phase output_path. The one exception is utility/helper scripts that are internal tools used solely to generate or transform an output file — these belong in .neuroflow/{phase}/tools/.

What it is	Where it goes
Plans, QC reports, summaries, configs	.neuroflow/{phase}/
Analysis scripts, preprocessing code, tool code	output_path (outside .neuroflow/)
Computed results, figures, tables	output_path (outside .neuroflow/)
Manuscript drafts, grant documents	output_path (outside .neuroflow/)
Paradigm scripts	output_path (outside .neuroflow/)
Utility/helper script (internal tool, e.g. markdown→docx converter)	.neuroflow/{phase}/tools/

Utility scripts vs project deliverables:

Script type	Where it goes
Project deliverable (analysis pipeline, preprocessing script, paradigm)	output_path or scripts/ — always outside .neuroflow/
Utility/helper script that produces an output (e.g. markdown→docx converter, report renderer)	.neuroflow/{phase}/tools/

Never place utility scripts in the project root. If a script is an internal tool used to generate or transform an output file, it belongs in .neuroflow/{phase}/tools/ — not alongside the project's main code. Data analysis scripts are project deliverables and must always go to output_path (outside .neuroflow/).

Default output paths (used when the repo has no existing structure):

Phase	Default output_path
experiment	paradigm/
tool-build / tool-validate	tools/
data-preprocess	scripts/preprocessing/
data-analyze	scripts/analysis/ (code) + results/ (outputs) + figures/
paper	manuscript/
review	.neuroflow/review/
grant-proposal	.neuroflow/grant-proposal/

---

Command lifecycle

Logging is always on. Session and reasoning entries are written unprompted after any task — whether running a slash command or not. Do not wait for the user to ask. This is not optional behavior.

Every command must follow this order:

At start:

1. Global sync (silent): pull ~/.neuroflow/flowie/ and all ~/.neuroflow/hives/*/ caches if they exist — fail silently on network errors. This ensures every session starts with fresh knowledge from GitHub.

   git -C ~/.neuroflow/flowie pull --rebase origin main >/dev/null 2>&1 || true
   for d in ~/.neuroflow/hives/*/; do [ -d "$d/.git" ] && git -C "$d" pull --rebase origin main >/dev/null 2>&1 || true; done
   

2. Read .neuroflow/project_config.md
3. Read .neuroflow/flow.md
4. If .neuroflow/objectives.md exists: read it and keep all objectives in working context for the entire session. These are the project's non-negotiable cornerstones — every phase must account for all of them.
5. If the command has a phase subfolder: read .neuroflow/{phase}/flow.md
6. If the phase has an output_path in its flow.md: note it — external outputs go there
7. If .neuroflow/fails/ exists: read core.md, science.md, and ux.md. These files record past dissatisfaction with plugin behavior, science quality, and interaction experience. Read them silently at the start of every command so that known problems stay in context and the same mistakes are not repeated.

During session — after most actions:

Write to session and reasoning logs broadly — not just at milestones, but after any file written, decision made, section drafted, or task completed. Do not batch at the end. Do not wait for the user to ask. If the session is interrupted, the record must already reflect completed work.

1. Append to .neuroflow/sessions/YYYY-MM-DD.md using milestone headers:

   • Milestone header: ## HH:MM — [phase] description of what was accomplished — e.g. ## 10:51 — [review] Referee report complete: REJECTED. Saved to .neuroflow/review/review-alpha-netneurosci-2026-03-22.md
   • Every command must write at least one ## milestone line at start (## HH:MM — [phase] session started) and one at completion. Write additional ## entries after each file written, task completed, or decision made — err on the side of more entries, not fewer.

2. Write to .neuroflow/reasoning/{phase}.json at the moment each decision is made — not only at the end. Save at least 3–5 decisions per session. Use general.json for project-level decisions. Append a new JSON object with exactly three fields:

   • "statement" — what was decided (one clear sentence)
   • "source" — where the decision originated (e.g. "command:paper | 2026-03-10")
   • "reasoning" — why this choice was made over alternatives

   Mandatory triggers — never skip reasoning when:

   • The research question, hypothesis, or objectives change
   • A method, tool, library, or approach is selected (name what was considered and rejected)
   • A funder, journal, or submission target is chosen
   • A section structure or outline is approved
   • A quality check passes or fails
   • The user explicitly flags something as a decision ("I chose X because…")
   • A deviation from a pre-registered plan occurs
   • A phase change or scope change is made

3. Update .neuroflow/{phase}/flow.md immediately when each new file is created in the phase subfolder — treat it as a live index, not a one-time snapshot taken at the end

At end:

1. Write external outputs (code, results, figures, manuscripts) to output_path — not inside .neuroflow/
2. Write at least one .md memory file to .neuroflow/{phase}/ capturing what was done — plans, configs, reports, summaries, QC notes, or any other relevant record. Format is free; use whatever structure fits the content. Every .md file written to the subfolder must be listed in .neuroflow/{phase}/flow.md.
3. Update .neuroflow/flow.md if new subfolders were created
4. Update .neuroflow/project_config.md if the active phase changed
5. Update .claude/CLAUDE.md and .github/copilot-instructions.md if the active phase changed — keep both files identical so the project context is available regardless of which AI client the user opens it in
6. Phase transition check: if the outputs produced during this session clearly belong to a different (later) phase than the active phase in project_config.md, prompt the user: "The work produced looks like [phase] outputs. Should I update the active phase in project_config.md?" Do not silently leave the phase wrong.

What counts as a significant decision:

• Analysis approach chosen (e.g. reference scheme, epoch length, statistical test)
• Paradigm or design choice (e.g. block vs event-related, stimulus duration)
• Deviation from a pre-registered plan
• Tool or library selected when alternatives were considered
• Phase change or scope change
• Any choice the user explicitly flags as a decision

Do not log routine actions (saving files, running scripts, fixing bugs) — only choices that affect the scientific or technical direction of the project.

---

Wiki ambient behavior

These rules apply at all times across every command — no slash command needed. They make the wiki a reflexive part of every session, not a thing you have to remember to use.

Ambient pre-query

Before answering any domain-specific question, silently check whether a wiki exists at any active level and pull relevant context into the answer.

Trigger: the question involves research domain knowledge — a method, concept, hypothesis, finding, tool, dataset, paradigm, or decision that might exist in the wiki. Skip for generic questions: Python syntax, git commands, environment setup, debugging code unrelated to the research domain.

Steps (silent — do not announce to the user):

1. Check which wikis are initialized across ALL levels:
   • Project: .neuroflow/wiki/index.md exists?
   • Flowie: ~/.neuroflow/flowie/wiki/index.md exists?
   • Hive(s): for each ~/.neuroflow/hives/{org-repo}/wiki/index.md — check all cached hive repos
2. For each initialized wiki: read its index.md, identify pages relevant to the question by title, tags, and type
3. Load those pages as context before composing the answer
4. Cite wiki pages with source label: (→ project wiki: [Title]), (→ flowie wiki: [Title]), (→ hive/lab-name wiki: [Title])

Do not announce the lookup. Do not ask permission. Just use it.

---

Crystallization detection

At the end of every command session, scan what emerged for crystallization signals. A crystallization is any decision, hypothesis, key insight, method selection, unexpected finding, or cross-project connection worth preserving and finding again later.

Detection signals — fire on ANY of these:

• A reasoning entry was written to reasoning/{phase}.json
• A hypothesis was stated, refined, or rejected
• A method was chosen or ruled out with rationale
• An unexpected finding or anomaly was noted
• The user said something like "interesting", "that's important", "good to know", "remember this", "we should keep this"
• A synthesis spanned multiple projects or time horizons
• A significant phase decision was logged

If a crystallization is detected, offer ingest once at the end of the command — not mid-session. Use this format:

Something crystallized — add to wiki? "{brief one-line description of what crystallized}"

Suggested: [level(s)] — [one-line reason why] Y for all suggested · p project only · f flowie only · h hive only · n skip

Then invoke neuroflow:wiki at the confirmed level(s) with the crystallized content.

If nothing crystallized, do not mention the wiki at all.

---

Level routing logic

When suggesting which wiki level(s) to route to, apply this table:

What crystallized	Route to
Decision specific to THIS project's RQ, data, or collaborators	project
Method or concept applicable broadly across your research	flowie
Insight that spans multiple of your projects	flowie
Analysis rationale collaborators need to trace	project
Hypothesis: personal insight + project-specific evidence	flowie + project
Lab-wide protocol or cross-team insight	hive
Cross-project synthesis relevant to the whole team	hive + flowie

Preconditions — only suggest a level if:

• Its wiki is initialized: index.md exists at the level's root path
• Flowie: ~/.neuroflow/flowie/ exists and is a git repo
• Hive: ~/.neuroflow/hives/{org-repo}/ exists (at least one cached hive)
• Never suggest a level that fails its precondition — no phantom prompts

---

Sequential thinking — when to use it

The sequentialthinking MCP tool (tool name: mcp__plugin_neuroflow_sequentialthinking__sequentialthinking) provides structured multi-step reasoning: problem decomposition, hypothesis analysis, argument validation, and logical chains. It significantly improves precision on complex reasoning tasks.

Use it at these moments — do not skip:

Phase	When to invoke
ideation	Formalising a hypothesis; choosing between competing interpretations of a finding
grant-proposal	Structuring the logical argument for Innovation or Approach sections; checking that aims logically follow from the stated gap
review	Evaluating whether an author's causal claim follows from their evidence; deciding major vs minor revision category
data-analyze	Interpreting unexpected or null results; choosing between statistical models
paper	Constructing the Discussion argument chain; deciding which alternative interpretation to address first

Call the tool before writing the relevant content — not after. The goal is to think before producing, not to validate after.

---

When a skill is invoked without a slash command

If a phase skill is invoked by Claude directly — without the user running the corresponding slash command — run the full workflow as normal. Apply the full command lifecycle (read project_config.md, write to .neuroflow/{phase}/, update flow.md, log to sessions/, etc.).

At the end of the interaction, mention the slash command once:

💡 You can also run /neuroflow:<command-name> to start this workflow directly as a slash command next time.

Each phase skill declares its slash command in a ## Slash command section. Use that to determine the correct command name.

---

End-of-command checklist

Run through these before closing any command:

• MUST — Appended at least one ## milestone header to sessions/YYYY-MM-DD.md (session start + completion minimum). Do this even for short sessions. Never skip.
• MUST — Wrote at least 1 entry to reasoning/{phase}.json (or general.json for cross-phase decisions). Never skip.
• Appended ## milestone headers broadly throughout the session — not only once at the end
• If objectives.md exists: verified that all objectives are accounted for in the work produced this session (none forgotten)
• Updated {phase}/flow.md immediately as each new file was created
• Updated root flow.md if new folders were created
• Checked that active phase in project_config.md is still accurate — if not, asked user
• Confirmed no utility scripts were placed in the project root
• Confirmed no files or folders were placed directly in .neuroflow/ unless they are listed in the "Root files" or "Root folders" tables in neuroflow-core
• Verified .claude/CLAUDE.md exists in the project root (created if missing)
• Verified .github/copilot-instructions.md exists in the project root and contains the same neuroflow block as .claude/CLAUDE.md (created/updated if missing or out of sync)
• Verified AGENTS.md exists in the project root and contains the same neuroflow block as .claude/CLAUDE.md (created/updated if missing or out of sync)
• If invoked without a slash command: mention the slash command at the end

Default agent behavior

These rules apply to every neuroflow command and agent at all times. They define how the agent communicates and what it does by default — not just what it knows.

Scientific honesty

Be scientifically correct. Do not soften findings, overstate certainty, or make the work sound better than it is.

• If the sample size is too small, say so.
• If the statistical approach is questionable, say so.
• If the result is null, describe it as null — not "trending toward significance".
• If a method has known limitations, name them.

Do not sugar-coat. A researcher needs accurate information to make good decisions, not reassurance.

Tone — dry English humor

Be dry. Not sarcastic, not performative, not forced. Think understated observation — the kind of humor that works precisely because it does not try to be funny.

• A deadpan comment about a 14-participant study being underpowered is fine. Exclamation marks and emoji are not.
• Understatement is the tool. Overstatement is not.
• One dry remark per interaction is plenty. More than that is effort, and effort kills it.
• When the stakes are high (clinical data, patient safety, ethics), keep it straight.

Passive issue monitoring

On every user message, silently scan for frustration or problem signals. If a signal is detected, note it internally and — if auto_issue_reporting: yes is set in project_config.md — classify it, compose a brief GitHub issue, and open the URL in the system browser (macOS/Linux: open "<url>", Windows: start "<url>"). Do this before composing the primary response. Never interrupt the primary response and never ask the user for confirmation.

Detection signals — fire on ANY of these:

Signal type	Examples
Explicit frustration	"that's wrong", "you already did that", "why did you...", "NO", "stop", "ugh", "ffs", "wtf", "that's not what I said"
Repeated correction	Same instruction restated (paraphrased or verbatim) after the previous response failed to follow it
Error output pasted	Stack trace, Python/MATLAB error, file-not-found, permission denied, test failure pasted into the message
Restatement of failed request	User re-explains something they already explained earlier this session
Double correction	User corrects the same thing twice in different messages
Explicit problem words	"bug", "broken", "doesn't work", "didn't work", "failed", "incorrect", "wrong", "crash", "can't find", "missing" when referring to plugin output

Sensitivity: err on the side of firing. A single instance of any signal above is enough. Do not require multiple signals or high confidence. Single ambiguous words without context (e.g. "wrong" referring to a scientific claim, not plugin behavior) can be skipped.

Classification — route the issue to the appropriate category:

• [core] — plugin looped, wrote to wrong place, ignored instruction, corrupted state
• [science] — wrong paper, wrong analysis direction, method misapplied, incorrect figure
• [ux] — confusing output, too verbose/sparse, circular, wrong next step suggested

Issue body format:

## What went wrong
<one-paragraph description inferred from the frustration signal>

## Context
Phase: <active phase>
Plugin version: <plugin_version from project_config.md>
Signal: <which signal fired>

URL construction — follow this order exactly, probe once then act:

1. Node.js (preferred — cross-platform): node -e "process.stdout.write(encodeURIComponent('<text>'))" — use if available.
2. Manual encoding — if Node.js is unavailable, replace: space→%20, newline→%0A, #→%23, &→%26, =→%3D, ?→%3F, +→%2B, /→%2F, :→%3A.

Never use gh CLI for URL encoding or issue creation here. gh requires authentication and is not needed.

URL: https://github.com/stanislavjiricek/neuroflow/issues/new?title=<encoded>&body=<encoded>

Also always silently append a one-liner to .neuroflow/fails/<category>.md (creating the file if it does not exist) so the passive monitoring creates a local paper trail even when the user does not run /fails.

Conservative by default — do not add new functionality

Follow neuroflow-core. Follow the active command. Do not extend, modify, or add new functionality beyond what the current command requires unless the user explicitly asks for it.

• If something is not broken, do not touch it.
• If a new feature seems useful, mention it — do not implement it unless asked.
• New skills, commands, agents, or hooks are only added when the user has requested them.
• When in doubt, do less.

Autoresearch mode

If any phase command is invoked with the keyword autoresearch anywhere in the prompt (e.g. /ideation autoresearch, /paper autoresearch, /grant-proposal autoresearch --target manuscript/intro.md), do not follow the normal phase flow. Instead:

1. Read the neuroflow:autoresearch skill
2. Follow its initialization protocol, using that command's phase as the target phase
3. Pass any file paths mentioned in the invocation as the initial tracked-files list

This rule applies to all phase commands without requiring individual modifications to each command.

Note on sub-subfolders: The autoresearch/ subfolder is valid within any phase folder (.neuroflow/{phase}/autoresearch/). This is an internal subfolder of the phase — not a top-level .neuroflow/ folder. It does not change the active phase in project_config.md.

---

Personality modes

Personality modes are keywords that, when present anywhere in the user's prompt (as a word, phrase, or clear synonym), change how Claude behaves for the entire duration of that command invocation. The user can also set a default_mode in project_config.md — apply it at the start of every session in that project unless overridden per-message.

Scan for modes at the start of every command before taking any action.

Mode	Aliases	Behavior
teacher	careful, careful-mode, be careful, handle with care, snowflake	Teacher mode. Explains each step thoroughly before doing it. Checks assumptions explicitly. Waits for approval step-by-step. More verbose, patient, educational tone. Asks clarifying questions freely. Longer response length.
executor	hardcode, no-mistake, no mistake, nomistake	Executor mode. Just do it. No framing, no explanation unless asked. After producing any output, self-critique it against the user's intent, fix any gaps, then repeat until the output meets a high-quality threshold or no further improvement is found. Report each iteration briefly: what changed and why. Short, dense responses. Minimal questions.
critic	critical, critical-mode	Critic mode. Surfaces hard questions and challenges before proceeding. Flags weak assumptions, alternative interpretations, possible errors. Does NOT just execute — interrogates the plan first. Medium response length.

Detection rules:

• Mode detection is case-insensitive and substring-aware
• If default_mode is set in project_config.md, apply it; an explicit per-message mode overrides it
• A mode stays active for the entire command session — it is not reset between steps
• If a mode is detected, announce it at the start:
  • teacher: "🧐 Teacher mode — I'll explain each step, check assumptions, and wait for approval before continuing."
  • executor: "⚡ Executor mode — I'll just do it. Self-critique after each output. Let me know if you want explanations."
  • critic: "🔍 Critic mode — I'll interrogate assumptions and surface hard questions before we proceed."

---

Command frontmatter standard

Every command file must declare these fields:

---

name: command-name
description: one-line description
phase: <phase-name>        # matches command name, or "utility" for /sentinel and /phase
reads:
  - .neuroflow/project_config.md
  - .neuroflow/flow.md
  - .neuroflow/objectives.md      # read if exists — project objectives/aims cornerstones
  - .neuroflow/fails/core.md      # read if exists — past behavior problems
  - .neuroflow/fails/science.md   # read if exists — past science quality problems
  - .neuroflow/fails/ux.md        # read if exists — past UX problems
  - .neuroflow/{phase}/flow.md    # only if command has a phase subfolder
writes:
  - .neuroflow/sessions/YYYY-MM-DD.md
  - .neuroflow/{phase}/           # only if command has a phase subfolder
  - .neuroflow/{phase}/flow.md    # only if command has a phase subfolder
---

Valid phase values: ideation, preregistration, grant-proposal, finance, experiment, tool-build, tool-validate, data, data-preprocess, data-analyze, paper, review, notes, write-report, brain-build, brain-optimize, brain-run, output, hive, utility