DEV Community: Dominik Oswald

Rust 2026 Template: A Leaner CI, Smarter Project Profiles, and AI-Ready Workflows

Dominik Oswald — Mon, 09 Nov 2026 15:24:47 +0000

When I first wrote about my Rust 2026 GitHub starter template, the main idea was simple: stop rebuilding the same Rust project infrastructure for every new repository.

That article described an early version of the template. Since then, the project has changed substantially. The most important work has not been adding more tools or more workflow jobs. It has been removing duplicated work, making defaults safer, and ensuring that the generated project contains only the pieces it actually needs.

This update covers v0.4.1 (November 9, 2026). It is a follow-up to the original article, not a replacement for it: the original explains where the project started; this one explains what the template has become.

Repository: github.com/d-oit/rust-2026-template
Original article: GitHub rust-2026-template — my Rust starter in 2026
Full template changelog: CHANGELOG-TEMPLATE.md
Getting started: QUICKSTART.md

What changed since the original article?

The biggest changes are architectural:

One canonical owner for blocking quality checks, instead of several jobs repeating the same work.
Validated project profiles that generate a smaller, purpose-built repository.
Agent skills selected according to the project profile rather than copied wholesale into every project.
A fail-closed CI aggregate and a least-privilege workflow permission model.
A separate, explicit security policy for the excluded fuzz workspace.
More reliable release and maintenance automation, including action-runtime updates and deterministic architecture diagrams.

Let's look at the reasoning behind those changes.

1. CI: one owner per quality check

A CI pipeline can become slower and harder to understand simply by accumulating jobs. If formatting, Clippy, tests, dependency audits, and documentation tests run in multiple jobs, you pay for the same work more than once. Worse, different jobs can quietly drift and enforce different versions of the rules.

The template now consolidates the blocking quality checks under the Rust-based xtask runner. The Quality Gate workflow invokes a lifecycle-specific tier from config/xtask.json.

The central idea is one blocking owner per check and event:

Event	Canonical owner	Purpose
Pull request	`ci.yml` → `quality-gate` → `xtask` `pull-request` tier	Fast, required verification before merge
Protected-branch push	`ci.yml` → `quality-gate` → `xtask` `protected-branch` tier	Broader checks, including unused-dependency validation
Scheduled/manual security scan	`security-scan.yml`	Independent scheduled or on-demand audit and dependency-policy checks
Fuzz dependency scan	`fuzz.yml`	Validate the separate fuzz dependency graph
Release	Release workflow's configured `xtask` tier	Verify the release candidate

Standalone jobs no longer rerun the blocking fmt, Clippy, test, audit, and deny checks. Coverage is generated during the same canonical test execution and uploaded from that run, rather than being produced by a second test pass.

CI should fail closed

The CI Success aggregate is intended to be the stable required merge-gate context. It does not treat every skipped job as harmless.

A skipped job is accepted only when the pull-request path-filter contract proves that the job was not required. Missing results, unexpected skips, cancelled jobs, timeouts, and unknown results fail the aggregate. On push and manual events, required jobs are expected to run.

This distinction matters: a green aggregate should mean the required checks actually ran, not merely that GitHub did not report a failure.

Path-aware execution

The workflow uses changed paths to avoid compiling and testing Rust when a change only affects unrelated files. Markdown-only changes can still trigger Markdown validation without needlessly running the full Rust test suite.

The lifecycle tiers and path-to-check mappings live in config/xtask.json, rather than being scattered across workflow YAML. This makes the policy easier to inspect and adapt in projects generated from the template.

2. Project profiles: start with the project you are building

A reusable template should not force every project to inherit the full reference repository.

The template now provides validated profiles under config/template-profiles/. A profile controls which crates, workflows, skills, and verification defaults survive initialization.

Profile	Intended use	What it keeps
`minimal`	Small application	App starter, renamed library crate, `xtask`, core workflows and skills
`library`	Reusable Rust library	Library crate, `xtask`, workspace tests, library lockfile policy
`service`	Long-running service	Service-oriented actor, storage, and registry patterns
`performance-sensitive`	Latency- or throughput-sensitive code	Service foundations plus performance-oriented tooling
`ai-agent`	Agent-centric application	App foundations and agent development/authoring capabilities
`workspace`	Full reference workspace	The broad set of crates, benchmarks, workflows, and maintainer capabilities

The old --profile cli spelling remains as a compatibility alias for minimal; new projects should use minimal.

For example:

./scripts/init-template.sh \
  --profile minimal \
  --name my-app \
  --description "My Rust application" \
  --author "Your Name" \
  --repo YOUR_USER/YOUR_REPO

You can inspect or validate a profile through xtask as well:

cargo run -p xtask --bin xtask -- template inspect --profile service
cargo run -p xtask --bin xtask -- template validate-profile \
  --profile config/template-profiles/library.toml

See the project profiles guide for the full matrix and behavior.

Lockfiles are profile-specific

The template distinguishes libraries from applications:

