It is not a prompt generator.

It is built to teach people how to think in prompt structure:

intent
context
boundary
output control
repair
iteration
chain vs mesh prompting
drift control
when to ask
when to execute
when to stop

The goal is simple:

help people stop treating prompting like magic words and start treating it like a structure for better thinking.

LPC teaches general prompting first. PTPF techniques are only shown if requested.

I would love feedback on the curriculum.

What do you think is missing from a prompting coach that teaches people how to actually work with AI instead of just copy/pasting prompt templates?

https://chatgpt.com/g/g-6a11b2f6a1348191839c5e6a49560482-lpc-lyra-the-prompting-coach

AGY Builders,

We are all trying to build useful and scalable workflows for our AGY CLI and ecosystem, but the speed at which we need to learn, build, and deploy new things is incredibly overwhelming. If you are feeling that pressure, you are in the right place here at r/GoogleAntigravityCLI.

Over the past few weeks, I have been testing an "AGY WIKI OKF" setup that I put together myself (after inviting some members of this community to collaborate; mod is not proud). I know some folks might hesitate to trust a tutorial from a random Redditor, but I wanted to share this with the community anyway because it actually works.

I was able to build this because I am all-in on Google and the Antigravity Ecosystem. I’m a truly AGY—I am not some ultra-smart, 10x developer, but I know how to work hard, I dig for the right information, and I iterate.

AGY WIKI OKF | The Idea

To build a frictionless, token-efficient knowledge WIKI engine that transforms static documentation or notes (information) into an active, intelligent collaborator—orchestrated entirely by Antigravity CLI.

The core philosophy is simple: treat knowledge management as a clean pipeline and tokens as a premium, finite resource.

By anchoring this architecture to Google’s Antigravity CLI, the AGY WIKI OKF bypasses heavy middleware and complex UI layers, delivering a hyper-focused AI partner built entirely for execution speed, context hygiene, and minimal footprint.

Why adopting AGY WIKI OKF matters:

• Stay organized (AGY OCD): Structured Markdown and YAML keep the chaos in check.
• Save tokens: Doing more with less context window bloat.
• Scale shareable knowledge: Making it easy to pass context and logic between different LLMs.
• Humans and Agents working together: One standardized, readable format that works perfectly for both of us.
• BYOD (Bring Your Own Data): Own your context. Port it to the newest model, platform, or OS instantly.

The Tools

• Antigravity CLI
• Obsidian : The IDE for the Knowledge bank
• Obsidian Web Clipper:
  • Official Site
  • Chrome Web Store
  • Firefox Add-on

The WIKI

In the agent-first era, a WIKI is no longer just a static graveyard for human notes; it is the operational hard drive for your agents. By maintaining a highly structured WIKI, you ensure that every piece of context is stored in a clean, machine-readable format. This means that whether you are testing a new modular skill or spinning up a specialized agent, your AGY CLI knows exactly where to find the precise context it needs to generate autonomous action, moving you far beyond simple, reactive conversational text.

Reference: Gist on Knowledge Representation

Google Open Knowledge Format (OKF)

Google’s Open Knowledge Format (OKF) feels like the exact missing piece we've needed for orchestrating multiple AI agents effectively. It provides a vendor-neutral, interoperable standard for storing and sharing organizational knowledge.

Why this is huge for orchestration:

1. The "Lingua Franca" for Agents: Any agent can read it out of the box without platform-specific integrations.
2. Seamless Context Passing: Specialized agents can access, update, and pass the exact same foundational context back and forth.
3. Human-in-the-Loop Oversight: Because OKF is just Markdown and YAML, it’s inherently readable and auditable.
4. Scalable Knowledge: It acts as a shared, living library that grows alongside your agents.

AGY WIKI OKF Integration

Structuring an AGY Wiki using OKF revolutionizes how complex knowledge is shared. By standardizing documentation with concise Markdown and YAML frontmatter, OKF provides a unified taxonomy for cataloging AGY CLI slash commands or skills It is highly token-efficient, stripping away bloated formatting and maximizing context window limits.

The Prompt for Building an AGY WIKI OKF

AGY CLI WIKI OKF PROMT EXAMPLE

