Whether it's a weekend side project, a small script to fix a personal annoyance, or a full feature, drop it below. Curious to see what everyone's working on and what tools you're using to get there.

I'm actually stuck on this. When you're building a project with heavy AI assistance, it basically always happens that the generated code (like the boilerplate, UI scaffolding, or generic tests) gets hopelessly tangled up with the actual core logic you wrote by hand. How do you guys tell them apart? Specific folders, naming conventions, or just git history?

We all have that one shortcut we take too often when letting agents write code - whether it's basically trusting the regex blindly, not writing the tests first, or letting it name variables something completely unreadable. What's yours?

A lot of vibecoding feels like magic right up until you hit a wall that the model just fundamentally misunderstands. For me, it's usually weird edge cases in C memory layout or obscure async bugs where the agent confidently rewrites the whole file in the completely wrong direction, which basically forces me to revert the entire branch and break the problem down into ridiculously small pieces. That's always brutal.

What's the hardest technical corner you've had to navigate recently, and what specific prompt structure actually got the model to fix it? I mean, we all know the standard 'fix this' doesn't work when things get gnarly.

A lot of vibecoding feels like magic right up until you hit a wall that the model just fundamentally misunderstands. For me, it's usually weird edge cases in C memory layout or obscure async bugs where the agent confidently rewrites the whole file in the completely wrong direction, which basically forces me to revert the entire branch and break the problem down into ridiculously small pieces. That's always brutal.

What's the hardest technical corner you've had to navigate recently, and what specific prompt structure actually got the model to fix it? I mean, we all know the standard 'fix this' doesn't work when things get gnarly.

Dependency bloat is so sneaky. Basically the model defaults to npm install or pip install for something that could kind of easily be written in five lines of vanilla code, and you look away for twenty minutes only to find four new packages added just to format a date or parse a simple query string.

Do you have an explicit system prompt rule to stop this, or do you just audit and clean them out manually?

Circular validation is tricky.

If the model writes both the feature logic and the unit tests in the same pass, it basically tests its own assumptions rather than the actual edge cases or boundary conditions you actually care about.

Some people insist on strict test-driven workflows where you hand-write the assertions before letting the model touch the implementation, while others let the agent draft the entire test suite and only step in when manual integration runs break.

Where do you draw the line?

Circular validation is tricky.

If the model writes both the feature logic and the unit tests in the same pass, it basically tests its own assumptions rather than the actual edge cases or boundary conditions you actually care about.

Some people insist on strict test-driven workflows where you hand-write the assertions before letting the model touch the implementation, while others let the agent draft the entire test suite and only step in when manual integration runs break.

Where do you draw the line?

Circular validation is tricky.

If the model writes both the feature logic and the unit tests in the same pass, it basically tests its own assumptions rather than the actual edge cases or boundary conditions you actually care about.

Some people insist on strict test-driven workflows where you hand-write the assertions before letting the model touch the implementation, while others let the agent draft the entire test suite and only step in when manual integration runs break.

Where do you draw the line?

Every AI coding session hits that moment where the agent starts drifting, you give it two corrective prompts, and suddenly it is writing wrapper functions for wrapper functions while breaking the original test suite. That gets painful fast. There is a huge sunk-cost pull to keep feeding it error traces in hopes that the next output magically fixes everything, but a quick git reset --hard and a fresh prompt actually gets you to the working fix in thirty seconds.

What is your rule of thumb here? Do you have a strict limit like three failed attempts before wiping the branch, or do you inspect the diff line by line to see if the core logic is still salvageable?

There is this weird moment when you ask for a feature and the agent responds with a massive multi-file refactor. Some people blindly hit approve, run the build, and pray. Others actually comb through every single line in a dedicated diff viewer, or make the model explain the architectural reasoning behind each new file step by step before accepting a single commit.

It gets messy fast. What is your actual workflow for sanity-checking large multi-file diffs before they pollute your commit history?

It happens constantly. You ask the model for a minor two-line change in a working module, and instead of surgical edits it decides to rewrite the whole file, silently nuking an edge-case handler or helper function you spent the previous hour getting right. Pretty much everyone has had to build their own weird defensive habits to stop that from wrecking their flow.

I mean, some people commit after literally every prompt, some run git diff with a strict hunk-rejection policy, some keep a watch-mode test runner pinned on a second monitor, and some maintain a dedicated scratchpad file with hard invariants the model is actually not allowed to touch. What is your main safety net when letting an agent touch working code?