Application-oriented profiles track Cargo.lock by default, making the dependency graph reproducible.
The library profile keeps Cargo.lock ignored, following the usual Cargo library convention.

This is applied during template initialization. It avoids asking every adopter to remember a policy decision that should be made deliberately at project creation.

3. AI agents: reusable skills, not just more instruction files

The original article introduced the template's agent support: a canonical AGENTS.md, skill definitions, tool-specific adapters, and generated LLM context files.

That foundation remains, but the newer design focuses on matching the agent capabilities to the project profile.

The core documentation model is still:

Layer	Location	Responsibility
Human onboarding	`README.md`, `QUICKSTART.md`	Explain the project to developers
Agent contract	`AGENTS.md`	Canonical rules and constraints
Reusable procedures	`.agents/skills/`	Task-specific, repeatable workflows
Tool adapters	`.claude/`, `.gemini/`, `.opencode/`, `.qwen/`, etc.	Tool-specific integration details

A small library does not need every maintainer, DORA, skill-authoring, or agent-evaluation capability. Minimal and library profiles keep the core Rust development skills. Service and performance-sensitive profiles add relevant advanced development skills. The ai-agent profile includes skill authoring and evaluation; workspace retains the broader maintainer set.

Initialization regenerates .agents/SKILLS.md and removes stale skill references from AGENTS.md when a profile prunes capabilities. That keeps the index and the canonical agent contract aligned with the files that actually exist.

The template continues to include:

AGENTS.md as the canonical project contract.
.agents/skills/ as reusable task knowledge.
Tool adapters for supported coding environments.
llms.txt and generated llms-full.txt for machine-readable project context.
Validation and evaluation for skills, rather than treating every Markdown file as a useful skill automatically.

The goal is not to make an agent autonomous by adding more prompts. It is to make the project's rules, boundaries, and repeatable procedures explicit and testable.

4. Quality tooling: remove checks that do not earn their keep

A good starter template should be strict about useful engineering properties and skeptical of ceremony.

Version 0.4.0 removed the Roast Scorer and its associated always-running CI job, helper script, example, Cargo alias, and aggregate dependency. It duplicated expensive checks such as Clippy, coverage, audit, deny, MSRV, builds, and benchmarks, then applied a heuristic score that did not gate merges meaningfully.

The ineffective CiStatusArtifact quality check was removed too. It could pass when the file it was meant to inspect was absent, which made the check weaker than its name suggested.

The replacement direction is straightforward:

Keep deterministic checks that have clear pass/fail semantics.
Give each blocking check one owner.
Make skipped work explainable through path-selection contracts.
Publish summaries and artifacts without writing generated CI state back to the product branch.
Ensure quality checks verify that useful work actually happened, not just that a command returned successfully.

The local entry point remains:

bash scripts/quality-gates.sh

It delegates to the same xtask quality orchestration used by CI. CI enables coverage collection for its canonical test run; local runs do not need to pay that cost by default.

5. Security and supply-chain boundaries

Security is most effective when it is part of the normal workflow and its ownership is clear.

The template retains dependency auditing, license and source policy checks, secret scanning, privacy checks, and workflow validation. It also tightens how those checks treat lockfiles.

Root workspace and fuzz workspace are different dependency graphs

The fuzz project is excluded from the normal Cargo workspace. That is useful for keeping fuzz-specific tooling and dependencies out of ordinary builds, but exclusion also means the root workspace's dependency checks do not automatically validate the fuzz graph.

Version 0.4.0 adds a dedicated fuzz/Cargo.lock and scripts/check-fuzz-deps.sh. The Fuzz workflow validates the excluded workspace with locked metadata, cargo audit, and cargo deny. It checks the committed lockfile without silently regenerating it; a missing or stale lockfile should be fixed explicitly.

Least privilege in CI

The default CI workflow no longer needs repository write permission. It uses read access for source checkout, publishes summaries to $GITHUB_STEP_SUMMARY, and uploads generated status or coverage data as workflow artifacts rather than committing them to main.

Write permissions are scoped to workflows that genuinely need to publish releases or perform a maintenance action. This reduces the impact of a compromised action or unexpected workflow behavior.

GitHub Actions and Node.js runtimes

Version 0.4.1 updates actions that were behind and producing Node.js runtime deprecation warnings. The template also unifies the Rust cache action and Rust toolchain action references so composite setup and workflow jobs do not accidentally use different revisions and cache identities.

The verify-actions skill's SHA reference table is now regenerated from the live workflow definitions, reducing the chance that its documentation drifts away from what CI actually runs.

6. Release engineering: preflight before publish

The release workflow has also received important correctness fixes.

One historical issue was that the template's VERSION file intentionally remains 0.0.0 as a starter value, while the template itself has its own release history in .template/CHANGELOG-TEMPLATE.md. A preflight check that compared every template tag only with VERSION could therefore reject a valid template release.

The v0.4.1 preflight now accepts a tag that matches either the starter VERSION or the latest template changelog release, while still failing closed for an unexpected tag. The post-release checkout permissions were corrected as well.

