Skip to content

Project Creation

Purpose

Define how a new PotatoLabs product project is created on the PotatoLabs Developer Platform.

Canonical bootstrap

The canonical bootstrap command is pdp-new-product <product>.

From the docs repository, the wrapper ./pdp-new-product <product> runs the same implementation.

Bootstrap performs the following steps:

  1. Create or integrate the GitLab repository.
  2. Clone the repository into /srv/potatolabs/projects/<product>.
  3. Create the initial main commit and push it.
  4. Generate AGENTS.md, PDP.md, README.md, .gitignore, and .gitlab-ci.yml.
  5. Create the standard src/, tests/, docs/, scripts/, and deployment/ scaffold.
  6. Emit machine-readable bootstrap context with bootstrap_status=success on success.

Generated repository contract

A new product repository should be immediately usable as a workspace and review target.

The bootstrap scaffold provides:

  • Source code directory: src/
  • Test directory: tests/
  • Documentation directory: docs/
  • Script directory: scripts/
  • Deployment directory: deployment/
  • Product AI instructions: AGENTS.md
  • Product operational contract: PDP.md
  • Product entry page: README.md
  • CI/CD contract: .gitlab-ci.yml

AI onboarding

After bootstrap, the developer should:

  • Open the workspace in code-server
  • Read AGENTS.md
  • Read PDP.md
  • Read the applicable PMP documents
  • Inspect the repository before making changes
  • Work only within the approved scope

CI contract

The generated .gitlab-ci.yml supports the lifecycle in a controlled way without inventing product-specific commands.

  • validate checks the scaffold and contract files
  • test, build, package, release, and deploy are manual placeholder jobs until the product defines real commands in PDP.md
  • Deployment remains explicit and product-specific

Naming conventions

  • Use clear, product-oriented repository names
  • Use the same product name across GitLab, the workspace, and documentation where practical
  • Keep branch names descriptive and short enough to review comfortably

SSH authentication

SSH access should be confirmed before the first clone or push so that repository operations are repeatable.

Repository initialization

Repository initialization should establish the product skeleton, documentation entry pages, build and test commands, and branch workflow expectations early.