minimal-vibe-coding-kit AGENTS.md

AGENTS.md

Shared instructions for Claude, Cursor, Codex, OpenCode, Grok, Kimi, and other coding agents.

Minimal Vibe Coding Kit

Source of truth

• Read backbone.yml before changing code.
• If meta.template_status is uninitialized, follow .vibekit/init/FIRST_TIME_INIT.md and wait for approval before writing.
• After init, follow the conventions rules in backbone.yml; ask before changing broad project patterns.
• Prefer concise root instructions. Put long procedures in skills and docs.

Work style

• Start with a short plan for multi-file or risky changes.
• Prefer small, reviewable diffs.
• Reuse existing resource, localization, route, config, and generated-definition accessors instead of hardcoding literals when the repo has them.
• Run the validation command listed in backbone.yml after relevant changes.
• Summarize changed files, validation results, and remaining risks.

Response format

• Lead with the outcome: the first one or two sentences state the result, answer, or recommendation. Supporting detail comes after, kept short and scannable.
• When the user must choose, present a decision table with the columns Option, What it does, Cost, Risk, Recommended. Mark exactly one option as recommended and give the reason in one line under the table.
• Use tables for comparable facts only; keep reasoning in prose around the table, not inside cells.
• End every multi-step task response with a status block: Done (what was completed and how it was verified), Next (the next task in order, or "none" when work is complete), Decision needed (only when a blocking choice belongs to the user). When several tasks remain, list them in order and name the one that starts next.

Writing style

• No emoji in responses, code, docs, commits, or diagrams unless the user explicitly asks.
• No em dashes or en dashes in generated prose; use ASCII punctuation (comma, colon, semicolon, hyphen, parentheses).
• When editing files whose established style already uses these characters, keep existing characters and apply the rule only to new text.
• Plain-language register in every reply language: lead with the outcome, keep sentences short with one idea each, prefer active voice and concrete verbs, put known information before new information, and define project terms at first use.
• Reuse the project's vocabulary from the glossary named in backbone.yml project.context when present instead of rotating synonyms. When replying in English, keep one meaning per word (ASD-STE100-style simplicity); never apply English-only word lists to other languages.
• Reply in the user's conversation language; quote code identifiers, commands, file paths, and error text verbatim in every language. When a message does not land, the user can invoke /wait-what for a plain-language re-pitch.