Phase 1 / Ep 01: Inception (One-Pager from a Human Perspective)

⏱ Est. reading time: 4 min Updated on 4/13/2026

When many people use Large Language Models (LLMs) for development, they often open the chatbox and start rambling: "Help me write a time management app, there should be a menu on the left, a calendar on the right, clicking inside the calendar should pop up a form, and it'd be great if it supported Google login..."

Wrong! Dead wrong. This kind of colloquial, stream-of-consciousness prompting is the root of all evil, leading to out-of-control code and inconsistent business logic.

In Antigravity and system development featuring the using-superpowers mechanism, the human's role is the top-level decision-maker for product architecture. Your job is to provide a one-pager with a strategic baseline and constraints; the remaining derivation (from boundary conditions to a complete PRD) is the job of the AI Chief Architect.

1. What is a One-Pager Intent?

A One-Pager does not pursue comprehensive and exhaustive page layout details; it only answers four core questions:

  1. What pain points are we solving? (Why)
  2. What is its moat/core differentiator? (Core Value)
  3. Where are the technical boundaries? (Tech Constraints)
  4. What must the MVP (Minimum Viable Product) absolutely NOT include? (Not-To-Do)

2. [Practical Example] One-Pager for a Time Management System

For the target project of this practical course, this is the most primitive "initial spark" template you need to feed into the system:

# Core Intent (Project Intent): T-Block Sync Calendar

## 1. Core Objective (Why & What)
I want to develop a time-blocking schedule management Web App called T-Block. It is not a simple Todo List, but emphasizes the concept of "packing to-dos into time blocks and dragging them into the calendar for scheduling." It must achieve two-way synchronization with Google Calendar.

## 2. Technical Moat Boundaries (Tech Constraints)
- **Tech Stack Requirements**: Mandatory use of Astro (SSR) or Next.js. Strictly forbid the introduction of heavy, legacy frameworks.
- **Storage Requirements**: Use Prisma + Relational Database (PostgreSQL preferred). Any external synchronization must introduce transactions and soft deletion mechanisms.
- **End-to-End Test Coverage**: The project cannot afford "manual changes causing sync chaos"; Google interfaces must implement a Mock testing layer in the early stages of development.

## 3. Design Language Tone (Design Tone)
- **Reject Mediocrity**. Use a minimalist style, and dark mode must be considered. Avoid writing massive amounts of CSS; mandatory use of Tailwind CSS and Radix UI (or equivalent high-level component libraries). The interface should reference the crisp and sleek style of Linear.

## 4. Pseudo-Requirements the MVP V1 will [Absolutely NOT Do] (Not-To-Do)
- No multi-account or multi-team groups (V1 is strictly a standalone personal version).
- No native mobile App version.
- Absolutely no integration with WeChat/Apple or other third parties; V1 will strictly stick to Google OAuth Single Sign-On.

3. Planting the Seed in the Soil

Now that this Markdown page is ready, should we just ask the AI to "help me write the code" right away?

Resist the urge!

If you start writing code directly, you will immediately fall into an endless hell of "file not found" and "overwriting previous logic" because LLMs lack historical file memory. It's like casually tossing a top-tier blueprint into the trash can of a roadside construction crew.

Before feeding this blueprint into the system, we must first build the workflow pipelines (Pipelines) and long-term memory brain (Files) for the system.

Coming Up Next: In Ep 02, we won't write a single line of code. Instead, we will first create .agents and configure GEMINI.md, transforming a cold code repository into a "smart office park" equipped with behavioral guidelines and error-correction capabilities.