# Enter Project Ops

> Create, iterate, and independently verify Enter-generated websites and apps with an agent. Use when Codex needs to spin up a new Enter project from a concept, drive the Enter editor chat with bounded change prompts, survive platform quirks (deploy lag, stale task streams, login gates), or prove the result with evidence gathered outside Enter — without publishing unless explicitly authorized.

- Skill: `convergeai-labs/enter-project-ops` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add convergeai-labs/enter-project-ops`
- Raw SKILL.md: https://api.skillmd.com/api/skills/convergeai-labs/enter-project-ops/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: convergeai-labs (https://skillmd.com/u/convergeai-labs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/convergeai-labs/enter-project-ops

---


# Enter Project Ops

Build and operate Enter projects with a strict division of labor: **Enter is the executor, you are the planner and the independent verifier.** Enter's completion message is an implementation claim, never test evidence. Everything worth shipping is proven from outside Enter.

## Read On Demand

- Read [acceptance-matrix.md](references/acceptance-matrix.md) before any visual/responsive/runtime regression pass.
- Read [change-prompt.md](references/change-prompt.md) before submitting anything through the Enter chat — creation prompts and bounded change prompts both.
- Read [platform-playbook.md](references/platform-playbook.md) before your first editor session of the day, and any time the platform behaves strangely — it catalogs the quirks that are normal.
- Apply `browser-ops` for login, session ownership, screenshots, and side-effect authorization.

## The Mental Model

| Role | Owner |
|---|---|
| What to build, in what order, with what invariants | You (the agent) |
| Writing code, running migrations, deploying | Enter |
| Whether the claim is true | You, from independent evidence |

Enter is strong at execution and honest in its receipts (it reports bugs it found and fixed itself). It is still a single lane: its "done" message, its in-editor lint/build, and its own screenshots are all the same system grading its own homework. Your job is the second lane.

## Guardrails

- Bind every action to the exact Enter project ID, chat ID, editor URL, and preview URL. Record them before the first prompt.
- Approval to optimize authorizes bounded edits and their verification. It does **not** authorize `发布` (publish), sharing as template, cover/asset generation, deletion, billing, another project, or another environment. Publishing is a separate, explicit authorization, every time.
- Never expose cookies, tokens, storage state, or account data. Save login state only to a secrets directory with `600` permissions, outside any repo.
- Separate product defects from platform noise. A stale task stream, a hot-update flicker, or a deploy-propagation delay is not a product bug — verify against a fresh preview load.
- Preserve user tabs and shared browser services. Close only task-owned isolated tabs or contexts.

## Workflow

### 0. Write The Contract First

Before touching the editor, write a local contract file (markdown) and keep it updated as the run log:

- **Target**: project ID, chat ID, editor URL, preview URL (fill in after creation).
- **Concept**: what the thing is, who it's for, the one-sentence demo story.
- **Capability showcase**: which platform abilities this project demonstrates (streaming, persistence, RLS, external data, etc.).
- **Guardrails**: what is never allowed without separate authorization (publish, share, assets, keys client-side…).
- **Run log**: one row per round — action, independent verification, result, evidence paths.

This file is what survives context compaction and session resets. Enter has its own memory; yours is this file.

### 1. Create (Greenfield)

1. Submit one rich creation prompt (see [change-prompt.md](references/change-prompt.md)). A good creation prompt fixes: concept, data sources, refresh/cost model, storage + access semantics, page structure, and the constraints (keys server-side, graceful degradation, no publish, viewports).
2. Answer Enter's clarifying questions only within the authorized scope. Model-choice cards, cloud-instance creation, and AI-capability enablement are normal gates — pick deliberately, they're part of the build.
3. If Enter returns a plan instead of building: inspect scope and files, then click `立即构建` only when the plan stays inside the authorized target.
4. Expect a long build (tens of operations). Monitor per [platform-playbook.md](references/platform-playbook.md) — task streams go stale, reload the editor URL to resync.

### 2. Capture A Baseline

Two lanes, always:

**Visual lane** — render at `1440x900`, `390x844`, `327x603`; first fold and full page; exercise the defining interaction; check hierarchy, overflow, touch targets, motion.

**Independent health lane** — isolated Playwright (no extensions): DOM assertions, console, network, broken images, exact overflow metrics. Plus the lanes Enter can't fake:

- **Data lane**: if the project uses Enter Cloud with public-read tables, query the REST endpoint directly with the public anon key and compare against what the UI claims. The database is the strongest source of truth.
- **Stream lane**: for streaming features, witness a live generation once — don't only verify the completed state.
- **Clipboard lane**: read the OS clipboard (e.g. `pbpaste`) after copy interactions; in-page `readText()` hangs on permission prompts.

Use [acceptance-matrix.md](references/acceptance-matrix.md) as the checklist.

### 3. Iterate In Bounded Batches

Never send a mega-prompt. Decompose a big mandate ("do everything") into cohesive batches, each:

- one theme (e.g. "radar-ize the leaderboard", "multi-source", "weekly digest");
- with fresh baseline evidence, explicit invariants that must not regress, explicit exclusions, and a required receipt format;
- independently verified before the next batch starts.

Enter's own discipline compounds: each batch's receipt becomes the next batch's baseline. Two to six batches per project is the healthy range we've battle-tested.

### 4. Verify Each Batch

1. Reopen the live preview fresh after Enter's receipt (deploy propagation lags — see playbook).
2. Re-run the failing case first, then the full matrix.
3. Confirm the revision actually changed (fresh content, new fields in the data lane).
4. Check backward compatibility explicitly: old data/rows/states must still render.
5. Update the contract run log with evidence paths.

### 5. Publish — Only On Explicit Authorization

Publishing is a distinct act with its own verification: prod URL, fresh load, viewports, console. Never infer it from "make it good" or from a previous project's publish approval.

## Closeout

Report: exact project and final preview URL, what changed per batch, fresh evidence, files created/updated, what was intentionally not done (publish, share, assets), and residual risk. Reset temporary viewport overrides. Update the contract file's run log — it's the next session's memory.