cellpycore 0.1.4__tar.gz → 0.2.0__tar.gz

{cellpycore-0.1.4 → cellpycore-0.2.0}/.aliases

@@ -54,3 +54,12 @@ release() {
     git push || return 1
     gh release create "$tag" --generate-notes
 }
+
+# `acp "commit message"` — stage all, commit, push
+acp() {
+    if [ $# -lt 1 ]; then
+        echo 'acp: usage: acp "commit message"'
+        return 1
+    fi
+    git add -A && git commit -m "$1" && git push
+}

{cellpycore-0.1.4 → cellpycore-0.2.0}/.cursor/rules/cellpy-core-migration.mdc

@@ -17,9 +17,10 @@ Key invariants from that doc:
 
 - **Branch, don't fork.** Integration work goes on a `cellpy` branch (optionally a
   `git worktree`), never a fresh clone of cellpy.
-- **Dev wiring:** cellpy uses a `[tool.uv.sources]` editable path to `../cellpy-core`
-  for local dev; the `git+https…@<ref>` reference in `[project.dependencies]` stays the
-  release/consumer truth. Pin a tag/commit for releases.
+- **Dev wiring:** cellpy pins `cellpycore` on PyPI in `[project.dependencies]`. Local
+  dual-repo dev: `uv sync --no-sources` then `uv pip install -e ../cellpy-core` (or
+  `cellpy/scripts/dev_sync.sh`). Do not commit `[tool.uv.sources]` path overrides.
+  Regenerate lock with `UV_NO_SOURCES=1 uv lock`. Pin exact `==` before cellpy releases.
 - **Parity is enforced by tests** (legacy header/unit contract tests + golden parquet
   fixtures), not by vigilance.
 - **Metadata boundary:** core may own metadata *scaffolding and tooling* (schemas,

{cellpycore-0.1.4 → cellpycore-0.2.0}/.cursor/rules/issueflow-rules.mdc

@@ -1,7 +1,8 @@
 ---
-description: Issue-flow workflow rules for LLMs
+description: Issue-flow workflow rules for cellpycore
 globs:
-alwaysApply: true
+  - "**/*"
+alwaysApply: false
 ---
 
 
@@ -103,11 +104,52 @@ Use an explicit status checkbox in the status file:
 - `- [x] Done` when fully resolved
 - `- [ ] Done` when not fully resolved
 
+### Chat invocation (no slash)
+
+On keyboard layouts where `/` and `@` are awkward to type (for example Norwegian), invoke lifecycle skills in **chat** without special keys.
+
+**Primary form:** `iflow <step>` (space-separated) — e.g. `iflow plan`, `iflow pick`, `iflow close`. Plain `iflow` runs the smart dispatcher.
+
+**Also recognized** (same obligation as slash-menu invocation): hyphen form (`iflow-plan`), slash form (`/iflow-plan`), slash + space (`/iflow plan`).
+
+When the user message is **exactly** one of these forms, or **starts with** it followed by a space and trailing arguments, **read and follow** the matching skill immediately. Forward trailing text verbatim (e.g. `iflow pick fix` → `iflow-pick` with arg `fix`). Do **not** treat incidental mid-sentence mentions as commands — the message must **start with** the invocation.
+
+| Chat / slash form | Skill |
+|-------------------|-------|
+| `iflow` / `/iflow` | `iflow` (dispatcher) |
+
+| `iflow archive`, `iflow-archive`, `/iflow-archive`, `/iflow archive` | `iflow-archive` |
+
+| `iflow cleanup`, `iflow-cleanup`, `/iflow-cleanup`, `/iflow cleanup` | `iflow-cleanup` |
+
+| `iflow close`, `iflow-close`, `/iflow-close`, `/iflow close` | `iflow-close` |
+
+| `iflow fix`, `iflow-fix`, `/iflow-fix`, `/iflow fix` | `iflow-fix` |
+
+| `iflow graphify`, `iflow-graphify`, `/iflow-graphify`, `/iflow graphify` | `iflow-graphify` |
+
+| `iflow init`, `iflow-init`, `/iflow-init`, `/iflow init` | `iflow-init` |
+
+| `iflow pause`, `iflow-pause`, `/iflow-pause`, `/iflow pause` | `iflow-pause` |
+
+| `iflow pick`, `iflow-pick`, `/iflow-pick`, `/iflow pick` | `iflow-pick` |
+
+| `iflow plan`, `iflow-plan`, `/iflow-plan`, `/iflow plan` | `iflow-plan` |
+
+| `iflow start`, `iflow-start`, `/iflow-start`, `/iflow start` | `iflow-start` |
+
+| `iflow status`, `iflow-status`, `/iflow-status`, `/iflow status` | `iflow-status` |
+
+| `iflow yolo`, `iflow-yolo`, `/iflow-yolo`, `/iflow yolo` | `iflow-yolo` |
+
+
+Skill `@` attachment is supported on some editors but is not the recommended keyboard-friendly path.
+
 ### Command lifecycle
 
-If you have not chosen an issue yet, run **`/iflow-pick`** — the front door that helps you select the next issue (parked work first, else ranked open GitHub issues), creates the branch, and runs `/iflow-init` for you. It is off-path (never auto-dispatched).
+If you have not chosen an issue yet, run **`/iflow-pick`** (or type **`iflow pick`** in chat) — the front door that helps you select the next issue (parked work first, else ranked open GitHub issues), creates the branch, and runs `/iflow-init`. It is off-path (never auto-dispatched).
 
-If you just want the next right step, run **`/iflow`** — it detects state (by file presence under `.issueflows/01-current-issues/` and the status-file `- [x] Done` marker) and dispatches to `/iflow-init`, `/iflow-plan`, `/iflow-start`, or `/iflow-close`. It never auto-dispatches to `/iflow-pick`, `/iflow-pause`, `/iflow-cleanup`, or `/iflow-yolo` — those stay explicit.
+If you just want the next right step, run **`/iflow`** (or type **`iflow`** in chat) — it detects state (by file presence under `.issueflows/01-current-issues/` and the status-file `- [x] Done` marker) and dispatches to `/iflow-init`, `/iflow-plan`, `/iflow-start`, or `/iflow-close`. It never auto-dispatches to `/iflow-pick`, `/iflow-pause`, `/iflow-cleanup`, or `/iflow-yolo` — those stay explicit.
 
 The full slash-command lifecycle is:
 
@@ -124,10 +166,16 @@ The full slash-command lifecycle is:
 Issue labels can select the flow: when an issue picked via `/iflow-pick` carries the **`yolo`** label, it is routed through `/iflow-yolo` (one combined confirmation). Controlled by `label_flows` (default `true`) and `yolo_label` (default `"yolo"`) under `[issueflow]` in `.issueflows/config.toml`; re-run `issue-flow update` after changing them.
 
 
+
+Lifecycle skills include a **`### MODEL & EXECUTION DIRECTIVE`** section that tells agents whether to prioritize **economy** (speed) or **reasoning** (depth) for that step. Toggle with `step_directives` under `[issueflow]`; override per step via `[issueflow.step_profiles]`; optional label hints during `/iflow-pick` via `model_label_flows`, `deep_model_label`, and `fast_model_label`. Re-run `issue-flow update` after changing any of these.
+
+
 `/iflow-fix` opens an interactive iterative-fixes session: it creates one GitHub issue + long-lived branch, then loops over many small fixes (each gets a short plan and is implemented only on confirmation, recorded as a dated bullet in `issue<N>_status.md`), and ends with `/iflow-close`. It is off-path (never auto-dispatched); while a session is active, drive it with `/iflow-fix` + `/iflow-close`, not `/iflow`.
 
 `/iflow-status` prints a **read-only** overview of where every issue stands — the local tracking state under `.issueflows/` (focus / parked / solved) plus open GitHub issues cross-referenced against it. It is off-path (never auto-dispatched) and changes nothing.
 
+`/iflow-archive` condenses old solved issue groups under `.issueflows/03-solved-issues/` into a single dated `YYYY-MM-DD_archived_issues.md` summary file (recording the pre-archive git ref for recovery via `git show <ref>:<path>`), then deletes the original `issue<N>_*` files. It is off-path and destructive: nothing is deleted before one consolidated confirmation.
+
 > On tools without project slash commands (e.g. Codex CLI), invoke the mirrored Agent Skills instead (for example `iflow-init` in place of `/iflow-init`).
 
 ### When finishing an issue
@@ -182,6 +230,16 @@ Long-lived design docs, design decisions, and project "good practices" live unde
 - **Never overwritten by `issue-flow update`.** The folder is recreated if missing, but existing files are left alone.
 
 
+### Multi-root workspaces
+
+When an editor workspace contains **multiple sibling repositories**, each with its own `.issueflows/` scaffold:
+
+- **Resolve the target repo first** — explicit `root:` / `repo:` hints, then `issue-flow agent resolve`, then branch/single-scaffold heuristics, then the **workspace default** from `issueflow-workspace.toml` at the workspace root (create it with `issue-flow workspace init`); **ask** when still ambiguous. Never let `git` or `gh` infer the repo from cwd alone.
+- **Scoped rules** — this repo's `issueflow-rules` apply under this project root only (path globs). Put **toolchain-specific** run/test commands in `.issueflows/04-designs-and-guides/this-project.md`, not in shared boilerplate that every repo merges.
+- **Per-repo lifecycle** — `/iflow-cleanup`, branch hygiene, and focus issue folders are **per repository**; repeat commands in each repo when needed.
+- **Design doc** — see `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` when present (issue #67).
+
+
 ### Branch hygiene
 
 - Do issue work on an **issue branch** named like `<N>-<short-slug>`, not on the default branch.

{cellpycore-0.1.4 → cellpycore-0.2.0}/.cursor/skills/caveman/SKILL.md

@@ -6,6 +6,7 @@ description: >-
   caveman mode, token-greedy / terse answers, or says "be brief" / "stop
   wasting tokens". Stays active across the session once on; off via "stop
   caveman" / "normal mode".
+issue-flow-version: 0.4.2a4
 ---
 
 # Be token greedy - as a caveman
@@ -31,7 +32,7 @@ English only. Caveman applies to English output; do not garble other languages.
 
 ## Intensity
 
-Single level: **full**. Drop articles, fragments OK, short synonyms. Classic caveman. No tool-call narration, no decorative tables/emoji, no long raw error-log dumps unless asked. Standard acronyms OK; no invented abbreviations.
+Single level: **full**. Classic caveman — every rule above applies at full strength; there is no milder setting.
 
 Example — "Why React component re-render?"
 - "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."

{cellpycore-0.1.4 → cellpycore-0.2.0}/.cursor/skills/grill-me/SKILL.md

@@ -5,6 +5,7 @@ description: >-
   the decision tree is resolved, then feed the conclusions into the issue plan.
   Use when the user wants to stress-test a plan, asks to "grill me", or during
   /iflow-plan when grilling is turned on. Off via "stop grilling" / "normal mode".
+issue-flow-version: 0.4.2a4
 ---
 
 # Grill me — relentless planning interview

{cellpycore-0.1.4 → cellpycore-0.2.0}/.cursor/skills/iflow/SKILL.md

@@ -1,24 +1,58 @@
 ---
 name: iflow
 description: >-
-  Run the /iflow smart dispatcher: detect where the focus issue stands in the
-  lifecycle (via files in .issueflows/01-current-issues/ and
-  status markers) and dispatch to /iflow-init, /iflow-plan, /iflow-start, or
-  /iflow-close. Forwards trailing args verbatim. Never auto-dispatches to
-  /iflow-pause, /iflow-cleanup, or /iflow-yolo.
+  Smart dispatcher: detect where the focus issue stands and dispatch to
+  /iflow-init, /iflow-plan, /iflow-start, or /iflow-close.
 disable-model-invocation: true
+issue-flow-version: 0.4.2a4
 ---
 
 # issue-flow — iflow smart dispatcher (`/iflow`)
 
-Follow this skill when the user wants to run **the right next step** in the issue-flow lifecycle without remembering which specific command applies.
+Follow this skill to run **the right next step** in the issue-flow lifecycle: it detects state and routes to `/iflow-init`, `/iflow-plan`, `/iflow-start`, or `/iflow-close`, forwarding trailing args verbatim.
 
-## When to use
+Do **not** use this skill for `/iflow-pick`, `/iflow-pause`, `/iflow-cleanup`, `/iflow-yolo`, or `/iflow-fix`. Those are explicit-only commands. (`/iflow-pick` is the front door *before* `/iflow-init`, for when no issue has been chosen yet. `/iflow-fix` runs an interactive iterative-fixes session, driven by `/iflow-fix` + `/iflow-close`.)
 
-- The user runs `/iflow`, mentions **iflow**, or asks "what's the next step?" during an issue-flow lifecycle.
-- You want a single entry point that routes to `/iflow-init`, `/iflow-plan`, `/iflow-start`, or `/iflow-close` based on current state.
 
-Do **not** use this skill for `/iflow-pick`, `/iflow-pause`, `/iflow-cleanup`, `/iflow-yolo`, or `/iflow-fix`. Those are explicit-only commands. (`/iflow-pick` is the front door *before* `/iflow-init`, for when no issue has been chosen yet. `/iflow-fix` runs an interactive iterative-fixes session, driven by `/iflow-fix` + `/iflow-close`.)
+**Invoke:** type `iflow` in chat, or `/iflow` from the slash menu.
+
+
+
+
+### MODEL & EXECUTION DIRECTIVE
+
+
+**Profile: economy** — Prioritize speed and token economy over deep reasoning.
+
+In Cursor: use **Auto** or a fast model before invoking this step.
+
+
+
+Keep scope tight to what this step requires.
+
+
+
+
+### Resolve project root (multi-root workspaces)
+
+Before any `git`, `gh`, or `.issueflows/` path operation in this workflow:
+
+**Resolution order** (stop when unambiguous):
+
+1. **Explicit hints** in slash input — `root:<path>`, `repo:<folder-basename>` (directory name, e.g. `cellpy-core`), or `repo:owner/name`.
+2. **CLI fast path** — `issue-flow agent resolve [-C <start>] [--from-file <active-file>] [--json]`. Use the returned `project_root` and `repo`; pass `-C <project_root>` to other `issue-flow agent …` subcommands. When the answer came from the workspace registry, the payload sets `resolved_via_workspace_default: true`.
+3. **Branch context** — exactly one workspace repo whose branch matches `^\d+-` → that root.
+4. **Single scaffold** — exactly one `.issueflows/` tree visible in the workspace → that root.
+5. **Workspace default** — an `issueflow-workspace.toml` at the workspace root (created with `issue-flow workspace init`) may name a `default` member repo; use it when no scaffold matched above. Tell the user the default was used.
+6. **Ambiguous** → **stop and ask**; never guess between sibling repos.
+
+After resolution, treat the result as `<project_root>` and `<owner/repo>`:
+
+- **Git:** `git -C <project_root> …` (or `issue-flow agent … -C <project_root>` for supported ops).
+- **GitHub:** always `gh … --repo <owner/repo>` — never rely on `gh`'s implicit cwd default.
+- **Paths:** all `.issueflows/…` paths are under `<project_root>`.
+
+When `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` exists, read it for layout and cross-repo guidance.
 
 ## Instructions
 

cellpycore-0.2.0/.cursor/skills/iflow-archive/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: iflow-archive
+description: >-
+  Condense old solved issue groups into one dated summary file, then delete
+  the originals. Destructive, one consolidated confirm.
+disable-model-invocation: true
+issue-flow-version: 0.4.2a4
+---
+
+# issue-flow — archive solved issues (`/iflow-archive`)
+
+Follow this skill to **shrink the solved-issues archive**:
+old `issue<N>_*` groups under `.issueflows/03-solved-issues/` are
+summarised into one dated markdown file and the originals are deleted (they
+stay recoverable through git history).
+
+Do **not** use this to park or close an active issue — that is `/iflow-pause` / `/iflow-close`. This skill only touches `.issueflows/03-solved-issues/`.
+
+## Input
+
+- **(nothing)** — smart default: propose archiving every solved group **except the 5 most recent** (highest issue numbers).
+- **`keep <K>`** — same, but keep the `<K>` most recent groups instead.
+- **an explicit list** (e.g. `12 13 24`) — archive exactly those issues.
+- **`all`** — archive every solved group.
+
+
+**Invoke:** type `iflow archive` in chat, or `/iflow-archive` from the slash menu (`iflow-archive` also works).
+
+
+
+
+### MODEL & EXECUTION DIRECTIVE
+
+
+**Profile: reasoning** — Prioritize deep thinking and careful trade-offs over speed or token economy.
+
+In Cursor: switch to a thinking-capable model before invoking this step (not Auto-only).
+
+
+
+Keep scope tight to what this step requires.
+
+
+
+## Instructions
+
+> **CLI fast path (optional).** If the `issue-flow` CLI is on `PATH`, the
+> mechanical deletion step has a deterministic shortcut:
+> `issue-flow agent archive <N> [<N> ...]` (add `--dry-run` to preview,
+> `--json` for a machine-readable object). It removes the chosen groups'
+> files and reports the pre-archive HEAD sha — you still select candidates,
+> confirm with the user, and write the summary file yourself. The CLI is
+> optional: if it is missing or errors, fall back to the manual instructions
+> below.
+
+1. **Preflight.** Require a **clean working tree** (`git status --porcelain`); if dirty, **stop** and ask the user to commit or stash first — the recovery ref is only meaningful when the deletion lands as its own commit. Capture the pre-archive ref: `git rev-parse HEAD`.
+
+2. **Select candidates.** List every `issue<N>_*` group in `.issueflows/03-solved-issues/` with its number and title (from the `# Issue #N: <title>` heading of `issue<N>_original.md`). Apply the input rule (default: all except the 5 most recent by issue number). Show the resulting candidate list — number, title, file names — and let the user add/remove issues.
+
+3. **Consolidated confirm** (destructive — written in normal prose, never shortened). One prompt covering exactly: which issues get summarised, that their files will be **deleted**, and that recovery relies on git history via the recorded ref. Do not proceed without a clear yes.
+
+4. **Summarise (before deleting).** Append to `.issueflows/03-solved-issues/YYYY-MM-DD_archived_issues.md` (today's date; create the file if missing). Structure:
+
+   ```markdown
+   # Archived issues — YYYY-MM-DD
+
+   Pre-archive git ref: `<sha>`
+   Recover any archived file with `git show <sha>:<path>` (or browse `git log -- <path>`).
+
+   ## Issue #<N>: <title>
+
+   - Source: <GitHub issue URL, from the original file>
+   - Archived files: issue<N>_original.md, issue<N>_plan.md, issue<N>_status.md
+   - Summary: 2–4 sentences distilled from the original / plan / status files —
+     what the issue was, what was done, and the outcome.
+   ```
+
+   One `## Issue` section per archived issue. If the dated file already exists (same-day rerun), append a `---` separator followed by a fresh `Pre-archive git ref:` line for this run, then the new issue sections. The dated filename deliberately does **not** match `issue<N>_*`, so it never interferes with issue grouping.
+
+5. **Delete.** Remove the archived groups' files — CLI fast path (`issue-flow agent archive ...`), or manually `git rm .issueflows/03-solved-issues/issue<N>_*` per issue.
+
+6. **Commit offer.** Propose a single commit, e.g. `chore(iflow): archive <count> solved issues (pre-archive ref <short-sha>)`, including the new/updated dated file and the deletions. Ask before committing; never push from this skill.
+
+7. **Report.** Summarise: how many issues were archived, the dated file path, the pre-archive ref, and the one-line recovery recipe.
+
+## Constraints
+
+- **Off-path.** Never auto-dispatch from `/iflow`, `/iflow-start`, or `/iflow-close`. The user opts in explicitly.
+- **Destructive, so gated.** Never delete anything before the consolidated confirm in step 3, and never delete files that were not summarised in step 4.
+- Only `.issueflows/03-solved-issues/` is touched — never `01-current-issues/`, `02-partly-solved-issues/`, `00-tools/`, or `04-designs-and-guides/`.
+- Requires a clean working tree; the deletion should land as its own commit so `git show <ref>:<path>` recovery always works.
+- Summaries are interpretive (agent judgment); the CLI only ever does the mechanical deletion.

cellpycore-0.2.0/.cursor/skills/iflow-cleanup/SKILL.md

@@ -0,0 +1,81 @@
+---
+name: iflow-cleanup
+description: >-
+  Post-merge branch hygiene: switch to the default branch and delete merged
+  local branches under one consolidated confirm. Never -D.
+disable-model-invocation: true
+issue-flow-version: 0.4.2a4
+---
+
+# issue-flow — issue cleanup (`/iflow-cleanup`)
+
+Follow this skill to **run post-merge branch hygiene** after a PR has been merged (typically the PR opened by `/iflow-close`).
+
+
+**Invoke:** type `iflow cleanup` in chat, or `/iflow-cleanup` from the slash menu (`iflow-cleanup` also works).
+
+
+
+
+### MODEL & EXECUTION DIRECTIVE
+
+
+**Profile: economy** — Prioritize speed and token economy over deep reasoning.
+
+In Cursor: use **Auto** or a fast model before invoking this step.
+
+
+
+Keep scope tight to what this step requires.
+
+
+
+
+### Resolve project root (multi-root workspaces)
+
+Before any `git`, `gh`, or `.issueflows/` path operation in this workflow:
+
+**Resolution order** (stop when unambiguous):
+
+1. **Explicit hints** in slash input — `root:<path>`, `repo:<folder-basename>` (directory name, e.g. `cellpy-core`), or `repo:owner/name`.
+2. **CLI fast path** — `issue-flow agent resolve [-C <start>] [--from-file <active-file>] [--json]`. Use the returned `project_root` and `repo`; pass `-C <project_root>` to other `issue-flow agent …` subcommands. When the answer came from the workspace registry, the payload sets `resolved_via_workspace_default: true`.
+3. **Branch context** — exactly one workspace repo whose branch matches `^\d+-` → that root.
+4. **Single scaffold** — exactly one `.issueflows/` tree visible in the workspace → that root.
+5. **Workspace default** — an `issueflow-workspace.toml` at the workspace root (created with `issue-flow workspace init`) may name a `default` member repo; use it when no scaffold matched above. Tell the user the default was used.
+6. **Ambiguous** → **stop and ask**; never guess between sibling repos.
+
+After resolution, treat the result as `<project_root>` and `<owner/repo>`:
+
+- **Git:** `git -C <project_root> …` (or `issue-flow agent … -C <project_root>` for supported ops).
+- **GitHub:** always `gh … --repo <owner/repo>` — never rely on `gh`'s implicit cwd default.
+- **Paths:** all `.issueflows/…` paths are under `<project_root>`.
+
+When `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` exists, read it for layout and cross-repo guidance.
+
+## Instructions
+
+1. **Detect the default branch.** Prefer `gh repo view --repo <owner/repo> --json defaultBranchRef -q .defaultBranchRef.name`, else `git -C <project_root> symbolic-ref --quiet --short refs/remotes/origin/HEAD`, else `main`.
+
+2. **Identify the target branch.** If the user named a branch after `/iflow-cleanup`, use it. Else use the current branch (`git branch --show-current`). If the current branch **is** the default, skip to step 4 (folder sweep only).
+
+3. **Check PR / merge state.** Prefer `gh pr view <branch> --json state,mergedAt,mergeCommit,headRefName`. If `gh` is unavailable, approximate with `git fetch --prune` then `git cherry origin/<default> <branch>` (all commits marked `-` means squash-merged).
+   - **If not merged:** remind the user that the working copy is still on the issue branch; suggest `git switch <default>` before unrelated work and re-run `/iflow-cleanup` after the PR merges. **Stop.** Do not delete anything.
+   - **If merged:** continue.
+
+4. **Consolidated confirm** — one yes/no prompt listing every action:
+   - `git switch <default>`
+   - `git pull --ff-only`
+   - `git fetch --prune`
+   - Every local branch whose tip is already reachable from `origin/<default>` (include squash-merges via `git cherry`). List them explicitly before running `git branch -d <branch>` for each. Never use `-D`; if `-d` refuses, report the branch and move on.
+   - **Planned release tag (tag-derived projects only).** When `/iflow-close` planned a tag it did not create — check the focus issue's status file and the newest `HISTORY.md` release section for a version whose tag is missing from `git tag -l` — include creating it here: `git tag <planned>` then `git push origin <planned>` (or `gh release create <planned> --generate-notes`). Run it **after** the pull so the tag lands on the merged squash commit.
+
+5. **Optional folder sweep** (safe; no destructive git). In `.issueflows/01-current-issues/`, for each `issue<N>_*` group whose status file contains `- [x] Done` (case-insensitive on `done`), move the group to `.issueflows/03-solved-issues/`. Leave groups without a checked `Done` in place — routing them to `.issueflows/02-partly-solved-issues/` is `/iflow-pause`'s job.
+
+6. **Report.** Summarize: default branch, PR/merge status, commands run, branches deleted, branches skipped (with reason), folder sweep result. If `issue-flow agent resolve --json` reports `sibling_roots`, list them and remind the user that **each scaffolded repo needs its own `/iflow-cleanup`** — do not loop automatically in this step.
+
+## Constraints
+
+- Never use `git branch -D` or `git push --force`.
+- Never delete the default branch.
+- If anything is ambiguous (detached HEAD, multiple remotes, missing tracking info), report and stop rather than guess.
+- Do not open or update PRs. Do not bump version fields — pyproject bumps belong to `/iflow-close`. The only version action allowed here is creating a release tag that `/iflow-close` **planned** (tag-derived strategy), inside the consolidated confirm.

cellpycore-0.2.0/.cursor/skills/iflow-close/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: iflow-close
+description: >-
+  Finish and land the focus issue: tests, optional version bump, status
+  update, commit, push, and PR.
+disable-model-invocation: true
+issue-flow-version: 0.4.2a4
+---
+
+# issue-flow — issue close (`/iflow-close`)
+
+Follow this skill to **finish and land** work: tests, optional version bump, issue-folder updates, git, and PR.
+
+Post-merge branch hygiene lives in `/iflow-cleanup` — this skill never deletes branches.
+
+## Optional version bump (command input)
+
+If the user included text after `/iflow-close` that requests a version bump:
+
+- **`bump`** (no level) → apply the pre-release-aware default.
+- **A named level** (`patch`, `minor`, `major`, `stable`, `alpha`, `beta`, `rc`, `post`, `dev`) → use exactly that.
+- Otherwise infer the level from natural language (e.g. "bugfix release" → `patch`); ask once if ambiguous. Never auto-pick `major`.
+
+The exact semantics and the default rule live in `.cursor/skills/iflow-version-bump/SKILL.md` — that skill is the source of truth. When a bump applies: read it, then run the bump from the **project root** **after** the sanity check and **before** issue-folder updates and **before** commit / push / PR.
+
+## Changelog update tokens (command input)
+
+- **`nohistory`** or **`skip history`** → skip step 3 entirely.
+- **`log "..."`** or **`note "..."`** → override the bullet summary verbatim. Otherwise the GitHub issue title is used.
+
+## Branch switch tokens (command input)
+
+- **`stay`**, **`stay on branch`**, **`don't switch`**, or **`dont switch to main`** → after the PR step, stay on the issue branch instead of switching back to the default branch.
+
+## Hands-off token (command input)
+
+- **`yolo`** (used by `/iflow-yolo`) → close the loop without user input: write the `HISTORY.md` bullet without a confirm prompt (step 3), **merge the PR** right after opening it (step 8a), then switch back to the default branch and `git pull --ff-only` (step 9, unless `stay` was also passed).
+
+
+**Invoke:** type `iflow close` in chat, or `/iflow-close` from the slash menu (`iflow-close` also works).
+
+
+
+
+### MODEL & EXECUTION DIRECTIVE
+
+
+**Profile: economy** — Prioritize speed and token economy over deep reasoning.
+
+In Cursor: use **Auto** or a fast model before invoking this step.
+
+
+
+Keep scope tight to what this step requires.
+
+
+
+
+### Resolve project root (multi-root workspaces)
+
+Before any `git`, `gh`, or `.issueflows/` path operation in this workflow:
+
+**Resolution order** (stop when unambiguous):
+
+1. **Explicit hints** in slash input — `root:<path>`, `repo:<folder-basename>` (directory name, e.g. `cellpy-core`), or `repo:owner/name`.
+2. **CLI fast path** — `issue-flow agent resolve [-C <start>] [--from-file <active-file>] [--json]`. Use the returned `project_root` and `repo`; pass `-C <project_root>` to other `issue-flow agent …` subcommands. When the answer came from the workspace registry, the payload sets `resolved_via_workspace_default: true`.
+3. **Branch context** — exactly one workspace repo whose branch matches `^\d+-` → that root.
+4. **Single scaffold** — exactly one `.issueflows/` tree visible in the workspace → that root.
+5. **Workspace default** — an `issueflow-workspace.toml` at the workspace root (created with `issue-flow workspace init`) may name a `default` member repo; use it when no scaffold matched above. Tell the user the default was used.
+6. **Ambiguous** → **stop and ask**; never guess between sibling repos.
+
+After resolution, treat the result as `<project_root>` and `<owner/repo>`:
+
+- **Git:** `git -C <project_root> …` (or `issue-flow agent … -C <project_root>` for supported ops).
+- **GitHub:** always `gh … --repo <owner/repo>` — never rely on `gh`'s implicit cwd default.
+- **Paths:** all `.issueflows/…` paths are under `<project_root>`.
+
+When `.issueflows/04-designs-and-guides/multi-repo-workspaces.md` exists, read it for layout and cross-repo guidance.
+
+## Instructions
+
+1. **Sanity check** — Run the project test suite (e.g. `uv run pytest`) and any checks the repo relies on. **Ruff (when present):** if the project uses ruff (`[tool.ruff]` in `pyproject.toml`, ruff in dev dependencies, or `.issueflows/04-designs-and-guides/python-quality-tools.md` exists), run auto-fix lint through the documented Python runner before committing — e.g. `uv run ruff check --fix …` then `uv run ruff format …` (match paths to what the project documents). Skim the diff; avoid bundling unrelated changes. Confirm that any design decisions or good practices that emerged from this issue are captured under `.issueflows/04-designs-and-guides/` before committing.
+
+2. **Optional version bump** — If the user asked for a bump (see above), follow `.cursor/skills/iflow-version-bump/SKILL.md` — it resolves the project's **release strategy** first (the "Release & version bump" section of `.issueflows/04-designs-and-guides/this-project.md`, else `pyproject.toml` detection, else the uv default). **Static version:** run `uv version --bump <level>`. **Git-tag derived:** edit nothing — compute and report the **planned tag** (e.g. `v1.0.4a3`), record it in the status file, and defer creating it until after the merge (step 9 with `yolo`, else `/iflow-cleanup`). If neither strategy applies, skip and continue.
+
+3. **Update `HISTORY.md`** — Unless the user passed `nohistory`, follow `.cursor/skills/iflow-history-update/SKILL.md`. If step 2 did not bump (or plan) a version, append a bullet to the `## [Unreleased]` section. If step 2 bumped or planned a version, promote `## [Unreleased]` to `## [<new_version>] - <YYYY-MM-DD>` (for tag-derived projects use the planned tag's version) and open a fresh empty `## [Unreleased]` above it. Show the diff and confirm once before writing. Skip with a note if `HISTORY.md` does not exist at the project root. With the `yolo` token, do not ask — decide yourself and write the bullet (issue title, or `log "..."` text) directly.
+
+4. **Issue tracking** — Under `.issueflows/01-current-issues/`, update the status file: remaining work, checklists, and **`- [x] Done`** only when the issue is fully resolved. If fully resolved, move that issue's markdown files (`issue<n>_*`) to `.issueflows/03-solved-issues/`. If partially resolved, move to `.issueflows/02-partly-solved-issues/`. Follow any stricter rules in `.cursor/rules/issueflow-rules.mdc` if present.
+
+5. **Commit** — First check `git status`; if any changes are **not relevant** to this issue, tell the user which ones and ask whether to include them — do not auto-include or drop silently. Then stage intentionally (include `pyproject.toml` and `uv.lock` if changed after a bump, and `HISTORY.md` if step 3 updated it); write a commit message in full sentences describing what changed and why.
+
+6. **Branch hygiene before push** — Run `git fetch --prune`, then sync with the default branch using `git pull --ff-only` (rebase or merge per project preference). Use `--ff-only` so unrelated history never gets pulled in silently; if it refuses, stop and ask how to reconcile. Resolve merge conflicts before pushing.
+
+7. **Push** — Push to the remote the project uses (typically `origin`).
+
+8. **Pull request** — Open (or update) a PR against the default branch. Body should explain the change, how to test, and link the GitHub issue (`Closes #n` / `Refs #n`).
+
+8a. **Merge the PR (`yolo` token only)** — Merge immediately with `gh pr merge <number> --squash` (never `--delete-branch`; branch deletion stays in `/iflow-cleanup`). If GitHub refuses (branch protection, pending checks), fall back to `gh pr merge <number> --squash --auto` and report the merge as queued. If even `--auto` fails, stop the hands-off behaviour, report the error, and leave the PR open. Without the `yolo` token, skip this step — merging stays a user decision (step 10).
+
+9. **Switch back when safe** — If the input included `stay`, `stay on branch`, `don't switch`, or `dont switch to main`, stay on the issue branch and report that opt-out. Otherwise, after the PR is open or updated:
+   - **CLI fast path (preferred).** If the `issue-flow` CLI is on `PATH`, run `issue-flow agent switchback --json`. It performs this whole step deterministically: refuses while the working tree is dirty (listing the paths), else switches to the detected default branch and runs `git pull --ff-only`. On exit 1, report its `notes` to the user and stop — do not force anything.
+   - **Manual fallback.** Detect the default branch (prefer `gh repo view --json defaultBranchRef -q .defaultBranchRef.name`, else `git symbolic-ref --quiet --short refs/remotes/origin/HEAD`, else `main`). Run `git status --porcelain`; if clean, run `git switch <default>` and then `git pull --ff-only` (a clean tree here means the branch work has been committed and pushed to the PR branch). If dirty, stay on the current branch, list the uncommitted paths, and explain that switching is unsafe until those changes are committed, stashed, or discarded by the user.
+   - Never delete the issue branch here. With the `yolo` token this step runs **after** the merge from step 8a so the pull brings the squash commit into the local default branch (a queued auto-merge arrives later; note that).
+   - **Planned release tag (`yolo` + tag-derived strategy only):** if step 2 planned a tag, create it now — after the pull, standing on the squash commit — with `git tag <planned>` then `git push origin <planned>` (covered by the yolo consolidated confirm). If the merge was only queued via `--auto`, leave the tag to `/iflow-cleanup` and say so.
+
+10. **After review** — With the `yolo` token the PR was already merged in step 8a; skip to the `/iflow-cleanup` reminder. Otherwise address feedback, push updates, and merge when approved and CI is green. If step 9 switched back to the default branch, switch to the PR branch again before making review fixes. Tell the user to run **`/iflow-cleanup`** once the PR is merged so the standard post-merge cleanup runs (`git fetch --prune`, `git branch -d` on merged local branches under a single consolidated confirm — and, for tag-derived projects, the offer to create the release tag planned in step 2).
+
+11. **Output** — Summarize commit, push result, PR URL, whether the working copy switched back to the default branch or stayed on the issue branch, the merge result when `yolo` applied (merged, or queued via `--auto`), and next step (`/iflow-cleanup` after merge, or "blocked on …" if stuck).
+
+## Constraints
+
+- Do not skip failing tests without the user's explicit agreement.
+- Prefer focused commits; do not rewrite unrelated history unless asked.
+- Never delete branches from `/iflow-close`. Branch deletion belongs to `/iflow-cleanup`.

{cellpycore-0.1.4 → cellpycore-0.2.0}/.cursor/skills/iflow-comments/SKILL.md

@@ -1,24 +1,31 @@
 ---
 name: iflow-comments
 description: >-
-  Triage a GitHub issue's comment thread into a curated, bucketed summary
-  (additional tasks, clarifications, superseded) for inclusion in
-  issue<N>_original.md. Invoked by /iflow-init; also reusable when re-triaging
-  comments later in an issue's lifecycle.
+  Triage a GitHub issue's comment thread into the curated, bucketed summary
+  section of issue<N>_original.md.
 disable-model-invocation: true
+issue-flow-version: 0.4.2a4
 ---
 
 # issue-flow — issue comments triage
 
-Follow this skill when you need to turn a GitHub issue's comment thread into a short, decision-useful summary that lives next to the original issue body under `.issueflows/01-current-issues/issue<N>_original.md`.
+Follow this skill to turn a GitHub issue's comment thread into a short, decision-useful summary that lives next to the original issue body under `.issueflows/01-current-issues/issue<N>_original.md`.
 
-It is the playbook that `/iflow-init` (and the `iflow-init` skill) delegate to for anything beyond fetching raw comments.
+It is the playbook that `/iflow-init` (and the `iflow-init` skill) delegate to for anything beyond fetching raw comments. It also covers re-triage of an already-captured issue when new comments arrive (the issue body text stays unchanged; only the curated section is rewritten).
+
+
+### MODEL & EXECUTION DIRECTIVE
+
+
+**Profile: economy** — Prioritize speed and token economy over deep reasoning.
+
+In Cursor: use **Auto** or a fast model before invoking this step.
+
+
+
+Keep scope tight to what this step requires.
 
-## When to use
 
-- `/iflow-init` just fetched an issue with a non-empty `comments` array and needs to write the `## Comments (curated summary)` section.
-- You are re-running triage on an already-captured issue because new comments have arrived (the issue body text must stay unchanged; only the curated section is rewritten).
-- Any workflow that needs to understand "what does the comment thread actually ask us to do?" without pasting the raw thread into a file.
 
 ## Inputs
 
@@ -78,7 +85,6 @@ Formatting rules:
 - Each bucket's bullet is itself a list if there is more than one item — nest concrete bullets under the bold label.
 - **Drop any bucket that is empty** — do not leave `- **Additional tasks**: ` with no content.
 - **Always keep the `_Note: ..._` footer** when the section exists. Use the total `comments` length for `<count>` and the `author.login` + date of the most recent non-dropped comment for `@<login>` / `<date>`.
-- Use UTF-8 markdown. No leading/trailing blank lines inside the section beyond what's shown.
 
 ## Edge cases
 
@@ -92,5 +98,4 @@ Formatting rules:
 ## Constraints
 
 - This skill only writes into the `## Comments (curated summary)` section of `issue<N>_original.md`. It never touches the issue body, the status file, or the plan file.
-- It never calls `gh` itself — it expects the caller (`/iflow-init` or similar) to provide the comments JSON.
-- It never talks to the network beyond what the caller has already fetched.
+- It never calls `gh` or the network itself — it expects the caller (`/iflow-init` or similar) to provide the comments JSON.