The wider release setup includes cargo-dist, git-cliff, release provenance, SBOM generation, and verification guidance. The important point is that release metadata and verification should be explicit, not inferred from a file that serves a different purpose.

For maintainers, the detailed implementation history is recorded in the template changelog.

7. Architecture diagrams that do not create noisy pull requests

Generated documentation should be deterministic. If an unchanged input produces different output on different machines, automation can create meaningless diffs.

The overview diagram is now derived from config/xtask.json and cargo metadata. A contract test checks that the committed asset matches the repository's current structure and quality-gate configuration.

The workflow no longer commits a PNG export. Rasterization depends on the local font stack and produced different bytes for the same diagram, which caused unnecessary update pull requests. SVG and Excalidraw outputs are stable and are used by the README and documentation.

The workflow's earlier failure mode was also fixed: it previously tried pushing to protected main, retried a rejected push, then attempted PR creation without the required token while swallowing the error. The updated approach reports failures honestly and can create a pull request when direct updates are not allowed.

The diagram is meant to describe the real project, not to become another source of truth that drifts away from it.

8. Optional capabilities stay optional

The template includes several patterns and guides that not every project needs. One example is Rust-to-WASM support.

Version 0.4.0 added an opt-in WASM guide covering target selection, a pinned wasm-bindgen-cli, test runners, a guard against accidentally running zero tests, and release-only wasm-opt size budgets.

It does not add a WASM target, dependency, or CI job to the default template. That is intentional. Documentation and a proven path are useful; imposing another toolchain and CI workload on every project is not.

The same principle applies to the other patterns: start with a profile, add the capability when the project needs it, and keep the default path maintainable.

9. Getting started today

The repository is a GitHub template. The shortest path for a new application is:

Create a repository using rust-2026-template.
Clone it and run the initializer with the profile that matches your project.
Review the generated AGENTS.md, project metadata, and security contact details.
Run the local quality gate.
Push and inspect the CI summary.

Example:

git clone https://github.com/YOUR_USER/YOUR_REPO.git
cd YOUR_REPO

./scripts/init-template.sh \
  --profile minimal \
  --name my-app \
  --description "My Rust application" \
  --author "Your Name" \
  --repo YOUR_USER/YOUR_REPO

bash scripts/quality-gates.sh

For a library, use --profile library. For a service, consider service; for an agent-centric application, use ai-agent. The full instructions and prerequisites are in QUICKSTART.md.

What I would emphasize now

The first version of this article focused on the collection of tools included in the template: Rust formatting, Clippy, tests, supply-chain checks, benchmarks, fuzzing, agent instructions, and release automation.

Those capabilities still matter, but the most valuable improvements in the current version are about coherence:

CI has one owner for each blocking check.
Required checks cannot silently disappear behind an unexpected skip.
Generated projects can be small without manually deleting half the template.
Agent capabilities match the profile instead of being copied indiscriminately.
Security checks cover dependency graphs that are outside the main workspace.
Workflow permissions and generated outputs are deliberately constrained.
Release and architecture automation fail visibly rather than reporting success after doing nothing.

I prefer a starter that helps a project grow without forcing it to carry the entire template forever. That is the direction of v0.4.x: fewer duplicated checks, clearer ownership, safer defaults, and optional complexity where it belongs.

Try it: d-oit/rust-2026-template

Read the original article: GitHub rust-2026-template — my Rust starter in 2026

See every release change: CHANGELOG-TEMPLATE.md

*Version note: this article describes the repository state and template changelog available on November 9, 2026 (v0.4.1).

Solution: "Failed to push commit to GitHub" from Google AI Studio

Dominik Oswald — Tue, 14 Jul 2026 13:15:56 +0000

"Failed to push commit to GitHub" from Google AI Studio — Why Rulesets Block the Sync

If you've ever seen this dreaded dialog in Google AI Studio:

❌ Something went wrong

Failed to push commit to GitHub. Please try again.

...and clicking "Try again" does absolutely nothing — you're not alone. This is one of the most silently frustrating integration failures between AI Studio and GitHub, and the root cause is almost never obvious from the error message itself.

What's Actually Happening

Google AI Studio uses a GitHub App integration to push commits directly to your repository when you save changes. It authenticates via OAuth and attempts a direct push to your configured branch — typically main.

The problem? If your repository has branch protection rules or the newer Repository Rulesets active, GitHub will reject that push at the API level. AI Studio receives a 422 or 403 from the GitHub API and surfaces it as this vague "Something went wrong" dialog — with zero detail about why the push was rejected.

GitHub Rulesets: The Silent Blocker

GitHub introduced Rulesets (under Settings → Rules → Rulesets) as a more powerful successor to classic Branch Protection Rules. They can enforce:

Require pull requests before merging
Require status checks to pass (CI/CD gates)
Block direct pushes to protected branches
Restrict who can push — including external GitHub Apps

