publisher-skills

Name: publisher-skills
Author: publisher-skill

52stars0forks

How to install publisher-skills?

publisher-skill/publisher/publisher-skills

$npx -y skills add publisher-skill/publisher --skill publisher-skills

Installs into the current project.

Summary

Publish HTML frontend projects to the PushWebly publishing platform, list published projects, obtain shareable project URLs, change a published app's public/private visibility, and package published HTML projects into Android APKs. Use when Codex needs to publish a local zip proj

Files · 1

View on GitHub

SKILL.md

1	# Publisher Skill
2
3	Publish HTML frontend projects to the publishing platform and optionally package
4	them as Android APKs.
5
6	Platform URL:
7
8	```text
9	https://pushwebly.com
10	```
11
12	Use "project" in user-facing messages. The canonical API paths are
13	`/api/projects` and canonical tool names are `project_`. Deprecated `game_`
14	aliases and `gameId` response fields may still appear; treat `gameId` as the
15	project id.
16
17	## Codex Execution Rules
18
19	- Prefer mounted `project_*` MCP tools if they exist in the current environment.
20	- If remote MCP tools are not mounted, use the HTTP APIs with `curl`.
21	- Do not require Python. Optional scripts, if present, are for CLI/CI users only.
22	- Ask only for genuinely missing information: credentials, zip path, project
23	name, public/private visibility, or private access password preference.
24	- Never write credentials into a project zip or repository file. Store them only
25	in the user's local `~/.publisher/config.json` after consent.
26	- On Windows/PowerShell, use a temp JSON file for request bodies instead of
27	shell-escaping inline JSON.
28
29	## Intent Mapping
30
31	\| User intent \| Action \| Missing information to ask for \|
32	\|---\|---\|---\|
33	\| Publish, ship, upload, put online \| Publish project \| zip path, project name \|
34	\| Make an installable phone app, APK, Android package \| Publish and build APK \| zip path, project name \|
35	\| Build APK for an already published project \| Build APK \| project id; use project list if needed \|
36	\| Make an app private/public, add/remove access password \| Change visibility \| app URL, target visibility (optional password when private) \|
37	\| Show my projects, list published projects \| List projects \| none if token is available \|
38	\| Log in, register, account setup \| Login/register \| username and password \|
39
40	If the intent is ambiguous, ask one short question: "Just publish it, or publish
41	it and build an Android APK too?"
42
43	## Publishing Conversation Process
44
45	When users express intentions such as publishing, deploying, launching, sharing applications, generating access links, etc., they must enter this process.
46
47	<HARD-GATE>
48	The publishing process is a blocking finite-state machine. As long as the current step lacks user input, the model must stop advancing, only pose one question for the current step, and wait for the user's response.
49	Guessing answers based on context is prohibited.
50	Automatic selection of public/private is prohibited.
51	Automatic generation of access passwords is prohibited, unless the user explicitly chooses to have the system generate them.
52	It is prohibited to call the release interface before completing all necessary steps.
53	Each response can contain at most one user-facing question.
54	</HARD-GATE>
55
56	### General Principles of Finite-State Machine
57
58	- On entering the flow, first run `S-1` (version check, non-blocking), then proceed in the order of `S0 -> S1 -> S2 -> S3 -> S4`.
59	- Skipping steps is not allowed (except `S-1`).
60	- Multiple fields cannot be queried in a single request.
61	Information that the user has clearly provided can be recorded, and there is no need to ask repeatedly.
62	When the user's response is ambiguous, only follow up once for the current field.
63	- Only after the current step is completed can we proceed to the next step.
64	- If waiting for user input is required, do not append explanations, suggestions, or previews of the next step at the end of the response.
65
66	---
67
68	### S-1: Version Check (first node of the publish flow, non-blocking)
69
70	When entering the publish flow, run a version self-check before `S0`. This step is NOT part of the `<HARD-GATE>` blocking rules: whatever the result — even if the endpoint is unreachable — always continue. Never interrupt publishing because of a version issue.
71
72	Steps:
73
74	1. Read the local skill version: the `version` field in this file's frontmatter.
75	2. Query the latest platform version (no login required):
76
77	```bash
78	curl -s https://ai-pub.pushwebly.com/api/skill/latest-version
79	```
80
81	The response `data` contains: `version` (latest), `downloadUrl` (cross-platform doc package, unzip-and-use), `downloadUrlWindows` (Windows installer .exe), and `downloadUrlMac` (macOS installer .zip).
82
83	3. Compare local `version` with the returned `version`.
84
85	Comparison rule: a version is `major.minor.patch`. Compare segment by segment as integers, left to right — major first, then minor, then patch; pad missi

