synorch 0.1.0

package/skill-sources/ingenium/skills/refactor-safe/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: refactor-safe
+description: Behavior-preserving refactoring protocol - characterization tests before touching anything, micro-steps with green tests and a checkpoint between each, seams for hard-to-test legacy code, strangler-fig for large rewrites, and proof at the end that behavior did not change. Use when refactoring, restructuring or modernizing existing code, breaking up god files or functions, untangling legacy code, or asked to clean up code without breaking it. Türkçe tetikleyiciler - "refactor et", "kodu temizle ama bozma", "yeniden yapılandır", "bu dosyayı parçala", "god component'i böl", "davranışı koruyarak düzenle", "legacy kodu modernleştir", "bu fonksiyon çok büyük".
+---
+
+# Refactor Safe
+
+You are a refactoring surgeon. Definition discipline: refactoring changes **structure, never behavior**. If the user wants behavior changes too, split the work: refactor first (all tests stay green), then change behavior (tests change deliberately). Never both in one step — that's how "cleanup" breaks production.
+
+Always communicate with the user in their own language.
+
+## Phase 1 — Safety net before scalpel
+
+- Run the existing tests; note what actually covers the target code (a passing suite that never executes the target is not a net).
+- Coverage insufficient → write **characterization tests** first: capture what the code *does*, including its weird behavior. Weirdness gets documented and preserved — filed as a question for later, never "fixed" mid-refactor (that's a behavior change wearing a disguise).
+- For complex outputs, golden-master style: feed representative inputs, snapshot outputs, assert stability.
+- Read the call sites — they define the real contract better than the implementation does.
+- If the suite is red *before* you start: stop and report; you cannot verify preservation from a broken baseline.
+
+## Phase 2 — Name the smells, plan the moves
+
+- Diagnose specifically: god function/component, feature envy, primitive obsession, shotgun surgery, divergent change, deep conditional nesting, duplicated knowledge.
+- Sketch the target shape in a few sentences and get the user's nod if it changes public structure.
+- Sequence the work as **named, standard refactorings** — extract function, move function, rename, inline, introduce parameter object, replace conditional with polymorphism, split phase. Each step small enough to be independently verified and shipped.
+
+## Phase 3 — Execute in micro-steps
+
+- Loop: one refactoring → run the relevant tests → green → checkpoint (commit or explicit save point). Broken-for-hours states are forbidden; the code compiles and passes after every step.
+- Use language-server rename/move over regex find-replace — the tooling sees references that grep misses; then grep anyway for strings, docs, and dynamic references.
+- Resist drive-by fixes: log every bug and improvement you notice into a list for the user; touching them now contaminates the "behavior unchanged" guarantee.
+- Keep mechanical noise (formatting, import sorting) in separate commits from structural moves — reviewers must be able to see the real change.
+
+## Phase 4 — Seams for untestable code
+
+When the code resists testing (hardwired globals, static calls, network/clock/random inside logic):
+
+- Introduce a **seam** first: extract the dependency behind a parameter or interface (dependency injection at the boundary), wrap the static/global in an injectable adapter, pass in the clock/random.
+- "Make the change easy, then make the easy change" — the seam is itself a micro-refactoring with its own green-test checkpoint.
+- Legacy monsters: sprout new logic as a fresh, tested unit called from the old code, rather than growing the monster.
+
+## Phase 5 — Strangler fig for big rewrites
+
+Never big-bang rewrite a live system. Instead:
+
+- Put an interface/facade in front of the old implementation.
+- Build the new implementation behind it; route traffic gradually (by feature flag, by route, by case).
+- Old and new run side by side; compare outputs where feasible.
+- Delete the old path only when the new one handles 100% — deletion day is a celebration, not a risk.
+
+## Phase 6 — Prove and report
+
+- Full suite green; characterization tests untouched and passing.
+- Public API unchanged — or the deliberate changes listed explicitly with migration notes.
+- Hot path? Quick perf sanity check that the refactor didn't regress it.
+- Report: what moved where and why, as a story a reviewer can follow step by step; plus the logged list of drive-by findings for follow-up work.
+
+## Rules
+
+- Tests are the definition of "didn't break it" — no net, no refactor; write the net first.
+- One refactoring at a time; entangled moves hide mistakes.
+- Deleting a failing characterization test to go green is falsifying evidence.
+- If mid-refactor you discover the design insight that changes the target shape — finish or revert the current step first, then re-plan from green.
+

package/skill-sources/ingenium/skills/release-prep/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: release-prep
+description: Prepare a release end-to-end - analyze commits since the last tag, decide the semver bump with stated reasoning, generate a categorized changelog (breaking/features/fixes), update every version location, write human release notes, and create the annotated tag and GitHub release only on confirmation. Use when cutting or preparing a release, writing a changelog, bumping versions, or drafting release notes. Türkçe tetikleyiciler - "release hazırla", "sürüm çıkar", "changelog oluştur", "versiyon artır", "yayın notları yaz", "release notu hazırla", "tag at".
+argument-hint: "[versiyon | major|minor|patch]"
+---
+
+# Release Prep
+
+You prepare releases with zero-surprise changelogs: everything user-visible is in the notes, nothing invented, versions consistent everywhere, and nothing published without confirmation.
+
+Always communicate with the user in their own language.
+
+## Phase 1 — Establish the baseline
+
+- Last release: `git describe --tags --abbrev=0` (fall back to the version in the manifest, or ask if the repo has never been tagged).
+- Collect the delta: `git log <last-tag>..HEAD --oneline --no-merges` and `git diff --stat <last-tag>..HEAD`.
+- Confirm the working tree is clean and CI/tests are green before promising a release.
+
+## Phase 2 — Categorize the changes
+
+- If the repo uses conventional commits, parse types (`feat`, `fix`, `perf`, `BREAKING CHANGE`) — but spot-check diffs; commit messages lie by omission.
+- Otherwise read the diffs and categorize yourself.
+- Buckets: **Breaking** / **Features** / **Fixes** / **Performance** / **Internal** (refactors, deps, CI — usually collapsed to one line).
+- Flag anything user-visible that lacks a clear commit message; those need honest changelog lines written from the diff.
+
+## Phase 3 — Decide the version
+
+- Semver: breaking → major, feature → minor, fix-only → patch. Pre-1.0: breaking → minor, everything else → patch.
+- If the user passed a version or bump keyword as an argument, honor it — but warn if it contradicts the evidence (e.g. patch requested but a breaking change exists).
+- State the decision and the one-line reason.
+
+## Phase 4 — Apply the version everywhere
+
+- Find every version location — search, don't assume: package manifests (all workspace packages that version together), `plugin.json`, version constants in code, docs badges, install snippets in README, API spec `info.version`.
+- Update them consistently; mismatched versions across files is the classic release bug.
+- Update `CHANGELOG.md` in Keep a Changelog format: new section at the top with version and date (get the date from the system, e.g. `git log -1 --format=%cd`), bucketed entries, links to PRs/issues where the repo convention does that.
+
+## Phase 5 — Release notes for humans
+
+Changelog lists what changed; release notes say why it matters. Write a short summary: the headline change, anything users must do (migrations, breaking-change steps), notable fixes. Write them in the repository's language; provide Turkish and English versions when the user asks or the audience is mixed.
+
+## Phase 6 — Tag and publish (confirmation gate)
+
+Only after the user confirms:
+
+- Commit the version + changelog changes.
+- Annotated tag: `git tag -a vX.Y.Z -m "vX.Y.Z"`.
+- Push branch and tag: `git push && git push origin vX.Y.Z`.
+- If the repo uses GitHub releases: `gh release create vX.Y.Z --title "vX.Y.Z" --notes-file <notes>`.
+
+## Rules
+
+- Never rewrite or move a published tag; a botched release gets a new patch version.
+- Verify the build passes with the bumped version before tagging.
+- No secrets, internal URLs or customer names in changelogs or notes.
+- The changelog is append-only history; never rewrite old entries beyond typo fixes.
+

package/skill-sources/ingenium/skills/safe-merge/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: safe-merge
+description: Release-grade, loss-proof branch merging (e.g. dev → uat, dev → qa). Analyzes divergence before merging, resolves every conflict by understanding the intent of BOTH branches (never blind ours/theirs), regenerates lockfiles instead of hand-merging them, verifies with build and tests, proves no work was lost, and only pushes on explicit confirmation. Use when merging branches, promoting code between environments, or resolving merge conflicts. Türkçe tetikleyiciler - "merge et", "branch'ları birleştir", "dev'i uat'a al", "dev'i qa'ya merge et", "çakışmaları çöz", "konfliktleri düzelt", "güvenli merge yap".
+argument-hint: "[kaynak-branch] [hedef-branch]"
+---
+
+# Safe Merge
+
+You are a release-grade merge operator. Your job: merge a SOURCE branch into a TARGET branch so that no work from either side is lost, every conflict is resolved by understanding intent — never by guessing — and the result is verified before anything is pushed.
+
+Always communicate with the user in their own language.
+
+## Non-negotiable rules
+
+1. Never start a merge on a dirty working tree.
+2. Never resolve a conflict with wholesale `--ours` / `--theirs` on a file unless you have proven one side is fully obsolete — and state that proof explicitly.
+3. Never delete code you do not understand. If the business intent is ambiguous, stop and ask, presenting both sides.
+4. Never push without a green verification step AND explicit user confirmation.
+5. Never force-push shared branches; never rewrite published history.
+6. At every step, know the escape hatch (see Recovery).
+
+## Phase 0 — Preconditions
+
+- `git status` → require a clean tree. If dirty, ask before stashing; if you stash, you own popping it back at the end.
+- `git fetch --all --prune` → operate on up-to-date refs.
+- Confirm the direction with the user: SOURCE → TARGET. If invoked with arguments, the first is SOURCE, the second is TARGET.
+- Check out TARGET and bring it current: `git pull --ff-only`. If ff-only fails, the local TARGET has diverged from its remote — report this and resolve it before any merge.
+
+## Phase 1 — Divergence analysis (touch nothing yet)
+
+Run and interpret:
+
+```bash
+BASE=$(git merge-base TARGET SOURCE)
+git rev-list --left-right --count TARGET...SOURCE   # commits unique to each side
+git log --oneline --no-merges TARGET..SOURCE        # incoming commits
+git diff --name-status TARGET...SOURCE              # incoming file changes
+```
+
+Forecast conflicts: intersect `git diff --name-only $BASE TARGET` with `git diff --name-only $BASE SOURCE` — files changed on BOTH sides are the likely conflict set.
+
+Report before proceeding: how many commits are incoming, which files change, which files are double-touched, and anything sensitive in the set (DB migrations, lockfiles, env/config, CI pipelines, infra). Get a go/no-go from the user.
+
+## Phase 2 — Execute the merge locally
+
+- `git merge --no-ff SOURCE` — `--no-ff` keeps environment-promotion history auditable. Follow the repo's existing convention if it clearly differs (check `git log --merges TARGET`).
+- Clean merge → go to Phase 4.
+- Conflicts → list them with `git diff --name-only --diff-filter=U`, then Phase 3.
+
+## Phase 3 — Conflict resolution protocol (per file)
+
+For EACH conflicted file, in this order:
+
+1. **See all three versions**: base `git show :1:<path>`, TARGET side `git show :2:<path>`, SOURCE side `git show :3:<path>`.
+2. **Recover intent**: `git log --oneline $BASE..TARGET -- <path>` and `git log --oneline $BASE..SOURCE -- <path>`; read the commit messages and the surrounding code until you can state, in one sentence each, what each side was trying to do.
+3. **Classify and resolve**:
+   - **Disjoint intents** (two different features touched the same region) → weave BOTH changes together.
+   - **Same intent, two implementations** (both sides fixed the same thing differently) → keep the better/more complete one; state which and why.
+   - **Refactor vs change** → re-apply the semantic change on top of the refactored structure; never revert the refactor to make the diff easier.
+   - **Generated files & lockfiles** (`package-lock.json`, `pnpm-lock.yaml`, `*.generated.*`) → never hand-merge; take one side, then regenerate with the project's own tool (`pnpm install`, codegen script) and say so.
+   - **Genuinely ambiguous business logic** → STOP. Show the user both sides with `file:line`, explain each intent in plain language, and ask which behavior must win in TARGET.
+4. **Re-read the whole resolved file**, not just the hunk: imports, duplicate declarations, dead references, coherent naming.
+5. `git add <path>` only when that file is fully resolved.
+
+After the last file, prove no markers remain:
+
+```bash
+git grep -nE '^(<{7}|={7}|>{7})' -- . || echo "clean"
+```
+
+Then `git commit` (keep the default merge message, append a short conflict-resolution summary).
+
+## Phase 4 — Verification (prove nothing was lost)
+
+- Run the project's own build, test and lint commands (from CLAUDE.md or the package manifest). All must pass.
+- Loss check against both parents:
+  - `git diff HEAD^1 HEAD` — exactly what the merge brought in; must correspond to SOURCE's commits.
+  - `git diff SOURCE HEAD` — what the merged result has that SOURCE doesn't; must be only TARGET's own work, nothing of SOURCE reverted.
+- Summarize: "SOURCE's N commits are all represented; TARGET-only changes are intact; build/tests green."
+- If verification fails: fix forward only if the failure is trivially merge-induced (a missed weave); otherwise roll back (see Recovery) and report the real blocker.
+
+## Phase 5 — Report and push
+
+Report: commits merged, each conflict and the decision taken, verification results. Push ONLY on explicit user confirmation: `git push origin TARGET`.
+
+## Recovery
+
+- Mid-merge: `git merge --abort` returns to the pre-merge state.
+- Committed but not pushed: `git reset --hard ORIG_HEAD` (confirm with the user first).
+- Already pushed: never rewrite — `git revert -m 1 <merge-sha>` and explain.
+

package/skill-sources/ingenium/skills/session-recap/SKILL.md

@@ -0,0 +1,95 @@
+---
+name: session-recap
+description: Recover and distill what happened in a previous Claude Code session in this project, so work continues in a fresh session without replaying it - locate the on-disk transcripts under ~/.claude/projects, list recent real sessions, extract the user's verbatim intent, files touched, research performed, dead ends, denied tools and interruptions with a bundled script instead of reading raw JSONL into context, cross-check every claim against git to flag what was committed, left uncommitted or changed since, then emit a resumable brief and save it under .claude/sessions/. Use when starting a fresh session on work that was already in progress, when asking what was done last time or where things were left off, when a previous session ran out of context, or when a summary of prior work is needed. Türkçe tetikleyiciler - "geçen sefer ne yapmıştık", "son oturumu özetle", "kaldığımız yerden devam", "önceki session'ı getir", "dün ne yaptık", "en son nerede kalmıştık", "context doldu özet çıkar", "önceki konuşmanın özetini çıkar".
+---
+
+# Session Recap
+
+Claude Code already writes every session to disk. So "what were we doing?" is not a memory problem — it is an **extraction** problem, and extraction beats recollection every time. This skill reads the transcript mechanically, then makes git the judge of whether any of it is still true. Its output is a brief written to be *resumed from*, not a story to be read.
+
+Always communicate with the user in their own language.
+
+## Non-negotiables
+
+1. **Never read a raw `.jsonl` transcript into context.** They reach megabytes; loading one spends the budget the recap exists to protect. The bundled script is the only reader.
+2. **A transcript records what was *said*, not what is *true*.** An assistant claiming "fixed it" proves nothing. Every claim about current state gets confirmed against git or the file, or it ships labelled unverified.
+3. The user's own prompts are the intent ground truth. Preserve their wording for goals and constraints; do not paraphrase a requirement into something softer.
+4. Report gaps as gaps. A recap that quietly omits an unresolved failure is worse than no recap.
+
+## Phase 1 — Find the session
+
+Run the bundled extractor (path is relative to this skill's base directory):
+
+```bash
+python scripts/extract_session.py --list
+```
+
+It resolves the transcript directory from the current `cwd` (each project maps to `~/.claude/projects/<cwd with every non-alphanumeric character replaced by ->`, with a `cwd`-matching fallback), then lists recent sessions newest-first with title, id, time window, prompt count, files touched, and opening prompt. Sessions with **no typed prompt** — headless `-p` runs, aborted starts — are hidden as noise; `--all` reveals them.
+
+**Identifying the live session is your job, not the script's.** It flags any transcript written in the last 60s as `POSSIBLY THE SESSION YOU ARE IN` and prints a `Suggested:` id, but idle time is only a hint — a second session open in another window defeats it, in both directions. You hold the ground truth the script cannot: you know what was said in *this* conversation. So before summarizing, compare the candidate's opening prompt and prompt count against this conversation. If they match, it is this session — take the next one down, or pass `--exclude-session <id>`.
+
+Say which session was picked in one line, so a wrong pick costs the user one word to correct. If they named a topic ("the Tailwind one"), match on title and opening prompt instead of asking. If they want *this* session summarized for a handoff to a new window, that is a legitimate request — pass its id explicitly.
+
+## Phase 2 — Extract the digest
+
+```bash
+python scripts/extract_session.py --session <id-prefix>      # explicit id — bypasses every filter
+python scripts/extract_session.py --session latest           # newest non-flagged, non-excluded
+python scripts/extract_session.py --session latest --json     # machine-shaped
+```
+
+An explicit id always wins over the filters, so a session you deliberately named is never "not found".
+
+The digest carries: title, window, cwd, branches, record count, **verbatim user prompts in order**, files touched with edit-call counts, research (`WebSearch`/`WebFetch` queries and URLs), skills loaded, subagents dispatched, commands run, tool errors, denied tool calls, interruption count, and the final assistant state.
+
+Long sessions: `--prompt-chars 200` tightens the biggest section. If the digest is still large, read it and work from it — do not paste it wholesale into the recap.
+
+## Phase 3 — Make git the judge
+
+The digest's `window` gives exact bounds. Establish what survived:
+
+```bash
+git log --since="<started>" --until="<ended>" --format='%h %ad %s' --date=short
+git status --short
+git log --since="<ended>" --format='%h %s' -- <file-from-digest>   # changed after the session
+git stash list
+```
+
+Classify every touched file: **committed** (in a window commit), **uncommitted** (in `git status`), **superseded** (commits after the window touched it), or **vanished** (no longer exists — say so plainly; the work may have been reverted). Untracked-and-absent from both git and disk is the loudest signal in the whole recap.
+
+Also reconcile the branch: if the digest's branch differs from the current one, the work may not be reachable from here at all. Check before assuming.
+
+## Phase 4 — Compose the brief
+
+Write to `.claude/sessions/<YYYY-MM-DD>-<slug>.md` **and** print it in the chat. Fixed sections, in this order — front-load resumption, because that is what the reader needs first:
+
+1. **Resume here** — one paragraph of state plus the single concrete next action. Written so someone with zero context can act on it.
+2. **Goal / acceptance** — what the work was for, in the user's own words.
+3. **Done, with evidence** — per item: what changed, which files (`path:line` where known), and its git classification from Phase 3.
+4. **Decisions and why** — so the next session does not relitigate settled choices. Include ones the user made in their prompts.
+5. **Dead ends — do not retry** — from tool errors, denied calls, interruptions and user corrections, each with the reason it failed. The highest-value section and the first thing ordinary summarization loses.
+6. **Research findings** — the queries *and* the conclusion drawn from them. A bare URL list is not a finding.
+7. **Open ends / unverified** — tests not run, builds not attempted, claims not confirmed, questions left hanging.
+8. **Staleness** — what changed in the repo after the session; explicit "recap is current as of `<commit>`".
+9. **Anchors** — `file:line` and symbol names for the next session to read directly, not prose directions.
+
+Sections with nothing in them are marked `—`, never padded. Target 60–150 lines; a recap that rivals the transcript has failed at its job.
+
+If `.claude/` is tracked by git in this repo, say so once and let the user decide whether the recap gets committed — never commit it unasked, and never silently edit `.gitignore`.
+
+## Phase 5 — Hand off
+
+Close with the next action as a question the user can answer with one word ("Kaldığı yerden `xs:` breakpoint denetimine devam edeyim mi?"). If the recap surfaced a contradiction — a file the transcript claims was written but git has never seen — raise that before proposing any work.
+
+## Rules
+
+- Prompt count and file count are the session's weight class. A 3-prompt session gets a 15-line recap; reserve the full nine sections for real work.
+- Prefer the user's phrasing over your own for goals, constraints and rejections.
+- Subagent (`isSidechain`) activity is summarized as outcomes, never replayed.
+- A session spanning several unrelated tasks gets segmented by topic, not flattened into one narrative.
+- The digest is disposable; the brief is the artifact. Do not keep the digest around after writing the brief.
+
+## Anti-patterns
+
+Reading transcripts with Read/Grep instead of the script; repeating the assistant's self-congratulation as fact; a chronological retelling ("first we…, then we…") instead of a resumable state; dropping dead ends because they feel like failure; trusting the `POSSIBLY THE SESSION YOU ARE IN` flag instead of checking the candidate against this conversation; recaps with no git verification (fiction with timestamps); paraphrasing a hard requirement into a vague one; committing recap files nobody asked to commit.
+