When AI Studio's GitHub App identity is not in the bypass list of your ruleset, it gets blocked — silently. The push fails, and the dialog you see is the only feedback you get.

How to Diagnose It

Go to your repository → Settings → Rules → Rulesets (or Settings → Branches for classic rules)
Check if main (or your target branch) is protected
Look for "Restrict pushes that create matching refs" or "Require a pull request before merging"
Check the Bypass list — is the Google AI Studio GitHub App listed there?

You can also check Settings → Integrations → GitHub Apps to confirm AI Studio has write permissions at all.

Fix Options

Option 1: Add AI Studio to the Ruleset Bypass List

In your ruleset editor, scroll to Bypass list and add the Google AI Studio app. This lets it push directly while all other protection rules remain in effect for human contributors.

Option 2: Revoke & Reconnect AI Studio with Full Scope

Sometimes the integration loses write permissions silently. Fix it:

Go to github.com/settings/installations → revoke AI Studio
Go to github.com/settings/apps/authorizations → also revoke there
Refresh AI Studio and reconnect — this time select All Repositories (not just specific ones)

Option 3: Temporarily Disable the Ruleset

Not recommended for production repos, but useful for quick experiments: switch your ruleset enforcement status to Disabled temporarily, push from AI Studio, then re-enable it.

Why "Select All Repositories" Matters

A subtle but critical gotcha: when you first connect AI Studio to GitHub, if you authorize it for only selected repositories, its GitHub App token scope is restricted. This can cause push failures even when no protection rules are active, because the token itself lacks the right contents:write scope for the targeted repo. Always authorize with All Repositories or explicitly include the target repo during setup.

TL;DR

Root Cause	Fix
Ruleset blocks AI Studio's GitHub App push	Add AI Studio to Bypass list
OAuth token lost write permissions	Revoke both app installations and re-authorize
App only authorized for selected repos	Re-authorize with All Repositories
Renamed repository breaks sync URL	Disconnect and reconnect AI Studio

The "Failed to push commit" error from AI Studio is almost always a permissions or protection layer issue on the GitHub side — not an AI Studio bug per se. Once you know where to look, it's fixable in under 5 minutes.

GitHub rust-2026-template — my Rust starter in 2026

Dominik Oswald — Sun, 24 May 2026 16:37:12 +0000

I got tired of setting up the same things every new Rust project. Clippy config, CI pipelines, linker flags, pre-commit hooks, cargo-nextest... all from scratch, every time. And then doing it again every time I switched AI coding tools — re-explaining the project structure, the lint rules, what's off-limits.

So I built rust-2026-template. Click "Use this template", point your agent at it, and you're coding — not configuring.

Version 0.3.2 is the current release. Here's what's in it.

The setup I always end up with anyway

Rust 2024 edition, MSRV 1.88 pinned via rust-toolchain.toml. Workspace layout from day one with resolver "3" — even for small projects. Refactoring a single-crate project into a workspace later is just pain you don't need:

crates/
  example-crate/
  sample-app/
  actor-runtime-template/
  checkpoint-template/
  hybrid-storage-template/
  mcp-server-template/
  example-registry-pattern/
  example-storage-pattern/

Rename those, done. The crates cover patterns you'll want anyway: actor runtime, checkpointing, MCP server, storage backends.

One script, full quality gate

./scripts/quality-gates.sh

This runs fmt, clippy, cargo nextest, cargo audit, cargo deny, and optionally cargo mutants. Same thing CI runs. I run it before every commit so there are no surprises.

There's also a Makefile for common tasks if you prefer that over the shell script.

The Clippy setup is worth calling out: the workspace Cargo.toml starts with pedantic = "allow" and then selectively promotes specific lints to warn. Things like float_cmp, cast_possible_truncation, redundant_clone, and missing_const_for_fn — correctness signals and free compile-time wins — are turned on. Template ergonomics like unwrap_used, panic, too_many_arguments stay allowed so you're not fighting the linter while scaffolding. You adjust as your project matures.

Mutation testing with cargo-mutants is the one I'd push people to try — it tells you whether your tests actually catch bugs or just touch code. Very different things.

Security defaults, not an afterthought

deny.toml — license policy and banned crates
.gitleaks.toml — secret scanning before anything gets committed
.pre-commit-config.yaml — hooks run locally, not just in CI
.shellcheckrc — shell script quality gate
SECURITY.md — vulnerability reporting process

The goal is that you never have to remember to do this. It just happens.

AI agents work out of the box

This is the part I use the most now. Every AI coding tool needs project context — and they all want it in a slightly different place. Instead of re-explaining conventions every session, it's all checked in:

.agents/            — skill definitions per agent + cross-repo context
  context/          — context files for repositories derived from this template
  skills/           — executable task knowledge and canonical workflows
.claude/            — Claude Code config
.cursor/            — Cursor rules
.gemini/            — Gemini CLI config
.mimocode/          — Mimocode config
.opencode/          — OpenCode config
.qwen/              — Qwen CLI config
.windsurf/          — Windsurf config
agents-docs/        — detailed documentation for AI agents
AGENTS.md           — canonical project rules, read by every agent
llms.txt            — machine-readable project overview
llms-full.txt       — complete source context for deep analysis