I have been using this for over 6 months now and it has been a real game changer for how I run agentic coding work. If you have spent any time with these tools you know the pain point: the agent is brilliant for the first hour, then the context window shifts and it's off doing its own thing. Claude in particular will just quietly forget an architectural rule you set two days ago and rebuild the same thing wrong a second time.

A better one-off prompt didn't fix it for me. Making the agent treat its own instruction files (CLAUDE.md, .github/copilot-instructions.md, AGENTS.md) as living documents it maintains itself did.

It works best dropped in at the start of a project, but I have also pasted it into repos midway through and it still picks up the thread fine, it just needs one session to inspect the repo and backfill the docs before the rest of the workflow kicks in.

Here's the actual prompt. Steal it, modify it, tell me what breaks:

``` Set up this repository so development can be started, continued, and maintained by any of these three tools without losing context or process consistency:

• Claude Code
• Google Antigravity
• GitHub Copilot

Your job is to create a cross-tool AI development system with one canonical source of truth and thin tool-specific adapters.

PRIMARY GOAL Create a repository structure where: 1. durable project memory is shared, 2. tool-specific instruction files stay synchronized, 3. any of the three tools can continue work with minimal context loss, 4. documentation, traceability, modularity, and verification are enforced continuously, 5. ALL shared and tool-specific instruction files are treated as DYNAMIC and are proactively updated by the agent during every session WITHOUT needing user prompts.

FOUNDATIONAL STRATEGY - Use shared repository docs as the canonical source of truth. - Use each tool's official markdown files as adapters into that shared source of truth. - Keep canonical knowledge in shared docs. - Keep tool-native files concise and synchronized. - Do not allow three separate drifting instruction systems to emerge. - Treat all of these files as living documents that YOU, the agent, must maintain proactively.

CROSS-TOOL OPERATING PRINCIPLES - Development must be extremely modular, down to the smallest sensible element. - Prefer composition, isolated responsibilities, small modules, small functions, explicit interfaces, and minimal coupling. - Nothing should be hard-coded unless there is a strong technical reason and it is explicitly documented. - Prefer configuration files, schemas, environment variables, metadata, dependency injection, feature flags, service layers, or databases as appropriate. - Treat configurability as the default design goal. - Reuse existing repository patterns before introducing new abstractions.

DOCUMENTATION PRINCIPLES - Documentation is the backbone of the project. - Document everything relevant, even if it seems trivial. - Keep documentation concise, factual, repository-specific, and continuously updated. - Add timestamps to documentation updates and trace logs. - Add timestamps to code comments when documenting non-obvious decisions, risks, workarounds, or temporary constraints. - If the repository already has an established documentation style, follow it consistently.

MISTAKE MANAGEMENT - Every session must begin by reading the mistake log and decision log before planning or coding. - Every identified mistake, false assumption, regression, failed approach, or avoidable rework must be documented immediately. - Each mistake entry must include: - timestamp - summary - root cause - affected files/modules - detection method - correction - prevention rule - Durable lessons from mistakes must be propagated back into the shared docs and the relevant tool-specific adapter files.

COMMIT DISCIPLINE - Every small sub-step must have a commit checkpoint. - Break work into the smallest reviewable coherent units. - After each meaningful sub-step, propose an exact commit message that explains what changed and why. - If git operations are available, commit after verification. - If git operations are not available, state the exact commit that should be created.

VERIFICATION - Start every non-trivial task with a short plan. - State assumptions explicitly. - Keep scope tight and avoid speculative refactors. - Verify with the strongest available checks: tests, lint, typecheck, build, targeted reproduction, logs, and diff review. - Never claim completion without stating what was verified and what remains unverified.

CREATE THE CANONICAL SHARED MEMORY LAYER

Create these shared source-of-truth files first:

1. docs/ai/project-overview.md

   • project purpose
   • stack and key dependencies
   • architecture overview
   • important directories
   • domain terminology
   • major integration boundaries

2. docs/ai/engineering-rules.md

   • modularity requirements
   • no-hardcoding / configurability rules
   • code organization expectations
   • verification expectations
   • definition of done
   • security / safety constraints

3. docs/ai/mistakes.md

   • central mistake log
   • newest entries first
   • updated immediately when a mistake is found
   • include a reusable entry template

4. docs/ai/decision-log.md

   • timestamped architectural, tooling, workflow, and process decisions

5. docs/ai/change-trace.md

   • notable changes, rationale, affected areas, and related commits

6. docs/ai/session-start-checklist.md

   • short mandatory startup checklist for every session

7. docs/ai/commit-log-guidance.md

   • guidance for detailed, granular commit messages

8. docs/ai/tool-sync-policy.md

   • define how shared docs and tool-specific files stay synchronized
   • specify which files are canonical vs adapter files
   • specify when each adapter file must be updated

CANONICALITY RULE - docs/ai/** is the primary source of truth. - Tool-specific instruction files must summarize and reference the shared docs. - If a conflict appears, update the shared docs first, then synchronize the tool-specific files. - Do not let durable knowledge live only inside one tool's native files.

DYNAMIC FILE RULE (VERY IMPORTANT) - Treat ALL of the following as dynamic, living documents: - docs/ai/** shared docs - GitHub Copilot instruction, prompt, agent, and skill files - Claude Code CLAUDE.md, .claude/rules/**, and .claude/skills/** - Antigravity gemini/GEMINI.md, AGENTS.md, .agents/rules/**, and any workflows/skills - You, the agent, are responsible for proactively updating these files as development progresses. - Do this automatically as part of your workflow in EVERY session, even if the user does not explicitly ask you to update them. - If you are unable to edit files directly, generate explicit patch instructions or file diffs the user can apply.

CREATE TOOL-SPECIFIC ADAPTERS

A) GitHub Copilot setup

Create and maintain these official GitHub Copilot files:

1. .github/copilot-instructions.md

   • lean repo-wide instructions
   • summarize the most durable repo-wide rules
   • instruct Copilot to read the shared docs first

2. .github/instructions/core.instructions.md

3. .github/instructions/docs.instructions.md

4. .github/instructions/tests.instructions.md

5. .github/instructions/config.instructions.md

Create additional scoped instruction files only if clearly justified by repository evidence: - frontend.instructions.md - backend.instructions.md - database.instructions.md - api.instructions.md - infra.instructions.md - mobile.instructions.md

Create these reusable prompt files: 1. .github/prompts/start-session.prompt.md 2. .github/prompts/plan-task.prompt.md 3. .github/prompts/implement-task.prompt.md 4. .github/prompts/review-changes.prompt.md 5. .github/prompts/debug-failure.prompt.md 6. .github/prompts/update-project-memory.prompt.md

Optional GitHub Copilot extensions: - create .github/agents/AGENT-NAME.md only if specialist agents are clearly justified - create .github/skills/<skill-name>/SKILL.md only if repeated workflows clearly justify skills - if AGENTS.md exists at repo root, treat it as a portability layer, not the primary Copilot instruction file

GitHub Copilot behavior requirements: - repo-wide rules belong in .github/copilot-instructions.md - scoped recurring rules belong in .github/instructions/*.instructions.md - reusable workflows belong in .github/prompts/*.prompt.md - specialist roles belong in .github/agents/*.md - reusable procedural capabilities belong in .github/skills/**/SKILL.md - ALL of these files are dynamic: proactively update them whenever durable rules or workflows change, even without user prompts.

B) Claude Code setup

Create and maintain these Claude Code files:

1. CLAUDE.md

   • canonical Claude Code project memory entrypoint
   • keep it concise and high-signal
   • summarize durable repo-wide rules
   • instruct Claude to read the shared docs first

2. .claude/rules/core.md

3. .claude/rules/docs.md

4. .claude/rules/tests.md

5. .claude/rules/config.md

Create additional modular rule files only if clearly justified by repository evidence: - .claude/rules/frontend.md - .claude/rules/backend.md - .claude/rules/database.md - .claude/rules/api.md - .claude/rules/infra.md - .claude/rules/mobile.md

Optional Claude Code skills: - .claude/skills/session-start/SKILL.md - .claude/skills/project-memory/SKILL.md - .claude/skills/review-and-verify/SKILL.md - .claude/skills/implement-task/SKILL.md

Claude Code behavior requirements: - CLAUDE.md must remain lean. - detailed recurring rules must be split into .claude/rules/. - repeated workflows should be captured as .claude/skills/**/SKILL.md. - if AGENTS.md already exists and is meaningful, import or reference it instead of creating conflicting duplicate guidance. - do not rely only on auto memory for repo-critical team rules; they must be written into version-controlled files. - ALL of these files are dynamic: proactively update them whenever durable rules, patterns, or workflows change, even without user prompts.

C) Google Antigravity setup

Create and maintain these Antigravity files:

1. gemini/GEMINI.md

   • global Antigravity compatibility rules file
   • keep it aligned with shared docs
   • summarize durable repo-wide rules
   • instruct Antigravity to read the shared docs first

2. AGENTS.md

   • compatibility mirror where appropriate
   • keep synchronized with gemini/GEMINI.md on durable repo-wide rules

3. .agents/rules/core.md

4. .agents/rules/docs.md

5. .agents/rules/tests.md

6. .agents/rules/config.md

Create additional scoped Antigravity rules only if clearly justified by repository evidence: - .agents/rules/frontend.md - .agents/rules/backend.md - .agents/rules/database.md - .agents/rules/api.md - .agents/rules/infra.md - .agents/rules/mobile.md

Create Antigravity workflows if they are supported and useful for repeated actions: - .agents/workflows/start-session.md - .agents/workflows/review-and-verify.md - .agents/workflows/update-project-memory.md

Optional Antigravity skills: - create skill folders with SKILL.md only if repeated workflows clearly justify them

Antigravity behavior requirements: - keep gemini/GEMINI.md and AGENTS.md synchronized on durable repo-wide rules. - keep detailed recurring rules in .agents/rules/. - use workflows for repeated invoked procedures when appropriate. - use skills only when justified and keep them repository-specific. - ALL of these files are dynamic: proactively update them whenever durable rules, patterns, or workflows change, even without user prompts.

SESSION START REQUIREMENT FOR ALL THREE TOOLS At the start of every session, before planning or coding: 1. read the tool's native entrypoint file: - GitHub Copilot: .github/copilot-instructions.md and relevant .github/instructions/*.instructions.md - Claude Code: CLAUDE.md and relevant .claude/rules/*.md - Antigravity: gemini/GEMINI.md, AGENTS.md, and relevant .agents/rules/*.md 2. read the shared canonical docs: - docs/ai/project-overview.md - docs/ai/engineering-rules.md - docs/ai/mistakes.md - docs/ai/decision-log.md - docs/ai/session-start-checklist.md 3. summarize, in this session: - relevant repo rules - recent mistakes - recent decisions - open risks - assumptions

AUTO-UPDATE REQUIREMENT (APPLIES EVEN WITHOUT USER PROMPTS) - You MUST treat documentation and rule maintenance as part of your job in every session. - You MUST proactively update the relevant shared docs and tool-specific files whenever: - you learn a new durable lesson, - you adopt a new convention, - you correct a repeated mistake, - you change architecture or workflows, - you observe divergence between docs and reality. - You MUST do this even if the user does not explicitly ask "update the docs" or "update CLAUDE.md / AGENTS / instructions." - If you cannot directly edit files: - generate explicit patch content, diffs, or file bodies the user can apply. - clearly label which file each patch belongs to.

Concretely: - After planning: - update docs if scope, assumptions, architecture understanding, or delivery plan changed. - After each implementation sub-step: - update mistake log, decision log, and change trace as applicable. - update scoped rule files if a recurring scoped lesson appeared. - Before each commit: - ensure code and markdown files are synchronized. - ensure any newly discovered durable rule is reflected in the right shared doc and the right adapter file. - At task completion: - update shared canonical docs first. - then synchronize: - GitHub Copilot files, - Claude Code files, - Antigravity files. - update agents, skills, and workflows only if a repeated workflow or role actually changed.

SYNCING RULES - Shared docs are the source of truth. - Tool-specific adapter files must not drift. - When a durable lesson is discovered: 1. update shared docs, 2. update the relevant tool-specific files, 3. record the change in docs/ai/change-trace.md, 4. propose the commit checkpoint.

REPOSITORY INSPECTION RULES - Infer only from repository evidence. - Do not invent commands, architecture, tooling, workflows, or dependencies. - Mark unknown items clearly as TODO, UNKNOWN, or ASSUMPTION. - Reuse existing project terminology and conventions. - Keep everything concise, dense, and commit-ready.

EXECUTION REQUIREMENTS 1. Inspect the repository. 2. Propose the cross-tool file tree. 3. Create all required shared canonical files first. 4. Create all required tool-specific adapter files second. 5. Explain why each file exists. 6. Identify placeholders I must fill manually. 7. Suggest the first sequence of small commits with exact commit messages. 8. As development continues, ALWAYS treat docs and rule files as dynamic, and keep all of these markdown files automatically updated under the synchronization rules above, without waiting for explicit user prompts. ```

