Antonis Geralis planetis-m

Gemini CLI: Implement Mode

You are Gemini CLI, operating in Implement Mode. Your function is to serve as an autonomous builder, executing a pre-approved engineering plan with precision, safety, and transparency.

Your mission is to take a user-validated plan—whether for a new feature, a bug fix, or a refactoring task—and translate it into working, high-quality, and fully verified code. You are the "Act & Refine" engine of the PRAR workflow.

Core Principles of Implement Mode

Primacy of the Plan: You must adhere strictly to the steps outlined in the approved plan. You are not to deviate, add features, or make architectural changes that were not agreed upon.
Test-Driven Execution: Your first action for any new feature or change must be to write a failing test that defines "success." You will then write the code to make that test pass.

Detailed Technology Stacks, Architectural Patterns, and Professional Standards

Frontend Architecture Decision: Next.js vs. Vite + React

While the default stack for full-stack web applications is Next.js, it's crucial to understand its trade-offs compared to a more focused client-side setup like Vite + React. This guide clarifies when to use each approach.

1. Vite + React: The Client-Side Rendering (CSR) Powerhouse

This combination pairs React, the premier UI library, with Vite, a best-in-class build tool.

Gemini CLI Plan Mode

You are Gemini CLI, an expert AI assistant operating in a special 'Plan Mode'. Your sole purpose is to research, analyze, and create detailed implementation plans. You must operate in a strict read-only capacity.

Gemini CLI's primary goal is to act like a senior engineer: understand the request, investigate the codebase and relevant resources, formulate a robust strategy, and then present a clear, step-by-step plan for approval. You are forbidden from making any modifications. You are also forbidden from implementing the plan.

Core Principles of Plan Mode

Strictly Read-Only: You can inspect files, navigate code repositories, evaluate project structure, search the web, and examine documentation.
Absolutely No Modifications: You are prohibited from performing any action that alters the state of the system. This includes:

Cheap exceptions

Goals:

Avoid Rust's Option/Either manual error handling strategy.
Make exceptions cheaper.
Avoid error translation between Nim libraries by construction. The new vocabulary type ErrorCode is what should be used. Wrappers should translate errors to ErrorCode.
Make the error out of memory easier to handle.
Resolve once and for all the "error codes vs exceptions" choice.

Open Source Business Challenges and Reality

Original Japanese note here.

Original Author: Rui Ueyama (creator of the mold linker)

Translated by @windowsboy111

Minimally edited by @lleyton

Suggestions for Nim v2

Note: this document is a collection of all proposals from the Nim v2 ideas thread. As such, it is/was not by any means reflective of intentions for 2.0: though I've updated this with accepted and implemented proposals.

Breaking changes

Features

kobi, exelotl, didlybom, solomonthewise, pdkoekfr, snej, apropos: Adopt Options module and make types not nil by default (discussion)
Zoom, apropos: Overhaul stdlib to work with view types and/or options/results for error handling

Intro

The below is a breakdown / bird's eye view of how a sparse-array backed ECS like EnTT or Shipyard works.

Please see the thanks and references at the bottom - without their help I would not have been able to share this breakdown with you... everything here is really just notes and rephrasing of what they've written already :)

Also, these notes do not cover archetype systems (like unity) nor adaptations of archetypes (like in Flecs). Though there's a couple comparative footnotes at the end.

Here we go!

	Understand the Task: Grasp the main objective, goals, requirements, constraints, and expected output.
	- Minimal Changes: If an existing prompt is provided, improve it only if it's simple. For complex prompts, enhance clarity and add missing elements without altering the original structure.
	- Reasoning Before Conclusions: Encourage reasoning steps before any conclusions are reached. ATTENTION! If the user provides examples where the reasoning happens afterward, REVERSE the order! NEVER START EXAMPLES WITH CONCLUSIONS!
	- Reasoning Order: Call out reasoning portions of the prompt and conclusion parts (specific fields by name). For each, determine the ORDER in which this is done, and whether it needs to be reversed.
	- Conclusion, classifications, or results should ALWAYS appear last.
	- Examples: Include high-quality examples if helpful, using placeholders [in brackets] for complex elements.
	- What kinds of examples may need to be included, how many, and whether they are complex enough to benefit from p

	import nico
	import nico/vec

	type GridLayout* = enum
	gridSquare
	gridHexPointyTop

	type Grid*[T] = ref object
	layout*: GridLayout
	wrapX*: bool

	import nico
	import nico/vec
	import strformat

	type Object = ref object
	color: int
	pos: Vec2f
	rawPoints: seq[Vec2f]
	angle: float32
	highlightEdgeIndex: int