一键导入
sync-cli-skill
Synchronize the base44-cli skill with the latest CLI source code from the Base44 CLI repository
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Synchronize the base44-cli skill with the latest CLI source code from the Base44 CLI repository
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
The base44 CLI is used for EVERYTHING related to base44 projects: resource configuration (entities, backend functions, ai agents), initialization and actions (resource creation, deployment). This skill is the place for learning about how to configure resources. When you plan or implement a feature, you must learn this skill
The base44 SDK is the library to communicate with base44 services. In projects, you use it to communicate with remote resources (entities, backend functions, ai agents) and to write backend functions. This skill is the place for learning about available modules and types. When you plan or implement a feature, you must learn this skill
Troubleshoot production issues using backend function logs. Use when investigating app errors, debugging function calls, or diagnosing production problems in Base44 apps.
Develop a Base44 app remotely from your own coding agent (Claude Code, claude.ai, or any MCP client) by connecting it to the Base44 sandbox. Cloud agents connect over MCP; local agents can connect over MCP or drive the same sandbox with the `base44 sandbox` CLI subcommands (the CLI uses shorter names — e.g. read_file is `sandbox read`, list_directory is `sandbox ls`, run_command is `sandbox run`). Covers connecting/ authenticating, the available sandbox tools (run_command, read_file, write_file, edit_file, grep, list_directory, create_checkpoint, get_app_preview_url, get_app_status, list_user_apps, and the connector tools list_connectors / initiate_connector_connection), the edit→preview→verify loop, how changes persist, builder/external-agent concurrency, the in-editor "Send to Coding Agent" button + onboarding README URLs, and tips like reading the Vite dev-server logs. Triggers on "develop my Base44 app remotely", "connect Claude Code to Base44", "bring my own agent", "edit a Base44 app over MCP", "Base44
Develop a Base44 app remotely inside Base44's cloud sandbox using your own agent — no local checkout and no deploy/push commands. The implementation is remote: writing a resource file into the sandbox is what ships it (backend functions, entities, and agents all auto-sync from the file you write), and OAuth connectors are set up against the remote app via MCP tools or the projectless `base44 connectors` CLI. This skill is the place for learning what you can author in the sandbox, how backend functions, entities, and agents are structured, and how to connect a connector without a local filesystem. Triggers on 'develop my Base44 app remotely', 'no local files', 'cloud sandbox', 'create an entity/agent remotely', 'connect a connector remotely', 'bring my own agent', or any work editing a Base44 app inside a sandbox.
Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Claude's capabilities with specialized knowledge, workflows, or tool integrations.
| name | sync-cli-skill |
| description | Synchronize the base44-cli skill with the latest CLI source code from the Base44 CLI repository |
| disable-model-invocation | true |
| metadata | {"internal":true} |
Synchronize the skills/base44-cli/ skill with the latest CLI source code from the Base44 CLI repository using git-based change detection.
When activated, this skill will ask for:
This skill uses git to efficiently detect changes:
CLI_VERSION (e.g., v0.0.17)Ask the user for the CLI source folder path using the AskQuestion tool if available, otherwise ask conversationally:
Required:
~/projects/base44-cli or /Users/me/base44-cli)If the user provided this in the initial prompt, use that value.
.git/ directory exists)package.json with CLI-related contentsrc/cli/commands/, src/commands/, commands/, lib/commands/.command( or program.command patternsStore these discovered paths for use in subsequent steps:
<commands-path>: Path to commands directory (e.g., src/cli/commands)<cli-root>: Path to CLI source root (e.g., src/cli)If validation fails or structure is unclear, ask the user to clarify.
Read the stored version from CLI_VERSION in the skills repository root (e.g., v0.0.17)
Get changed command files using git in the CLI source folder:
# From the CLI source folder, list command files changed since the stored version
git diff --name-only <stored-version> HEAD -- <commands-path>
If the stored version tag doesn't exist, fall back to:
# List all command files if tag is missing
git ls-files <commands-path>
Get infrastructure changes (CLI source root excluding commands):
# From the CLI source folder, list infra files changed since the stored version
git diff --name-only <stored-version> HEAD -- <cli-root> | grep -v "<commands-path>"
Present findings to the user before proceeding:
Found X changed command files since vX.X.X:
- <commands-path>/deploy.ts
- <commands-path>/entities/push.ts
- <commands-path>/auth/login.ts
Found Y infrastructure changes (may affect all commands):
- <cli-root>/utils/api-client.ts
- <cli-root>/config/defaults.ts
If no changes detected (neither commands nor infra): Report "No changes since version X" and exit
Before processing individual commands, review any infrastructure changes that may affect all commands:
Review each changed non-command file and categorize by impact type:
| Impact Type | What to look for | Documentation Action |
|---|---|---|
| API/Client changes | Base URLs, endpoints, headers, request/response handling | May affect multiple commands' behavior |
| Config/Defaults | Default values, environment variables, config file paths | Update SKILL.md config section |
| Authentication | Token handling, login flow, session management | Update auth-related references |
| Global options | CLI-wide flags like --verbose, --json, --help | Update SKILL.md global options |
| Output formatting | How results are displayed, logging behavior | Note in affected command references |
| Types/Interfaces | Shared type definitions | Usually internal, but may indicate API changes |
| Error handling | Exit codes, error messages, validation | Update troubleshooting section |
| Dependencies | package.json changes | Check for behavior-affecting updates |
Note: The actual file structure varies by CLI. Discover the structure by examining the git diff output rather than assuming specific paths.
Changed file: (some config/defaults file)
Before:
export const DEFAULT_TIMEOUT = 30000;
After:
export const DEFAULT_TIMEOUT = 60000;
Impact: All commands now have 60s timeout instead of 30s
Action: Update SKILL.md "Configuration" or "Troubleshooting" section
For each changed command file, perform the following steps:
Commands are split across skills by concern. Before reading or updating a reference, determine which skill owns the command.
Known command routing:
| Command | Target Skill | Reason |
|---|---|---|
logs | skills/base44-troubleshooter/ | Troubleshooting / debugging concern |
| Everything else | skills/base44-cli/ | Project management concern |
For new/unknown commands, reason about ownership based on the command's purpose:
| Concern | Target Skill | Examples |
|---|---|---|
| Observability, debugging, diagnostics, monitoring | skills/base44-troubleshooter/ | logs, monitor, status, health |
| Project setup, resource management, deployment, auth | skills/base44-cli/ | create, deploy, entities push, login |
If a new command's purpose is ambiguous, read its source code and ask: "Would a developer use this to build/manage the app, or to investigate/debug it?" Route accordingly. When genuinely unclear, ask the user.
Use the target skill's references/ folder for reading and writing reference files, and update that skill's SKILL.md command table accordingly.
Read the corresponding reference file from the target skill's references/ folder:
skills/base44-cli/ <- project management commands
├── SKILL.md
└── references/
├── auth-login.md <- for <commands-path>/auth/login.ts
├── auth-logout.md
├── auth-whoami.md
├── create.md <- for <commands-path>/create.ts
├── deploy.md
├── entities-create.md <- for <commands-path>/entities/create.ts
├── entities-push.md
├── functions-create.md
├── functions-deploy.md
├── rls-examples.md
└── site-deploy.md
skills/base44-troubleshooter/ <- troubleshooting commands
├── SKILL.md
└── references/
└── project-logs.md <- for <commands-path>/logs.ts (or similar)
Mapping rule: <commands-path>/{parent}/{name}.ts → references/{parent}-{name}.md
If no reference file exists for a new command, note it for creation in the appropriate skill.
Compare the CLI source code with the existing skill documentation:
Parse the command file to extract:
Identify differences:
Command-Level:
Option/Argument-Level (CRITICAL):
3. New options added
4. Removed options
5. Changed option descriptions
6. Changed option defaults
7. Changed option types (e.g., string to boolean)
8. Changed required status
9. Changed option aliases (e.g., -f to -F)
10. Option converted to positional argument (e.g., create -n my-app → create my-app)
11. Positional argument converted to option (e.g., create my-app → create -n my-app)
Detecting Option ↔ Positional Changes:
Look for these patterns in Commander.js:
.option('-n, --name <value>', 'description') or .requiredOption(...).argument('<name>', 'description') or in command definition .command('create <name>')When an option disappears but a positional argument with similar semantics appears (or vice versa), flag this as a breaking change that affects how users invoke the command.
Command: deploy (<commands-path>/deploy.ts)
Source options:
--force (-f): Force deployment [boolean, default: false]
--env <name>: Target environment [string, required]
Documented options (references/deploy.md):
--force (-f): Force deploy without confirmation [boolean, default: false]
--env <name>: Environment name [string, optional]
Changes detected:
- --force: description changed
- --env: required status changed (required vs optional)
Command: create (<commands-path>/create.ts)
Source (current):
Positional: <name> - The app name [required]
Options: --template (-t): Template to use [string, optional]
Documented (references/create.md):
Options:
-n, --name <name>: The app name [string, required]
--template (-t): Template to use [string, optional]
Changes detected:
- BREAKING: --name (-n) option converted to positional argument <name>
Old syntax: npx base44 create -n my-app
New syntax: npx base44 create my-app
Update or create references/{command-name}.md with the following format:
# base44 {command}
{Description from source}
## Syntax
```bash
npx base44 {command} [options]
| Option | Description | Required |
|---|---|---|
-o, --option <value> | {description} | {yes/no} |
{example usage from source}
{Any important behavioral notes}
### Step 6: Update Main Skill Files (if needed)
After processing all changed commands, update the SKILL.md of each affected skill:
**For `skills/base44-cli/SKILL.md`** (project management commands):
1. Update the **Available Commands** tables if commands were added/removed
2. Update **Quick Start** if workflow changed
3. Update **Common Workflows** sections if relevant
**For `skills/base44-troubleshooter/SKILL.md`** (troubleshooting commands):
1. Update the **Available Commands** table if troubleshooting commands were added/removed
2. Update the **Troubleshooting Flow** if command behavior changed
**General rules:**
- Keep the existing structure and formatting of each skill
- Do NOT change the frontmatter description unless explicitly asked
### Step 6b: Flag base44-sandbox for review
The `skills/base44-sandbox/` skill (the cloud-sandbox flavor) is **hand-authored** and self-contained — it carries its own concise guidelines and links out to `base44-cli`'s references rather than copying them, so this sync does not edit it automatically. If this sync changed the backend-function authoring conventions in `skills/base44-cli/references/functions-create.md` (directory layout, `function.jsonc` shape, Deno entry-point conventions, naming rules), **flag `skills/base44-sandbox/SKILL.md` for manual review** in the summary so its inline guidance can be updated to match.
### Step 7: Update CLI_VERSION and Skill Frontmatter
After successfully updating all changed commands:
1. Get the current version/commit from the CLI source:
```bash
# Get latest tag, or HEAD commit if no tags
git describe --tags --always
Update CLI_VERSION in the skills repository root with the new version (e.g., v0.0.47)
Update metadata.sourcePackage in skills/base44-cli/SKILL.md frontmatter. Set name to base44 (the npm package being synced) and version to the new version without the v prefix (e.g., 0.0.47). Example:
metadata:
sourcePackage:
name: base44
version: 0.0.47
This allows the Base44 CLI to detect when installed skills are out of date.
After all updates, present a summary to the user:
## Sync Summary
### Version Updated
- Previous: v0.0.17
- Current: v0.0.20
### Changed Command Files Processed
- <commands-path>/deploy.ts
- <commands-path>/entities/push.ts
### Infrastructure Changes Reviewed
- (list infra files from git diff output)
- Example: config.ts (timeout increased to 60s)
- Example: api-client.ts (no user-facing changes)
### Files Updated
- references/deploy.md (updated options)
- references/entities-push.md (updated description)
- SKILL.md (updated command table, added timeout note)
- CLI_VERSION (v0.0.17 → v0.0.20)
- skills/base44-cli/SKILL.md frontmatter metadata.sourcePackage.version (0.0.17 → 0.0.20)
### Breaking Changes (highlight prominently)
- `create`: `-n, --name` option converted to positional argument
- Old: `npx base44 create -n my-app`
- New: `npx base44 create my-app`
### Option Changes
- `deploy --env`: now required (was optional)
- `entities push --dry-run`: default changed from true to false
### New Commands
- (none)
### Removed Commands
- (none)
### Manual Review Recommended
- [List any changes that need verification]
entities-create.md and rls-examples.md contain hand-written security documentation - update carefully| Issue | Solution |
|---|---|
| Tag not found in CLI repo | Use git tag -l to list available tags, or fall back to comparing with a commit hash |
| Infra changes not detected | Check if shared code is in non-standard directories; adjust the git diff paths |
| Unsure if infra change affects users | Look for exports used by command files; if internal-only, note but skip documentation |
| Can't find command files | Try searching for .command( or program.command patterns |
| Options not detected | Look for .option( patterns in commander.js files |
| Positional args not detected | Look for .argument( or <argName> in .command('cmd <argName>') patterns |
| Option → positional change missed | Compare old options list with new arguments list; if an option disappeared and a similar argument appeared, it's likely a conversion |
| Missing descriptions | Check for description: properties or .description( calls |
| Subcommand structure | Commands like entities push may be in entities/push.ts |
| Changed args not detected | Compare each option property: name, alias, description, default, required, type |
| No changes detected but expected | Verify the stored version in CLI_VERSION matches a valid git tag/commit |