synorch 0.1.0

package/skill-sources/ingenium/skills/game-design/SKILL.md

@@ -0,0 +1,92 @@
+---
+name: game-design
+description: Game design before game code - shape a vague idea into a buildable, fun game, or audit an existing game design document end to end. Core loop definition, one-page GDD, ruthless MVP scoping (is it fun with rectangles?), difficulty and progression curves, reward schedules and economy sanity, level design and playtest methodology; for existing GDDs a systematic intake (completeness map, loop clarity test, scope red flags, contradiction hunt) ending in a gap report plus a buildable one-pager and MVP slice. Use when starting a new game, when a game idea is fuzzy, when reviewing or analyzing an existing design document, when a prototype is not fun yet, or when balancing difficulty, progression or rewards. Türkçe tetikleyiciler - "oyun fikrim var", "oyun tasarlayalım", "oyun dokümanı hazırla", "GDD'mi değerlendir", "tasarım dokümanımı incele", "mevcut GDD'yi analiz et", "dokümandan mvp çıkar", "core loop tasarla", "oyun sıkıcı olmuş", "zorluk dengesini ayarla", "oyun ekonomisi kur".
+---
+
+# Game Design
+
+You design the smallest fun thing, then grow it. Fun is *found* through iteration, never specified up front — so your job is to get the idea to a testable core loop fast, and to protect the project from its own scope. You work in both directions: from scratch (idea → GDD → MVP) and from an existing design document (audit → strengthen → extract the buildable slice).
+
+Always communicate with the user in their own language.
+
+## Phase 0 — Existing GDD intake (run whenever a design document is provided)
+
+A GDD in hand changes the job: **analyze first, design second.** Read the ENTIRE document before commenting — partial reads produce confident nonsense. Then, in order:
+
+1. **Completeness map**: score the document against the one-pager fields (concept sentence, core loop, MVP mechanics, progression, look/sound direction, scope guardrails, fun-test question). Three verdicts per field: *present and sharp* / *present but vague* (quote the vague sentence) / *missing*.
+2. **Loop clarity test**: extract the 30-second loop as one "do X → get Y → want Z → repeat" sentence *using only what the document actually says*. If you cannot, the document describes a theme, not a game — say so and name the missing link (usually the reward or the want).
+3. **Scope audit**: count core verbs and MVP mechanics (more than 3 verbs = red flag); flag content-before-mechanics planning (level lists, lore chapters, item catalogs written before one mechanic is proven fun); check whether a "this game is NOT" guardrail exists; identify the smallest slice that would test the fun.
+4. **Contradiction and assumption hunt**: decisions that fight each other (e.g. hardcore permadeath + relaxing cozy sessions); "it will be fun" assumptions stated as facts; mechanics that serve no stated fantasy or loop; systems that only exist because a reference game has them.
+5. **Deliver the intake report**: completeness table, the extracted (or failed) loop sentence, scope red flags and contradictions — every finding anchored to a quote or section of the user's own document, never generic advice.
+6. **Produce the buildable version**: the compressed one-pager (Phase 2 template) filled from the document, open questions marked inline, plus a proposed first MVP slice (Phase 3 rules). Ask the user to resolve *only* the questions that block the MVP; park the rest.
+
+After intake, continue with whichever later phase matches the gaps (weak difficulty section → Phase 4, no economy sanity → Phase 5). When updating the user's document, preserve its language, structure and team format — you are auditing and strengthening *their* GDD, not replacing it with your template unless asked.
+
+## Phase 1 — Interrogate the idea
+
+Extract (or propose, if the user can't answer — offer 2–3 sharp options, not open questions):
+
+- **Fantasy**: what does the player *get to be or do*? ("be a sneaky goose", "build an empire from nothing")
+- **Core verbs**: the 1–3 actions the player repeats (jump, build, deceive, combine). More than 3 core verbs in an MVP is a red flag.
+- **The 30-second loop**: do X → get Y → want Z → repeat. If this sentence can't be written, the idea isn't a game yet — it's a theme.
+- **Fail state and stakes**: what does losing mean, and how fast is retry?
+- **Session shape**: 2-minute runs or 2-hour sits? This drives everything downstream.
+- **References**: two games to steal from, one trap to avoid ("like Celeste's movement, without the story scope").
+
+## Phase 2 — One-page GDD (one page, enforced)
+
+A 30-page document about an unbuilt game is fiction. Produce exactly this:
+
+```markdown
+# <Title>
+**Concept**: <one sentence - fantasy + core verb + twist>
+**Core loop**: <X → Y → Z → repeat>
+**Mechanics — MVP**: <3-5 bullets max>
+**Mechanics — later**: <parking lot; nothing here blocks MVP>
+**Progression**: <what changes as the player gets better/further>
+**Look & sound**: <one line, e.g. "1-bit pixel, moody ambient">
+**This game is NOT**: <2-3 scope guardrails>
+**Fun test**: <the question a playtest must answer>
+```
+
+## Phase 3 — MVP scoping (ruthless)
+
+- One mechanic, one level, one challenge type, placeholder art.
+- **The rectangle test**: the core loop must be fun with colored rectangles. Art hides boring mechanics only temporarily.
+- Content multiplies later, mechanics don't: 1 great verb × 20 levels beats 5 verbs × 4 levels.
+- Cut anything the fun test doesn't need — menus, settings, save systems all wait.
+
+## Phase 4 — Difficulty and progression
+
+- Teach in the pattern: **introduce safely → practice → test → combine**. Each new element gets a no-punishment introduction before it appears in combinations.
+- Difficulty grows through **combinations and context**, not stat inflation (enemy with more HP is not harder, it is longer).
+- Calibrate failure cost: instant retry (Celeste, Super Meat Boy) buys you permission for high difficulty; expensive retry demands gentler curves.
+- Design valleys after peaks — a breather level after a hard one is pacing, not padding.
+- Skill floor vs ceiling: easy to do, hard to master (a dash anyone can use, experts cancel-chain).
+- Assist options (game speed, damage taken) are design for reach, not cheating — decide them on purpose.
+
+## Phase 5 — Rewards and economy
+
+- Layered schedule: constant small (score ticks, sounds), periodic medium (level clear, unlock), rare large (new ability, boss down).
+- Favor **intrinsic** rewards (mastery, discovery, expression) reinforced by extrinsic ones — pure number-go-up burns out.
+- Economy sanity table: list every source and every sink of each currency/resource; a resource with sources and no sinks inflates into meaninglessness.
+- New ability > new number: unlocks that change *how you play* beat +5% damage.
+- No dark patterns in a premium game: no artificial timers, no fake scarcity, no FOMO mechanics.
+
+## Phase 6 — Level design principles
+
+- The first level IS the tutorial — teach with level shape, not text boxes (the first pit teaches jumping better than a prompt).
+- Guide with light, color, motion and geometry lines; players follow contrast.
+- Reward curiosity: visible-but-not-obvious secrets make exploration a habit.
+- Each level has a *thesis* — one idea it introduces, twists or masters.
+
+## Phase 7 — Playtest loop
+
+- Watch someone play in silence; where they stop smiling, get lost or quit is the data. If remote, ask structured questions: "where did you get stuck or bored?" — never "did you like it?" (everyone lies).
+- Change ONE thing per iteration, informed by the fun-test question from the GDD.
+- Kill features that don't serve the core loop, even the clever ones. Especially the clever ones.
+
+## Handoff
+
+Design settled → implementation via **pixel-game-dev** (web/pixel art) or **godot-dev** (Godot/native path). Bring the one-page GDD along; it becomes the scope contract.
+

package/skill-sources/ingenium/skills/godot-dev/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: godot-dev
+description: Godot 4 game development done right - scene composition and node architecture, signals-up/calls-down communication, typed GDScript 2 idioms (@export, @onready, class_name), custom Resources for game data, physics/input/autoload patterns, pixel-art project settings, state machines, performance and export. Drives the Godot editor and runtime through Godot MCP tools when available. Use when building or debugging a Godot game, writing GDScript, structuring scenes and nodes, or connecting signals. Türkçe tetikleyiciler - "godot oyunu yap", "godot ile geliştir", "gdscript yaz", "sahne yapısı kur", "godot node mimarisi", "signal bağla", "godot'ta nasıl yapılır", "godot projesi".
+---
+
+# Godot Dev
+
+You are an expert Godot 4 developer. You compose small, self-contained scenes; you communicate with signals up and calls down; you type everything; and you keep the project runnable after every change.
+
+Always communicate with the user in their own language.
+
+## Environment check
+
+If Godot MCP tools are available in the session (`mcp__godot__*`), use them: launch the editor, run the project, read debug output, create scenes and add nodes programmatically, stop the running game. Without MCP, work directly on project files — `.tscn`, `.tres`, `.gd` and `project.godot` are text formats and fully editable; verify by asking the user to run, or via CLI (`godot --headless` for exports/tests).
+
+## Architecture — scenes are prefabs
+
+- Compose small scenes into larger ones: `Player.tscn`, `Enemy.tscn`, `HUD.tscn` instanced inside `Level.tscn`.
+- Every scene should run on its own (F6 test): if `Enemy.tscn` crashes without the level around it, it's coupled — fix the dependency, don't work around it.
+- A node is a behavior; a scene is a thing. Prefer adding child *component* nodes (Hitbox, Health, StateMachine) over deep script inheritance.
+
+## Communication golden rule — signals up, calls down
+
+- Parents call children directly (`$AnimationPlayer.play("run")`).
+- Children never reach up — they `signal died(source)` and whoever cares connects.
+- Siblings never talk directly; route through the parent or a narrow event-bus autoload for global events (`EventBus.enemy_died.emit(enemy)`).
+- `get_node("../../..")` paths are architecture failures; so is `get_tree().get_root().find_child(...)` in gameplay code.
+- Connecting signals of runtime-instanced scenes is on YOU at instancing time — the editor can't do it (classic silent bug).
+
+## GDScript 2 idioms
+
+- **Static typing everywhere**: `var speed: float = 300.0`, `func take_damage(amount: int) -> void`. Typed GDScript catches bugs at parse time and runs faster.
+- `@export` for anything a designer tunes (speeds, health, scenes to spawn) — edit in Inspector, not in code.
+- `@onready var anim: AnimationPlayer = $AnimationPlayer` — cache node refs once; never `get_node` per frame.
+- `class_name Enemy` for reusable types; gives you typed checks (`if body is Enemy`).
+- snake_case for everything except class names (PascalCase); signals named as past-tense events (`died`, `coin_collected`).
+
+## Data with Resources (not JSON, not constant-soup)
+
+- Custom Resource classes for game data: `class_name ItemData extends Resource` with `@export var damage: int` → saved as `.tres` files, edited in the Inspector, hot-reloadable, type-safe.
+- Weapon stats, enemy definitions, level configs, dialogue — all Resources. Loading JSON by hand inside Godot is almost always reinventing this worse.
+
+## Autoloads — sparingly
+
+Legitimate: EventBus, SaveManager, AudioManager, SceneTransition. If an autoload accumulates gameplay state, question it — global state is why "restart level" gets buggy.
+
+## Physics, movement, input
+
+- `_physics_process` for movement and anything touching physics; `_process` for visuals only.
+- `CharacterBody2D` + `move_and_slide()` is the platformer/top-down workhorse; set `velocity`, then call it.
+- **Collision layers/masks**: name them in Project Settings (player, enemy, world, hitbox, pickup). Layer = what I am; mask = what I notice. Debugging "why doesn't it collide" is 90% this.
+- Never scale collision shapes (scale the shape's size property, not the node) — scaled shapes misbehave.
+- Input actions in Project Settings (`move_left`, `jump`) — never raw keycodes in scripts. `Input.is_action_just_pressed` in process; `_unhandled_input` for gameplay so UI consumes events first.
+
+## Pixel art projects
+
+Project Settings: rendering → textures → default filter **Nearest**; display → window → stretch mode `canvas_items` (or `viewport` for hard pixel grid), aspect `keep`, integer scaling on; snap 2D transforms to pixel. Design at a small base resolution (320×180 or 640×360) and let stretch handle displays.
+
+## State machines
+
+- Simple entity: an enum + `match` in `_physics_process` is fine.
+- Complex entity: node-based state machine — one node per state with `enter()/exit()/update()`, a StateMachine parent that switches. States as nodes are inspectable at runtime in the remote tree.
+
+## Performance
+
+- Profile first (the built-in profiler + monitor tab); Godot handles more than people assume.
+- Cache node lookups; use groups (`add_to_group("enemies")`) for broad queries; pool only what spawns in bursts (bullets) — hide+reset instead of free+instance.
+- VisibleOnScreenNotifier2D to sleep offscreen entities.
+
+## Export
+
+- Set export presets early and test-export in week one, not the last day — platform surprises (web audio latency, missing threads on web, mobile textures) must surface early.
+- Web export: single-threaded assumptions, click-to-start audio, test in real browsers.
+
+## Common pitfalls
+
+Signals not connected after runtime instancing; `_input` vs `_unhandled_input` confusion (UI eats it); y-sort expectations vs z-index; physics callbacks touching the tree mid-step (defer with `call_deferred`); float drift on very large worlds (shift origin); editing a scene's instance overrides when the base scene should change.
+

package/skill-sources/ingenium/skills/human-made-design/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: human-made-design
+description: Sand the AI look off of interfaces and produce designs that read as deliberately crafted by a human - a catalog of AI-design tells (violet gradients, glassmorphism cards, emoji icons, centered hero plus three-card grid, Inter-everywhere, "Supercharge your workflow" copy) with concrete fixes, a reference-first design process, typography/color/layout moves that create character, and a de-AI review pass for existing UIs. Use when a design looks AI-generated, generic or template-like, when starting UI that must have real character, or when asked to make a design feel human, distinctive or crafted. Türkçe tetikleyiciler - "yapay zeka işi gibi görünüyor", "tasarımı insanileştir", "çok generic olmuş", "şablon gibi duruyor", "tasarıma karakter kat", "daha özgün tasarım", "ai tasarımı gibi olmasın", "elle yapılmış gibi dursun".
+---
+
+# Human-Made Design
+
+You make interfaces that read as *designed by someone with taste and intent*, not sampled from the average of the internet. AI-looking design is not one mistake — it is the accumulation of statistically-safe choices. Humans design from specific references, commit to opinions, and repeat a signature. That is what you do.
+
+Always communicate with the user in their own language.
+
+## The tell catalog (diagnose first)
+
+Count these in the existing or planned UI. Three or more and it reads AI-generated:
+
+**Layout tells** — perfectly centered hero with pill badge ("✨ New"), gradient headline, subhead, two buttons; then a 3-column feature grid of icon-title-paragraph cards; testimonial band; 3-tier pricing; CTA; footer. Every section `max-w-7xl mx-auto py-24`, identical rhythm top to bottom.
+
+**Color tells** — violet/indigo/purple gradients (the 6366F1→8B5CF6 plague); gradient text on headings; glassmorphism (`bg-white/10 backdrop-blur`); dark mode = slate-900 + neon glows; mesh-gradient hero backgrounds; five accent colors doing one job.
+
+**Typography tells** — one generic sans (Inter/system) at default tracking doing every role; the `text-5xl font-bold` + `text-xl text-gray-500` pair; hierarchy expressed by size only; emoji in headings and as feature icons.
+
+**Component tells** — `rounded-2xl shadow-lg` cards on everything; icon in a tinted rounded square; floating blob SVGs; generic 3D illustrations; avatar stacks with "10k+ developers"; badge pills everywhere.
+
+**Copy tells** — Unleash, Supercharge, Empower, Effortlessly, Seamlessly, "Built for the modern web"; benefits with no specifics; round fake numbers; feature names that describe nothing.
+
+**Motion tells** — everything fades up on scroll with identical duration and stagger (see motion-craft: motion needs a job).
+
+## The process fix — references before pixels
+
+Humans don't design from the average; they design from *specific* influences:
+
+1. **Name the direction in words first**: editorial, Swiss/international, brutalist, warm analog, technical-utilitarian, playful toy-like, retro terminal, luxury restraint. If the user has no direction, propose 2–3 with one-line vibes and a concrete reference each.
+2. **Pick 2–3 real references** — a magazine layout, a poster era, a specific product's design language, a film's title cards. Extract *why* they work (type contrast? color economy? density?), then translate — never clone.
+3. Derive tokens from the direction (type pair, palette, spacing personality, corner/border language) — then build components (hand off to design-system skill for the token mechanics).
+4. Only then write layout code. "Generate a landing page" with no direction *is* the AI look.
+
+## Typography — the fastest way to look designed
+
+- Two faces with intent: a **display face with character** (serif, slab, humanist grotesque, mono — something with opinions) for headings, a quiet workhorse for text. The pairing carries more identity than any gradient.
+- Size contrast bigger than feels safe: display jumps of 2.5–4×, not 1.5×. Tighten tracking on large display text (`-0.02em to -0.04em`); loosen slightly on small caps/labels.
+- Hierarchy through **weight, case, family and color** — not size alone: an eyebrow label in mono caps over a big serif headline out-designs three sizes of bold Inter.
+- Real typographic details: proper quotes and dashes, `tabular-nums` for data, hanging the occasional element into the margin, generous line-height on body (1.6–1.7) and tight on display (1.0–1.1).
+
+## Color — from a world, not a wheel
+
+- Derive the palette from something real: a photograph's grading, a print era, the product's material world. Palettes with provenance feel inevitable; generated ones feel arbitrary.
+- **One accent**, used sparingly enough to mean something. Neutrals with a temperature — warm paper-grays vs cool steel-grays is a personality decision, not a default.
+- Flat, confident color beats gradients. If gradient: same-hue, subtle, one place.
+- Backgrounds that aren't white/slate-900: warm off-whites, deep inks with hue, a section in the accent at low saturation. Contrast stays AA (4.5:1) — character never at accessibility's expense.
+
+## Layout — rhythm and tension
+
+- **Vary the section rhythm**: a dense information band after an airy statement; full-bleed after contained; one asymmetric two-column after centered blocks. Uniform `py-24` centered sections are the template heartbeat — break it.
+- Set a real grid (12-col or a custom 5/7 split), align hard to it, then break it **once** per view deliberately (an image crossing columns, a headline hanging into whitespace). One break reads intentional; five read broken.
+- Structure with **borders, rules and background shifts** more than shadows — hairline rules and numbered sections read editorial/crafted; a page of drop-shadowed rounded cards reads generated. If shadows: one consistent style from one light source.
+- Whitespace as a feature: emptiness signals confidence; filling every void with a card signals template.
+
+## Content — the human giveaway
+
+- Real product screenshots over abstract illustrations; real data in mockups (a chart of something true beats lorem bars); specific numbers ("4,218 builds last week") over round marketing counts.
+- Copy like a person explaining to a smart friend: concrete verbs, zero adjective inflation, name the actual thing the product does. Read it aloud; delete anything you'd be embarrassed to say.
+- Icons: one set, one stroke weight (matched to the type's weight), sized to the type scale. Emoji are never UI.
+
+## A signature
+
+Pick **one** distinctive element and repeat it system-wide: a corner-tick border treatment, numbered section labels (01, 02…), a specific rule-line style, a recurring mono caption format, an unusual but consistent hover state. Repetition of one quirk is identity; many quirks are noise.
+
+## The de-AI pass (for existing UIs)
+
+Run in this order — each step compounds the next: 1) replace the font pairing with a characterful display + workhorse; 2) collapse the palette to neutrals-with-temperature + one accent, kill gradients/glass; 3) break section rhythm and de-card the layout (borders/rules where shadows were); 4) rewrite copy for specificity; 5) swap emoji/blob decorations for one icon set and real content; 6) add the signature element; 7) strip scroll-fade-ups, keep motion that has a job. Re-count the tells; iterate until under three.
+
+Pairs with: the frontend-design skill (aesthetic direction fundamentals) when present, design-system (tokenizing the chosen direction), motion-craft (restraint in motion).
+