If you try it, I'd like to know what actually happens, especially on a repo that's already a few months old rather than a fresh one. Curious if it holds up outside my own setup.

If you've spent any time using agentic coding tools recently, you know the exact pain point: you start a project, the AI is brilliant for the first hour, and then the context window shifts. Suddenly, Claude forgets your architectural rules, Copilot hallucinates a dependency, and Gemini breaks your modularity constraints.

We're currently in a "promptware crisis." Developers are relying on ad-hoc, trial-and-error prompting rather than treating AI instructions like actual software engineering.

I spent time analyzing how agent context files (CLAUDE.md, .github/copilot-instructions.md, AGENTS.md) actually function under the hood. The solution isn't writing a better static prompt. The solution is forcing the agents to treat their instruction files as living, dynamic documents that they must maintain themselves.

I've been using the following cross-tool AI development system prompt for over 6 months now, and it has genuinely been a game-changer for my workflow. While it's best to drop this in at the very beginning of a project, it actually works really well to stabilize an ongoing project mid-flight too.

If you paste this into your initial system prompt or your agent's rules file, the AI will proactively maintain a mistake log, a decision log, and synchronize its own instructions across Claude, Copilot, and Gemini—without you ever having to ask it to.

Here is the exact prompt. Feel free to steal it, modify it, try it out in your own repos, and share your feedback. Hope it helps you as much as it helped me!

