cellpycore 0.1.1__tar.gz

cellpycore-0.1.1/.aliases

@@ -0,0 +1,56 @@
+# `release [patch|minor|major]`
+#
+# Cuts a GitHub release whose tag matches the *committed* project version, so
+# the git history and the published tags can never drift apart.
+#
+#   release              # tag the already-committed version (e.g. after `/issue-close patch`)
+#   release patch        # bump -> commit -> push -> tag, all in one consistent step
+#   release minor|major  # same, for the other bump levels
+#
+# Guards:
+#   - refuses to tag while a version bump is still uncommitted (the old alias
+#     silently dropped uncommitted bumps from history -> tag/repo drift);
+#   - refuses if the target tag already exists locally or on origin
+#     (this is what produced the confusing "tag already exists" error after a
+#     double bump from `/issue-close` + the release ritual).
+release() {
+    local level="${1:-}"
+
+    if [ -n "$level" ]; then
+        case "$level" in
+            patch|minor|major) ;;
+            *) echo "release: unknown bump level '$level' (use patch|minor|major)"; return 1 ;;
+        esac
+        if [ -n "$(git status --porcelain)" ]; then
+            echo "release: working tree is not clean; commit or stash before bumping."; return 1
+        fi
+        uv version --bump "$level" || return 1
+    fi
+
+    # Derive the version from pyproject AFTER any bump.
+    local ver
+    ver="$(python -c "import tomllib; print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])")" || return 1
+    local tag="v$ver"
+
+    # Commit the bump (if we made one) so the tag points at committed history.
+    if [ -n "$(git status --porcelain -- pyproject.toml uv.lock)" ]; then
+        if [ -n "$level" ]; then
+            git add pyproject.toml uv.lock || return 1
+            git commit -m "$tag" || return 1
+        else
+            echo "release: pyproject.toml/uv.lock has an uncommitted version change."
+            echo "         commit it first, or run: release patch|minor|major"
+            return 1
+        fi
+    fi
+
+    # Never re-create an existing tag.
+    if git rev-parse -q --verify "refs/tags/$tag" >/dev/null 2>&1 \
+       || git ls-remote --exit-code --tags origin "refs/tags/$tag" >/dev/null 2>&1; then
+        echo "release: tag $tag already exists. Bump the version first (release patch|minor|major)."
+        return 1
+    fi
+
+    git push || return 1
+    gh release create "$tag" --generate-notes
+}

cellpycore-0.1.1/.cursor/rules/cellpy-core-migration.mdc

@@ -0,0 +1,28 @@
+---
+description: Required reading before cross-repo cellpy <-> cellpy-core integration/migration work
+alwaysApply: true
+---
+
+# cellpy <-> cellpy-core migration
+
+Before doing **any** work that touches the boundary between `cellpy` (jepegit/cellpy)
+and `cellpy-core` (cellpy/cellpy-core) — wiring the dependency, the processing seam,
+shared headers/units, test/cell metadata, or "what belongs in core" — you MUST first
+read:
+
+`.issueflows/04-designs-and-guides/cellpy-core-migration.md`
+(and its companion `cellpy-core-integration-into-cellpy.md`).
+
+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.
+- **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,
+  `test_id`, helpers) but must NOT require populated metadata on its `Data`; attaching
+  real metadata to a data object is the next level's opt-in (e.g. cellpy v2.0). The
+  core engine must degrade gracefully when metadata is absent.

cellpycore-0.1.1/.cursor/rules/graphify.mdc

@@ -0,0 +1,10 @@
+---
+description: graphify knowledge graph context
+alwaysApply: true
+---
+
+This project has a graphify knowledge graph at graphify-out/.
+
+- Before answering architecture or codebase questions, read graphify-out/GRAPH_REPORT.md for god nodes and community structure
+- If graphify-out/wiki/index.md exists, navigate it instead of reading raw files
+- After modifying code files in this session, run `graphify update .` to keep the graph current (AST-only, no API cost)

cellpycore-0.1.1/.cursor/rules/issueflow-rules.mdc

