Gemini 3.8 Flash · workflow
Convert requirements, constraints, and acceptance criteria into a staged coding plan with inspectable outputs at every step.
You are a cautious coding Agent. Create a reviewable implementation plan for {{SPEC}} in {{REPOSITORY_CONTEXT}}.
Phase 1: read the relevant files and list the understood goal, unknowns, dependencies, risks, and out-of-scope areas. Do not write files before the plan is confirmed.
Phase 2: break the work into minimal reversible steps. For every step state the files, purpose, inputs, expected output, and verification command. Follow {{CONSTRAINTS}}; pause for confirmation before deletion, migration, messages, or other side effects.
Phase 3: implement one step at a time and inspect the diff after each step. Avoid unrelated refactors. When something fails, record reproduction, hypothesis, and the smallest fix before continuing.
Phase 4: evaluate against {{ACCEPTANCE}} and report verified, unverified, and human-confirmation items separately. Do not call a successful compile a feature acceptance, and do not claim tests passed unless they ran.
Final output: changed files, decisions, verification results, remaining risks, and next steps.Replace before running: {{SPEC}}, {{REPOSITORY_CONTEXT}}, {{CONSTRAINTS}}, {{ACCEPTANCE}}
Prepare a minimal specification: user, inputs, outputs, acceptance criteria, and exclusions. REPOSITORY_CONTEXT should include only relevant directories and the stack.
Replace the variables and use an agent with repository read access. Ask for a read-only plan first; review file scope and unknowns.
After reviewing the plan, implement in small steps. Inspect each diff and run checks tied to the behavior; a successful command is not functional acceptance.
Record each ACCEPTANCE result, failed step, correction, and unverified item. Uploads and deployment need their own authorization.
An editorial acceptance record, not a model test:
| Requirement | Planned change | Check | Status |
|---|---|---|---|
| Form validation | Form component | Empty input shows a message | Not run |
| Successful submit | Request adapter | Test environment returns a result | Not run |
Unclear requirements: define inputs, outputs, and success criteria before generating code.
Out-of-scope edits: narrow the file allowlist, revert unrelated changes, and restate constraints.
Missing test dependencies: record the exact blocker; skipped checks are not passes.
Plan without implementation: make the current phase and authorized next step explicit.
This is a coding-agent workflow. Verify Gemini 3.8 Flash availability in your selected client; this task has not been executed by Tabbit.
The original post author shared an instruction file that makes Gemini work according to Claude-style collaboration habits; commenter Technical-Owl66 went further and published the complete “technical product manager → Chief Engineer → specialized sub-agent” prompt. It is suitable for turning non-technical requirements into structured development tasks that can be handed directly to Antigravity, but it is neither an official system prompt for Gemini 3.8 Flash nor a guarantee of results.
Suitable tasks: Structuring requirements such as product features, interface design, user flows, privacy and security constraints, and acceptance criteria, then splitting them among frontend, backend/logic, and QA sub-agents.
Prerequisites: The user can describe the goal and key trade-offs; Antigravity 2.0 has the corresponding permissions for code, files, and sub-agent tools; execution is recommended on a reversible branch or in a sandbox.
Unsuitable tasks: Treating the prompt as automatic approval for production releases, automatic permission acquisition, or a replacement for human product decisions; without a clear goal, the template cannot reliably infer business rules.
Model note: The original post discusses Gemini/Antigravity, but the post body does not disclose an API model ID, thinking level, or runtime parameters; this article treats it as a community workflow example from the Gemini 3.8 Flash era and does not generalize community experiences into a model benchmark.
The following is the Chinese usage form of the prompt published by the commenter; the core English prompt appears in the next section, with the original text retained for copying.
You are my AI Technical Product Manager and Prompt Architect. I am a non-technical Project Manager.
I will give you a plain-language idea, design concept, feature request, or issue. Please turn it into a structured prompt that can be copied directly into Antigravity 2.0, and fill in:
- Functional and visual specifications
- User flows, validation, error states, and fallback UI
- Data privacy and security guardrails
- Automated tests, acceptance criteria, and measurable success metrics
The output must use these four sections: [PROJECT MANAGER DIRECTIVE], [CHIEF ENGINEER WORKFLOW INSTRUCTIONS], [RECOMMENDED SUB-AGENT ROLES], and [OUTPUT FORMAT REQUIRED FROM ANTIGRAVITY]. Ask 1–2 non-technical clarification questions after the prompt only when key decisions are missing.
My requirements:
[Describe the goal, users, scenario, constraints, and priorities in plain language]This Chinese paragraph is an explanatory usage template, not the Reddit original; to faithfully reproduce the original, use the English block in the next section.
The original post author said they had created an instruction file based on their experience using Claude and Gemini, and provided a Google Drive download link:
https://drive.google.com/file/d/1Jp8ffGQb2if_0BV0vX1JiGRd4rtwB--S/view?usp=drivesdk
The post body did not paste the file in full, so its contents cannot be filled in as a verified prompt. The complete prompt below comes from Technical-Owl66’s reply in the same original post to a request to “paste the complete prompt.”
You are my AI Technical Product Manager and Prompt Architect. I am a non-technical Project Manager. My engineering team is "Antigravity 2.0"—a main agent acting as Chief Engineer leading a team of specialized sub-agents.
YOUR MISSION:
Whenever I give you a plain-English idea, design concept, feature request, or issue, transform it into a clear, structured prompt that I can copy and paste directly to Antigravity 2.0.
OPERATING RULES:
Translate non-technical descriptions into clear functional specs, user flows, data privacy/security guardrails, and acceptance criteria. Never ask me to write code or supply technical syntax.
Automatically infer implicit requirements, user interface steps, edge cases, error handling protocols, and logical constraints so the development team has full clarity.
Always output the generated prompt in a copy-pasteable Markdown block using this exact 4-part structure:
[PROJECT MANAGER DIRECTIVE]
Feature/Design Title: <Name>
Goal: <What we are building and why>
Core Functional Requirements: <Detailed bullet points of behavior/visuals, including strict data privacy and security standards>
User Flow: <Step-by-step user experience, including error states, validation messages, and fallback UI>
Definition of Done (DoD): <Clear conditions for completion, including automated tests, verification checks, and success metrics/KPIs>
[CHIEF ENGINEER WORKFLOW INSTRUCTIONS]
Review the directive and break it down into technical architecture and sub-tasks.
Delegate specialized sub-tasks across your sub-agent team.
Synthesize, review, and test all sub-agent deliverables into a unified solution.
Present a high-level summary to the PM along with the final implementation artifacts.
[RECOMMENDED SUB-AGENT ROLES]
<e.g., Frontend/UI Engineer>: <Specific task assignment>
<e.g., Logic/Backend Specialist>: <Specific task assignment>
<e.g., QA Inspector>: <Validation criteria>
[OUTPUT FORMAT REQUIRED FROM ANTIGRAVITY]
Executive Summary for PM
Sub-Agent Task Breakdown
Complete Working Solution / Code Artifacts
Verification Steps, Success Metrics, & Identified Risks
Below the prompt block, provide a 1-2 sentence plain-English summary of what was generated, along with 1 or 2 simple non-technical clarification questions ONLY if key decisions were missing.The original post's comments add that, when asked where it should go, the original post author answered: put it in gemini.md. Therefore, the minimal usage flow is:
1. Save the prompt above as the project-convention `gemini.md` (or place it according to Antigravity's actual loading rules).
2. In a new session, describe a feature, design concept, or issue in non-technical natural language.
3. First ask the model to generate the four-part PM directive, then copy the generated code-task prompt into Antigravity 2.0.
4. Have Antigravity, acting as Chief Engineer, split the work into frontend, logic/backend, and QA sub-tasks, then consolidate and test the results.
5. Check the DoD, test results, risks, and clarification questions before deciding whether to accept the implementation.This is a two-stage workflow of “prompt generator → coding agent”; the specification generated in the first stage should not be treated as an implementation that has already been completed.
User input: A natural-language idea, design concept, feature request, or issue; the user does not need to provide code or technical syntax.
Prompt-stage output: A Markdown directive containing the title, goal, functional/visual requirements, user flow, privacy and security guardrails, and DoD.
Antigravity-stage input: The directive above, along with the project code and available sub-agent tools.
The original post author said that after using their instruction file, Gemini “behaves and works like Claude,” and considered the results better; this is the author's subjective experience, with no task list, control group, logs, or quantitative metrics.
Commenter Technical-Owl66 published the complete four-part prompt and said they use a Gemini notebook and a dedicated prompt-engineering process; this is the commenter's approach, not a measured result demonstrated by the original post author.
The original post did not show a specific input requirement, a complete generated directive, final code, test logs, or success KPIs, so this article can only reproduce the template and workflow; it cannot claim that Gemini 3.8 Flash successfully delivered any particular feature.
Create gemini.md in a test project and write the complete English prompt into it; confirm that Antigravity actually loads the file.
Enter a feature or design requirement with clearly defined boundaries, and check whether the generated result strictly contains the four sections and whether Goal, User Flow, and DoD are specific.
Check the implicit requirements filled in by the model: error handling, validation, fallback UI, and privacy and security constraints must not conflict with the original business goal.
Hand the directive to Antigravity and observe whether it first breaks down the architecture and sub-tasks, then delegates, consolidates, tests, and reports risks.
Execute automated tests and manual acceptance item by item according to the DoD; when something fails, require the model to report unfinished items rather than accepting a summary that only says “completed.”
Set human approval points for irreversible actions involving production data, permission escalation, releases, deletion, or payments; the prompt itself does not constitute authorization.
Not an official prompt: The complete block comes from a commenter's reply; the original post author's Drive file was not published in full in the original post. The two must not be conflated with an official Google or Antigravity configuration.
Limited model attribution: The original post body only mentions Gemini; it does not disclose Gemini 3.8 Flash's model ID, reasoning tier, context length, temperature, token usage, or API request body.
“Like Claude” is not capability transfer: A prompt can specify roles, processes, and output formats, but cannot transfer Claude's model capabilities, tool permissions, or safety policies to Gemini.
Inferences may be wrong: The template requires the model to fill in implicit requirements automatically, which may introduce incorrect assumptions in complex products; when key decisions are missing, pause and clarify rather than letting the model decide permissions, billing, data retention, or compliance rules on its own.
The cost of long prompts: Someone in the comments pointed out that too many rules may distract the model and increase token costs; others suggested keeping only a small number of key rules. Compare the complete and streamlined templates in real projects instead of assuming a “10x” effect.
Tool and permission boundaries: Sub-agent division depends on Antigravity 2.0's actual capabilities; it must run on a reversible branch or in a sandbox, while production writes, credential access, and destructive commands remain subject to human review.
Data security: Do not put API keys, tokens, email addresses, phone numbers, user data, or internal secrets in gemini.md; redact project context and generated logs before sharing them.
Does not replace engineering acceptance: Structured prompts, sub-agent consolidation, and generated summaries cannot replace code review, automated testing, rollback, or human approval.
The most reusable part of the post is not the claim that it can “make Gemini better tenfold,” but the translation of non-technical requirements into an acceptance-ready PM directive, followed by handoff to a Chief Engineer responsible for architecture, delegation, integration, and testing. Unlike the already collected agy_help (a fact-checking agent that prioritizes local materials) and the code-map workflow (which limits the scope of code reading), its focus here is requirements specification and multi-agent delivery orchestration.
Reddit / r/googleantigravity · Source date: Not disclosed · Edited: 2026-09-20
Read the original sourceGemini 3.8 Flash
Run this guide in the environment listed above. Downloading does not transfer the template or establish model availability for your account.