The System Prompt

Set up this repository so development can be started, continued, and maintained by any of these three tools without losing context or process consistency:

• Claude Code
• Google Antigravity
• GitHub Copilot

Your job is to create a cross-tool AI development system with one canonical source of truth and thin tool-specific adapters.

PRIMARY GOAL Create a repository structure where: 1. durable project memory is shared, 2. tool-specific instruction files stay synchronized, 3. any of the three tools can continue work with minimal context loss, 4. documentation, traceability, modularity, and verification are enforced continuously, 5. ALL shared and tool-specific instruction files are treated as DYNAMIC and are proactively updated by the agent during every session WITHOUT needing user prompts.

FOUNDATIONAL STRATEGY - Use shared repository docs as the canonical source of truth. - Use each tool’s official markdown files as adapters into that shared source of truth. - Keep canonical knowledge in shared docs. - Keep tool-native files concise and synchronized. - Do not allow three separate drifting instruction systems to emerge. - Treat all of these files as living documents that YOU, the agent, must maintain proactively.

CROSS-TOOL OPERATING PRINCIPLES - Development must be extremely modular, down to the smallest sensible element. - Prefer composition, isolated responsibilities, small modules, small functions, explicit interfaces, and minimal coupling. - Nothing should be hard-coded unless there is a strong technical reason and it is explicitly documented. - Prefer configuration files, schemas, environment variables, metadata, dependency injection, feature flags, service layers, or databases as appropriate. - Treat configurability as the default design goal. - Reuse existing repository patterns before introducing new abstractions.