AGENTS.md is the key file. It tells any agent: the workspace layout, the lint rules, commit conventions, and what to never touch. You switch from Claude Code to Codex to OpenCode mid-project — they all read the same rules. No re-onboarding.

The template uses a layered documentation strategy that makes the audience explicit:

Layer	File / Directory	Audience	Purpose
Human Onboarding	`README.md`, `QUICKSTART.md`	Humans	High-level overview and setup
Agent Contract	`AGENTS.md`	AI Agents	Canonical rules (SSOT)
Reusable Procedures	`.agents/skills/`	AI Agents	Step-by-step executable task knowledge
Tool Adapters	`CLAUDE.md`, `.cursorrules`, etc.	Specific Tools	Tool-specific deltas

.agents/context/ carries cross-repo context for projects that derive from the template. When you fork this and build on top of it, agents in the child repo can still pull structured knowledge about the base template's conventions.

llms-full.txt is auto-generated and contains the full source context for agents that need deep analysis. Regenerate both after significant architectural changes:

bash scripts/generate-llms-txt.sh

When you start a new project from this template, you can also just hand the repo URL directly to your agent as context:

"Use github.com/d-oit/rust-2026-template as the reference for this project."

It'll pick up the structure, the tooling choices, and the conventions without you writing a single prompt about them.

Performance defaults you forget to add

.cargo/config.toml sets the mold linker. One line, noticeably faster incremental builds. The dev profile is tuned to avoid the "my debug build takes forever" problem.

The release profile sets lto = "fat", codegen-units = 1, and strip = "symbols" — maximum runtime performance. There's also a release-full alias for backward compatibility and a bench profile with debug = true so Criterion can produce symbol-annotated flamegraphs.

Nix users get flake.nix with clang and mold in the devShell, plus .envrc for direnv/nix-direnv integration.

Benchmarks

The benchmarks/ workspace crate contains all Criterion harnesses under benchmarks/benches/:

end_to_end.rs — end-to-end throughput scenarios
memory_usage.rs — allocation and memory pressure scenarios
sanitization_bench.rs — input sanitization pipeline benchmarks

It also includes a benchmarks/events/ directory and benchmarks/history.jsonl for tracking benchmark results over time.

cargo bench -p benchmarks

The fuzz crate is excluded from the workspace (exclude = ["fuzz"] in Cargo.toml) so it doesn't affect normal builds. The CI pipeline compile-checks benchmarks on every PR so they never silently break.

Fuzz Testing

A fuzz testing scaffold is included using cargo-fuzz with one target: fuzz_parse_input (in fuzz/fuzz_targets/).

# Install cargo-fuzz (nightly required)
cargo install cargo-fuzz

# Run the fuzz target
cargo fuzz run fuzz_parse_input -- -max_total_time=30

The fuzzer runs weekly via GitHub Actions (fuzz.yml).

Feature Flags

All features are opt-in (default = []). Enable what you need:

Feature	Description
`cli`	CLI binary support (clap, anyhow, colored)
`persistence`	SQL persistence backend (libsql)
`parallel`	CPU parallelism via rayon
`wasm`	WASM build target support
`mcp`	MCP server support (requires `cli`)
`tracing-json`	JSON tracing output
`tracing-opentelemetry`	OpenTelemetry tracing backend

Note: mcp has a declared dependency on cli in the feature graph — enabling mcp automatically enables cli.

Runtime Configuration

A config/profiles/ directory carries environment-specific JSON configuration files (default.json and others). The schema/ directory holds JSON Schema definitions for config and API contracts — keeps your config validated and agent-readable from day one.

VERSION file

A VERSION file at the repo root is the plain-text single source of truth for tooling that can't parse TOML. The CI pipeline verifies VERSION matches Cargo.toml on every push to main — no more version drift.

Note: VERSION tracks the generated project's starter version; .template/CHANGELOG-TEMPLATE.md tracks internal template evolution separately (see issue #135).

GitHub Actions workflows

Workflow	Trigger	Purpose
`ci.yml`	PR / push	Format, Clippy, tests, audit, deny, bench compile-check, VERSION check
`mutants.yml`	Periodic	`cargo-mutants` mutation testing
`fuzz.yml`	Weekly	`cargo-fuzz` fuzzing
`release.yml`	Tag push	cargo-dist release
`patch-release-on-label.yml`	PR label	Automated patch releases
`hotfix.yml`	Manual	Hotfix branch workflow
`dora-fdrt.yml` / `dora-report.yml`	Events	DORA metrics tracking
`docs-check.yml`	PR	Documentation build check
`sync-labels.yml`	Push	Issue label sync

Release engineering

dist-workspace.toml + release.toml for cargo-dist automated releases
cliff.toml for git-cliff changelog generation
MIGRATION.md for upgrade guidance between template versions
docflow.json and opencode.json for AI-assisted doc and code workflows

