@causyne/agent 0.0.0-stage → 1.10.0

package/native-skills/devops/kubernetes-deployment-hardening/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: kubernetes-deployment-hardening
+description: Write or review a Kubernetes Deployment, Service, or Helm chart. Use when a workload has no resource limits, no probes, or runs privileged.
+---
+
+# Kubernetes Deployment Hardening
+
+## Invariants
+
+1. Every container declares `resources.requests` and `resources.limits`. Without requests the scheduler cannot place the pod sensibly; without limits one pod can starve a node.
+2. Every container declares a readiness probe. Without one, traffic reaches a pod that is still starting.
+3. `securityContext` runs non-root with a read-only root filesystem unless the workload provably needs otherwise.
+
+## Workflow
+
+1. Read the current manifest and name what is missing.
+   - Check for: requests, limits, readiness, liveness, securityContext, and an explicit image tag (never `latest`).
+   - **Done when:** you have a written list of the missing fields.
+
+2. Set resources from measurement, not from a guess.
+   - If no measurement exists, say so and set a conservative starting point, then note that it must be revisited against real usage.
+   - **Done when:** requests and limits are present and the basis for the numbers is stated.
+
+3. Separate the two probes.
+   - Readiness gates traffic. Liveness restarts. Pointing both at the same endpoint means a slow dependency triggers a restart loop.
+   - **Done when:** readiness and liveness use different endpoints or different thresholds.
+
+4. Constrain the security context.
+   - `runAsNonRoot: true`, `allowPrivilegeEscalation: false`, `readOnlyRootFilesystem: true`, and drop all capabilities.
+   - **Done when:** the pod starts with those settings, or you have named the exact capability it needs and why.
+
+## Template
+
+```yaml
+spec:
+  template:
+    spec:
+      securityContext:
+        runAsNonRoot: true
+        seccompProfile: { type: RuntimeDefault }
+      containers:
+        - name: app
+          image: registry/app:1.4.2
+          resources:
+            requests: { cpu: 100m, memory: 128Mi }
+            limits:   { cpu: 500m, memory: 512Mi }
+          readinessProbe:
+            httpGet: { path: /readyz, port: 8080 }
+            initialDelaySeconds: 3
+          livenessProbe:
+            httpGet: { path: /livez, port: 8080 }
+            periodSeconds: 20
+            failureThreshold: 3
+          securityContext:
+            allowPrivilegeEscalation: false
+            readOnlyRootFilesystem: true
+            capabilities: { drop: ["ALL"] }
+```
+
+## Verification
+
+- `kubectl apply --dry-run=server -f manifest.yaml` accepts it.
+- `kubectl rollout status deploy/app` completes.
+- Killing the readiness endpoint removes the pod from the Service endpoints without restarting it.

package/native-skills/devops/observability-baseline/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: observability-baseline
+description: Add logging, metrics, or tracing to a service. Use when an incident could not be diagnosed from what the service already emits, or when logs are unstructured strings.
+---
+
+# Observability Baseline
+
+## The three questions
+
+Instrumentation exists to answer: is it up, is it slow, and what broke. Anything that answers none of those is noise with a retention cost.
+
+## Workflow
+
+1. Structure the logs.
+   - One JSON object per line, with a level, a timestamp, a message, and a request or trace identifier. Never interpolate values into a prose sentence — that makes them unsearchable.
+   - **Done when:** every log line parses as JSON and carries a correlation identifier.
+
+2. Emit the four signals that matter for a request-serving service.
+   - Request rate, error rate, duration distribution, and saturation (queue depth, pool usage, memory).
+   - Use histograms for duration, never averages. An average hides the tail, and the tail is the user experience.
+   - **Done when:** a dashboard can show p50, p95 and p99 latency.
+
+3. Propagate a trace identifier across every boundary.
+   - Generate at the edge, accept from an incoming header, attach to every outbound call and every log line.
+   - **Done when:** one identifier follows a request through every service it touches.
+
+4. Redact before emitting.
+   - Tokens, passwords, keys and personal data must be masked at the logging boundary, not filtered downstream.
+   - **Done when:** a deliberate log of a credential-shaped value comes out masked.
+
+5. Alert on symptoms, not causes.
+   - Alert on error rate and latency, which users feel. Do not alert on CPU, which they do not.
+   - **Done when:** every alert would have woken someone for a real user-visible problem.
+
+## Verification
+
+- Trigger an error and follow it from the log line to the trace to the metric.
+- Confirm no alert fires during a normal deploy.