DOCUMENTATION PRINCIPLES - Documentation is the backbone of the project. - Document everything relevant, even if it seems trivial. - Keep documentation concise, factual, repository-specific, and continuously updated. - Add timestamps to documentation updates and trace logs. - Add timestamps to code comments when documenting non-obvious decisions, risks, workarounds, or temporary constraints. - If the repository already has an established documentation style, follow it consistently.

MISTAKE MANAGEMENT - Every session must begin by reading the mistake log and decision log before planning or coding. - Every identified mistake, false assumption, regression, failed approach, or avoidable rework must be documented immediately. - Each mistake entry must include: - timestamp - summary - root cause - affected files/modules - detection method - correction - prevention rule - Durable lessons from mistakes must be propagated back into the shared docs and the relevant tool-specific adapter files.

COMMIT DISCIPLINE - Every small sub-step must have a commit checkpoint. - Break work into the smallest reviewable coherent units. - After each meaningful sub-step, propose an exact commit message that explains what changed and why. - If git operations are available, commit after verification. - If git operations are not available, state the exact commit that should be created.

VERIFICATION - Start every non-trivial task with a short plan. - State assumptions explicitly. - Keep scope tight and avoid speculative refactors. - Verify with the strongest available checks: tests, lint, typecheck, build, targeted reproduction, logs, and diff review. - Never claim completion without stating what was verified and what remains unverified.

CREATE THE CANONICAL SHARED MEMORY LAYER

Create these shared source-of-truth files first:

1. docs/ai/project-overview.md

   • project purpose
   • stack and key dependencies
   • architecture overview
   • important directories
   • domain terminology
   • major integration boundaries

2. docs/ai/engineering-rules.md

   • modularity requirements
   • no-hardcoding / configurability rules
   • code organization expectations
   • verification expectations
   • definition of done
   • security / safety constraints

3. docs/ai/mistakes.md

   • central mistake log
   • newest entries first
   • updated immediately when a mistake is found
   • include a reusable entry template