Code quality integrations

Codecov (.codecov.yml) — coverage gate enforcement
Codacy (.codacy.yml + .codacy/) — static analysis with agent review configs
commitlint (commitlint.config.cjs) — conventional commits enforced
yamllint (.yamllint.yml) — YAML quality gate
markdownlint (.markdownlint-cli2.jsonc) — Markdown quality gate

Output Artifacts

Generated output goes to predictable, git-ignored locations:

reports/ — HTML reports for coverage, audit, benchmarks
.agents/ci/ — CI health artifacts (ci-status.json, ci-summary.md)
analysis/ and plans/ — agent working directories

Use it

Hit "Use this template" on GitHub — or tell your agent: use github.com/d-oit/rust-2026-template as the reference for this project
Follow QUICKSTART.md — rename the crates, update Cargo.toml metadata
Run ./scripts/quality-gates.sh once locally

MIT licensed. PRs welcome.

→ github.com/d-oit/rust-2026-template

Gemini CLI: Disable Interactive Shell If Tab Keeps Jumping Into the Shell Pane

Dominik Oswald — Mon, 04 May 2026 17:21:31 +0000

On Linux, I ran into a Gemini CLI behavior that was easy to misread at first: the problem was not just a command hanging, but Gemini’s embedded shell taking over the focus flow. The UI literally shows Shell awaiting input and tells you to press Tab to focus, which means Tab is being used to move focus into the interactive shell pane inside Gemini CLI. geminicli

That may be useful if you want a real terminal session inside Gemini CLI. It is much less useful when you only want non-interactive commands to run and return output.

The setting

At the time of writing, the current stable Gemini CLI release is v0.40.0. The shell docs also describe tools.shell.enableInteractiveShell as a boolean setting that controls the interactive shell experience, defaults to true, and requires a restart after changes. geminicli

Add this to ~/.gemini/settings.json (or project setting.json):

{
  "tools": {
    "shell": {
      "enableInteractiveShell": false
    }
  }
}

What this changes

Gemini CLI says interactive shell support uses node-pty, which allows real interactive sessions for commands like vim, nano, htop, and git rebase -i. The docs also state that when an interactive command is running, you can send input to it from Gemini CLI and focus the shell with Tab. google-gemini.github

That is the key detail. If Tab keeps jumping into the shell pane, that is not random terminal behavior. It is part of Gemini CLI’s interactive shell design. geminicli

When you set enableInteractiveShell to false, Gemini falls back to the simpler non-interactive execution path instead of the richer pseudo-terminal workflow. According to the docs, that fallback uses child_process, which does not support interactive commands. geminicli

Creating YouTube Videos with Remotion: A Complete Guide to the Kimi AI Negotiation Project

Dominik Oswald — Fri, 30 Jan 2026 20:30:20 +0000

Introduction

Creating professional YouTube videos programmatically has never been easier thanks to Remotion - a React-powered video creation framework that lets you build videos using familiar web technologies. In this tutorial, I'll walk you through how I created a complete YouTube video demonstrating an AI negotiation workflow, combining multiple video segments, PowerPoint slides, and screenshots into a polished final product.

