Candidate implementation; actual host, native installation, and authoring acceptance are not yet complete. Only macOS arm64, Python 3.11+.
Routing scope
Handle layout queries and local operations explicitly requested by the user, including text/image frames, text threading, and asset placement; hand off complete multi-page results to designcraft-use（Install: npx skills add full-aigc-skills/designcraft-skills --skill designcraft-use), hand off project lifecycle to designcraft-cli-document（Install: npx skills add full-aigc-skills/designcraft-skills --skill designcraft-cli-document), and hand off export to designcraft-cli-export（Install: npx skills add full-aigc-skills/designcraft-skills --skill designcraft-cli-export). Layout commands may modify the project; first confirm the objects, working copy, and modification scope; queries may use the offline catalog first, but execution must use the real native catalog. After a failure, keep completed modifications and check affected pages; do not blindly replay. Acceptance checks the target objects, text flow, overflow, linked assets, and affected pages.
When to Use
Use when the user only requests viewing or locally modifying existing layout objects, including text/image frames, text threading, asset placement, and overflow checks. Hand off whole-document goals to designcraft-use, file save/reopen to designcraft-cli-document, and delivery formats to designcraft-cli-export。
Out-of-scope and safety boundaries
- Not responsible for whole-document reflow beyond the explicit page/object scope; first confirm additional authorization or return to the general composition entry point.
- Do not guess object IDs, command parameters, overflow status, or cross-session references; rediscover from the current project and the real command catalog.
- Scripts access the project and registered assets with the current user's permissions. Digest checks provide no sandbox or automatic rollback.
- Creating a working copy and any object writes must satisfy the user's path and scope authorization.
Workflow
Step 1: Define objects and impact scope
Record the project, page, object type, properties to modify, and areas explicitly not to be touched.
Step 2: Read current project state
Rediscover objects and command schema from the current session; queries may use the offline catalog, but write operations must not use the offline catalog.
Step 3: Prepare a working copy
Register and copy the input project, confirm asset links and target save path, and avoid directly modifying the original.
Step 4: Perform the minimal modification
Perform only the object operations authorized for this task; if text flow, object references, or parameters are uncertain, stop and query first without expanding scope.
Step 5: Check affected pages
Recheck target objects, text threading, overflow, cropping, asset links, and other affected pages; report the actual verification status only after saving.
Rules (execution constraints)
- Keep a single native session for the same plan; after reopening, objects must be rediscovered and old object IDs must not be reused.
- A batch-level exit status cannot imply that every object operation succeeded.
- Stop writing on out-of-scope changes, missing assets, or unknown results, and keep a record of modifications that have already occurred.
Gotchas (common pitfalls)
- Query results may be stale: Reread the current project and native catalog before executing the plan.
- Text frame overflow can affect subsequent pages: Check text flow and all affected pages.
- An available image link does not mean the image content is correct: Verify the target asset and preview.
- Object IDs are not guaranteed to be valid across sessions: Re-discover the target object after reopening.
- A successful modification does not prove the layout is deliverable: separately export and review page by page.
First use
Set SKILL_DIR to the absolute directory of the SKILL.md actually loaded by the host.
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 necessary dependencies, the public cli.py automatically validates and installs a pinned native version into the user data directory; do not use sudo, and do not modify PATH.
: "${SKILL_DIR:?设置为本技能真实加载目录}"
python3 -I -B "$SKILL_DIR/scripts/cli.py" -- commands
When you only need to check the installation:
python3 -I -B "$SKILL_DIR/scripts/bootstrap.py"
python3 -I -B "$SKILL_DIR/scripts/cli.py" -- --version
--runtime-home or have CRAFT_RUNTIME_HOME specify an isolated runtime directory, placed before -- .
--archive points to an existing pinned ZIP; the archive and binary digests are still verified.
On installation failure, return dependencySetup and do not automatically retry editing or rendering; on validation failure, 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, confirm the command, then execute; do not invent commands, and do not treat new interfaces in local source code as already supported by the pinned artifact. The asset paths and output locations in the following examples must be replaced with the actual authorized paths for the current task.
python3 -I -B "$SKILL_DIR/scripts/cli.py" -- describe frame.create
Deliver the native .designcraft project, the collected asset and font license list, page-by-page previews, and applicable PDF/IDML/EPUB. Reopen the native project to verify page count, text, and linked assets; record exchange-format losses separately.
CLI parameters are passed via argv, without executing a shell. Native commands may have file-writing and network behavior; use them only within the scope authorized by the task. On execution failure, 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 zero exit does not mean delivery passes: check the actual files, save and reopen, and the content and modified results, and separately record the creative review. Runtime and skill installation, host skill discovery, and model natural-language selection are gates verified separately.
Scenario examples
This skill's local layout success path and its refusal/recovery boundaries when object identity is unclear are in Scenario examples、text threading、image placementandoverflow handling. The examples only illustrate the flow; they do not prove the pinned native CLI has been accepted.
Object discovery, affected-page checks, and the evidence boundaries for inputs/receipts are in this skill's layout review reference. A summary check does not represent a sandbox or rollback.
Required reading before execution
Before executing a command plan, checkpoint recovery, or delivery verification, you must read this skill's execution and acceptance details, and operate according to its requirements for input preservation, UNKNOWN, receipts, and format verification. A summary can only detect changes; it cannot isolate or roll back writes; unknown results must not be automatically replayed.