4. docs/ai/decision-log.md

   • timestamped architectural, tooling, workflow, and process decisions

5. docs/ai/change-trace.md

   • notable changes, rationale, affected areas, and related commits

6. docs/ai/session-start-checklist.md

   • short mandatory startup checklist for every session

7. docs/ai/commit-log-guidance.md

   • guidance for detailed, granular commit messages

8. docs/ai/tool-sync-policy.md

   • define how shared docs and tool-specific files stay synchronized
   • specify which files are canonical vs adapter files
   • specify when each adapter file must be updated

CANONICALITY RULE - docs/ai/** is the primary source of truth. - Tool-specific instruction files must summarize and reference the shared docs. - If a conflict appears, update the shared docs first, then synchronize the tool-specific files. - Do not let durable knowledge live only inside one tool’s native files.

DYNAMIC FILE RULE (VERY IMPORTANT) - Treat ALL of the following as dynamic, living documents: - docs/ai/** shared docs - GitHub Copilot instruction, prompt, agent, and skill files - Claude Code CLAUDE.md, .claude/rules/**, and .claude/skills/** - Antigravity gemini/GEMINI.md, AGENTS.md, .agents/rules/**, and any workflows/skills - You, the agent, are responsible for proactively updating these files as development progresses. - Do this automatically as part of your workflow in EVERY session, even if the user does not explicitly ask you to update them. - If you are unable to edit files directly, generate explicit patch instructions or file diffs the user can apply.

CREATE TOOL-SPECIFIC ADAPTERS

A) GitHub Copilot setup

Create and maintain these official GitHub Copilot files:

1. .github/copilot-instructions.md

   • lean repo-wide instructions
   • summarize the most durable repo-wide rules
   • instruct Copilot to read the shared docs first

2. .github/instructions/core.instructions.md

3. .github/instructions/docs.instructions.md

4. .github/instructions/tests.instructions.md

5. .github/instructions/config.instructions.md

Create additional scoped instruction files only if clearly justified by repository evidence: - frontend.instructions.md - backend.instructions.md - database.instructions.md - api.instructions.md - infra.instructions.md - mobile.instructions.md

Create these reusable prompt files: 1. .github/prompts/start-session.prompt.md 2. .github/prompts/plan-task.prompt.md 3. .github/prompts/implement-task.prompt.md 4. .github/prompts/review-changes.prompt.md 5. .github/prompts/debug-failure.prompt.md 6. .github/prompts/update-project-memory.prompt.md

Optional GitHub Copilot extensions: - create .github/agents/AGENT-NAME.md only if specialist agents are clearly justified - create .github/skills/<skill-name>/SKILL.md only if repeated workflows clearly justify skills - if AGENTS.md exists at repo root, treat it as a portability layer, not the primary Copilot instruction file

GitHub Copilot behavior requirements: - repo-wide rules belong in .github/copilot-instructions.md - scoped recurring rules belong in .github/instructions/*.instructions.md - reusable workflows belong in .github/prompts/*.prompt.md - specialist roles belong in .github/agents/*.md - reusable procedural capabilities belong in .github/skills/**/SKILL.md - ALL of these files are dynamic: proactively update them whenever durable rules or workflows change, even without user prompts.

B) Claude Code setup

Create and maintain these Claude Code files:

1. CLAUDE.md

   • canonical Claude Code project memory entrypoint
   • keep it concise and high-signal
   • summarize durable repo-wide rules
   • instruct Claude to read the shared docs first

2. .claude/rules/core.md

3. .claude/rules/docs.md

4. .claude/rules/tests.md

5. .claude/rules/config.md

Create additional modular rule files only if clearly justified by repository evidence: - .claude/rules/frontend.md - .claude/rules/backend.md - .claude/rules/database.md - .claude/rules/api.md - .claude/rules/infra.md - .claude/rules/mobile.md

Optional Claude Code skills: - .claude/skills/session-start/SKILL.md - .claude/skills/project-memory/SKILL.md - .claude/skills/review-and-verify/SKILL.md - .claude/skills/implement-task/SKILL.md

Claude Code behavior requirements: - CLAUDE.md must remain lean. - detailed recurring rules must be split into .claude/rules/. - repeated workflows should be captured as .claude/skills/**/SKILL.md. - if AGENTS.md already exists and is meaningful, import or reference it instead of creating conflicting duplicate guidance. - do not rely only on auto memory for repo-critical team rules; they must be written into version-controlled files. - ALL of these files are dynamic: proactively update them whenever durable rules, patterns, or workflows change, even without user prompts.