package/native-skills/devops/secret-management/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: secret-management
+description: Handle credentials, API keys, or certificates in an application or pipeline. Use when a secret appears in a config file, in an environment file committed to the repository, or in CI logs.
+---
+
+# Secret Management
+
+## Invariants
+
+1. A secret in version control is compromised, including in deleted files — history retains it. Rotate it; do not merely delete it.
+2. Secrets reach the process through the environment or a mounted file, injected at runtime by a secret store. Never through the image, the repository, or the build args.
+3. Every secret has a rotation path. One that cannot be rotated is a permanent liability.
+
+## Workflow
+
+1. Find what is already exposed.
+   - Search the working tree and the history for key-shaped strings: long base64 or hex runs, `-----BEGIN`, and assignments to names containing key, token, secret, or password.
+   - **Done when:** you have a list of every exposure, with the file and the commit.
+
+2. Rotate before you clean.
+   - Cleaning history without rotating leaves a live credential in every existing clone and in every fork.
+   - **Done when:** the old value is revoked at the provider.
+
+3. Move the value to a store.
+   - Cloud secret manager, or the platform's own secret object. Reference it by name from config; never inline it.
+   - **Done when:** the repository contains the secret's NAME and never its value.
+
+4. Block the next one.
+   - Add a pre-commit secret scan and a `.gitignore` entry for the environment file. Commit an example file with placeholder values so the shape is documented without the values.
+   - **Done when:** a test commit containing a fake key is rejected locally.
+
+5. Mask in CI.
+   - Register every secret with the CI provider so it is masked in logs. A secret echoed by a debug command is a public secret on a public repository.
+   - **Done when:** a deliberate echo of the secret shows as a mask in the run log.
+
+## Verification
+
+- No key-shaped string survives in the working tree.
+- The application starts with values supplied only by the environment.
+- A commit containing a fake credential is rejected by the local hook.

package/native-skills/devops/terraform-state-and-modules/SKILL.md

@@ -0,0 +1,36 @@
+---
+name: terraform-state-and-modules
+description: Write or review Terraform. Use when state is stored locally, when a module is copy-pasted between environments, or before a first apply against real infrastructure.
+---
+
+# Terraform State and Modules
+
+## Invariants
+
+1. State lives in a remote backend with locking. Local state means the first concurrent apply corrupts it and the second person destroys production.
+2. `terraform plan` output is read before every apply. An apply nobody read is an outage waiting for a trigger.
+3. Secrets never appear in `.tf` files or in `terraform.tfvars` committed to the repository. State itself contains secrets in plaintext — treat the backend as a secret store.
+
+## Workflow
+
+1. Check the backend first.
+   - If `backend "local"` or no backend block exists, that is the finding to report before anything else.
+   - **Done when:** the backend is remote and versioned, with locking enabled.
+
+2. Parameterise instead of duplicating.
+   - Environments differ by variable values, not by copied directories. Use one module and separate `.tfvars` or workspaces.
+   - **Done when:** adding a third environment requires a new variables file and no new resource blocks.
+
+3. Pin every provider and module version.
+   - `required_providers` with `~>` constraints, and module sources with an explicit `?ref=` tag.
+   - **Done when:** `terraform init` in a clean directory resolves to the same versions it did before.
+
+4. Plan, then read the plan.
+   - Count creates, updates and destroys. Any unexpected destroy stops the work and gets reported.
+   - **Done when:** every line of the plan is explained, especially each destroy.
+
+## Verification
+
+- `terraform fmt -check` and `terraform validate` pass.
+- `terraform plan` shows zero unexplained changes against the current state.
+- The backend block names a remote store and locking is confirmed.

