A production-minded Gemini Antigravity agent harness for new and established repositories.
Turn agent-driven development into an inspectable path from project context to verified, explicitly authorized delivery.
Use this template · Adopt into an existing repo · Explore the visual playbook · Review the security model
Important
Geminicon improves the development process; it does not make an unfinished application production-ready by itself. Every project must still supply and verify its own architecture, security, data, operations, and release evidence.
| Create a new project | Adopt into an established repository |
|---|---|
| Begin with a clean harness, define the product before the stack, then initialize only what the project needs. | Inspect compatibility first, preserve project-owned work, and apply only reviewed harness files. |
| Create from the GitHub template → | Read the adoption guide → |
Geminicon is intentionally not an application starter or a framework opinion. It gives Gemini Antigravity durable operating rules, progressive workflows, canonical checks, and clear authority boundaries—then leaves product and technology choices to the evidence in the project.
| Durable context | Deliberate execution | Verifiable delivery |
|---|---|---|
AGENTS.md holds the small set of rules that should always be present. Detailed facts and workflows load only when relevant. |
Clear work stays lightweight. Ambiguity, architecture, experience, marketing, and production risk receive the process they need. | Local commands, trusted hooks, Git hooks, and CI share the same lint, test, and security paths. |
| Less repeated discovery | Less process without less rigor | Less room for stale confidence |
The harness also keeps external context in its proper place: integrations begin disabled, tools remain narrowly scoped, and content from issues, webpages, documents, or tool output cannot grant authority for writes.
- Know the ground. Adopt safely or define the product outcome before selecting technology.
- Choose the work. Route each request through the smallest workflow proportionate to uncertainty and risk.
- Prove the result. Run the repository's canonical checks and invalidate stale evidence after writes.
- Cross the boundary deliberately. Commits, pushes, deployments, messages, spend, and production changes require explicit authority.
| Coverage | Current baseline |
|---|---|
| Repository state | New repositories and conflict-preserving adoption into established repositories |
| Verification | Equivalent POSIX and native Windows lint, test, and security entry points |
| Continuous integration | Ubuntu, Windows, and macOS across Python 3.10 and 3.13 |
| Updates | Trusted local sources, baseline-aware conflicts, atomic writes, and rollback |
- Select Use this template and create a repository.
- Open Gemini Antigravity at the repository root.
- Review
AGENTS.mdand.gemini/config.tomlbefore trusting the project configuration. - Verify the baseline:
# POSIX
./scripts/lint.sh
./scripts/test.sh
./scripts/security.sh# Native Windows
.\scripts\lint.ps1
.\scripts\test.ps1
.\scripts\security.ps1- Define the project:
/discover
We need to solve [problem] for [specific user].
Success means [observable outcome].
Constraints: [real constraints].
Out of scope: [non-goals].
- Initialize the real stack after approving the charter:
/init Configure this repository from the approved charter. Recommend the
smallest suitable stack, replace every template command with a real one,
configure equivalent CI checks, and explain any irreversible choice before
making it. Do not add hosting or deploy anything unless I ask.
Keep Geminicon and the target repository separate, then begin with a read-only inspection:
python scripts/security_scan.pyInspection does not write. After reviewing conflicts and project-owned requirements, an explicit adoption copies only absent managed or merge files and records baseline hashes; it never replaces existing content.
The repository exposes compact skill metadata first. Complete instructions load only when a task needs them.
| Stage | Use when | Primary workflows | Evidence before continuing |
|---|---|---|---|
| Adopt | An established repository needs the harness | /adopt-geminicon |
Reviewed compatibility plan and conflicts |
| Define | The product or behavior is not settled | /discover, /brainstorm, /spec |
Approved charter or executable specification |
| Build | The outcome is clear enough to implement | /quick, /write-plan, /execute-plan |
Observable behavior and focused verification |
| Assure | Correctness, experience, architecture, or release risk needs scrutiny | /review, /review-creative, /architecture-review, /production-readiness |
Findings resolved and canonical checks passing |
| Deliver | A specific Git effect is authorized | /ship |
Only the requested commit, push, or pull request |
Open the complete workflow map
| Situation | Use |
|---|---|
| Established repository needs Geminicon | /adopt-geminicon |
| Unconfigured project | /discover → /init |
| Clear change affecting a few files | /quick |
| Unclear feature behavior | /brainstorm |
| Precise requirement needing a durable contract | /spec |
| Approved multi-step requirement | /write-plan → /execute-plan when delegation helps |
| Reproducible failure with an unknown cause | /investigate |
| Expensive-to-reverse technical choice | /architecture-review |
| App or website experience | /design-experience |
| Positioning, copy, campaign, or launch asset | /create-marketing |
| Customer-facing anti-slop review | /review-creative |
| Engineering correctness and regression review | /review |
| First launch or major production change | /production-readiness |
| Explicit commit, push, or pull-request request | /ship |
| Shorter communication with full rigor | /concise |
Skills are routing tools, not mandatory ceremony. Gemini Antigravity may select one automatically; name one when you want that exact workflow.
See a realistic project sequence
The visual playbook uses Matchday, a fictional community-football app, to show the workflows in context.
/discover
We want a mobile-first app for community football supporters to follow
fixtures, live scores, standings, and match alerts. Success means a supporter
can find today's match and understand its current state in under 10 seconds.
Constraints: accessible web app, no betting features, no data provider chosen.
/init Configure Matchday from the approved charter. Recommend the smallest
stack for a responsive web app with live-score updates. Create real setup,
development, lint, test, security, and CI commands. Do not initialize hosting
or contact providers.
/quick Add the upcoming-fixtures view using the existing API boundary.
Done when each fixture shows competition, teams, kickoff in the viewer's
timezone, and complete loading, empty, and error states. Add focused tests and
run the repository checks. Local code changes only.
Before the first real launch:
/production-readiness Audit this release across authorization, tenancy, data,
privacy, dependencies, provider failure, abuse controls, observability,
capacity, backups, restore evidence, migrations, rollback, and incident
ownership. Do not deploy or accept risk on my behalf.
Want the whole system at a glance? The interactive visual playbook maps every lifecycle stage, repository skill, safety boundary, example prompt, and capability tier. Its standalone source remains in
docs/repo-template-playbook.htmlfor local and offline use.
Geminicon treats safety as a chain of independent controls, not a single prompt.
| Layer | What it contributes |
|---|---|
| Repository policy | Forbids opening credential-bearing files, dumping environment variables, and inferring external authority |
| Trusted lifecycle hooks | Block common credential stores, track repository writes, and require fresh verification |
| Canonical security scan | Checks tracked and non-ignored safe text without printing suspected secret values |
| Git and CI checks | Offer opt-in local gates and repeat verification with credential scanners |
| Release review | Treats missing authorization, recovery, rollback, or operational ownership as a release gap |
Project hooks run only after the user reviews and trusts them. Repository code cannot grant that trust on the user's behalf. Optional MCP servers and other integrations remain disabled until their instructions, data boundaries, tool scope, and approval mode have been reviewed.
Geminicon reduces recurring context without weakening engineering work:
AGENTS.mdstays short and durable.- Skill metadata is visible before full workflow instructions are loaded.
- Project facts live under
agent_docs/and are read selectively. - Tool output is targeted; delegation is used only when it offsets its own context.
/conciseshortens communication without reducing implementation, review, tests, or security evidence.
The validator enforces budgets for always-loaded repository guidance and the initial skill catalog.
.
├── AGENTS.md # durable rules and workflow routing
├── START_HERE.md # complete project-start guide
├── .agents/skills/ # progressively disclosed workflows
├── .gemini/
│ └── config.toml # conservative trusted-project defaults
├── .githooks/ # opt-in commit and push verification
├── agent_docs/ # project facts, decisions, specs, and operations
├── docs/ # Gemini guide, patterns, and visual playbook
├── scripts/ # canonical cross-platform commands
└── tests/ # template, hook, scanner, and creative checks
- Gemini Antigravity opened at the repository root.
- Python 3.10 or newer for template validation and hooks.
- Git only when branches, commits, worktrees, remotes, or pull requests are wanted.
- Bash for POSIX scripts or PowerShell for equivalent native Windows paths.
No provider account, API key, database, hosting platform, or optional integration is required to begin.
- It does not choose a framework, database, or cloud before the project requires one.
- It does not guarantee generated code is correct, secure, accessible, or production-ready.
- It does not read credentials, create production secrets, or preconfigure third-party integrations.
- It does not download or apply automatic harness updates.
- It does not authorize commits, pushes, deployments, messages, purchases, or production changes.
- It does not replace product judgment, security review, operational ownership, or human risk acceptance.
Template releases are recorded in TEMPLATE_VERSION. Projects remain independent and never receive automatic or network-fetched upgrades.
Questions and reproducible problems belong in GitHub Issues after checking the support guidance. Security vulnerabilities must follow the private reporting process. Contributions are welcome under CONTRIBUTING.md and the Code of Conduct.
Geminicon is maintained by @bnet47 and released under the MIT License.