| name | swane-dev-assistant |
| description | Use when creating, changing, refactoring, debugging, reviewing, documenting, or validating SWANe code — Nipype nodes/workflows, DICOM inputs, configuration/preferences, resource scheduling, external neuroimaging tool integration (FSL, FreeSurfer, dcm2niix, 3D Slicer), GUI components, background workers, tests, pip dependency upgrades, or packaging/releases. |
SWANe Dev Assistant
Overview
Develop SWANe while preserving its workflow contracts, scientific behavior, persisted preferences, resource limits, GUI responsiveness, and repository conventions. Treat the current checkout as source of truth — inspect real code before proposing or implementing a change; do not invent APIs, node names, output fields, preferences, signals, or external-tool behavior.
Choose a reference
Always read references/architecture-and-change-map.md first — it routes to the others based on what is changing.
| Change area | Reference |
|---|
| Workflow graphs, custom Nipype interfaces, execution/resources/reporting, scientific processing | references/workflows-and-nipype.md |
Global/subject preferences, PreferenceEntry, presets, dependency gates, setup wizard, secrets | references/configuration-and-preferences.md |
Application lifecycle, MainWindow/SubjectTab, workers, signals, Slicer integration | references/ui-and-workers.md |
| Which suite to run, how to add/update tests for a given change | references/testing.md |
Bumping a pinned setup.py dependency (e.g. Nipype), checking monkeypatches and deprecated APIs, transitive dependency changes | references/dependency-updates.md |
Repository workflow
- Check the active branch and working tree (
git branch --show-current, git status --short --branch).
- Trace the requested behavior end to end: configuration/input → subject state →
MainWorkflow → subworkflow → Nipype interface/external tool → result/report → GUI or Slicer consumer.
- Identify the stable contracts touched by the change (see
CLAUDE.md).
- Implement the smallest coherent change using existing abstractions and patterns.
- Add or update focused regression coverage — see references/testing.md.
- Run the narrowest useful checks first, then broaden validation in proportion to risk. Report every check that could not run and why.
- If the change makes a reference file inaccurate (a renamed class/method, a moved file, a changed mechanism, a dead cross-reference), update that reference in the same change — do not leave it to drift. A reference describing code that no longer exists is worse than no reference.
Style
- Format changed Python with Black; do not reformat unrelated files.
- Match the surrounding NumPy-style docstring convention for public classes, workflow factories, and non-obvious methods.
- Avoid opportunistic refactors; do not rewrite existing wildcard-import areas solely for style.
- Preserve established public names and mixed legacy filename conventions unless the rename is the task itself.
Reporting the result
- Lead with the implemented or diagnosed outcome.
- Name affected persisted, workflow, scientific, signal, and result contracts.
- Report tests run, tests skipped, and missing prerequisites precisely.
- If the requested approach conflicts with the live architecture or a stable contract, explain the conflict and propose the smallest aligned alternative.