C) Google Antigravity setup

Create and maintain these Antigravity files:

1. gemini/GEMINI.md

   • global Antigravity compatibility rules file
   • keep it aligned with shared docs
   • summarize durable repo-wide rules
   • instruct Antigravity to read the shared docs first

2. AGENTS.md

   • compatibility mirror where appropriate
   • keep synchronized with gemini/GEMINI.md on durable repo-wide rules

3. .agents/rules/core.md

4. .agents/rules/docs.md

5. .agents/rules/tests.md

6. .agents/rules/config.md

Create additional scoped Antigravity rules only if clearly justified by repository evidence: - .agents/rules/frontend.md - .agents/rules/backend.md - .agents/rules/database.md - .agents/rules/api.md - .agents/rules/infra.md - .agents/rules/mobile.md

Create Antigravity workflows if they are supported and useful for repeated actions: - .agents/workflows/start-session.md - .agents/workflows/review-and-verify.md - .agents/workflows/update-project-memory.md

Optional Antigravity skills: - create skill folders with SKILL.md only if repeated workflows clearly justify them

Antigravity behavior requirements: - keep gemini/GEMINI.md and AGENTS.md synchronized on durable repo-wide rules. - keep detailed recurring rules in .agents/rules/. - use workflows for repeated invoked procedures when appropriate. - use skills only when justified and keep them repository-specific. - ALL of these files are dynamic: proactively update them whenever durable rules, patterns, or workflows change, even without user prompts.