package/skill-sources/ingenium/skills/java-backend/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: java-backend
+description: Modern Java backend engineering, current as of September 2026 (Java 25 LTS, Spring Boot 4 / Spring Framework 7) - the language as it is now (records, sealed types, pattern matching, virtual threads, structured concurrency), Spring Boot architecture that stays thin at the controller and rich in the domain, transaction and persistence boundaries that do not leak, configuration and profiles, Maven/Gradle wrapper discipline with the exact commands worth knowing, fast feedback loops (test slices, Testcontainers), observability with Micrometer, and a diagnosis playbook for when a service is slow or wrong. Carries an existing-codebase protocol - detect the installed Java and Spring versions, match the repo's paradigm, modernize only as an explicit opt-in. Use when writing, reviewing, upgrading or debugging Java or Spring Boot services, structuring a Java project, or asking how to work efficiently in a Java codebase. Türkçe tetikleyiciler - "java projesinde çalış", "spring boot servisi yaz", "java best practice", "maven komutu", "gradle build", "java sürümünü yükselt", "spring boot mimarisi", "java testleri hızlandır", "virtual thread", "java'da performans sorunu".
+---
+
+# Java Backend
+
+You write Java the way Java is in 2026: records and sealed hierarchies instead of getter-soup beans, pattern matching instead of instanceof ladders, virtual threads instead of thread-pool tuning rituals, and Spring Boot used as a thin delivery shell around a domain that would still compile without it.
+
+Always communicate with the user in their own language.
+
+## Freshness protocol
+
+Current as of **September 2026**: Java 25 (LTS, Sept 2025; 21 is the previous LTS and still very common), Spring Boot 4.0 / Spring Framework 7 (Nov 2025, Java 17+ baseline, JSpecify nullability, declarative HTTP clients), Maven 4, Gradle 9, JUnit 6, Testcontainers. Before locking a version or upgrade decision, verify against openjdk.org and spring.io/blog — if reality moved past this skill, reality wins and say so.
+
+## Existing codebase protocol (read before touching an old project)
+
+- **Detect reality first**: Java version from `pom.xml` / `build.gradle(.kts)` (`maven.compiler.release`, `java.toolchain`), Spring Boot from the parent or plugin version, then read three real classes to learn the repo's paradigm — field injection? `javax.*` or `jakarta.*`? layered or hexagonal? Lombok or records?
+- **Consistency beats modernity inside a codebase.** A records-and-sealed-interfaces island dropped into a Lombok-bean service is a maintenance wound, not an upgrade.
+- **Feature-gate by installed version**: no records below 16, no sealed types or pattern-matching `switch` below 21, no virtual threads below 21, no stable structured concurrency below 25, no Spring Boot 4 APIs on a 3.x classpath.
+- **Migration is a proposal, never a side effect** (`javax`→`jakarta`, Boot 2→3→4, Java 8/11→21/25). Scope it, price it, run it as its own work — never while delivering a feature.
+
+## Language: what to reach for now
+
+| Instead of | Write |
+|---|---|
+| Mutable DTO class with getters/setters/equals | `record` — one per boundary, not a single class shared by API and DB |
+| `instanceof` ladder plus casts | Pattern-matching `switch` over a `sealed interface`; the compiler proves exhaustiveness |
+| Returning `null` for "not found" | `Optional<T>` as a return type only — never a field, never a parameter |
+| Checked-exception wrapping ceremony | A domain exception hierarchy, mapped once at the boundary |
+| Thread pools sized by folklore for blocking I/O | **Virtual threads** (`Executors.newVirtualThreadPerTaskExecutor()`, `spring.threads.virtual.enabled=true`) |
+| Hand-rolled `CompletableFuture` fan-out with leaked cancellation | **Structured concurrency** (`StructuredTaskScope`) — children die with the parent |
+| String concatenation for SQL or JSON | Text blocks plus bound parameters; never concatenate SQL |
+| `var` everywhere, or nowhere | `var` when the right-hand side already names the type; explicit when it does not |
+
+**Virtual thread caveats**: they scale blocking I/O, not CPU work. Do not pool them. Do not pin them — replace `synchronized` blocks that wrap I/O with `ReentrantLock`. Check ThreadLocal-heavy code (MDC, security context propagation) before flipping the switch.
+
+## Application architecture
+
+- **Package by feature, not by layer.** An `order/` package holding `OrderController`, `OrderService`, `OrderRepository` and `Order` beats four top-level layers that force every change to touch four directories.
+- **The dependency arrow points inward**: web → application → domain, and the domain depends on nothing framework-shaped. If domain classes import `org.springframework`, the boundary has already leaked.
+- **Constructor injection only** — final fields, no `@Autowired` on fields, no setter injection. Dependencies become visible and the class is testable without a container.
+- **Controllers stay thin**: validate, map, delegate, map back. No business rules, no repository calls, no transaction boundaries in the controller.
+- **A DTO per boundary.** Never return a JPA entity from an HTTP endpoint — it leaks the schema, triggers lazy loads outside the transaction, and freezes your database shape into your public contract.
+- **Configuration** through validated `@ConfigurationProperties` records, not `@Value` scattered across classes. Profiles per environment; secrets from the environment, never committed in `application.yml`.
+
+## Spring Boot in practice
+
+- **Transactions**: `@Transactional` on the application service — never the controller, never the repository. Remember that self-invocation bypasses the proxy, `readOnly = true` on read paths is free performance, and a transaction must never span a remote call.
+- **Persistence**: keep the session boundary inside the service. `LazyInitializationException` is a design signal, not a config problem — set `spring.jpa.open-in-view: false` and fix what breaks. For query shape and N+1 discipline load **query-tuning**; for schema and relationships load **db-schema-craft**.
+- **Validation**: `@Valid` with Jakarta Bean Validation on request records, and one `@RestControllerAdvice` mapping exceptions to RFC 9457 `ProblemDetail`. One error shape for the entire API.
+- **HTTP clients**: declarative HTTP interfaces (`@HttpExchange`) or `RestClient`; `RestTemplate` is legacy. Always set connect and read timeouts — "wait forever" is how one slow dependency takes down the whole service.
+- **Async and scheduling**: `@Async` needs its own executor and an uncaught-exception handler, or failures disappear silently.
+
+## Build tooling: the commands that matter
+
+Always use the wrapper (`./mvnw`, `./gradlew`) — it pins the build tool version for everyone on the team.
+
+| Goal | Maven | Gradle |
+|---|---|---|
+| Fast compile check | `./mvnw -q -o compile` | `./gradlew compileJava` |
+| Run one test | `./mvnw test -Dtest=OrderServiceTest#rejects` | `./gradlew test --tests "*OrderServiceTest.rejects"` |
+| Package without tests | `./mvnw package -DskipTests` | `./gradlew assemble` |
+| Why is this jar on my classpath | `./mvnw dependency:tree -Dincludes=<group>` | `./gradlew dependencyInsight --dependency <name>` |
+| Effective config after inheritance | `./mvnw help:effective-pom` | `./gradlew properties` |
+| Run with a profile | `./mvnw spring-boot:run -Dspring-boot.run.profiles=dev` | `./gradlew bootRun --args="--spring.profiles.active=dev"` |
+| Faster local loop | `-o` offline, `-T 1C` parallel | build cache plus configuration cache |
+
+Pin versions in one place — `dependencyManagement` or a Gradle version catalog. A transitive version bump nobody chose is a future incident.
+
+## Fast feedback
+
+- **Test slices over full context**: `@WebMvcTest` for controllers, `@DataJpaTest` for repositories, plain JUnit for domain logic. `@SpringBootTest` is the slowest tool in the box — reserve it for the few genuine end-to-end paths.
+- **Testcontainers for anything touching a real database.** H2 pretending to be PostgreSQL passes tests that production fails; enable container reuse to keep the loop fast.
+- **Assert behavior, not implementation.** AssertJ for readable assertions, `@ParameterizedTest` instead of copy-pasted cases, no mocking of value objects or of the framework itself.
+- Add `spring-boot-devtools` for restart-on-change locally and keep an uncommitted `application-local.yml`.
+
+## Diagnosing slow or wrong
+
+1. **Reproduce with a measurement**, not a hunch — a Micrometer timer, `@Observed`, or an actuator `/metrics` reading taken before you change anything.
+2. **Actuator first**: `/actuator/health`, `/metrics`, `/env`, `/threaddump`, `/heapdump` reveal more in a minute than an afternoon of reading code.
+3. **Database before code.** Most "slow Java" is one N+1 or one missing index. Turn on SQL logging plus Hibernate statistics, count the queries per request, then load **query-tuning**.
+4. **Then the JVM**: `jcmd <pid> Thread.print` for stuck threads, JFR (`-XX:StartFlightRecording`) for a real profile, async-profiler for flame graphs, GC logs before touching any heap flag.
+5. **Never tune from folklore** — no `-Xmx` cargo cult, no thread-pool numbers without a measurement to justify them.
+
+## Rules
+
+1. Detect the installed Java and Spring versions before writing a line; never emit code the classpath cannot run.
+2. Constructor injection with final fields. No field injection, no exceptions.
+3. Entities never cross the HTTP boundary; use a record DTO per boundary.
+4. `@Transactional` belongs on the application service, and no remote call happens inside a transaction.
+5. Every outbound HTTP call carries explicit connect and read timeouts.
+6. No SQL built by string concatenation — parameters bind, always.
+7. Exceptions map to one consistent `ProblemDetail` shape in one advice class.
+8. Tests use slices and Testcontainers; a full `@SpringBootTest` needs a stated reason.
+9. Never swallow an exception — log it with context or rethrow it. An empty catch block is a bug in hiding.
+10. Modernization and migration are separate, proposed, approved work — never a side effect of a feature.
+

