Skip to content

New app

The agent scaffolds the app in five phases (check → init-runtime → add-data → add-tests → sync-infra), proves it runs locally, and creates the GitHub repository only after the developer says yes.

  1. A person opens a Linear issue with the users, the outcome, the production GCP project, and who can sign in (and an optional migration or design plan in the folder).
  2. The developer runs the create-app skill. The skill reads the Linear issue and any local plan, confirms archetype, name, auth, data store, and prod_project, and asks only what is still missing. The 17-point table is the receipt after phase 5, not the interview. If .sdlc/state.yaml already exists, it resumes the next phase.
  3. If part of the request is outside the platform catalog, the skill records it under unmet in service.yaml with a recommendation and scaffolds everything else.
  4. After the developer agrees, create-app runs the 5 phases using odlc (scripts/odlc.py):
  5. Phase 1 (check): Writes and validates service.yaml.
  6. Phase 2 (init-runtime): Scaffolds the runtime skeleton and customizes the initial routes, job entrypoints, or UI layout.
  7. Phase 3 (add-data): Installs the database/storage/queue/secret packages and customizes the state or schema helpers.
  8. Phase 4 (add-tests): Sets up the test runner, writes unit tests for the scaffolded entrypoints and invariants, and verifies ruff and pytest / npm test pass.
  9. Phase 5 (sync-infra): Deterministically generates infra/, .github/workflows/, AGENTS.md, CLAUDE.md, .cursor/rules/*.mdc, .devcontainer/, and README.md.
  10. The developer runs make setup && make dev && make test && make ci. make ci builds the same image the deploy workflow builds, and runs terraform validate with -backend=false when Terraform is installed. That validate does not read state and does not apply. The GitHub repository waits until make ci exits 0. A failed image build is fixed in service.yaml (path, docker_context, dockerfile) and sync-infra runs again. The last phase records generator_sha in .sdlc/state.yaml. Later generator runs reuse that commit until someone asks to upgrade.
  11. The developer says yes. The agent creates a private opptra/<name> repository, pushes main, staging, and production, and creates the GitHub environments staging and production.
  12. Connect GitHub Actions to GCP. The checklist is Bind a repository. Neither script deploys the app, and neither protects branches. main and production are covered by the organization ruleset. staging stays open so a push can deploy.
  13. The agent has already created the GitHub environments staging and production. A repository admin adds a required reviewer on production when the plan allows it. Then set the Actions variables the scripts print.
  14. The developer runs scripts/bind-staging.sh when they can change IAM in opptra-staging and can read the pool in opptra-sdlc-ci. They run the two gh variable set commands that script prints. They do not need production access.
  15. The developer sends scripts/bind-production.sh to someone who can change IAM in prod_project. That person runs it and runs the two production gh variable set commands it prints. They do not need access to opptra-staging. If they cannot set GitHub variables, they send those two commands back to a repository admin.