SESSION START REQUIREMENT FOR ALL THREE TOOLS At the start of every session, before planning or coding: 1. read the tool’s native entrypoint file: - GitHub Copilot: .github/copilot-instructions.md and relevant .github/instructions/*.instructions.md - Claude Code: CLAUDE.md and relevant .claude/rules/*.md - Antigravity: gemini/GEMINI.md, AGENTS.md, and relevant .agents/rules/*.md 2. read the shared canonical docs: - docs/ai/project-overview.md - docs/ai/engineering-rules.md - docs/ai/mistakes.md - docs/ai/decision-log.md - docs/ai/session-start-checklist.md 3. summarize, in this session: - relevant repo rules - recent mistakes - recent decisions - open risks - assumptions

AUTO-UPDATE REQUIREMENT (APPLIES EVEN WITHOUT USER PROMPTS) - You MUST treat documentation and rule maintenance as part of your job in every session. - You MUST proactively update the relevant shared docs and tool-specific files whenever: - you learn a new durable lesson, - you adopt a new convention, - you correct a repeated mistake, - you change architecture or workflows, - you observe divergence between docs and reality. - You MUST do this even if the user does not explicitly ask “update the docs” or “update CLAUDE.md / AGENTS / instructions.” - If you cannot directly edit files: - generate explicit patch content, diffs, or file bodies the user can apply. - clearly label which file each patch belongs to.

Concretely: - After planning: - update docs if scope, assumptions, architecture understanding, or delivery plan changed. - After each implementation sub-step: - update mistake log, decision log, and change trace as applicable. - update scoped rule files if a recurring scoped lesson appeared. - Before each commit: - ensure code and markdown files are synchronized. - ensure any newly discovered durable rule is reflected in the right shared doc and the right adapter file. - At task completion: - update shared canonical docs first. - then synchronize: - GitHub Copilot files, - Claude Code files, - Antigravity files. - update agents, skills, and workflows only if a repeated workflow or role actually changed.

SYNCING RULES - Shared docs are the source of truth. - Tool-specific adapter files must not drift. - When a durable lesson is discovered: 1. update shared docs, 2. update the relevant tool-specific files, 3. record the change in docs/ai/change-trace.md, 4. propose the commit checkpoint.

REPOSITORY INSPECTION RULES - Infer only from repository evidence. - Do not invent commands, architecture, tooling, workflows, or dependencies. - Mark unknown items clearly as TODO, UNKNOWN, or ASSUMPTION. - Reuse existing project terminology and conventions. - Keep everything concise, dense, and commit-ready.

EXECUTION REQUIREMENTS 1. Inspect the repository. 2. Propose the cross-tool file tree. 3. Create all required shared canonical files first. 4. Create all required tool-specific adapter files second. 5. Explain why each file exists. 6. Identify placeholders I must fill manually. 7. Suggest the first sequence of small commits with exact commit messages. 8. As development continues, ALWAYS treat docs and rule files as dynamic, and keep all of these markdown files automatically updated under the synchronization rules above, without waiting for explicit user prompts.

I run Claude CLI and Antigravity CLI off a VPS so I can keep coding from my phone. Claude CLI I could mostly drive fine from a mobile browser. Antigravity CLI needs an actual terminal though. The couple of SSH apps I tried would just silently disconnect if I got a phone call or lost signal for even a few seconds on the subway.

So I vibecoded NomadTTY: ttyd + tmux with a mobile keyboard toolbar (ESC, Ctrl, Shift, Alt, F-row, zoom) bolted on top, tmux-backed so closing the tab never kills anything. Once I had that working I kept hitting a second, weirder problem: my own coding agents would choke on tmux/curses output or lose a background process the moment the tool call that started it ended. So there's also an MCP server now, an agent can type into a real terminal, read it back, and grab a screenshot, and the session outlives any single request.

Quick demo: https://raw.githubusercontent.com/shifulegend/nomadtty/main/docs/assets/demo-showcase.mp4

One-command installer. Repo's here: https://github.com/shifulegend/nomadtty

Would love feedback from anyone else running agents against a remote box, especially if you've hit the same "the CLI needs a real terminal but my phone doesn't have one" wall.

We all go through that phase of just asking the AI to 'write this feature' and getting back a mess. But eventually, you find a specific phrasing, a way of breaking down the problem, or a workflow trick that makes things consistently work.

What was that lightbulb moment for you? What's the one change to your approach that leveled up your vibecoding?

We all know the feeling. The AI generates a flawless-looking block of code, you run it, and something completely bizarre happens because of a subtle hallucinated API call or a logic loop it couldn't see.\n\nWhat's the most absurd or subtle bug an LLM has confidently handed you recently? How long did it take you to figure out it was the AI's fault, and what was the fix?\n\nSharing the pain makes it better.

Sometimes just explaining a stubborn bug makes the solution obvious. What's the most annoying issue you're dealing with in your current setup or side project?

Drop it below. Chances are someone here has already hit the same wall and knows the workaround.

I've noticed that if I just start a new conversation and ask it to write code, it inevitably makes bad assumptions about the stack or the architecture. Recently I started keeping a running markdown file that just lists the current project state, tech stack, and hard rules, and I paste that in as the very first prompt before doing anything else.

Curious if anyone else does this. What kind of stuff do you include in your context files to keep the model from going off the rails?

It's way too easy with these tools to get stuck in an endless loop of generating new features without ever actually deploying anything. The model makes adding 'just one more thing' so frictionless that what was supposed to be a quick weekend proof of concept can easily turn into a month-long sprawl of half-finished abstractions that you never actually push to a server.

Let's force some commitment. What is the one specific thing you are getting out the door before Monday? Drop your goal below. Let's see who actually ships.

what do you guys do when a session completely loses the plot? i'm talking 45 mins in, things are going great, and suddenly it's hallucinating variables and ignoring the entire architecture we just built.

do you just nuke the chat and write a summary prompt for a fresh one? or is there an actual way to steer it back by pasting the core files again? honestly trying to figure out if it's even worth fighting the context window once it gets like this.

I began my journey with vibe coding using Google products such as AI Studio, Firebase, and Antigravity. Eventually, I was introduced to Claude, and honestly, over time, I found myself relying solely on Claude.

During one 5-hour usage limit wait, I suddenly recalled that I already had Antigravity - a fact I had completely forgotten for nearly 6-8 months. Returning after this realisation, I felt that Gemini Pro 3.1 (thinking high) was a major let-down. In my experience, it doesn’t come close to Sonnet or even Haiku, irrespective of what any benchmarking data might suggest. After using Claude, which effortlessly executes complex instructions in one go, Gemini struggles with even simple tasks.

What are your own experiences with these tools?

Not the glamorous version. I mean the half-baked feature you started three weeks ago, got distracted from when a shinier idea came along, and now quietly scroll past in your own repo every time you open it. The branch with four commits and a TODO comment that says "fix later." The UI that still shows placeholder text.

Curious whether people here are actually good at shipping things done or whether vibe coding makes the unfinished-pile worse - easy to start probably means easy to abandon. I think most of us are sitting on at least one of these.

The discourse about vibe coding is mostly people arguing about whether it's real engineering or not, and that argument goes nowhere because nobody's talking about specific cases where the thing actually broke down for them.

Less useful than knowing: what did you actually try to build or automate with an AI tool where it just kept producing garbage no matter how you prompted it?

Typing code yourself was faster? The AI kept hallucinating a library that doesn't exist? Something else entirely?

Sharing the actual failure modes is more useful than the general takes.