---
name: makelore-project-scaffold
description: Initialize a MakeLore interactive AI application from its .makelore/project.json metadata, or assess it against MakeLore publication and approval-submission requirements. Use when the user asks to initialize or scaffold an interactive_ai_app project, an existing legacy mini_game or mini_program project, asks what publishing requires or forbids, asks why a project cannot be published, or requests a release-readiness check. Do not use for creating the MakeLore project record itself, custom-project scaffolding, or general architecture discussion.
---

# MakeLore Project Scaffold

Use this skill only after MakeLore has created the project space. The project type in `.makelore/project.json` is authoritative; never infer or override it from the user's wording.

## Route the request

- If the user asks to initialize or scaffold the project, run the scaffold workflow.
- If the user asks what publishing or approval requires, what a project cannot contain, why publishing failed, or whether the project is ready to submit, read `references/submission-requirements.md` in full and follow the release-readiness workflow below.
- If the user asks for both, scaffold first, then assess submission readiness.

## Scaffold workflow

1. Confirm the current working directory is the intended project root and that `.makelore/project.json` exists.
2. Require a non-empty `MAKELORE_NODE_EXECUTABLE`. This value is supplied by the MakeLore host. If it is missing, do not invoke the script; report `HOST_RUNTIME_UNSUPPORTED` and tell the user that the current MakeLore version does not support this plugin. Do not fall back to `node` on `PATH`, Python, another runtime, or a package-manager command.
3. Resolve the absolute directory containing this `SKILL.md`.
4. Run exactly one scaffold command from the project root:

   ```bash
   "$MAKELORE_NODE_EXECUTABLE" "<absolute-skill-directory>/scripts/scaffold.mjs" --project-root "$PWD"
   ```

5. Parse the command's single version-1 JSON result. Success is written only to stdout and includes `status: created`; failure is written only to stderr and includes top-level `code`, `message`, and optional project-relative `paths`. On success, report only the returned `createdFiles`. On failure, report the returned code, message, and paths when present.

The script performs a complete conflict preflight before writing. Never add `--force`, delete or rename existing user files, retry by overwriting conflicts, or manually fill gaps after a script failure. Resolve the reported conflict with the user before running again.

## Release-readiness workflow

Keep this workflow read-only unless the user also asks to fix a reported issue or explicitly starts the product's existing one-click submission flow.

1. Read `references/submission-requirements.md` in full. Its four categories are semantically different: required input, direct blocker, source-package exclusion, and authoritative runtime/platform check.
2. For a general requirements question, explain those categories and do not claim to have inspected a project.
3. For a project-specific check, gather project-relative evidence for:
   - the validity and publishable type of `.makelore/project.json`;
   - the required root files and the relevant `package.json` and `package-lock.json` fields;
   - source file count, byte limits, path shapes, links or special files, and paths the source packager excludes;
   - project-authored source or assets that appear to exist only under an excluded path;
   - statically visible build-output risks such as configuration that emits a root `release.json`.
4. Classify every finding instead of flattening it into a blacklist:
   - **阻断项**: current evidence proves the one-click flow will reject or cannot accept the project;
   - **打包排除影响**: a path will not enter the source archive; its mere presence is not a blocker, but required content there is a release risk;
   - **待权威流程验证**: npm installation, Vite execution, built output, both browser viewports, account/ownership, upload, cloud build, and review state;
   - **已通过静态项**: a requirement supported by concrete file evidence.
5. Report the evidence path and observed value for every blocker. Do not infer an external-network blocker merely because source text contains an HTTP(S) URL; only an actual cross-origin request during authoritative preflight proves that failure. You may report the literal as a runtime risk.
6. Use exactly one of these conclusions:
   - `不能进入一键提交` when at least one confirmed blocker exists;
   - `可进入一键提交，仍需运行期验证` when static blockers are absent but the product flow has not run;
   - `本地构建与预检已通过，仍待平台结果` only when the current one-click flow actually returned that evidence.

Never say that a project is approved based on this Skill's inspection. Do not run `npm ci`, Vite configuration, project scripts, upload, or submission merely to answer a readiness question: those steps execute code or change external state and belong to the explicit product flow. Do not delete excluded files just to make the report look clean.

## Error handling

Treat these codes as stable outcomes:

- `USAGE_INVALID`: the script invocation is malformed.
- `PROJECT_CONFIG_MISSING`: `.makelore/project.json` is absent.
- `PROJECT_CONFIG_INVALID`: project metadata is unreadable or unsupported.
- `PROJECT_TYPE_UNSUPPORTED`: the project is neither `interactive_ai_app` nor an existing legacy `mini_game` / `mini_program` project.
- `TARGET_CONFLICT`: at least one target path already exists or cannot be used; show every returned conflict.
- `TEMPLATE_UNAVAILABLE`: the installed plugin is incomplete.
- `WRITE_FAILED`: file creation failed and the script attempted to roll back only files and directories it created in this run.

## Ownership boundaries

- MakeLore owns project creation and `.makelore/project.json`.
- This skill owns only the fixed starter files listed by the scaffold script and never edits project metadata.
- New projects use `interactive_ai_app`. Existing `mini_game` and `mini_program` metadata are read-only compatibility aliases and receive the same unified scaffold; the script reports the canonical type without rewriting metadata.
- MakeLore's existing release builder and publisher remain authoritative for build, preflight, packaging, upload, and approval submission.
- The requirements reference is this plugin version's release contract snapshot. If it differs from runtime validation, report the mismatch, follow the runtime result, and do not silently reinterpret an exclusion as a prohibition.