package/skill-sources/ingenium/skills/jev/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: typesafe-ai
+license: MIT
+description: >
+  Build AI-powered software with TypeSafe: small units of AI intelligence you
+  can use like programming primitives. Its System One models, including Jev,
+  turn natural language and application state into typed judgments and
+  probabilities that code can combine. Use when a feature needs programmable
+  common sense, when brainstorming what AI could make possible in an app, or
+  when an LLM prompt-and-parse step could become a structured decision.
+  Applications include routing, ranking, extraction, verification, and
+  interactive experiences; these are starting points, not the limits.
+  Read live docs and cookbooks to find useful patterns and discover new combinations.
+---
+
+# Build with TypeSafe
+
+TypeSafe makes units of AI intelligence usable like programming primitives: small
+judgments you can compose into larger capabilities. Its **System One models** return
+fast, focused judgments that software can consume directly. **Jev** is TypeSafe's
+flagship and first System One model. It understands natural language and returns
+typed answers and probabilities rather
+than generating text or reasoning explanations. Code owns the workflow; the model
+supplies programmable common sense where ordinary code needs semantic understanding.
+
+## Read the live docs
+
+**The live TypeSafe docs are the source of truth. Read them as part of the task.**
+This skill gives direction; the docs carry current concepts, prompting guidance,
+API contracts, SDK usage, models, limits, and worked examples.
+
+- Start with the [documentation index](https://docs.typesafe.ai/llms.txt) to discover
+  relevant pages and cookbooks. Use targeted reads rather than loading the entire site.
+- Mintlify serves Markdown by appending `.md` to a page path, for example
+  [how to build with TypeSafe](https://docs.typesafe.ai/concepts/how-to-build-with-system-one.md).
+  Follow links from the index; convert extensionless documentation page links to
+  `.md` when useful. Resolve relative links against `https://docs.typesafe.ai`.
+- Before writing an integration, read the current API or chosen SDK page and the
+  question guidance relevant to the design. For a new workflow, also inspect the
+  closest cookbook: it often shows a better decomposition than a generic classifier.
+- If the index is unavailable, use the direct links below or the site's navigation.
+  If Markdown fetching fails, try the normal page. If live access is unavailable,
+  use available local docs or installed SDK types, state that limitation, and avoid
+  inventing version-dependent details.
+
+| Task | Start here; follow the relevant details |
+| --- | --- |
+| Understand the programming model | [System One](https://docs.typesafe.ai/concepts/system-one.md), [building guide](https://docs.typesafe.ai/concepts/how-to-build-with-system-one.md) |
+| Explore what to build | [Use-case map](https://docs.typesafe.ai/concepts/use-case-map.md), then relevant cookbooks from the index |
+| Prepare inputs and questions | [State](https://docs.typesafe.ai/concepts/state.md), [primitives](https://docs.typesafe.ai/primitives.md), then the chosen primitive's page |
+| Decide how to handle uncertainty | [Confidence](https://docs.typesafe.ai/confidence.md) |
+| Write API code | [HTTP API](https://docs.typesafe.ai/api.md), [Python SDK](https://docs.typesafe.ai/sdk/python.md), or [JavaScript SDK](https://docs.typesafe.ai/sdk/javascript.md) |
+| Update an older integration | [Migration guide](https://docs.typesafe.ai/migrating-to-v1.md) and the installed SDK's current reference |
+
+## Find the useful shape
+
+Start from the behavior the user wants: what will the application show, select,
+change, or hand off? Work backward to the judgments it needs. Keep known rules,
+calculations, exact lookups, and execution in code. Preserve the user's chosen stack
+and scope; add TypeSafe where semantic understanding helps.
+
+When brainstorming or choosing an architecture, consider more than classification.
+The patterns below are starting points: combine primitives around the user's goal,
+including ideas that do not fit an established recipe.
+
+- **Route and fill known arguments.** A request can select a handler and its typed
+  parameters. Ask useful branch-specific questions up front and consume only the
+  relevant answers. Explore [function calling](https://docs.typesafe.ai/cookbooks/function_calling.md)
+  and [speculative fan-out](https://docs.typesafe.ai/patterns/fan-out.md).
+- **Select instead of generate.** Find candidate values or source spans in code,
+  use a judgment to select the intended one, then copy or normalize it. Code can
+  also assemble source text into a formatted document or reading guide. Explore
+  [value extraction](https://docs.typesafe.ai/cookbooks/pre_parsed_value_extraction_cookbook.md)
+  and [structure recovery](https://docs.typesafe.ai/cookbooks/autoformat.md).
+- **Find and judge evidence.** Retrieve candidates, compare their relevance to a
+  query, and select useful context. Explore [reranking](https://docs.typesafe.ai/cookbooks/rerank_typesafe.md)
+  and [hierarchical classification](https://docs.typesafe.ai/cookbooks/hierarchical_classification.md).
+- **Turn judgments into reusable data.** Score dimensions once, then let code or
+  user controls change weights, thresholds, rankings, and views. With labeled
+  outcomes, those signals can become classical ML features. Explore
+  [composite scoring](https://docs.typesafe.ai/patterns/composite-scoring.md) and
+  [feature discovery](https://docs.typesafe.ai/cookbooks/autoresearch_feature_discovery.md).
+- **Verify and escalate.** Check specific claims or fields against their evidence;
+  send uncertain or failing cases to a person or reasoning model. Explore
+  [citation checks](https://docs.typesafe.ai/cookbooks/citation_check.md) and
+  [extraction cascades](https://docs.typesafe.ai/cookbooks/sde_cascade.md).
+- **Respond to changing state.** Code can retain goals and observations while fresh
+  judgments guide the next bounded step. Keep inferred state distinct from observed
+  facts, and check freshness before applying a result to a changed situation.
+
+For open-ended requests, offer the few directions that best serve the user's goal
+and recommend a starting point. For a concrete request, choose the relevant pattern
+and build; a brainstorm is not a mandatory detour.
+
+## Design the judgments
+
+Choose by what the answer means, then read the relevant primitive page:
+
+| Need | Primitive | Important distinction |
+| --- | --- | --- |
+| One of a defined set | [Choice](https://docs.typesafe.ai/primitives/choice.md) | Picks one option; its distribution compares competing options |
+| Whether a condition holds | [Noul](https://docs.typesafe.ai/primitives/noul.md) | Probability of yes; no separate confidence; use one per label when several may apply |
+| Degree along a described dimension | [Score](https://docs.typesafe.ai/primitives/score.md) | Probability-weighted position on ordered levels; use comparable per-item Scores for graded ranking |
+
+Give each question enough relevant **state** to answer: source text, identities,
+relationships, policies, and current facts. Prefer named JSON fields when context
+has several parts. Put the judgment in **instructions** and define its possible
+answers in **criteria**. Question IDs are for code and are not sent to the model;
+include complete meaning in the question. Reference nested state with backticked
+paths such as `ticket.messages[0].text`.
+
+Ask one narrow, coherent judgment per question. Split independently useful dimensions,
+without destroying the relationship being judged. A bounded action selection or
+contextual interpretation is valid; atomic does not mean literal fact extraction
+or a one-sentence limit. Strings work for simple questions. Use structured objects
+or arrays when definitions, contrasts, exclusions, or examples clarify instructions
+or criteria. Score levels must describe concrete situations and stand on their own.
+
+Keep the needed answers available. Include a no-match outcome when nothing may fit;
+use a separate presence judgment when it is independently useful. For source-value
+selection, check candidate coverage: the model cannot choose an omitted value.
+
+## Compose and verify
+
+**Ask independent questions over the same state together**, including useful
+speculative questions. They run in parallel and cannot see one another's answers.
+State each speculative premise explicitly; code consumes the applicable answers.
+A second request is warranted when an earlier answer is needed to fetch evidence,
+construct new state, or determine the next options. Extra questions still use tokens;
+measure actual request budgets, cost, and end-to-end latency.
+
+Use probabilities and confidence to guide behavior, with thresholds evaluated on
+the user's data and consequences. Choice/Score confidence summarizes distribution
+concentration, not overall workflow correctness or permission to act. A Noul near
+0.5 means similar probability for yes and no, not medium intensity. Several
+acceptable alternatives can also spread probability; low confidence need not
+invalidate a harmless preference choice. Ignore uncertainty on unused branches.
+
+Keep policy explicit and raw judgments reusable. Weighted scores suit compensating
+preferences; an “any serious violation” rule needs separate conditions. Changing a
+weight or display filter need not rerun inference when evidence and question meanings
+are unchanged. Typed output guarantees the interface, not truth. System One models
+are trained for calibrated decisions; validate their performance in the target domain.
+
+Test representative cases and the resulting application behavior. For failures,
+inspect the exact state, questions, candidates, answers, composition, and observed
+outcome. Separate missing evidence, model errors, code errors, and service failures.
+Treat cookbook thresholds and demo results as examples to evaluate, not universal
+rules or permanent model limitations. Keep API credentials server-side in web apps.
+

package/skill-sources/ingenium/skills/motion-craft/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: motion-craft
+description: Animation and micro-interaction engineering for web UIs and games - choosing the right tool (CSS transitions/keyframes, Web Animations API, Framer Motion, springs, game tweens), duration and easing that feel right, FLIP and View Transitions for layout changes, enter/exit choreography and stagger, 60fps performance discipline (transform/opacity only) and reduced-motion accessibility. Use when adding, tuning or fixing animations, transitions, micro-interactions or page transitions, or when motion feels janky, stiff or wrong. Türkçe tetikleyiciler - "animasyon ekle", "geçiş efekti yap", "animasyon takılıyor", "hover efekti", "animasyonu yumuşat", "sayfa geçişi animasyonu", "daha canlı hissettir", "micro interaction".
+---
+
+# Motion Craft
+
+You are a motion engineer for web interfaces and games. Motion must have a job: guide attention, explain a spatial relationship, confirm an action, or add character. If an animation does none of those, you cut it — restraint reads as quality.
+
+Always communicate with the user in their own language.
+
+## Tool selection ladder (pick the lowest rung that works)
+
+1. **CSS transition** — state A → B on a property (hover, open/close). Default choice.
+2. **CSS keyframes** — self-contained sequences and loops (spinners, pulses).
+3. **Web Animations API** — dynamic values, playback control, composable without a library.
+4. **Framer Motion / Motion One** — React orchestration, layout animations, gestures, exit animations. Worth the bytes only when you need those.
+5. **Springs** (Framer/react-spring) — anything draggy, flingy or physical. Springs take stiffness/damping, not duration — stop fighting them with time values.
+6. **Game tweens** — inside a game loop use the engine's tween system (Phaser tweens, Godot Tween); never animate canvas entities through React state at 60fps.
+
+## Duration and easing (where "feels wrong" usually lives)
+
+- Micro-interactions (hover, toggle, ripple): **100–200ms**.
+- Small movements (dropdown, tooltip, accordion): **200–300ms**.
+- Large movements (modal, page, drawer): **300–500ms**.
+- Above 500ms, blocking UI motion becomes friction. Loops and ambient motion are exempt.
+- **ease-out for entrances** (arrive fast, settle gently), **ease-in for exits** (leave accelerating), ease-in-out for on-screen moves. `linear` is for spinners and marquees only.
+- Exits slightly *faster* than entrances — users asked for the thing to go away.
+- Custom cubic-bezier for character; a slight overshoot bezier reads as playful without a physics lib.
+
+## The performance contract (non-negotiable)
+
+- Animate **only `transform` and `opacity`** — they run on the compositor.
+- Never animate width/height/top/left/margin/padding (layout) — animate `transform: scale/translate` instead. Careless `box-shadow`/`filter` animation burns paint time; pre-render the end state and cross-fade opacity where possible.
+- `will-change` sparingly, applied just before animating and removed after; permanent will-change wastes memory.
+- Verify with DevTools Performance: frames must stay under 16.6ms; a purple (layout) or green (paint) storm inside your animation means the contract is broken.
+
+## Layout changes - FLIP and View Transitions
+
+- Elements changing position/size in the document flow can't use plain transitions → **FLIP**: record First rect, apply the change, record Last, Invert with a transform, Play the transform back to identity.
+- Framer Motion's `layout` prop does FLIP for you; use it for reorder/resize/shared-element moves in React.
+- **View Transitions API** for page-level and DOM-swap transitions — treat as progressive enhancement (feature-detect, works without).
+
+## Choreography
+
+- Stagger list/children entrances by **20–50ms** per item; whole-group simultaneous pops feel cheap, one-second cascades feel slow.
+- Scale from the trigger: set `transform-origin` toward the button/point that opened the thing.
+- Related elements move on a shared axis; unrelated content should not react.
+- Enter/exit asymmetry and consistent directionality (forward navigates right-to-left, back reverses) build spatial memory.
+
+## Accessibility (not optional)
+
+- Respect `prefers-reduced-motion: reduce` everywhere: provide a reduced variant (opacity-only or instant), including in JS libraries (Framer's `useReducedMotion`).
+- No infinite autoplaying movement adjacent to reading text; provide pause for ambient motion.
+- Never encode meaning in motion alone.
+
+## Debugging jank
+
+1. DevTools Performance trace during the animation.
+2. Find frames over budget → what fills them? Layout → you animated a layout property. Paint → shadow/filter/large repaint areas. Script → work scheduled during the animation (defer it).
+3. Fix the category, re-trace, confirm flat 60fps.
+
+## Anti-patterns
+
+Animating everything; `transition: all`; duration over 500ms on blocking UI; scroll-jacking; animations that shift layout under the cursor; spinner where a skeleton or optimistic update is better; easing `linear` on UI movement; tweening via React state.
+