package/native-skills/devops/zero-downtime-deploys/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: zero-downtime-deploys
+description: Design or repair a deployment strategy. Use when a release causes a visible outage, when migrations and code ship together, or when rollback is untested.
+---
+
+# Zero-Downtime Deploys
+
+## The rule that governs everything else
+
+Old code and new code will run at the same time. Every change must be safe in that window, or the deploy is not zero-downtime regardless of the orchestration.
+
+## Workflow
+
+1. Classify the change.
+   - Additive (new column, new endpoint, new field): safe to ship together.
+   - Destructive (dropped column, renamed field, changed semantics): must be split across releases.
+   - **Done when:** every change in the release is labelled additive or destructive.
+
+2. Split every destructive change into the expand/contract sequence.
+   - Release 1: add the new shape, write to both, read from the old.
+   - Release 2: read from the new. Deploy, then verify.
+   - Release 3: stop writing the old, then drop it.
+   - **Done when:** no single release both writes and removes the same shape.
+
+3. Make migrations independent of the deploy.
+   - Migrations run before the new code and must be safe for the old code still serving traffic.
+   - **Done when:** the migration can run with zero new instances started.
+
+4. Verify rollback before you need it.
+   - Roll back in a staging environment and confirm the previous version serves correctly against the migrated schema.
+   - **Done when:** rollback has actually been executed once, not merely documented.
+
+5. Drain connections on shutdown.
+   - Handle the termination signal: stop accepting new work, finish in-flight work, then exit. A process that exits immediately drops live requests.
+   - **Done when:** a rolling restart under load shows zero failed requests.
+
+## Verification
+
+- Run a rolling restart with a load generator active; error count stays at zero.
+- Roll back one version with traffic flowing; error count stays at zero.

package/native-skills/git/bisect-regression-hunt/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: bisect-regression-hunt
+description: Find the commit that introduced a bug. Use when something worked before and does not now, and the cause is not obvious from a recent diff.
+---
+
+# Bisect a Regression
+
+## Why this beats reading diffs
+
+Bisect is a binary search over history. A thousand commits take ten tests. Reading diffs is linear and relies on recognising the bug on sight, which is exactly what has already failed.
+
+## Workflow
+
+1. Write the test FIRST.
+   - A command that exits non-zero when the bug is present and zero when it is not. Without this you will make subjective calls at each step and the search will land on the wrong commit.
+   - **Done when:** the command fails on the current commit and passes on a commit you know is good.
+
+2. Find the bounds.
+   - A known-bad commit (usually HEAD) and a known-good one. If the good end is unknown, step backwards by powers of two until the test passes.
+   - **Done when:** `git bisect start <bad> <good>` is accepted.
+
+3. Automate the search.
+   - `git bisect run ./check.sh` runs the test at each step with no further input.
+   - The script must exit 125 when the commit cannot be tested at all (a broken build), so bisect skips rather than mislabels it.
+   - **Done when:** bisect reports a single first-bad commit.
+
+4. Confirm the verdict.
+   - Check out the reported commit and its parent, and run the test on both by hand. Bisect is only as correct as the test.
+   - **Done when:** the parent passes and the reported commit fails, verified manually.
+
+5. Reset.
+   - `git bisect reset` returns to where you started. Forgetting this leaves the tree detached at an arbitrary commit.
+   - **Done when:** `git status` shows the original branch.
+
+## When the history is merges
+
+`git bisect` handles merge commits, but a first-bad merge means the bug came from the merged branch. Re-run bisect within that branch's own commits.
+
+## Verification
+
+- The reported commit fails the test and its parent passes.
+- The change in that commit plausibly explains the symptom.
+- `git status` is back on the original branch.

