Discuz Plugin Spec Planner
Turn an authorized business requirement into a bounded Discuz X5 plugin specification. Do not claim that a specification is already an installed or tested plugin.
Inputs
- - Plugin name, lowercase identifier, and concise purpose.
- Frontend modules, admin page requirement, settings, and data tables.
- Target versions, permission rules, payment/API needs, and acceptance criteria.
Workflow
- 1. Reject identifiers that are not lowercase letters, digits, and underscores or that do not start with a letter.
- Separate public pages, admin pages, API endpoints, scheduled jobs, hooks, and external services. Only include capabilities requested by the buyer.
- Define tables without a site prefix. Discuz applies the configured prefix through
DB::table(). - Record sensitive actions and require human confirmation for publication, deletion, payment, permission changes, or production deployment.
- Save the normalized request as JSON and run:
CODEBLOCK0
- 6. Pass
plugin-spec.json to discuz-x5-plugin-builder.
Outputs
- - A deterministic
plugin-spec.json containing modules, settings, tables, compatibility choices, risks, and required files. - A list of unresolved decisions that must be confirmed before production use.
Recovery And Boundaries
- - Stop on malformed JSON, invalid identifiers, duplicate module names, or duplicate tables.
- Never place passwords, cookies, private keys, production database dumps, or user personal data in the specification.
- X5.1 commercial-only interfaces must be confirmed against the target installation. Default to the X5.0-compatible local plugin mechanism when evidence is missing.
- Acceptance means the JSON is valid and complete enough for the next skill; it does not prove installation success.