@@ -0,0 +1,203 @@
+---
+description: Issue-flow workflow rules for LLMs
+globs:
+alwaysApply: true
+---
+
+
+# Issue-flow best practices
+
+
+## Running python
+
+**Respect the project's existing toolchain first.** If this project already
+documents how to run Python and manage dependencies — in its `README`,
+`AGENTS.md`, `CLAUDE.md`, `.cursor/rules`, `environment.yml`, `pyproject.toml`,
+`Makefile`, CI config, etc. — **follow that**, even where it conflicts with the
+defaults below. These rules describe issue-flow's *default* assumptions, not a
+mandate to override a project that has already chosen differently.
+
+The one tool-neutral principle: **don't call bare `python ...`** — invoke Python
+through the project's environment (its runner, or an activated virtualenv/conda
+env) so scripts and tests see the right interpreter and dependencies.
+
+### If the project uses conda
+
+When the project documents a conda environment, run **all** Python commands —
+scripts **and `pytest`** — inside the **activated conda environment**. Do **not**
+substitute `uv run`.
+
+```bash
+# Either activate the environment first…
+conda activate <env-name>
+python run_script.py
+pytest
+
+# …or run one-off commands inside it:
+conda run -n <env-name> pytest
+```
+
+### If the project uses uv (issue-flow's default)
+
+For projects scaffolded fresh (and this is the default when nothing else is
+documented), use `uv`:
+
+```bash
+# ❌ BAD: bare interpreter
+python run_script.py
+
+# ✅ GOOD: through uv
+uv run run_script.py
+```
+
+**Package management with `uv`**
+
+- Install, synchronize, and lock dependencies with `uv`; don't reach for `pip`,
+  `pip-tools`, or `poetry` in a uv-managed project.
+
+```bash
+# Add or upgrade dependencies
+uv add <package>
+
+# Remove dependencies
+uv remove <package>
+
+# Reinstall all dependencies from the lock file
+uv sync
+
+# Run a script with the right environment
+uv run script.py
+```
+
+### Other toolchains (plain venv / pip / poetry)
+
+If the project uses something else, use whatever it documents (e.g. activate its
+`.venv` and use `pip`, or run `poetry run`). Match the project; don't force `uv`.
+
+
+## Issue tracking structure
+
+```bash
+cellpycore/
+    .issueflows/
+        00-tools/
+        01-current-issues/
+            issueXX_original.md
+            issueXX_status.md
+        02-partly-solved-issues/
+        03-solved-issues/
+        04-designs-and-guides/
+    pyproject.toml
+    readme.md
+    ...
+```
+
+
+## Development information
+
+
+### Working on issues
+
+After each iteration, update the documents in `.issueflows/01-current-issues` (should contain one file labelled `_original` with the original issue description, a `_plan` file with the confirmed approach, and supplementary status files describing what has been done, current status, and remaining work).
+Use an explicit status checkbox in the status file:
+- `- [x] Done` when fully resolved
+- `- [ ] Done` when not fully resolved
+
+### 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 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.
+
+The full slash-command lifecycle is:
+
+1. **`/iflow-init`** — capture the GitHub issue as `issue<N>_original.md`.
+2. **`/iflow-plan`** — design the approach in `issue<N>_plan.md` and get explicit confirmation before any code changes.
+3. **`/iflow-start`** — implement the confirmed plan. Asks to run `/iflow-plan` first if the plan file is missing.
+4. **`/iflow-pause`** *(optional)* — park work mid-stream: update status, move the issue group to `02-partly-solved-issues`, optional WIP commit.
+5. **`/iflow-close`** — tests, optional `uv version --bump`, status update, commit, push, PR. Does not delete branches.
+6. **`/iflow-cleanup`** — post-merge: switch to default, `git pull --ff-only`, `git fetch --prune`, `git branch -d` on merged local branches under a single consolidated confirm. Never `-D`.
+
+`/iflow-yolo` chains `init → plan → start → close` for small, low-risk issues with up-front safeguards (clean tree, passing tests, single consolidated confirm).
+
+`/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.
+
+> 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
+
+If the issue is fully resolved (no additional subtasks present), move the original, plan, and status markdown files to `.issueflows/03-solved-issues`. Else, move them to `.issueflows/02-partly-solved-issues`.
+
+### Scripts that can help us when working on issues
+
+`.issueflows/00-tools/` is the project's durable toolbox of reusable helper scripts, with a `README.md` index describing each one.
+
+- **Check it first.** Before writing a new one-off helper for an issue, skim the `00-tools/README.md` index and the folder — a suitable tool may already exist.
+- **Contribute back.** If you build something during an issue that could help on a future one, save it into `.issueflows/00-tools/` and add a one-line entry to the index (name, what it does, when to use it) so the next agent knows whether to reach for it.
+
+
+
+### Optional response styles
+
+A **caveman** Agent Skill is installed under `.cursor/skills/caveman/` and
+is **on by default for this project**: reply in the terse, "token-greedy" caveman
+style — keep all technical substance, drop filler, articles, and pleasantries —
+from the first message of every session, re-arming each new session. Turn it off
+for the rest of a session with **"stop caveman"** or **"normal mode"**. Code,
+commits, PRs, security warnings, and destructive-action confirmations are always
+written in normal prose, never caveman. (This default comes from
+`caveman_default = true` under `[issueflow]` in `.issueflows/config.toml`;
+set it to `false` and re-run `issue-flow update` to make caveman opt-in per
+session instead.)
+
+
+
+
+### Planning aids
+
+A **grill-me** Agent Skill is installed under `.cursor/skills/grill-me/`.
+It runs a relentless planning interview that stress-tests a plan or design —
+one question at a time, each with a recommended answer — until every branch of
+the decision tree is resolved. It is **off by default** and only kicks in when
+you ask for it (e.g. "grill me", "poke holes in this"). Turn it off with **"stop
+grilling"** or **"normal mode"**. (To make grilling on by default during planning
+for this project, set `grill_me_default = true` under `[issueflow]` in
+`.issueflows/config.toml` and re-run `issue-flow update`.)
+
+
+
+### Designs and guides
+
+Long-lived design docs, design decisions, and project "good practices" live under `.issueflows/04-designs-and-guides/`. Unlike the issue folders, content here is **not** tied to a single issue and is **not** archived when an issue closes — it is the project's durable memory.
+
+- **Project brief:** if `.issueflows/04-designs-and-guides/this-project.md` exists, read it early for project-specific context (what the repo is, stack/runtime, how to run/test, conventions, entry points, and known limitations).
+- **Before planning or implementing**, skim `.issueflows/04-designs-and-guides/` for existing docs relevant to the current issue and follow them (cite them in the plan when they influence the approach).
+- **When a non-trivial design decision is made** during `/iflow-plan` or `/iflow-start`, add or update a markdown file here. Keep entries terse: context, the decision, alternatives considered, and a link back to the issue.
+- **Never overwritten by `issue-flow update`.** The folder is recreated if missing, but existing files are left alone.
+
+
+### Branch hygiene
+
+- Do issue work on an **issue branch** named like `<N>-<short-slug>`, not on the default branch.
+- Before starting or continuing work on an issue branch, run `git fetch --prune` and check where the branch sits relative to `origin/<default>` (ahead/behind). A branch that is "several commits ahead" after a merged PR usually means the PR was squash-merged and the local branch is stale.
+- **Assume squash-merges on GitHub.** After a PR merges: run **`/iflow-cleanup`** — it switches to the default branch, runs `git pull --ff-only`, `git fetch --prune`, and deletes merged local branches with `git branch -d <branch>` under a single consolidated confirm (never `-D` automatically). `/iflow-close` no longer does this step itself.
+- If an issue is already archived under `.issueflows/02-partly-solved-issues` or `.issueflows/03-solved-issues`, the matching local branch is stale; don't resume work on it silently — switch back to the default branch and, if the issue really needs re-opening, do it deliberately through `/iflow-init` (which will ask for a second confirmation).
+
+
+### Folder hygiene for `.issueflows/01-current-issues`
+
+- Only the **focus issue** (the one currently being worked on) should live in `.issueflows/01-current-issues`.
+- `/iflow-init` and `/iflow-start` both sweep that folder automatically: every `issue<n>_*` group **other than the focus issue** is moved to `.issueflows/03-solved-issues` if a status file contains `- [x] Done`, otherwise to `.issueflows/02-partly-solved-issues`. Keep status files accurate so the sweep routes them correctly.
+
+
+### Knowledge graph (optional, via [graphify](https://iflow-graphify.net))
+
+If a `graphify-out/` folder exists in the project root, the project has the optional [graphify](https://iflow-graphify.net) integration enabled and a knowledge graph is available alongside the source.
+
+- **Before grepping**, skim `graphify-out/GRAPH_REPORT.md`. It surfaces god-nodes (most-connected concepts), surprising cross-module connections, and suggested questions the graph can answer — often a faster way to locate the files an issue actually touches than full-text search.
+- **`/iflow-graphify`** (slash command) or **`issue-flow graphify`** (CLI) rebuild the graph. With no extra args this runs `graphify update <project>` — AST-only, **no LLM API key needed**. For richer semantic relationships (cross-file links surfaced by an LLM pass), run `issue-flow graphify extract` after setting `GEMINI_API_KEY` / `ANTHROPIC_API_KEY` / `OPENAI_API_KEY` / `MOONSHOT_API_KEY` (or pass `--backend ollama` for a local LLM). Other subcommands: `watch` (live), `cluster-only --no-viz` (re-cluster). Trailing flags pass through verbatim. Your agent's own LLM cannot be reused by subprocesses; graphify needs its own backend.
+- `/iflow-graphify` is **off-path**: never auto-dispatched by `/iflow`, `/iflow-start`, or `/iflow-close`. It is the user's call. `/iflow-start` may *suggest* skimming `GRAPH_REPORT.md`; `/iflow-close` may *suggest* a rebuild after large structural changes — neither runs `graphify` automatically.
+- If `graphify-out/` is not present, ignore graph-related guidance entirely. The integration is opt-in (install with `uv tool install graphifyy`, then `issue-flow update` to register the graphify skill).
+

cellpycore-0.1.1/.cursor/rules/kiss.mdc

@@ -0,0 +1,101 @@
+---
+description:
+globs:
+alwaysApply: true
+---
+
+<!-- 
+Description: Global KISS development rules to prevent over-engineering and enforce simple, maintainable solutions across all projects.
+Auto-attach: true
+-->
+
+KISS PRIME DIRECTIVE
+Keep every change simple, evidence-based, and reproducible.
+
+Solution Design and Scope Control
+- **Scope-First Principle**: Before coding, ask "What's the simplest thing that could work?"
+- **File Budget**: For tasks <50 lines total, use MAX 1 existing file or create MAX 1 new file
+- **Dependency Budget**: Don't add dependencies for stdlib-solvable operations
+- **Abstraction Budget**: No classes/modules/frameworks for one-time operations  
+- **Research Time-Box**: MAX 10 minutes researching before trying obvious solution
+
+Complexity Prevention
+- **Start with stdlib**: Can `shutil`, `pathlib`, `os`, `json` solve this? Do that first.
+- **Question every layer**: Do I need a function/class/module? Usually no for <20 line operations.
+- **Match project scale**: Small codebases get small solutions; don't over-architect.
+- **Prototype first**: Write inline/script before creating abstractions.
+
+Before Creating Any New File:
+1. Can this be 5-10 lines added to existing file?
+2. Am I solving a problem that doesn't exist yet?  
+3. Would a junior developer understand immediately?
+4. Does this match existing codebase complexity?
+
+- No invented data or code to mask failures; focus on root cause and add tests.
+- Remove dead or duplicated code promptly.
+- Use Conventional Commits; prefer squash merges for clean history.
+
+Dependencies
+- Make dependencies explicit; update requirements.txt or lockfiles immediately on changes.
+- List only third-party packages (exclude standard library).
+- Pin minimum compatible versions for stability; use a lockfile (e.g., pip-tools/uv) when reproducibility is required.
+
+Testing
+- Run tests after substantive edits; keep the suite green.
+- Add tests for new behavior and edge cases before or with the change.
+- Use automated testing (unit/integration/e2e as appropriate); prefer CI to enforce.
+
+Logging and Error Handling
+- Use project loggers, not prints; include actionable context (counts, paths, IDs).
+- Fail fast on invalid config or inputs; never silently auto-correct.
+- Follow log levels best practices (debug, info, warning, error, critical).
+
+IO and Artifacts
+- Treat input data directories as read-only; write derived artifacts to an output/ folder.
+- Avoid committing large generated files or runtime outputs to version control.
+- Project rules may redefine exact paths and modes (dry-run/live, backups).
+
+Platform and Paths
+- Avoid hard-coded, user-specific absolute paths; externalize to config.
+- Use cross-platform path APIs for portability.
+
+Code Style and Quality
+- Match project style consistently; use automated tools (linters/formatters) when available.
+- Prefer early returns, shallow nesting, and meaningful naming.
+- Avoid bare except; handle exceptions explicitly.
+- Maintain concise docstrings focused on behavior and intent.
+
+Operational Safeguards (minimal)
+- Dry-run and backups
+  - Do: provide a dry-run that exercises the flow without mutating prod; create and verify a backup before writes; log backup paths and intended changes.
+  - Don't: modify prod without a backup/restore path; label runs "dry" if they mutate state.
+- Feature-gated behavior
+  - Do: ship new behavior behind a default-off flag; add tests for old/new paths; document enable/disable steps.
+  - Don't: change defaults silently; ship behavior that cannot be turned off.
+- Config/schema safety
+  - Do: validate config strictly (types, required keys, unknown keys = error); version config/schema when behavior changes; make migrations reversible and tested.
+  - Don't: auto-migrate without backups/logs; accept unknown config keys; make irreversible schema changes.
+
+Collaboration and Workflow
+- Read project docs and tests before changes; preserve stated invariants.
+- Encourage peer reviews for risky or substantial changes.
+- Propose and document plans for risky IO/DB changes; provide OS-appropriate, non-interactive commands.
+
+Security and Scalability
+- Integrate basic security hygiene (e.g., dependency scans like pip-audit/dependabot).
+- Patch vulnerabilities promptly; remove unused deps.
+- Prefer simple, modular designs; avoid microservices or heavy patterns unless clearly justified.
+
+Documentation Standards
+1) Project-Level README
+- Include: purpose/scope, setup, example usage, directory structure, and ownership/contact.
+
+2) Configuration Reference and Runbook
+- Include: config keys with types/defaults, example configs, dry-run/live procedures, backup/restore steps, and common recovery actions.
+
+3) Change Logs and Versioning
+- Maintain a CHANGELOG.md or use tags/releases to track features, fixes, and breaking changes.
+
+Conflict Resolution
+- This global rule is the default. Project rules in .cursor/rules may override specifics (paths, workflows, tooling).
+

cellpycore-0.1.1/.cursor/rules/this-project.mdc

@@ -0,0 +1,41 @@
+---
+description: cellpy-core project overview, environment/tooling (uv, .venv), repo layout, and docstring conventions.
+globs:
+alwaysApply: true
+---
+
+
+This is a python project. And it uses a python environment (.venv). Rember to activate it! We
+also have uv installed. Use uv if you want. If not, just do the normal "source .venv/Scripts/activate" (assuming you are in the top directory). The project uses the common structure for python projects, where the main code is in the src/cellpycore folder and tests are in the tests folder. And docs are in the docs folder. Again, assuming you are in the top directory of this repository.
+
+This library is to be used as a core part of a larger library (cellpy) that should read cell testing data from battery testers. It implements the core functionallity: finding all the steps and cycles and creating tables containing information pr step or pr cycle. It should run fast. And it should be easy for developers of the full cellpy library to use and extend it. It should be thread safe. It should be understandable.
+
+## Docstrings
+
+Use **Google-style** docstrings everywhere (this matches both `cellpy-core` and the old `cellpy` codebase). Do not use NumPy-style (underlined section headers) or plain reST field lists (`:param:` / `:return:`).
+
+Rules:
+- Start with a one-line summary, then an optional blank line and longer description.
+- Use these section headers (a header line ending in a colon, followed by an indented block): `Args:`, `Returns:`, `Raises:`, `Yields:`, `Attributes:` (for classes / enums), `Example:`, `Note:`.
+- In `Args:`, write each parameter as `name (type): description`. The `(type)` is optional when the signature already has a type hint, but stay consistent within a function.
+- Wrap code-like tokens (types, values, identifiers) in double backticks, e.g. ``` ``pandas.DataFrame`` ```, ``` ``"anode"`` ```.
+- Keep them concise and focused on behavior and intent, not a restatement of the code.
+
+Example:
+
+```python
+def find_steps(data, schema=None):
+    """Find all steps in the raw data and build the step table.
+
+    Args:
+        data (Data): The data object to process.
+        schema: The column-header schema to use. Defaults to the native
+            cellpy-core schema when not provided.
+
+    Returns:
+        Data: The data object with the step table added.
+
+    Raises:
+        NoDataFound: If the data object has no raw data.
+    """
+```

cellpycore-0.1.1/.cursor/skills/caveman/SKILL.md

@@ -0,0 +1,62 @@
+---
+name: caveman
+description: >-
+  Respond in a terse "smart caveman" style that keeps all technical substance
+  but drops filler, articles, and pleasantries. Use when the user asks for
+  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".
+---
+
+# Be token greedy - as a caveman
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE once turned on. No revert after many turns. No filler drift. Still active if unsure. Off only: "stop caveman" / "normal mode".
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). No tool-call narration, no decorative tables/emoji, no dumping long raw error logs unless asked — quote shortest decisive line. Standard well-known tech acronyms OK (DB/API/HTTP); never invent new abbreviations reader can't decode. Technical terms exact. Code blocks unchanged. Errors quoted exact.
+
+No self-reference. Never name or announce the style. No "caveman mode on", "me caveman think", no third-person caveman tags. Output caveman-only — never normal answer plus "Caveman:" recap. Exception: user explicitly ask what the mode is.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+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.
+
+Example — "Why React component re-render?"
+- "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
+
+Example — "Explain database connection pooling."
+- "Pool reuse open DB connections. No new connection per request. Skip handshake overhead."
+
+## Auto-Clarity
+
+Drop caveman when:
+- Security warnings
+- Irreversible action confirmations
+- Multi-step sequences where fragment order or omitted conjunctions risk misread
+- Compression itself creates technical ambiguity (e.g., `"migrate table drop column backup first"` — order unclear without articles/conjunctions)
+- User asks to clarify or repeats question
+
+Resume caveman after clear part done.
+
+Example — destructive op:
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+> ```sql
+> DROP TABLE users;
+> ```
+> Caveman resume. Verify backup exist first.
+
+## Boundaries
+
+Code/commits/PRs: write normal. "stop caveman" or "normal mode": revert. Mode persist until changed or session end.

cellpycore-0.1.1/.cursor/skills/grill-me/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: grill-me
+description: >-
+  Interview the user relentlessly about a plan or design until every branch of
+  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".
+---
+
+# Grill me — relentless planning interview
+
+Interview the user about every aspect of the plan until you reach a shared,
+unambiguous understanding. Walk down each branch of the design tree, resolving
+dependencies between decisions one at a time. The goal is to surface hidden
+assumptions and edge cases **before** they get encoded in code or written into
+`.issueflows/01-current-issues/issue<N>_plan.md`.
+
+## When to use
+
+- The user asks to be grilled / stress-tested ("grill me", "poke holes in this").
+- During `/iflow-plan`, when grilling is active (see *Activation* below), to
+  pressure-test the approach before the plan file is drafted.
+
+## How to grill
+
+- **One question at a time.** Never batch questions. Wait for the answer before
+  moving to the next branch.
+- **Always recommend an answer.** For each question, give your recommended option
+  and a one-line rationale, so the user can accept quickly or push back.
+- **Explore before asking.** If a question can be answered by reading the code,
+  the issue text, or `.issueflows/04-designs-and-guides/`, explore first
+  and confirm what you found instead of asking the user to do your homework.
+- **Follow the decision tree.** Resolve upstream decisions before the ones that
+  depend on them; let earlier answers prune later branches.
+- **Stay on scope.** Grill the issue at hand. Park genuinely separate concerns as
+  follow-up notes rather than expanding the interview indefinitely.
+- **Know when to stop.** End when every open branch is resolved (or explicitly
+  deferred) and you can restate the plan without ambiguity. Summarize the agreed
+  decisions so they can flow straight into the plan.
+
+## Activation
+
+This skill is **dormant by default**: it engages only when the user asks for it
+("grill me") or when a project turns it on for planning.
+
+Turn it off again for the rest of a session with **"stop grilling"** or
+**"normal mode"**. (To make grilling on by default during planning for this
+project, set `grill_me_default = true` under `[issueflow]` in
+`.issueflows/config.toml` and re-run `issue-flow update`.)
+
+
+## Boundaries
+
+- Grilling is a **planning** aid: it questions and aligns, it does not write code.
+- Hand the agreed decisions to `/iflow-plan` so they land in `issue<N>_plan.md`;
+  implementation still goes through `/iflow-start`.

cellpycore-0.1.1/.cursor/skills/iflow/SKILL.md

@@ -0,0 +1,64 @@
+---
+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.
+disable-model-invocation: true
+---
+
+# 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.
+
+## When to use
+
+- 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`.)
+
+## Instructions
+
+> **CLI fast path (optional).** If the `issue-flow` CLI is on `PATH`, run
+> `issue-flow agent state --json` to resolve the focus issue, its lifecycle
+> stage, and the suggested `next_command` in one deterministic step (covers
+> instructions 1–2), then dispatch to that command. The CLI is optional: if it
+> is not installed or it errors, fall back to the manual instructions below.
+> (`issue-flow` is only present when the user installed it, e.g.
+> `uv tool install issue-flow`.)
+
+1. **Resolve the focus issue number `N`.**
+   - `git branch --show-current`. If it matches `^(\d+)-.+`, the leading digits are the **authoritative** `N`.
+   - List `issue<n>_*` groups in `.issueflows/01-current-issues/`, and also check `.issueflows/02-partly-solved-issues/` and `.issueflows/03-solved-issues/` for archived groups matching `N`.
+   - Pick `N` by precedence:
+     1. **Branch-derived `N` wins**, regardless of whether a group for `N` exists in `01-current-issues/`. State **A** will apply when no `issue<N>_*` files are present yet. If `issue<N>_*` is archived under `02-partly-solved-issues/` or `03-solved-issues/`, warn the user that `/iflow-init`'s archived-issue guard will ask for an explicit confirmation before re-opening.
+     2. No branch-derived `N`, exactly one group exists in `01-current-issues/` → use it.
+     3. No branch-derived `N`, no groups at all → state **A** (dispatch `/iflow-init`; it will ask for a number).
+     4. No branch-derived `N`, multiple groups → **stop and ask**.
+
+2. **Detect state and choose the dispatch target** (first match wins):
+
+   - **A** — no `issue<N>_original.md` (or no focus issue) → dispatch to **`/iflow-init`**. Reason: "no `*_original.md` yet".
+   - **B** — original exists, no `issue<N>_plan.md` → dispatch to **`/iflow-plan`**. Reason: "no plan file yet".
+   - **C** — plan exists, and status file is missing or its `- [x] Done` is unchecked → dispatch to **`/iflow-start`**. Reason: "plan is confirmed but status is not `- [x] Done`".
+   - **D** — status file contains `- [x] Done` (case-insensitive on `done`) → dispatch to **`/iflow-close`**. Reason: "status marks the issue `- [x] Done`".
+
+
+3. **Announce and dispatch.** Print one line like `/iflow -> /iflow-plan  (issue #N: no plan file yet)` and then follow the chosen command's playbook. Forward the user's trailing text verbatim.
+
+4. **Respect downstream checkpoints.** Never suppress the downstream command's own prompts (plan confirmation, unrelated-changes prompt, etc.). `/iflow` adds no new confirmation layer of its own.
+
+5. **Report.** Summarize: focus issue `N` and how it was resolved, which command was dispatched and why, the downstream output, and a one-line hint when an off-path command is the natural next step:
+   - state **D** + PR likely merged → "after the PR merges, run `/iflow-cleanup`"
+   - mid-stream context switch needed → "to park this work, run `/iflow-pause`"
+   - tiny fix that would benefit from a single-shot chain → "consider `/iflow-yolo` next time"
+
+## Constraints
+
+- Never auto-dispatch to `/iflow-pick`, `/iflow-pause`, `/iflow-cleanup`, `/iflow-yolo`, or `/iflow-fix`.
+- If the focus issue cannot be resolved (multiple groups, branch ambiguous), stop and ask.
+- Do not modify files beyond what the downstream command would normally modify. `/iflow` itself writes nothing — all file changes come from the dispatched command.
+- Dispatch to at most one command per `/iflow` invocation.