People who liked this also viewed

6 picks

Type

publisher-skills

52stars0forks

View on GitHub

How to install publisher-skills?

publisher-skill/publisher/publisher-skills

$npx -y skills add publisher-skill/publisher --skill publisher-skills

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Publisher Skill
2
3	Publish HTML frontend projects to the publishing platform and optionally package
4	them as Android APKs.
5
6	Platform URL:
7
8	```text
9	https://pushwebly.com
10	```
11
12	Use "project" in user-facing messages. The canonical API paths are
13	`/api/projects` and canonical tool names are `project_`. Deprecated `game_`
14	aliases and `gameId` response fields may still appear; treat `gameId` as the
15	project id.
16
17	## Codex Execution Rules
18
19	- Prefer mounted `project_*` MCP tools if they exist in the current environment.
20	- If remote MCP tools are not mounted, use the HTTP APIs with `curl`.
21	- Do not require Python. Optional scripts, if present, are for CLI/CI users only.
22	- Ask only for genuinely missing information: credentials, zip path, project
23	name, public/private visibility, or private access password preference.
24	- Never write credentials into a project zip or repository file. Store them only
25	in the user's local `~/.publisher/config.json` after consent.
26	- On Windows/PowerShell, use a temp JSON file for request bodies instead of
27	shell-escaping inline JSON.
28
29	## Intent Mapping
30
31	\| User intent \| Action \| Missing information to ask for \|
32	\|---\|---\|---\|
33	\| Publish, ship, upload, put online \| Publish project \| zip path, project name \|
34	\| Make an installable phone app, APK, Android package \| Publish and build APK \| zip path, project name \|
35	\| Build APK for an already published project \| Build APK \| project id; use project list if needed \|
36	\| Make an app private/public, add/remove access password \| Change visibility \| app URL, target visibility (optional password when private) \|
37	\| Show my projects, list published projects \| List projects \| none if token is available \|
38	\| Log in, register, account setup \| Login/register \| username and password \|
39
40	If the intent is ambiguous, ask one short question: "Just publish it, or publish
41	it and build an Android APK too?"
42
43	## Publishing Conversation Process
44
45	When users express intentions such as publishing, deploying, launching, sharing applications, generating access links, etc., they must enter this process.
46
47	<HARD-GATE>
48	The publishing process is a blocking finite-state machine. As long as the current step lacks user input, the model must stop advancing, only pose one question for the current step, and wait for the user's response.
49	Guessing answers based on context is prohibited.
50	Automatic selection of public/private is prohibited.
51	Automatic generation of access passwords is prohibited, unless the user explicitly chooses to have the system generate them.
52	It is prohibited to call the release interface before completing all necessary steps.
53	Each response can contain at most one user-facing question.
54	</HARD-GATE>
55
56	### General Principles of Finite-State Machine
57
58	- On entering the flow, first run `S-1` (version check, non-blocking), then proceed in the order of `S0 -> S1 -> S2 -> S3 -> S4`.
59	- Skipping steps is not allowed (except `S-1`).
60	- Multiple fields cannot be queried in a single request.
61	Information that the user has clearly provided can be recorded, and there is no need to ask repeatedly.
62	When the user's response is ambiguous, only follow up once for the current field.
63	- Only after the current step is completed can we proceed to the next step.
64	- If waiting for user input is required, do not append explanations, suggestions, or previews of the next step at the end of the response.
65
66	---
67
68	### S-1: Version Check (first node of the publish flow, non-blocking)
69
70	When entering the publish flow, run a version self-check before `S0`. This step is NOT part of the `<HARD-GATE>` blocking rules: whatever the result — even if the endpoint is unreachable — always continue. Never interrupt publishing because of a version issue.
71
72	Steps:
73
74	1. Read the local skill version: the `version` field in this file's frontmatter.
75	2. Query the latest platform version (no login required):
76
77	```bash
78	curl -s https://ai-pub.pushwebly.com/api/skill/latest-version
79	```
80
81	The response `data` contains: `version` (latest), `downloadUrl` (cross-platform doc package, unzip-and-use), `downloadUrlWindows` (Windows installer .exe), and `downloadUrlMac` (macOS installer .zip).
82
83	3. Compare local `version` with the returned `version`.
84
85	Comparison rule: a version is `major.minor.patch`. Compare segment by segment as integers, left to right — major first, then minor, then patch; pad missi

People who liked this also viewed

6 picks

Type