Add Alipay merchant onboarding skill#653
Add Alipay merchant onboarding skill#653leilei926524-tech wants to merge 1 commit intonexu-io:mainfrom
Conversation
Add a top-level Alipay merchant onboarding skill, wire it into skill discovery coverage and localized skill indexing, and update the English README catalog counts. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Hi @leilei926524-tech! 🎉 Thanks for making open-design better! |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: e5c0a097f3
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| - next merchant-side action | ||
| - next engineering-side action | ||
|
|
||
| If the user already completed merchant onboarding and now needs code integration, explicitly hand off to the `alipay-payment-integration` skill workflow. |
There was a problem hiding this comment.
When users finish merchant onboarding and ask for implementation help, this instruction redirects them to alipay-payment-integration, but no such skill exists in the repository’s skills/*/SKILL.md entries. That creates a dead-end at the exact transition this skill promises (onboarding → integration), so the agent cannot complete the documented handoff path.
Useful? React with 👍 / 👎.
|
|
||
| # Step 1: 读取子技能主文档 | ||
| Read tool call: | ||
| file_path: "ar-sign-skill/SKILL.md" |
There was a problem hiding this comment.
This workflow instructs the agent to open ar-sign-skill/SKILL.md, and related sections also depend on application-publish, service-market, mcc-recommender, and ./ar-sign-skill/ar-sign, none of which are present in this repo. Because the main skill tells the model to read these references before execution, core signing/app-creation paths will fail on missing files/commands rather than yielding usable onboarding guidance.
Useful? React with 👍 / 👎.
lefarcen
left a comment
lefarcen
left a comment
There was a problem hiding this comment.
Hi @leilei926524-tech — thanks for adding the Alipay merchant onboarding skill! This is solid documentation with good scope boundaries and clear reference structure. A few observations and suggestions below.
Lens A — Code correctness (tests + i18n)
Test coverage looks good:
- The new test case in
apps/daemon/tests/skills.test.tsproperly verifies the skill is discoverable with expected metadata (mode, preview type, triggers) - It checks that reference docs are injected into the skill body
- I18n consistency:
alipay-merchant-onboardingis correctly added to all language fallback lists (en, fr, ru, de)
Lens B — Reasoning completeness (SKILL.md + references/)
Strengths:
- Explicit assumptions: SKILL.md clearly states what is NOT supported in open-design (POSIX-only scripts,
/tmp, external CLI assumptions, private key generation). This prevents false expectations. - Failure modes covered:
error-handling.mdandfaq.mdaddress common blockers (MCP auth errors, CLI installation, signing state detection). - Internal consistency: The flow from
flow.md→authorization.md→mcp-methods.mdforms a closed loop. The two product tracks (电脑网站支付 vs 智能收) are consistently differentiated throughout. - Actionable guidance: The skill provides concrete checklists and manual handoff points when external tooling is unavailable.
Suggestions for future iteration (non-blocking):
- Consider adding a "Prerequisites" section in SKILL.md stating what the user should have ready before starting (Alipay account, business license type, intended product surface). Currently this is scattered across multiple reference docs.
- The subskills.md note about "Read file instead of Skill tool" is good context, but it might be clearer to state this constraint upfront in SKILL.md § "Before doing anything" rather than only in the references.
flow.mdmentions "委托 ar-sign-skill 子技能" and similar delegations — these are implementation details that could be abstracted in the main SKILL.md for users who don't need to understand the internal subskill structure.
Overall
This skill fits the open-design catalog well. The guidance-first approach (rather than assuming full automation) is the right choice for a workflow that depends on external tooling. The reference docs are thorough, and the failure-mode coverage is strong.
Looks good to me; deferring final approval to a maintainer.
mrcfps
left a comment
mrcfps
left a comment
There was a problem hiding this comment.
@leilei926524-tech thanks for adding the Alipay merchant onboarding skill and wiring it into discovery/tests. I found a couple of workflow-contract issues in the new references that would make the documented implementation path fail for users, so I’m requesting changes to align the guidance with what this repo actually ships. 🙏
Generated by Looper 0.6.1 · runner=reviewer · agent=opencode| STATE_MANAGER=<skill-dir>/scripts/state_manager.py | ||
| python3 "$STATE_MANAGER" init |
There was a problem hiding this comment.
The flow initializes <skill-dir>/scripts/state_manager.py as the first state-management step, but this PR does not add a scripts/state_manager.py file under skills/alipay-merchant-onboarding/, and the main SKILL.md says this open-design version must not assume POSIX/shared-memory helpers are available. Because this is in the core Step 1 path, an agent following the changed references will fail before it can proceed with onboarding.
Please either ship/support the referenced state manager in this skill, or rewrite the flow/state-management references as checklist-only guidance that does not instruct agents to execute missing state scripts.
| #### 5.4.1 写入共享内存状态 | ||
|
|
||
| ```bash | ||
| # 智能收的服务注册入参采集后写入状态文件（service_market_data 字段） | ||
| python3 "$STATE_MANAGER" set-json service_market_data "{ | ||
| \"serviceName\": \"$SERVICE_NAME\", | ||
| \"serviceDesc\": \"$SERVICE_DESC\", | ||
| \"resourceUrl\": \"$RESOURCE_URL\", | ||
| \"pricing\": \"$PRICING\", | ||
| \"schemaUrl\": \"$SCHEMA_URL\" | ||
| }" |
There was a problem hiding this comment.
This 智能收 path requires writing service_market_data into the shared state and later reads service_market_data.* for service registration, but references/state-management.md defines the state contract as exactly four allowed fields and explicitly lists service_market_data as forbidden. Following the state contract drops the data Branch B needs; following this flow violates the documented state contract, so the primary 智能收 service-registration path cannot be implemented consistently.
Please choose one contract and update the references together: either add service_market_data to the allowed schema with validation/cleanup rules, or keep those five service-registration fields as runtime variables and pass them directly to the service-market handoff instead of reading/writing them through state.
3 participants
Summary
skills/alipay-merchant-onboarding/.Test plan
cd apps/daemon && ./node_modules/.bin/vitest run -c vitest.config.ts tests/skills.test.tscd apps/web && ./node_modules/.bin/vitest run -c vitest.config.ts tests/i18n/content.test.ts🤖 Generated with Claude Code