designcraft-cli

Complete native CLI

Candidate implementation, actual host, native installation, and creation acceptance are not yet complete. Only macOS arm64, Python 3.11+.

Routing scope

Use only when the user explicitly requests querying native commands, viewing parameters, or inspecting/executing a command plan. Requests aimed at complete typesetting results go to designcraft-use（Install: npx skills add full-aigc-skills/designcraft-skills --skill designcraft-use); standalone installation diagnostics go to designcraft-cli-setup（Install: npx skills add full-aigc-skills/designcraft-skills --skill designcraft-cli-setup). Querying the command catalog and describing parameters does not modify the project;run may install a fixed runtime and edit files, so the user-authorized inputs, outputs, and scope must be verified first. On failure or UNKNOWN, retain the receipt, inspect the project, and then decide on subsequent actions; the success criterion is that the corresponding plan completes and the artifacts pass independent inspection, not that the exit code serves as business acceptance.

When to Use

Use when the user explicitly requests viewing DesignCraft native commands, querying parameters, inspecting a plan, or executing a single plan. Complete publishing goals without an explicit command question go to designcraft-use。

Non-applicable scope and safety boundaries

• Do not use research source code, caches, or offline catalogs to execute native write operations; writes must use the real command catalog of the fixed version.
• run can install runtimes and modify local files; installation authorization, inputs, outputs, and plan scope must be verified separately.
• Scripts run with the current user's permissions;--input unregistered paths are not covered by summary protection.
• Do not claim business completion based on plan structure validation, process exit codes, or the existence of a receipt.

Workflow

Step 1: Classify the request

Distinguish read-only queries from commands that may install or write; hand off complete document goals to use and pure installation questions to setup.

Step 2: Determine the runtime and catalog

Verify the fixed CLI version and the current command catalog read-only; when the catalog is missing or the version does not match, block write operations that depend on that capability.

Step 3: Inspect the plan

Validate commands and parameters against the real schema and register inputs that must be preserved. Offline catalogs are only for queries or static inspection.

Step 4: Controlled execution

After verifying the output paths and the user's scope authorization, run the plan once and save the raw stdout/stderr, receipt, and identity summary.

Step 5: Verify side effects

Inspect files and the project reopen state according to the artifact contract; on unknown or partial failure, do not replay the command, and list the missing evidence.

Rules (execution constraints)

• Pass CLI / Python parameters via argv; do not concatenate or execute shell commands.
• Keep a single native session for each multi-step plan, but the overall exit code cannot prove that every step succeeded.
• Verify input and skill resource identities both before and after execution; summaries cannot replace sandboxing or process isolation.

Gotchas (common misconceptions)

1. A missing real catalog does not mean the command does not exist: can report missing evidence read-only but must not guess and then write.
2. A zero exit may include business warnings: inspect the raw issues and artifact content.
3. UNKNOWN cannot be retried automatically: first verify the process, receipt, and existing side effects.
4. A single session cannot prove step-level completion: when there are no per-step receipts, retain batch-level status.
5. Successful installation is not model or business acceptance: Report the status of each item by layer.

First use

Set SKILL_DIR to the absolute directory where the host actually loaded this SKILL.md. The skill can be installed independently into the project .agents/skills, a user skills directory, or a plugin cache; do not guess sibling directories, and do not modify skill files. When the user request has authorized the necessary dependencies, the public cli.py automatically validates and installs the pinned native version into the user data directory; it does not use sudo and does not modify PATH.

: "${SKILL_DIR:?设置为本技能真实加载目录}"
python3 -I -B "$SKILL_DIR/scripts/cli.py" -- commands

To only check the installation:

python3 -I -B "$SKILL_DIR/scripts/bootstrap.py"
python3 -I -B "$SKILL_DIR/scripts/cli.py" -- --version

--runtime-home or CRAFT_RUNTIME_HOME to specify an isolated runtime directory, placed before -- . --archive points to an existing pinned ZIP; the archive and binary digests are still validated. If installation fails, return dependencySetup and do not automatically retry editing or rendering; if validation fails, keep the existing directory. The current lock only pins the native CLI; the release snapshot and host auto-discovery still require separate verification.

Current scenario

First record the user's assets, goals, output location, dimensions/page count/format, and modification boundaries. Query the real parameters from the native directory and execute after confirming the command; do not invent commands or treat new interfaces in the local source as supported by the pinned artifact. The asset paths and output locations in the examples below must be replaced with the paths actually authorized for the current task.

python3 -I -B "$SKILL_DIR/scripts/cli.py" -- commands

Deliver the native .designcraft project, the collected asset and font license inventory, page-by-page previews, and applicable PDF/IDML/EPUB. Reopen the native project to verify page count, text, and linked assets; record interchange-format losses separately.

Pass CLI parameters via argv; do not execute a shell. Native commands may write files and access the network; use them only within the scope authorized by the task. If execution fails, first verify the project and output; do not replay writes for unknown results. For output to the same path, protect existing files first. A command query or a zero exit code does not mean delivery passed: inspect the actual files, save and reopen, and check the content and the modified results, and separately record the creative review. Runtime and skill installation, host skill discovery, and model natural-language selection are gates to be accepted separately.

Scenario examples

For this skill's directory query success path and the rejection/recovery boundaries when a command is unsupported, see Scenario examples、read-only query、planned executionandunknown result. The examples only illustrate the process; they do not prove that the pinned native CLI has been accepted.

Required reading before execution

Before executing a command plan, recovering from a checkpoint, or verifying delivery, you must read this skill's execution and acceptance details, and operate according to its requirements for input preservation, UNKNOWN, receipts, and format verification. Digests can only detect changes; they cannot isolate or roll back writes; unknown results must not be automatically replayed.