package/native-skills/git/branch-strategy/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: branch-strategy
+description: Set up or repair a branching model for a team. Use when merges are painful, when long-lived branches diverge badly, or when there is no agreement on where releases come from.
+---
+
+# Branch Strategy
+
+## The bias
+
+Prefer short-lived branches off a single main line. Almost every branching pain is a symptom of branches living too long, and no model fixes that.
+
+## Workflow
+
+1. Establish one source of truth.
+   - `main` is always releasable. Everything branches from it and merges back into it.
+   - **Done when:** there is exactly one branch nobody force-pushes.
+
+2. Keep feature branches short.
+   - Under a few days. Anything longer merges into a codebase it no longer recognises. Split the work and use a feature flag if the feature is not ready to be seen.
+   - **Done when:** the median open branch age is measured in days, not weeks.
+
+3. Choose integration direction deliberately.
+   - Rebase a private branch onto main to keep history linear. Merge a shared branch, because rebasing rewrites commits other people have.
+   - **Done when:** the rule is written down and matches what people actually do.
+
+4. Protect the main line mechanically.
+   - Require review, require CI, forbid force-push. A convention nobody enforces is a convention nobody follows.
+   - **Done when:** a direct push to main is rejected by the server.
+
+5. Tag releases; do not branch them.
+   - A tag is an immutable pointer. A release branch is a second main line that will drift.
+   - Branch a release only to backport a fix to a version that is still supported.
+   - **Done when:** every shipped version corresponds to a tag.
+
+## Verification
+
+- Branch protection rejects a direct push and an unreviewed merge.
+- The oldest open feature branch is days old, not months.
+- Every release in the changelog has a matching tag.

package/native-skills/git/commit-hygiene/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: commit-hygiene
+description: Structure commits and write commit messages. Use when a change is being committed, when a branch has a messy history before review, or when a message says only "fix".
+---
+
+# Commit Hygiene
+
+## What a commit is for
+
+A commit is a message to whoever runs `git blame` on this line in two years. It should say WHY, because the diff already says what.
+
+## Workflow
+
+1. One commit, one logical change.
+   - A refactor and a behaviour change in one commit cannot be reviewed or reverted separately. Split them.
+   - `git add -p` stages hunks rather than whole files.
+   - **Done when:** each commit could be reverted alone without breaking the build.
+
+2. Write the subject as an instruction.
+   - Imperative mood, under about seventy characters, no trailing period: `fix race in session close`, not `fixed a race` or `fixing races`.
+   - **Done when:** the subject completes the sentence "if applied, this commit will …".
+
+3. Use the body for the why.
+   - What was wrong, why this approach, what was considered and rejected. Reference the issue.
+   - Skip the body only when the subject is genuinely complete.
+   - **Done when:** a reader who disagrees with the change knows what to argue with.
+
+4. Never commit noise.
+   - Debug prints, commented-out code, unrelated formatting, generated files that should be ignored.
+   - `git diff --cached` before every commit.
+   - **Done when:** every line in the staged diff is intentional.
+
+5. Clean the branch before review.
+   - Squash the "fix typo" commits into what they fix. Do this only on a branch nobody else has pulled.
+   - **Done when:** the branch reads as a sequence of deliberate steps.
+
+## Verification
+
+- `git log --oneline origin/main..HEAD` reads as a coherent narrative.
+- No commit message is a single word.
+- `git diff origin/main...HEAD` contains no debug output or unrelated reformatting.

package/native-skills/git/history-recovery/SKILL.md