/grillme I want to initialize a brand-new, empty Obsidian vault from scratch that adheres strictly to the Open Knowledge Format (OKF) standard, with the specific intent of potentially open-sourcing or sharing this architecture later. I want a purely blank, skeletal framework with no pre-populated data. Please grill me to define the optimal architectural blueprint for this vault. I need you to interrogate me on: Do not generate the directory structure or files until you are satisfied that you have captured all my requirements for a production-ready, shareable knowledge base. 
Core Directory Hierarchy: How should we structure the root (e.g., /concepts, /resources, /indices, /log) to be intuitive for external users? Template Strategy: What base boilerplate templates do we need to ensure every new file is automatically OKF-compliant and structured for consistent metadata? Workflow Logic: Since this is a fresh start, what processes should we bake in for capturing information vs. refining knowledge that could be easily documented for others? CLI Integration: What specific file locations or configurations do we need to ensure this vault plays nicely with the Antigravity CLI from day one? Open-Source & Contributor Documentation: What files should we create to make this a "deployable" standard? Please include requirements for: A README.md with installation and usage instructions. A CONTRIBUTING.md that defines how to add new concepts or schemas. A "System Architecture" document that explains the logic behind the folder structure and metadata fields, ensuring anyone who clones this vault understands how to extend it.

The Final File Structure

AGY WIKI OKF
    ├── .agyrc
    ├── ARCHITECTURE.md
    ├── CONTRIBUTING.md
    ├── README.md
    ├── .agy
    │   └── .keep
    ├── .obsidian
    │   ├── app.json
    │   ├── appearance.json
    │   ├── core-plugins.json
    │   └── workspace.json
    ├── 00-Inbox
    │   └── .keep
    ├── 10-Projects
    │   └── .keep
    ├── 20-Areas
    │   └── .keep
    ├── 30-Resources
    │   ├── .keep
    │   └── Google Antigravity Documentation.md
    ├── 40-Archive
    │   └── .keep
    ├── 99-Meta
    │   └── Templates
    │       ├── Base_Template.md
    │       ├── Project_Template.md
    │       └── Resource_Template.md
    └── Clippings

TL;DR

• AGY WIKI OKF: Organizes your information (context) , AGY CLI commands, skills  behaviors, and A2A workflows into a token-efficient, shareable format that reduces inference costs for any LLM.
• Open Knowledge Format (OKF): Provides a standardized, vendor-neutral way to share context (Markdown + YAML), preventing platform lock-in and eliminating data fragmentation.

AGY Builders, I genuinely want your input on this. Please comment, grill me, roast me, ask questions, or give me your raw feedback on this AGY WIKI OKF setup. We are building the foundation to organize and share our data in the BYOD era. Let's build the future together.

Hi all, I built InfraNode, an open-source (Apache-2.0) MCP server that gives AI assistants live open data for 84 German cities: weather, air quality, public transit departures, parking, bike counts, solar potential and more, all from official open-data sources.

Why it might interest this community:
- Keyless and hosted. Point your client at the remote server (mcp.infranode.dev, streamable-http) and the tools just work. No signup, no API key.
- Around 48 read-only tools, plus a get_city_overview discovery tool so an agent can see in one call which data a given city offers and which tool to use next.
- The same data is also a plain REST API, so it works outside MCP too.

Repo: https://github.com/street1983nk/infranode
Docs: https://infranode.dev

Full disclosure: I am the author. I would love feedback on the tool design and especially the discovery flow.

Agent memory is either the full chat log, a vector index, or an LLM summary you dump back into the prompt. If two facts disagree or a problem that's been solved already. It's not my favorite to fix something only to later have to remind Claude that the argument value or authorization has been updated, so 3 months later, this is what I got to share. It honestly has changed the way I work with AI.

The MCP server is stdio, 42 tools, and auto-shuts down. Agents call recall_compile for whatever it's working on and get a small context packet of tiered addressed cells back instead of the whole store, ranked by evidence and capped to a word budget. The memory evolves and adjusts itself in real time. Writes go through recall_write, which runs an admission firewall. Schema gets checked, provenance gets stamped, and anything can be rolled back. Facts are addressable cells with real programmable hyperedges, not a flat pile of md files with no handles to grip what matters.

Every cell carries an effective confidence that recalculates straight from the graph. who backed it, who challenged it, whether that writer has been wrong before. No LLM in the loop, and it runs offline. Drop in one cell that contradicts another, and the score moves on its own.

Capable models reach for it on their own. Once an agent knows the tools are there, it compiles context at the start of a task and writes back at the end without me telling it to. That held across model class, model vendor, and model family, small instruction following ones included. It doesn't need nagging to remember or to check what's already known. That's the part that actually changed how I work day to day.

Local first. It uses node's built-in sqlite so there's no database server, no account, no network. You paste the MCP config once, then type /recall in a project, and it spins up that project's DB and just works from there. One DB per project, no schema to manage, nothing to repeat. Want a team on one graph? Park that single file on a host they can reach and everyone writes through the same firewall, still no server. Set up tripwires and get automated team alerts when changes setback deployment ready state Runs on Linux, macOS, and Windows. github.com/H-XX-D/recall-memory-substrate