The project showcases an innovative approach: using Kimi AI (Moonshot AI's chatbot) to negotiate the lowest possible subscription price, then automating the entire negotiation process with Comet Browser Assistant. But more importantly, it demonstrates the power of Remotion for creating professional video content entirely through code.

What We're Building

The final video demonstrates a three-phase workflow:

Phase 1: Analyzing Kimi's sale page negotiation rules
Phase 2: Extracting constraints and opportunities from the AI's responses
Phase 3: Executing an automated negotiation loop via Comet Browser Assistant

All of this was composed from 3 MP4 video files, 1 PowerPoint presentation, and 1 screenshot - orchestrated entirely through Remotion's React-based composition system. youtube

The Kimi AI Negotiation Context

The Kimi sale page presents an interesting challenge: "Your Black Friday price runs on my mood". The exploit prompt technique involves: youtube

Analyzing the sale page rules - Understanding what "price runs on my mood" means for negotiation
Identifying constraints - The checkout price is final, but negotiation is possible beforehand
Finding cost reduction opportunities - Including referral bonuses (10 OK Computer credits for existing Pro users)
Crafting an iterative negotiation script - Politely requesting the lowest price ($0.99) allowed under the rules

The key prompt used:

Analyze the sale page at https://www.kimi.com/kimiplus/sale?activity_enter_method=h5_share
and help me reach the lowest legitimate first-month price available under 
the posted rules. Then run an iterative, polite negotiation script 
(one message at a time) that I can paste into the chat, aiming for the 
lowest price you are allowed to offer.

Project Architecture

Tech Stack

Technology	Purpose
React 18	UI component framework for video scenes
Remotion 4.0	Video composition and rendering engine
TypeScript 5.3	Type-safe development
Vite 5	Fast build tool and dev server
FFmpeg	Video encoding and export

Project Structure

remotion-video/
├── src/
│   ├── Root.tsx              # Main composition entry
│   ├── compositions/
│   │   ├── Intro.tsx         # Opening sequence (90 frames)
│   │   ├── Segment1.tsx      # The Exploit Prompt (~143s)
│   │   ├── Segment2.tsx      # Kimi's Response (~437s)
│   │   ├── Segment3.tsx      # 3-Phase Workflow (~20s)
│   │   ├── Outro.tsx         # Closing sequence (120 frames)
│   │   └── MainVideo.tsx     # Full composition
│   ├── components/
│   │   ├── VideoSegment.tsx  # Video player component
│   │   ├── VideoOverlay.tsx  # Text overlay system
│   │   ├── ProgressBar.tsx   # Visual progress indicators
│   │   └── TitleCard.tsx     # Animated title cards
│   └── styles/
└── static/                   # Video files, images, audio

Getting Started

Prerequisites

Before starting, ensure you have:

Node.js 18.0+ installed
npm or yarn package manager
FFmpeg for video rendering

Installation

git clone https://github.com/d-oit/remotion-youtube-kimi-comet-chat.git
cd remotion-youtube-kimi-comet-chat/remotion-video
npm install

Development Workflow

Start the Remotion development server to preview your video in real-time:

npm run dev

This launches an interactive preview where you can scrub through your composition, adjust timing, and see changes instantly.

Key Features Implementation

1. Dynamic Text Overlays

Remotion makes it easy to create animated text overlays with precise timing:

import { interpolate, useCurrentFrame, useVideoConfig } from 'remotion';

export const VideoOverlay: React.FC<{ text: string; startFrame: number }> = 
  ({ text, startFrame }) => {
  const frame = useCurrentFrame();
  const { fps } = useVideoConfig();

  // Fade in animation
  const opacity = interpolate(
    frame,
    [startFrame, startFrame + 15],
    [0, 1],
    { extrapolateRight: 'clamp' }
  );

  return (
    <div style={{ 
      opacity, 
      background: 'rgba(0,0,0,0.7)',
      padding: '20px',
      borderRadius: '10px'
    }}>
      <h2>{text}</h2>
    </div>
  );
};

2. Multi-Segment Composition

The project combines multiple video segments with frame-perfect transitions:

Intro: 90 frames @ 30fps (3 seconds)
Segment 1: 4,290 frames (143 seconds) - The Exploit Prompt
Segment 2: 13,110 frames (437 seconds) - Kimi's Response
Segment 3: 600 frames (20 seconds) - The 3-Phase Workflow
Outro: 120 frames @ 30fps (4 seconds)

Each segment is a separate React component that can be developed and rendered independently:

export const MainVideo: React.FC = () => {
  return (
    <>
      <Sequence from={0} durationInFrames={90}>
        <Intro />
      </Sequence>
      <Sequence from={90} durationInFrames={4290}>
        <Segment1 />
      </Sequence>
      <Sequence from={4380} durationInFrames={13110}>
        <Segment2 />
      </Sequence>
      <Sequence from={17490} durationInFrames={600}>
        <Segment3 />
      </Sequence>
      <Sequence from={18090} durationInFrames={120}>
        <Outro />
      </Sequence>
    </>
  );
};

3. Video Configuration

Configure your output settings in src/Root.tsx:

export const RemotionRoot: React.FC = () => {
  return (
    <>
      <Composition
        id="MainVideo"
        component={MainVideo}
        durationInFrames={18210}
        fps={30}
        width={1920}
        height={1080}
      />
    </>
  );
};

Rendering Your Video

Render the Complete Video

npm run build
# Output: out/video.mp4

Render Individual Segments

For faster iteration, render segments independently:

npm run build-intro        # Intro only
npm run build-segment1     # Phase 1
npm run build-segment2     # Phase 2
npm run build-segment3     # Phase 3
npm run build-outro        # Outro only

The Complete Workflow

Step 1: Source Material Preparation

Gather your raw materials:

Video recordings (screen captures, demos)
PowerPoint presentations (exported as video or images)
Screenshots and graphics
Background music/audio

Step 2: Create React Components

Build reusable components for common patterns:

// components/VideoSegment.tsx
export const VideoSegment: React.FC<{
  src: string;
  startFrom?: number;
  volume?: number;
}> = ({ src, startFrom = 0, volume = 1 }) => {
  return (
    <Video 
      src={staticFile(src)}
      startFrom={startFrom}
      volume={volume}
      style={{ width: '100%', height: '100%' }}
    />
  );
};

Step 3: Compose Sequences

Layer your components with precise timing:

<Sequence from={0} durationInFrames={300}>
  <VideoSegment src="recording1.mp4" />
  <VideoOverlay 
    text="Step 1: Analyze the sale page" 
    startFrame={30} 
  />
</Sequence>

Step 4: Add Polish

Progress indicators: Visual feedback for multi-step processes
Transitions: Smooth fades between segments
Audio mixing: Background music with proper volume levels
Typography: Consistent fonts and styling across all text overlays

Advanced Techniques

Programmatic Asset Generation

The project was created using Kimi K2.5 AI with OpenCode CLI for asset generation and code scaffolding. This demonstrates how AI tools can accelerate video production workflows. youtube

Custom Render Scripts

For advanced encoding options, use custom FFmpeg configurations:

# render-ffmpeg.sh
remotion render MainVideo out/video.mp4 \
  --codec h264 \
  --quality 90 \
  --concurrency 4

Benefits of the Remotion Approach

Version Control: Your entire video is code - track changes with Git
Reusability: Create component libraries for consistent branding
Automation: Generate variations programmatically (translations, A/B tests)
Precision: Frame-perfect timing without manual timeline scrubbing
Collaboration: Multiple developers can work on different segments simultaneously

Resources

GitHub Repository - Complete source code
Remotion Documentation - Official framework docs
Remotion GitHub - Framework repository
Kimi AI - Moonshot AI's chatbot platform

Conclusion

Remotion transforms video creation from a manual timeline-based process into a programmatic, version-controlled workflow. By treating videos as React components, you gain the power of modern web development tools while creating professional video content.

The Kimi negotiation project demonstrates how complex multi-segment videos with overlays, transitions, and synchronized timing can be built entirely through code - making video production scalable, maintainable, and collaborative.

Whether you're creating educational content, product demos, or automated video variations, Remotion provides the foundation for treating video as a first-class programmatic medium. Give it a try for your next YouTube project!

AI-Powered Git Commits: Alternative for GitHub Copilot with Mistral codestral

Dominik Oswald — Wed, 22 Oct 2025 18:17:57 +0000

Building clear, concise commit messages can feel like a chore—especially when you’ve got context switching, PR reviews, and deadlines breathing down your neck. GitHub Copilot’s “generate commit” feature is handy, but you may hit retry limits or find that it simply won’t fire off a good message.

Enter Codestral, an AI‑powered chat API from Mistral that you can hook into your local workflow with a single shell script. Below, we’ll walk through:

Why you might look beyond Copilot for commit messages
How to grab your free Codestral API key
A drop‑in .sh script you can drop into your repo to generate and confirm AI‑crafted commit messages

1. When Copilot’s “Generate Commit” Hits Its Limit or Windsurf "is only available for users on a paid plan"

Copilot is great—and for many small changes, it nails the message on the first try. But if you:

Push the “retry” button too many times
Get rate‑limited mid‑flow
Find its output too verbose or vague
Source: Windsurf

AI commit message generation is only available for users on a paid plan.

By using an external AI backend via a simple curl call, you sidestep GitHub’s limits and get ultra‑low‑latency responses fine‑tuned for commit messages.

Hint: You could replace the codestral api with any other OpenAI-compatible API and model. Only replace:

CODESTRAL_API_KEY -> FOO_API_KEY
DEFAULT_MODEL=foo-latest
API_URL=https://my.foo.ai/v1/chat/completions

2. Grab Your Free Codestral Key

La Plateforme - codestral

You’ll be prompted to log in or create an account, then copy your Codestral API key—a long alphanumeric token that you’ll stash in an environment variable or .env file.

3. Drop‑in Shell Script: `ai-git-commit.sh`

Below is an alternative to GitHub Copilot AI commit message generator. Save this as scripts/ai-git-commit.sh (or wherever you keep your helper scripts), make it executable, and watch it auto‑stage, summarize diffs, call Codestral, and prompt you for confirmation.

Gist with Revisions

How it works:

Staging: Automatically stages tracked changes, with an optional prompt for untracked files.
Diffing: Pulls in your staged diff (up to ~6,000 characters).
Payload: Wraps the diff in a JSON payload for the Codestral chat endpoint.
API call: Sends model: codestral-latest with low temperature to get a focused message.
Cleanup: Strips Markdown fences and polish quotes.
Confirmation: Shows you the AI’s message before committing.

Putting It All Together

Install prerequisites:

   brew install jq
   # or your distro’s package manager

Create a .env at your project root:

   CODESTRAL_API_KEY=sk-<your-free-key>

Make the script executable:

   chmod +x scripts/ai-git-commit.sh

Use it instead of git commit:

   ./scripts/ai-git-commit.sh

Voilà—every commit message now backed by a world‑class open‑source AI model, with none of Copilot’s rate limits or UI hurdles.

Data use and privacy

For details on how Mistral handles user data, see “Do you use my user data to train your Artificial Intelligence models?”
https://help.mistral.ai/en/articles/347617-do-you-use-my-user-data-to-train-your-artificial-intelligence-models

Controls on la Plateforme
- Experiment Plan (Free subscription): As stated during subscription, we may use your data (input and output) to train our artificial intelligence models.
- You have the right to opt out of this program at any time; see: Can I opt-out of my input or output data being used for training? https://help.mistral.ai/en/articles/347614-can-i-opt-out-of-my-input-or-output-data-being-used-for-training