How to Deploy Projects Through Agentic PCL

This guide shows you how to deploy a project through Agentic PCL using the deploy-credible-assertions skill. The agent creates or resolves a Phylax platform project, creates an assertion release, and activates it on-chain with pcl.

Prerequisites

Before you begin, make sure you have:

Completed the Agentic PCL setup
A reviewed assertion project that passes pcl test
A configured assertions/credible.toml
An authenticated pcl session for the target platform
The target chain ID and an RPC endpoint
Access to the protocol manager wallet through a Foundry keystore

Confirm that your installed CLI supports the agentic deployment command:

pcl deploy --help

Deployment creates remote platform state and can broadcast an on-chain transaction. Start with staging unless you explicitly intend to deploy to production, and do not approve a broadcast until you have reviewed the dry-run result.

1. Authenticate manually

Complete authentication yourself before giving the agent the deployment task. The platform URL selects the target network:

pcl auth login

pcl auth -u https://ethereum.phylax.systems login

The default https://app.phylax.systems platform targets Linea. After login, pcl remembers the selected platform and uses it as the default for subsequent platform commands. Confirm the session before starting the agent:

pcl auth status

2. Request a deployment plan

Start with a prompt that provides the required choices and sets a clear approval boundary:

Use the deploy-credible-assertions skill to prepare this assertion project
for deployment.

Target platform: <https://app.phylax.systems or https://ethereum.phylax.systems>
Target chain ID: <chain-id>
RPC: <rpc-url or where the RPC can be found>
Environment: staging
Signer: Foundry keystore <account-name>

Inspect the repository and credible.toml, then check the installed pcl command
surface. Confirm the existing authentication and explain every remote or
on-chain mutation that would be required.

Do not create a project, create a release, access signing credentials, or
broadcast a transaction until I explicitly approve the deployment.
Never print, store, or commit secrets.

Use production only when that is your deliberate deployment target.

3. Review `credible.toml`

For a new platform project, assertions/credible.toml needs a project name and no project_id:

environment = "staging"
project_name = "my-protocol-assertions"

[contracts.my_contract]
address = "0x1234...5678"
name = "My Contract"

[[contracts.my_contract.assertions]]
file = "src/MyAssertion.a.sol"

On the first approved deployment, pcl deploy creates the platform project and writes its project_id back to credible.toml. Review and commit that change after deployment.

4. Require a dry run

Ask the agent to build and verify the project without changing remote or on-chain state:

Do a dry run of the project deployment and verify the correctness of
credible.toml.

Review the result for:

The protected contract addresses
The assertions and constructor arguments
Any warnings or failed verification

The dry run returns after building and verifying the release payload. It does not authenticate, resolve a platform project, validate a chain, or inspect the protocol manager. Confirm those values separately from your authenticated session, credible.toml, and deployment prompt before continuing.

5. Approve the deployment

After you approve the dry-run result, use a separate prompt:

Deploy the project according to the credible.toml specification and broadcast
the deployment transactions to the specified RPC endpoints.

The deployment workflow:

Creates or resolves the platform project
Verifies or sets the protocol manager
Builds and verifies the assertions
Creates or resumes the release
Waits for deployment-blocking checks
Broadcasts the activation transaction
Confirms the deployment with the platform

pcl deploy observes existing state before each step. If an interruption occurs, ask the agent to inspect the structured error and rerun the same command; the workflow resumes rather than intentionally creating a duplicate release.

6. Verify the result

Require the agent to report:

Project ID
Release ID
Environment
Transaction hash, if a transaction was broadcast
Deployment outcome
Any remaining timelock or activation step

Keep these identifiers with your deployment record. You can inspect the project and release through the platform or the corresponding pcl projects and pcl releases commands.

pcl Deploy Reference

Review commands, configuration, and machine output

Platform Deployment

Review the browser-assisted platform workflow

Start Here

Tutorials

How-to Guides

Explanation

Platform

Reference

Prerequisites

1. Authenticate manually

2. Request a deployment plan

3. Review `credible.toml`

4. Require a dry run

5. Approve the deployment

6. Verify the result

pcl Deploy Reference

Platform Deployment

​Prerequisites

​1. Authenticate manually

​2. Request a deployment plan

​3. Review credible.toml

​4. Require a dry run

​5. Approve the deployment

​6. Verify the result

pcl Deploy Reference

Platform Deployment

Prerequisites

1. Authenticate manually

2. Request a deployment plan

3. Review `credible.toml`

4. Require a dry run

5. Approve the deployment

6. Verify the result