Many people, when using Large Language Models for development, tend to open a dialog box and start rambling: "Help me write a time management software with a menu on the left, a calendar on the right, pop-up forms from the calendar, and preferably Google login support..."
Wrong! Completely wrong. This kind of colloquial, "candy-feeding" style of interaction is the root cause of code loss and business logic contradictions.
In development using Antigravity and systems equipped with the using-superpowers mechanism, the human's role is that of a top-level decision-maker for product architecture. Your task is to provide a One-Pager with strategic baselines and constraints, and the remaining derivation (from boundary conditions to a full PRD) is the work of the AI Architect.
1. What is a One-Pager Intent?
A One-Pager doesn't aim for exhaustive page layout details; it only answers four core questions:
- What pain points are we solving? (Why)
- What is its moat/core differentiator? (Core Value)
- Where are the technical boundaries? (Tech Constraints)
- What must the MVP (Minimum Viable Product) absolutely NOT include? (Not-To-Do)
2. [Case Study] One-Pager for a Time Management System
For our project in this Masterclass, here is the original "Intent" template you need to feed the system:
# Project Intent: T-Block Sync Calendar
## 1. Core Objectives (Why & What)
I want to develop a Web App called T-Block for time-block-based schedule management. It's not a simple Todo List; it emphasizes the concept of "boxing tasks into time blocks and dragging them into a calendar schedule." It must support bidirectional synchronization with Google Calendar.
## 2. Technical Moat & Boundaries (Tech Constraints)
- **Tech Stack Requirements**: Mandatory use of Astro (SSR) or Next.js. Heavy, outdated frameworks are strictly prohibited.
- **Storage Requirements**: Use Prisma + relational database (PostgreSQL preferred). External synchronization must involve transactions and soft-delete mechanisms.
- **E2E Test Coverage**: The project cannot tolerate "manual changes leading to sync chaos." Google interfaces must implement a Mock testing layer from the early stages of development.
## 3. Design Tone
- **Reject Mediocrity**. Use a minimalist style with dark mode support. Avoid writing extensive CSS; mandatory use of Tailwind CSS and Radix UI (or equivalent high-level component libraries). Interface inspired by Linear's clean and efficient style.
## 4. MVP Phase 1 [Absolutely Not Doing] (Not-To-Do)
- No multi-account or multi-team support (Version 1 is purely for a single user).
- No Native mobile app version.
- No integration with other third parties like WeChat or Apple; Phase 1 focuses solely on Google OAuth SSO.
3. Planting the Seed
Now that you have this Markdown page ready, are you going to ask the AI to "help me write the code" right away?
Absolutely restrain yourself!
If you start writing code immediately, you'll soon fall into the hell of "file not found" and "overwriting the previous version's logic" because the LLM lacks persistent file history memory. It's like throwing a top-tier blueprint into a trash can at a roadside construction site.
Before feeding this blueprint into the system, we must first build the work-flow pipelines and the long-term memory (Files) for the system.
Next Episode Preview:
In Ep 02, we won't write a single line of application code. Instead, we'll create the .agents directory and configure GEMINI.md, turning a cold code repository into an "Intelligent Office Park" with a code of conduct and error-correction capabilities.