DEV Community: Dominik Oswald

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