@@ -0,0 +1,44 @@
+---
+name: history-recovery
+description: Recover lost commits or undo a destructive git operation. Use after a bad reset, a deleted branch, a force-push over someone else`s work, or an amended commit that ate a change.
+---
+
+# History Recovery
+
+## The fact that makes recovery possible
+
+Git almost never deletes a commit immediately. A commit that nothing references is unreachable, not gone, and stays in the object store until garbage collection runs — usually weeks. `git reflog` is the index of where HEAD has been.
+
+## Workflow
+
+1. Stop and take a snapshot.
+   - Do not run further git commands that move HEAD. Copy the whole working directory first if the state is valuable.
+   - **Done when:** a copy of the current directory exists outside the repository.
+
+2. Find the lost commit in the reflog.
+   - `git reflog` for HEAD, `git reflog show <branch>` for a specific branch.
+   - Each entry has a hash. The one just before the destructive command is what you want.
+   - **Done when:** you have the hash and have confirmed it with `git show <hash>`.
+
+3. Recover without overwriting.
+   - Prefer a new branch: `git branch recovered <hash>`. This is non-destructive and inspectable.
+   - Only after inspection: `git reset --hard <hash>` on the original branch.
+   - **Done when:** the recovered content is visible on a branch and verified with `git log`.
+
+4. If the reflog is empty, search unreachable objects.
+   - `git fsck --lost-found --unreachable` lists dangling commits. `git show` each candidate.
+   - **Done when:** the content is found, or you can state that it never reached the object store.
+
+## The specific disasters
+
+- **Bad `reset --hard`:** the previous HEAD is the reflog entry above the reset.
+- **Deleted branch:** `git reflog show` no longer works, but the branch tip is still in `git reflog` under HEAD, or in `fsck --unreachable`.
+- **Bad `commit --amend`:** the pre-amend commit is one reflog entry back.
+- **Force-push over a colleague:** the old remote tip is in their local reflog, and in the remote's reflog if you have server access. Ask before rewriting again.
+- **Detached HEAD with commits:** `git branch <name> HEAD` before checking anything else out.
+
+## Verification
+
+- `git log --oneline` on the recovered branch shows the missing commits.
+- The files that were lost are present with the expected content.
+- Nothing else moved: `git status` is clean.

package/native-skills/git/large-repository-surgery/SKILL.md

@@ -0,0 +1,46 @@
+---
+name: large-repository-surgery
+description: Remove a large file or a secret from git history, or split a repository. Use when a clone is slow because of a committed binary, or when a credential must be purged from history.
+---
+
+# Large Repository Surgery
+
+## Before anything else
+
+Rewriting history breaks every existing clone. Everyone must re-clone or reset. Confirm the team knows, and if the goal is removing a secret, ROTATE THE SECRET FIRST — the rewrite does not reach forks, caches or anyone's existing clone.
+
+## Workflow
+
+1. Measure before you cut.
+   - Find the largest objects in history and confirm they are what is actually causing the size.
+   - `git count-objects -vH` gives the total; `git rev-list --objects --all` piped through `git cat-file --batch-check` and sorted by size gives the offenders.
+   - **Done when:** you can name the paths responsible for most of the repository size.
+
+2. Back up.
+   - `git clone --mirror` to a separate location. A rewrite has no undo.
+   - **Done when:** the mirror exists and `git log` in it shows the current history.
+
+3. Rewrite with a purpose-built tool.
+   - `git filter-repo` is the current tool. `filter-branch` is deprecated, orders of magnitude slower, and easy to get subtly wrong.
+   - `git filter-repo --path secrets.env --invert-paths` removes a path from all history.
+   - **Done when:** the path no longer appears in `git log --all -- <path>`.
+
+4. Expire and collect.
+   - The old objects are still reachable through the reflog until it is expired.
+   - **Done when:** `git count-objects -vH` shows the reduced size.
+
+5. Coordinate the push.
+   - Force-push all branches and tags, then have everyone re-clone. Anyone who merges an old clone reintroduces the history.
+   - **Done when:** every collaborator has confirmed a fresh clone.
+
+## Prevention
+
+- Add the file pattern to `.gitignore`.
+- Use Git LFS for binaries that genuinely belong in the repository.
+- Add a pre-commit size check.
+
+## Verification
+
+- The removed path is absent from `git log --all`.
+- Repository size has dropped as expected.
+- CI passes against the rewritten history.

package/native-skills/git/merge-conflict-resolution/SKILL.md

@@ -0,0 +1,42 @@
+---
+name: merge-conflict-resolution
+description: Resolve merge or rebase conflicts. Use when a merge stops with conflicts, when a rebase halts, or when conflict markers appear in a file.
+---
+
+# Merge Conflict Resolution
+
+## Invariants
+
+1. Never resolve a conflict by taking one side wholesale without reading both. That silently discards someone's work.
+2. Never commit a file containing `<<<<<<<`, `=======` or `>>>>>>>`.
+3. Run the tests after resolving. A syntactically valid resolution can still be semantically wrong.
+
+## Workflow
+
+1. See the shape of the conflict before editing.
+   - `git status` lists the conflicted paths. `git diff --diff-filter=U` shows only the conflicting hunks.
+   - **Done when:** you have the list of conflicted files and know which are code and which are generated.
+
+2. Resolve generated files by regenerating, not by editing.
+   - Lock files, build output and snapshots: check out one side, then re-run the generator.
+   - `git checkout --theirs package-lock.json && npm install`
+   - **Done when:** the generated file matches what the tool produces from the merged source.
+
+3. Resolve code by understanding both intents.
+   - `git log --merge -p <path>` shows the commits from each side that touched the file. Read them; the right resolution is often neither side but a combination.
+   - **Done when:** the resolved hunk preserves the intent of both branches, or you can state which was deliberately dropped and why.
+
+4. Verify before continuing.
+   - `git add` the resolved files, then run the tests BEFORE `git rebase --continue` or `git commit`.
+   - **Done when:** the test suite passes on the resolved tree.
+
+## Escape hatches
+
+- Abandon the attempt cleanly: `git merge --abort` or `git rebase --abort`. Both return to the pre-merge state and lose nothing.
+- Recover a resolution you already made once: `git rerere` records and replays them.
+
+## Verification
+
+- `grep -rn '<<<<<<<' .` finds nothing outside test fixtures.
+- The test suite passes.
+- `git diff <base>...HEAD` contains no unrelated change.

package/native-skills/media/cinematic-3d-shot/SKILL.md

@@ -0,0 +1,104 @@
+---
+name: cinematic-3d-shot
+description: Build a 3D object in Blender and render it as a short cinematic clip. Use when a task asks for a 3D model, a product shot, a turntable, or a rendered animation of a few seconds.
+---
+
+# Cinematic 3D Shot
+
+A render looks amateur for four reasons, always the same four: default grey
+material, one flat light, the camera where Blender left it, and nobody looked at
+the result before shipping it. Fix those four and an ordinary model reads as a
+product shot.
+
+## Workflow
+
+1. Verify Blender before planning anything.
+   - Use the local CLI path. Budget a low-cost `renderFrame` whenever you need
+     to inspect the current visual result.
+   - **Done when:** the local Blender binary is available and the review loop is planned.
+
+2. Clear the scene.
+   - Blender opens with a cube, one lamp and a camera. Building around them is
+     how the default cube ends up in a client render.
+   - **Done when:** `clearScene` has run.
+
+3. Build the silhouette, then the detail.
+   - A shape is read as an outline before it is read as a surface. If the form
+     does not identify itself at thumbnail size, no amount of material work will
+     save it. Use `smartGeometry` — it applies bevel and subdivision, and a
+     bevel is what catches a highlight along an edge. Perfectly sharp edges are
+     the most common tell of untouched 3D: nothing in the real world has them.
+   - **Done when:** the object is recognisable as a flat grey silhouette.
+
+4. Give every visible object a material.
+   - `smartMaterial` on each one. One untouched object in a dressed scene reads
+     as unfinished more loudly than a whole scene of grey.
+   - Match the material to the object's story: a pen barrel is brushed metal or
+     lacquered resin, not plastic; the grip is rubber, and rubber is rough where
+     metal is not. Contrast between materials is what tells the eye there are
+     two parts.
+   - **Done when:** no object still carries the default surface.
+
+5. Light with three lights, in this order.
+   - `setupStudioLighting` gives key, fill and rim. The ratio does the work:
+     the key states the form, the fill keeps the shadow side from going black,
+     and the RIM is what separates the subject from the background. A render
+     that looks flat is almost always missing the rim.
+   - **Done when:** the subject's edge is visibly brighter than what is behind it.
+
+6. Add atmosphere only after the lights exist.
+   - `cinematicAtmosphere`. Fog scatters the light you already have, so adding
+     it first means tuning against something that will change. Keep the density
+     low — visible haze reads as a mistake unless the shot is about weather.
+   - **Done when:** there is depth between foreground and background, and the
+     subject is still crisp.
+
+7. Frame it deliberately.
+   - `autoFrameCamera`. A longer lens (65mm and up) flatters an object; a wide
+     lens distorts it and is why so many AI renders look like a fisheye photo of
+     a toy. Put the camera slightly above the eye line and the subject a little
+     off-centre.
+   - **Done when:** the camera is not where Blender put it.
+
+8. Look at it before you animate.
+   - `captureViewport`, or one low-sample `renderFrame`, then `view_image` or
+     `vision_inspect_ui`. Ask the specific question: is anything still grey, is
+     the subject separated from the background, does the silhouette read?
+   - **A render nobody has looked at is not a finished render.** This step is
+     the difference between the two outcomes, not a formality.
+   - **Done when:** you have described what you actually see, not what you
+     intended to build.
+
+9. One camera move, and do the arithmetic out loud.
+   - Seconds x fps = frames. 8s at 24fps is frames 1-192; set the range
+     explicitly or Blender renders its own 250-frame default.
+   - ONE move per short shot: a slow orbit, a push-in, or a rise. Three moves in
+     eight seconds reads as a screensaver. Ease the ends — constant velocity is
+     what makes a move feel mechanical.
+   - **Done when:** the frame range matches the requested duration exactly.
+
+10. Render with settings that fit the budget.
+    - EEVEE for anything short. Cycles at default samples will spend an entire
+      task budget on one frame and is almost never what a few seconds of
+      turntable needs.
+    - **Done when:** the file exists, and you have opened it to confirm it is
+      not zero bytes or a single black frame.
+
+## Failure modes worth naming
+
+- **Everything is grey.** A material step was skipped, or applied to one object.
+- **It looks flat.** No rim light, or fill too close to key.
+- **The object looks like a toy.** Lens too wide, or the camera is too close.
+- **The animation stutters.** Frame range and fps disagree with the duration.
+- **Blender is not installed.** Say so and offer the alternative. Do not loop
+  retrying the same missing binary — that spends budget to learn nothing.
+
+## Verification
+
+- The rendered file exists, is larger than a few kilobytes, and opens.
+- Open the first frame and the middle frame. Neither is black, neither is empty,
+  and the subject is in frame in both.
+- No object in shot still carries the default grey surface.
+- The subject's edge is brighter than the background directly behind it.
+- Frame count equals requested seconds x fps, exactly.
+- The camera position differs from Blender's default.

package/native-skills/mobile/app-startup-optimisation/SKILL.md

@@ -0,0 +1,41 @@
+---
+name: app-startup-optimisation
+description: Reduce mobile app startup time. Use when a cold start takes more than about two seconds, when a splash screen lingers, or when the first frame is blank.
+---
+
+# App Startup Optimisation
+
+## The three starts
+
+Cold (no process), warm (process alive, activity recreated), hot (everything alive). Cold start is what users judge you on, and it is the only one worth optimising first.
+
+## Workflow
+
+1. Measure each phase separately.
+   - Process creation, framework initialisation, application setup, first layout, first frame, first useful content. Optimising before you know which dominates is guessing.
+   - **Done when:** every phase has a measured duration on a mid-tier device.
+
+2. Move work out of application initialisation.
+   - Analytics, crash reporting, image loaders and dependency graphs commonly initialise eagerly. Almost none of them are needed before the first frame. Defer them behind lazy initialisation or a post-first-frame hook.
+   - **Done when:** application setup does only what the first screen needs.
+
+3. Make the first screen cheap.
+   - The first frame should render from cached or placeholder data, not from a network call. A skeleton that appears instantly beats correct content that appears in three seconds.
+   - **Done when:** something meaningful renders before any network response.
+
+4. Do not hide the problem behind a splash screen.
+   - An artificial splash delay makes the measured start longer. Use the platform's own splash mechanism, which shows during process creation and costs nothing.
+   - **Done when:** no artificial delay exists on the startup path.
+
+5. Ship ahead-of-time compilation hints.
+   - A baseline profile covering launch and the first interaction removes interpretation on the critical path.
+   - **Done when:** a profile generated from a real launch journey is included in the release.
+
+6. Audit the dependency graph.
+   - Each library initialising at startup costs time. Some register a startup provider automatically — check what is actually running before your first line of code.
+   - **Done when:** every automatic initialiser is either needed or disabled.
+
+## Verification
+
+- Cold start to first useful content is measured before and after, on a mid-tier device, on a release build.
+- Nothing on the startup path performs network or disk work that the first screen does not need.