Xz01 Dev Skill

Use when 用户提到“xz01规范”时必须命中本技能;xz01规范=xz01-dev-skill。用于 Hermes + Claude Code 围绕用户现有 OpenClaw/xz01 模板资料进行角色编排、开发学习范围、测试/规范分工,并严格将 /root/.openclaw 作为只读学习资料库;编码修复交给 Claude dev,测试输出写入 /www/wwwroot/www.900az.com,彻底验证通过的模板按编号压缩到 /root/.hermes/workspace/xz01/。

Audits

Pass

Install

openclaw skills install xz01-dev-skill

xz01-dev-skill

Trigger Alias / 命中别名

xz01规范 = xz01-dev-skill

当用户提到以下中文触发词时,必须优先加载并遵循本技能:

  • xz01规范
  • xz01 规范
  • xz01开发规范
  • xz01学习范围
  • xz01角色分工
  • Hermes+Claude xz01
  • OpenClaw xz01
  • 谁是 dev / 谁是 test
  • /root/.openclaw 只读
  • 测试输出写到 /www/wwwroot/www.900az.com
  • 验证通过模板打包到 /root/.hermes/workspace/xz01/
  • 安装或接入 Lanhu MCP / 蓝湖 MCP

References

  • references/lanhu-mcp-installation.md — recommended Docker Compose + HTTP MCP setup for dsphper/lanhu-mcp, including Hermes native MCP and Claude Code connection examples.
  • references/demo-xz01-may-2026-source-update.md — read-only learning notes from the May 2026 demo_xz01 source update, including the user-confirmed rule that front-end PC/mobile search is canceled/weakened and should not be a default QA failure.
  • references/xz01-template-factory-architecture.md — architecture notes for upgrading the current main/dev/test/rule loop into a 60-template dual-end xz01 automation factory with corpus ingestion, DB/route learning, planning, rendering, validation, repair loops, rule review, and packaging.
  • references/hermes-native-xz01-first-run.md — first-run pattern for building a safe Hermes-native xz01 prototype under /root/.hermes/workspace/xz01-factory, including minimal output shape, static validation checklist, and prototype-vs-production boundary.
  • references/hermes-native-xz01-live-deploy-validation.md — live temporary deployment pattern for /www/wwwroot/www.900az.com/public/themes/default/, including backup, cache clearing, HTTP/PHP/static/browser/AI validation, fallback data blocks, trace-overlay hiding, and screenshot artifact paths.
  • references/run-0002-visual-repair.md — session-specific repair notes for making a temporary xz01 homepage more demo-like after AI visual review: PC density/card-count fixes, topic-background cleanup, desktop-vs-mobile-UA validation, true 390px mobile screenshots, right-side alignment/overflow probes, long mobile screenshots for lower modules, and viewport clipping remedies.
  • references/session-2026-05-16-main-role-boundary-correction.md — user correction that xz01 coding/HTML/CSS/template fixes must be delegated to Claude Code dev even when the fix is small or obvious; main must not directly patch implementation files.
  • references/session-2026-05-16-pc-gap-dev-test-rule-loop.md — concrete example of handling a small PC quick-topic spacing defect through Claude dev → independent test screenshot/AI review → rule audit, including constrained dev prompt shape and test acceptance criteria.
  • references/session-2026-05-16-right-sidebar-height-balance.md — follow-up lesson from repeated PC gap corrections: if a lower section is pushed down by a taller right sidebar, reduce right-side content height (e.g. 专题推荐 4→3) instead of only compressing margins.
  • references/session-2026-05-16-packaging-gate-runtime-list-detail.md — user correction after an invalid package: every dev change must clear /www/wwwroot/www.900az.com/runtime/ before validation, and packaging is forbidden until homepage/list/detail rendering, jQuery, trailing-slash links, data images, and dynamic data gates all pass.
  • references/session-2026-05-16-no-php-controller-template-dev.md — user correction that xz01 template development must never modify PHP/backend/controller/model/config files; dev scope is theme templates/assets only unless the user explicitly authorizes a non-template backend task.
  • references/session-2026-05-16-theme-only-data-links-search.md — theme-only repair notes after backend restoration: restore data with existing template tags, make slash-ending column links absolute with the correct PC/mobile host, avoid double-prefix domains, keep PC search out of the top center, fix missing detail templates in the theme, and keep test artifacts out of /root/.openclaw.
  • references/session-2026-05-16-max-turns-task-splitting-validation-scripts.md — user correction for repeated max_turns and long-running tasks: do not raise max-turns, split work to minimum units, use fixed validation scripts, do not enable the no-re-exploration rule for now, time-box dev/test tasks, use Claude interactive/tmux only as a supervised workbench for a sequence of small tasks, and prioritize stability with a single serial queue unless the user explicitly re-enables concurrency.
  • references/session-2026-05-16-demo-xz01-systematic-validation.md — user correction that demo_xz01 must be learned systematically: dual-end list/detail templates must exist and render, pagination variables/data rendering must follow demo patterns, runtime cache must be cleared after every dev change, PC+mobile static/HTTP/browser/screenshot/AI gates are mandatory before packaging, and the validation scripts are part of this skill.

Overview

This skill is for operating a Hermes + Claude Code workflow around the user's existing OpenClaw/xz01 material. The existing OpenClaw tree is a read-only learning corpus, not a place to write configs, skills, memory, cron state, sessions, templates, or generated reports unless the user explicitly authorizes a specific write.

Authoritative read-only boundary:

/root/.openclaw/ and every subdirectory = read-only learning material

Default runtime division:

Hermes current session = main / dispatcher / final reporter
Claude Code = dev / implementation worker
Hermes independent test role = test / validation worker
Hermes independent rule role = rule / process and standard reviewer

When to Use

Use this skill when the user asks about:

  • “xz01规范”
  • “xz01 规范”
  • “xz01-dev-skill”
  • “Hermes 和 Claude 怎么分工”
  • “谁是 dev,谁是 test”
  • “OpenClaw 的学习范围”
  • “/root/.openclaw 只读”
  • “把这个流程做成 skill”
  • “持续优化技能”
  • Hermes + Claude role division for OpenClaw/xz01-style work
  • what each role should learn from /root/.openclaw
  • turning OpenClaw process rules into Hermes skills
  • coordinating template development, validation, and rule review without modifying OpenClaw's existing files
  • preserving dev/test/rule separation while using Claude Code for implementation

Do not use this skill to modify /root/.openclaw files. Treat them as reference-only.

Non-Negotiable Boundary

All roles must obey:

Do not write to /root/.openclaw/
Do not patch /root/.openclaw/
Do not update /root/.openclaw/openclaw.json
Do not modify /root/.openclaw/workspace/*
Do not modify /root/.openclaw/agents/*
Do not modify /root/.openclaw/cron/*
Do not modify /root/.openclaw/memory/*
Do not modify /root/.openclaw/flows/*
Do not modify /root/.openclaw/workspace/demo_xz01

Allowed operations on /root/.openclaw:

  • read targeted files
  • inventory directories
  • summarize rules
  • learn conventions
  • compare reports against known standards

Template-development backend boundary:

For xz01 template development, NEVER modify PHP/backend/controller/model/config files.
Forbidden paths include: application/**/*.php, config/**/*.php, route/**/*.php, thinkphp/**/*.php, vendor/**/*.php, and any controller/model/service/backend PHP file.
Allowed template scope by default: public/themes/<theme>/** only (HTML templates, CSS, JS, theme assets).
If required data/routes are unavailable through existing backend/template tags, report the limitation; do not patch PHP to make a template pass.
Any package created after PHP/controller/config changes is invalid until those backend changes are reverted and the template is revalidated with theme-only changes.

If writes are required, write only to:

  • Hermes skill storage (~/.hermes/skills/...) when creating/updating Hermes skills
  • a user-authorized non-OpenClaw project directory
  • /www/wwwroot/www.900az.com for all test-side outputs, validation artifacts, screenshots, reports, and website verification outputs unless the user explicitly changes it
  • /root/.hermes/workspace/xz01/ for numbered zip packages of templates that have fully passed verification
  • another explicit path the user names

Packaging rule for verified templates:

Only templates that are thoroughly verified as passed may be packed.
Package verified templates as numbered compressed archives under /root/.hermes/workspace/xz01/.
Do not store final verified template packages under /root/.openclaw/.

Hard packaging gate:

- After every add/modify/delete development change, delete all directories/items under `/www/wwwroot/www.900az.com/runtime/` before validation.
- Do not package until PC/mobile homepage, software/game list pages, and detail pages are generated/available and render correctly from existing database routes; list/detail pages must not be merely referenced or assumed.
- Do not package if rendered pages contain missing header/head jQuery loading, no-slash column URLs, malformed duplicate-host absolute URLs, `cms/page/index/id` / `cms/Page/index` / `mobile/Page/index` errors, prohibited filler SVG data images, mostly `暂无...数据` placeholders, or zero real content/detail links while DB records exist.
- For every rendered column/category URL whose path ends with `/`, output an absolute URL with protocol and the correct host: PC uses `https://www.900az.com/.../`, mobile uses `https://m.900az.com/.../`. Normalize helper output first so an already-absolute URL is not prefixed again.
- PC header/search layout gate: the PC search box must never be placed at the top center of the header. Use a right-side, below-header, or otherwise non-center placement. Mobile is evaluated separately.

Role Map

RoleDefault assigneePurposeMay write /root/.openclaw?
mainHermes current sessionreceive requests, split work, dispatch, supervise, final reportNo
devClaude Codeimplement code/template changes in authorized workdirNo
testindependent Hermes test role/sessionscreenshots, AI visual analysis, lint/HTML/CSS/template validationNo
ruleindependent Hermes rule role/sessionprocess audit, rule review, skill/spec suggestionsNo

Main Role Learning Scope

Main learns coordination and boundaries, not implementation.

Read-only sources:

  • /root/.openclaw/workspace/IRON_RULES.md
  • /root/.openclaw/workspace/AGENTS.md
  • /root/.openclaw/workspace/MEMORY.md
  • /root/.openclaw/workspace/error.md
  • /root/.openclaw/workspace/DREAMS.md
  • /root/.openclaw/workspace/scripts/flow-controller.js
  • /root/.openclaw/workspace/scripts/check-flow-stuck.js
  • /root/.openclaw/workspace/scripts/violation-tracker.js
  • /root/.openclaw/openclaw.json
  • /root/.openclaw/cron/jobs.json
  • /root/.openclaw/agents/*/sessions only when targeted history/debug context is needed
  • /root/.openclaw/memory/*.sqlite only when targeted memory inspection is explicitly needed

Main must learn:

  1. role boundaries
  2. flow sequence: main → dev → test → rule → main
  3. when to dispatch to each role
  4. how to avoid dev/test/rule collapse
  5. report format expectations
  6. historical violations and user corrections
  7. that /root/.openclaw is read-only

Main must not:

  • write code
  • test/screenshot
  • modify CSS/templates
  • modify PHP/backend/controller/model/config files for template development
  • update OpenClaw configs
  • silently skip test or rule

Dev Role Learning Scope

Dev is Claude Code by default. Dev learns implementation standards and writes only in an authorized non-OpenClaw workdir.

Read-only sources:

  • /root/.openclaw/workspace/IRON_RULES.md
  • /root/.openclaw/workspace/AGENTS.md
  • /root/.openclaw/workspace/TEMPLATE-SPEC.md
  • /root/.openclaw/workspace-dev/MEMORY.md
  • /root/.openclaw/workspace-dev/skills
  • /root/.openclaw/workspace-dev/memory
  • /root/.openclaw/workspace/demo_xz01
  • /root/.openclaw/workspace/memory/team/project targeted template-development notes

Dev must learn:

  1. ThinkPHP template structure
  2. PC/mobile dual-template structure
  3. common module organization
  4. HTML/CSS/JS conventions
  5. template tag closure rules (include, foreach, if)
  6. data filters such as is_hide=0 and status=1
  7. search/navigation/carousel/data rendering conventions, with updated demo_xz01 nuance: front-end PC/mobile header search forms are no longer mandatory by default after the May 2026 source update; do not re-add or require full search unless the specific template/design explicitly includes it
  8. route rule: database routes are authoritative; do not invent routes from template filenames
  9. demo_xz01 is a pattern library, not editable and not copy-paste source
  10. updated template-structure nuance: some newer templates remove zyxz_module entirely or inline sidebar/recommendation blocks instead of using fixed _side_*.html partials; preserve the specific template's structure instead of forcing old module inventories
  11. demo_xz01 systematic rendering rules: every xz01 template must implement complete PC+mobile homepage/list/detail coverage for existing DB routes, especially software/game list pages and detail pages; list pages that paginate should follow demo-style getPcPageData / getMobilePageData and $page_code|raw or an explicitly confirmed equivalent.
  12. resource loading rules: do not use /themes/default/common_cms/common/jquery.min.js; load jQuery from the correct PC/mobile asset path. Include UIkit and Swiper only when needed, using the correct PC/mobile asset CSS+JS pair.

Dev must not:

  • read Feishu group messages
  • self-certify final acceptance
  • skip test
  • write /root/.openclaw
  • modify demo_xz01
  • modify PHP/backend/controller/model/config files for template development (application/**/*.php, config/**/*.php, routes, ThinkPHP core, vendor, backend services). Template tasks are limited to public/themes/<theme>/** unless the user explicitly authorizes a non-template backend task.
  • perform official screenshot/AI visual validation

Dev output should include:

  • changed file list in authorized workdir
  • implementation summary
  • self-check notes
  • items for test to validate

Test Role Learning Scope

Test is an independent Hermes role/session. It validates; it does not fix.

Read-only sources:

  • /root/.openclaw/workspace/IRON_RULES.md
  • /root/.openclaw/workspace/AGENTS.md
  • /root/.openclaw/workspace/TEMPLATE-SPEC.md
  • /root/.openclaw/workspace-test/MEMORY.md
  • /root/.openclaw/workspace-test/skills
  • /root/.openclaw/workspace-test/scripts
  • /root/.openclaw/workspace-test/skills/template-qa/scripts
  • /root/.openclaw/workspace/demo_xz01
  • /root/.openclaw/workspace/memory/team/project targeted testing/screenshot/AI-vision notes

Test must learn:

  1. PC screenshot requirements
  2. mobile screenshot requirements
  3. AI visual analysis requirement after screenshots
  4. layout/overlap/missing-element/color/font/responsive checks
  5. HTML tag closure checks
  6. CSS path/layout checks
  7. ThinkPHP template tag checks
  8. search/navigation/carousel/data rendering checks, with updated demo_xz01 nuance: missing PC/mobile header search form is not a default failure because the May 2026 source update cancels/weakens front-end dual-end search; only fail search when a required search element in the specific design/template is broken
  9. regression testing; do not only check the last fix
  10. full issue report format

Test must not:

  • write implementation code
  • fix issues directly
  • read Feishu group messages
  • write /root/.openclaw
  • claim visual correctness without screenshots + AI visual analysis

Test output should include:

  • PC screenshot paths under /www/wwwroot/www.900az.com
  • mobile screenshot paths under /www/wwwroot/www.900az.com
  • AI visual analysis findings saved/reported from the test output area
  • structural/lint findings
  • functional findings
  • pass/fail conclusion
  • issue list for dev when failed

All test-side artifacts must be written under /www/wwwroot/www.900az.com unless the user explicitly changes the output location.

Rule Role Learning Scope

Rule is an independent Hermes role/session. It audits workflow and proposes/maintains durable rules. Under the read-only boundary, it must not update OpenClaw files unless explicitly authorized.

Read-only sources:

  • /root/.openclaw/workspace/IRON_RULES.md
  • /root/.openclaw/workspace/AGENTS.md
  • /root/.openclaw/workspace/TEMPLATE-SPEC.md
  • /root/.openclaw/workspace-rule/MEMORY.md
  • /root/.openclaw/workspace-rule/skills
  • /root/.openclaw/workspace-rule/memory
  • /root/.openclaw/workspace/skills
  • /root/.openclaw/workspace/memory/team/project
  • /root/.openclaw/workspace/memory/violations
  • /root/.openclaw/workspace/error.md

Rule must learn:

  1. role-boundary violations to prevent
  2. process-completion requirements
  3. when a lesson should become a skill
  4. when a lesson should remain a report, not memory/skill
  5. skill metadata/version/documentation conventions
  6. cron-log noise restrictions
  7. user-specific hard rules

Rule must not:

  • implement code
  • test/screenshot
  • write /root/.openclaw
  • publish OpenClaw skills or edit OpenClaw specs without explicit authorization

Rule output should include:

  • compliance audit
  • whether the flow skipped steps
  • whether new durable guidance is needed
  • proposed skill/spec text if needed
  • where it should be saved, subject to authorization

Visual Repair Loop for xz01 Homepage Runs

When the user says to “继续” after a first xz01 prototype or says the page is not close enough to xz01_demo, do not stop at a functional page. Run an AI-vision-driven repair loop until the visible defects are fixed.

Workflow:

  1. Compare against the demo_xz01 target as a high-density download-station portal, not a sparse landing page.
  2. Patch PC/mobile templates and CSS in the authorized run directory and the temporary deployment copy when already deployed.
  3. Clear all directories/items under /www/wwwroot/www.900az.com/runtime/ after every add/modify/delete development change and before any validation. Do this before rendering screenshots or HTTP checks so stale ThinkPHP cache cannot hide template/controller changes.
  4. Validate HTTP 200, compiled PHP syntax, mobile no target="_blank", and screenshots.
    • PC validation uses the desktop domain/access path: https://www.900az.com/ with a desktop UA.
    • Mobile validation must use the mobile domain/access path: https://m.900az.com/ with a real Android/iPhone Mobile User-Agent. Do not validate m.900az.com using the same desktop/PC browser access method as PC.
  5. Submit PC and true small-width mobile-UA screenshots to AI vision; treat AI findings as actionable repair items.
  6. If the user reports right-side alignment issues, inspect both PC and mobile with the correct UA/domain pair, run an overflow probe on PC, capture a long mobile screenshot for lower modules, patch the run/deploy CSS, and re-check until AI vision passes.
  7. Re-patch and re-check until AI confirms pass.

Common repairs from run-0002:

  • PC hot games/apps need enough fallback cards to fill the grid; 3-4 cards create obvious blank areas.
  • Topic-card decorative background text should be low-opacity and not compete with foreground titles.
  • To match xz01_demo, reduce excessive modern-card spacing and increase list/module density.
  • Mobile default browser snapshots may hide real phone-width clipping; validate mobile with real Android/iPhone UA against https://m.900az.com/ and with DevTools mobile emulation at multiple CSS widths such as 390px and 430px.
  • If a template includes a mobile back-to-top control, verify it with real Mobile UA + 390px screenshot: the button should be visible when required, must not cover download buttons or core content, and tapping/clicking after scroll should return the page to the top.
  • Do not reuse the desktop/PC access method for mobile verification; mobile-domain validation requires a mobile UA header.
  • If a 390px screenshot shows left blank strip, right card clipping, or right-side misalignment, fix container/grid width, not just overflow-x:hidden.
  • If a mobile back-to-top () button visually crowds or overlaps content, prefer a non-intrusive document-flow placement near the page bottom with safe-area spacing over a fixed floating overlay.
  • Do not fix mobile containers to max-width:390px; it can pass a 390px screenshot but leave a blank strip on wider real phones. Under phone breakpoints prefer width:100%; max-width:100% plus safe padding/grid rules, then verify both 390px and 430px.
  • For right-side alignment defects, verify PC and mobile separately: PC with desktop UA on www.900az.com, mobile with real Android/iPhone UA on m.900az.com; do not share access mode.
  • For PC right-sidebar drift, probe documentElement.scrollWidth and overflowing elements, then unify .xz-wrap, hero grid, sidebar, lower sections, and card grids to the same right boundary.
  • For mobile lower-module alignment, capture a long 390px screenshot so 热门应用 / 攻略 / 精选专辑 are inspected, not only the first viewport.

Detailed notes: references/run-0002-visual-repair.md.

Lanhu MCP Integration

For xz01 work that needs Lanhu requirements/designs, the Lanhu MCP service is installed and managed outside /root/.openclaw:

  • Session note: see references/lanhu-mcp-discovery-notes.md for the currently exposed tools and the no-account-wide-project-list limitation.
Install path: /root/.hermes/workspace/lanhu-mcp
Docker container: lanhu_mcp_service
HTTP MCP endpoint: http://127.0.0.1:8000/mcp?role=Developer&name=HermesMain
Hermes MCP server name: lanhu

Operational rules:

  • Use Docker Compose from /root/.hermes/workspace/lanhu-mcp to manage the service.
  • Keep Lanhu credentials in /root/.hermes/workspace/lanhu-mcp/.env; do not write them to /root/.openclaw.
  • Hermes native MCP connects through mcp_servers.lanhu in /root/.hermes/config.yaml.
  • After MCP config changes, start a fresh Hermes session or restart the relevant Hermes process so discovered MCP tools are loaded.
  • If external downloads are needed, use the user's temporary proxy:
export http_proxy=http://192.168.1.9:1080
export https_proxy=http://192.168.1.9:1080
export all_proxy=socks5://192.168.1.9:1080

Verification commands:

cd /root/.hermes/workspace/lanhu-mcp
docker compose ps
curl -fsS http://127.0.0.1:8000/health
hermes mcp test lanhu

Discovered Lanhu tools include page analysis, design analysis, slice extraction, team messages, and member listing.

Hermes-Native Orchestration Boundary

Do not port OpenClaw-only runtime mechanisms into Hermes workflow design.

OpenClaw-specific concepts such as sessions_send(sessionKey: agent:dev:main, ...), /root/.openclaw/agents/*/sessions, and the OpenClaw flow-controller.js state machine are read-only legacy/reference material for this workflow. They must not be treated as Hermes-native execution primitives.

Hermes-native replacements:

OpenClaw conceptHermes-native replacementUse case
sessions_send to dev/test/rule sessionsdelegate_taskShort synchronous subtasks; parent waits for result
Persistent role sessionsHermes profiles + hermes kanbanDurable multi-worker queues and role separation
flow-controller.js single JSON stateKanban board / factory SQLite queueMulti-task durable workflow state
OpenClaw cron progress monitorHermes cronjob / hermes cronScheduled watchdogs and periodic reports
Manual subprocess role agentsterminal(background=True) or tmux-spawned hermes / claudeLong-running autonomous workers
Feishu-only role routingHermes gateway / WebUI / kanban notificationsUser-facing delivery and status updates

For xz01 automation, prefer a Hermes-native design:

Hermes main/orchestrator
  -> xz01-factory queue/SQLite/Kanban task
  -> dev worker: Claude Code or Hermes profile for implementation
  -> renderer/test worker: deterministic scripts + independent Hermes/vision validation
  -> rule worker: Hermes profile or main-side review task
  -> packaging/reporting

Rules:

  1. Do not claim Hermes supports OpenClaw sessions_send unless an explicit OpenClaw compatibility bridge is installed and verified.
  2. Do not design new Hermes workflows around /root/.openclaw writable state.
  3. Use OpenClaw files only as learning/reference material.
  4. Use Hermes delegate_task for quick isolated checks, hermes kanban for durable multi-agent work, and deterministic scripts/SQLite queues for production xz01 factory state.
  5. For long-running dev/test agents, spawn explicit hermes or claude processes via terminal(background=True)/tmux, or use Kanban dispatcher profiles.
  6. When the user asks whether to keep noting caveats or directly build the first xz01 prototype, choose a safe action: create a Hermes factory run under /root/.hermes/workspace/xz01-factory, generate a prototype without touching production, run deterministic static validation, then report remaining production-validation steps. See references/hermes-native-xz01-first-run.md.

Execution Time Control and Task Splitting

User-specific rules for xz01 work after repeated max_turns interruptions and one task exceeding 50 minutes:

Do not solve this by increasing Claude Code max-turns.
Split all work into the smallest practical units.
Use fixed validation scripts.
Do not enable a hard "禁止重新探索" / no-re-exploration rule for now.
Stability first: do not use concurrency for xz01 template execution unless the user explicitly re-enables it.
Avoid long-running single tasks; time-box dev/test calls and split earlier.

Operational rules:

  1. Main must split work before dispatch. A dev task should normally cover one page, one component, or one defect class only.
  2. Execute xz01 template work through a strict serial queue: exactly one active dev task, one active test task, and one active rule review at a time. No parallel dev/test/rule lanes unless the user explicitly changes this rule.
  3. Do not bundle development + broad exploration + screenshot/AI visual + full regression + packaging into a single dev task.
  4. Dev should not perform official screenshots or full regression; test owns those.
  5. Use fixed validation scripts under /root/.hermes/workspace/xz01-factory/tools/ whenever applicable, or the embedded skill copies under scripts/ when installing/reusing this skill:
    • xz01-runtime-clear.sh — clear /www/wwwroot/www.900az.com/runtime/ after every add/modify/delete and before validation.
    • xz01-backend-baseline-check.sh — verify PHP/backend/controller/model/config scope was not modified for a template task.
    • xz01-theme-diff-check.sh — inspect theme-only change boundaries.
    • xz01-quick-http-gate.py — quick HTTP checks for key PC/mobile URLs.
    • xz01-template-static-scan.py — scan template code for PC/mobile core template completeness, bad jQuery/UI resource paths, pagination-pattern gaps, malformed links, mobile target="_blank", and forbidden filler assets.
    • xz01-full-url-scan.py — crawl same-host PC/mobile front-end URLs and fail on 5xx/ThinkPHP errors, malformed links, mobile blank targets, many empty placeholders, and zero-count software/game list pages.
    • xz01-screenshot-core.sh — deterministic Chromium headless screenshots for core PC/mobile homepage, software/game list, and news list pages; use before AI visual review and copy artifacts into /root/.hermes/workspace/... for WebUI media.
  6. Keep --max-turns task-appropriate, but do not raise it as the mitigation. If a task cannot complete without raising turns, it is too large and must be split.
  7. Time-box tool calls. If a run risks becoming long, stop and split the remaining work rather than allowing 50+ minute single runs.
  8. For a batch of many related minimum-unit fixes, use Claude interactive session / tmux as a supervised workbench to reduce repeated startup/resume overhead and preserve local context. Each tmux instruction must still be one small task with an explicit stop/checkpoint; tmux is not permission to run one large task.
  9. The proposed no-re-exploration rule is not active; do not insert it as a hard prompt constraint unless the user later enables it.

Dispatch Rules

Main routes tasks by type:

User request typeRoute to
code/template development or repairdev
screenshot, validation, visual QA, lint, functional checkingtest
rule changes, process audit, durable lessonsrule
final synthesis and user-facing statusmain

When in doubt:

  • development goes to dev
  • validation goes to test
  • durable process/spec review goes to rule
  • main does not collapse roles
  • use a serial queue for stability: no concurrent xz01 dev/test/rule execution unless explicitly re-enabled by the user
  • split every assignment to the smallest practical unit before dispatch; do not use a larger --max-turns setting as the fix for long tasks
  • prefer fixed validation scripts over ad-hoc validation commands
  • do not enable a hard no-re-exploration prompt rule for now; the user explicitly paused that recommendation
  • if a live xz01 page has a visible defect and the fix appears obvious, main still does not patch HTML/CSS/templates directly; main creates/dispatches the dev task and lets the dev→test→rule loop close it
  • for small visual spacing defects, main should still use a constrained dev prompt with exact text anchors, allowed files/run dirs, and boundaries; after dev self-check, route to independent test for screenshot + AI review before reporting pass; if the user names a remaining sliver (e.g. above 游戏活动), treat it as a new visible defect and repeat the loop rather than relying on the previous PASS
  • if the repeated PC gap is caused by right-sidebar height, reduce non-critical right-side content height directly (for example 专题推荐 from 4 entries to 3) before doing further margin-only tweaks; keep the sidebar structure intact and validate the resulting gap with screenshot/AI review

Flow

Default flow:

user → Hermes main → Claude dev → Hermes test
                              ↘ fail → dev fixes → test repeats
                               pass → Hermes rule → Hermes main → user

Main should preserve role separation even if a task is small.

Reporting Format for This User

For Hermes-native xz01 workflow reports, do not use the old OpenClaw 10-column table unless the user explicitly asks for it. Use a concise xz01 report format instead:

## xz01 执行报告|<阶段/任务名>

**结论**:✅/⚠️/❌ 一句话状态

### 已完成
- ...

### 发现问题与处理
- 问题:...
- 处理:...

### 验证结果
- PC:...
- 移动端:...
- 静态检查:...
- AI视觉:...

### 产物
- 模板目录:...
- 报告:...
- 截图:MEDIA:/root/.hermes/...  (不要用 /www 的媒体路径直接给 WebUI)

### 下一步
- ...

Media artifact rule:

  • Test artifacts may still be saved under /www/wwwroot/www.900az.com for website-side records.
  • When sharing screenshots/files in Hermes WebUI, also copy them under /root/.hermes/workspace/... or another Hermes-allowed media location and reference that path with MEDIA:/absolute/path.
  • Avoid sending /www/... paths as WebUI media links because the WebUI media API may return 403 Path not in allowed location.

Continuous Skill Improvement

Hermes should continuously improve this skill when actual workflow reveals gaps, but only within Hermes skill storage or another user-authorized non-OpenClaw location.

Patch this skill when:

  • the user corrects role division
  • a new hard boundary is stated
  • a role's learning scope is missing material
  • a recurring mistake appears
  • a command/path/tool pattern is proven useful
  • a previous instruction is stale or unsafe

Do not patch this skill for:

  • one-off task progress
  • temporary file paths
  • transient PR/issue/session IDs
  • anything likely to be stale within a week

Before finishing a complex task that changed the workflow, check whether this skill needs a patch.

Common Pitfalls

  1. Treating /root/.openclaw as a writable config home. It is read-only for this workflow unless explicitly authorized.
  2. Modifying PHP/controllers/config during template development. This is forbidden. Do not patch application/**/*.php, config/**/*.php, routes, ThinkPHP core, models, services, or backend PHP to make a theme render. Use existing routes/template tags/data variables; otherwise report the limitation and keep work theme-only.
  3. Double-prefixing absolute URLs. Helpers such as cmf_url() may already return an absolute URL. Normalize before prefixing; do not produce https://www.900az.comhttps://... or https://m.900az.comhttps//....
  4. Putting the PC search box at the top center. The user explicitly forbids this for PC templates. Keep PC search in a right-side, below-header, or otherwise non-center position.
  5. Letting Claude be both dev and test. Dev/test must stay separate; if Claude is used for test, it must be a separate test instance.
  6. Only reading Markdown. Scripts, JSON metadata, cron state, SQLite flow state, skill support files, and test tooling also encode rules.
  7. Skipping AI visual analysis. Test screenshots are incomplete without AI visual review.
  8. Copying demo templates. demo_xz01 is a sample corpus, not an editable/copy target.
  9. Writing test artifacts under /root/.openclaw. Treat /root/.openclaw as read-only; screenshots/reports should go under /root/.hermes/workspace/... for Hermes media or /www/wwwroot/www.900az.com for site-side records.
  10. Main doing hands-on QA or fixes. Main supervises and reports; it does not implement or test. User explicitly corrected this after a PC homepage visual repair: even small/urgent HTML/CSS/ThinkPHP fixes must be delegated to Claude Code dev, then verified by an independent test role. Do not let speed become a reason for main to patch templates directly.
  11. Under-scoped Claude Code delegation. When delegating implementation in print mode, include Grep/Glob if the task requires locating selectors/files; otherwise permission denials can burn turns and trigger error_max_turns. If that happens, resume the same Claude session with the missing tools allowed, or ask for a no-edit completion summary before moving to test.
  12. Writing OpenClaw memories/skills/configs. Durable updates for this Hermes workflow belong in Hermes skills/memory unless user authorizes otherwise.

Verification Checklist

Before reporting role orchestration status:

  • /root/.openclaw treated as read-only
  • main/dev/test/rule are distinct
  • dev assigned to Claude Code by default
  • test assigned to independent Hermes test role/session
  • rule assigned to independent Hermes rule role/session
  • each role has a clear learning scope
  • no write/patch to OpenClaw directories occurred
  • no PHP/backend/controller/model/config files were modified for a template-development task; allowed changes stayed within public/themes/<theme>/** unless the user explicitly authorized backend work
  • task was split to the smallest practical unit; max-turns was not increased as the mitigation for long-running work
  • xz01 execution used a strict serial queue with no concurrent dev/test/rule lanes unless the user explicitly re-enabled concurrency
  • fixed validation scripts were used where applicable instead of ad-hoc repeated checks
  • no hard no-re-exploration rule was added to prompts unless explicitly re-enabled by the user
  • every add/modify/delete development change was followed by clearing /www/wwwroot/www.900az.com/runtime/ before validation
  • static template validation was run with xz01-template-static-scan.py against the deployed/default theme or candidate theme
  • PC/mobile URL crawl validation was run with xz01-full-url-scan.py or equivalent browser/curl scan before packaging; no existing DB route checked returns 500/ThinkPHP error
  • PC/mobile homepage plus required software/game list pages and detail pages are generated/available and render correctly from existing DB routes before any package is created
  • list pages using pagination follow demo-style getPcPageData / getMobilePageData and $page_code|raw (or an equivalent confirmed project pattern), so missing pagination variables do not break pages such as /gzos/
  • rendered output passes xz01 hard gates: header/head jQuery loading present and not using /common_cms/common/jquery.min.js; UIkit and Swiper assets are included only when needed using the correct PC/mobile asset paths; column URLs that end with / are absolute with the correct PC/mobile host and are not double-prefixed; PC search is not top-center; no cms/page/index/id links; no prohibited filler SVG data images; mobile no target="_blank"; and real data/detail links are present when DB records exist
  • before packaging, PC+mobile relevant pages have static scan, curl/browser access, screenshots, and AI visual review results recorded
  • user-facing reply starts with the required 10-column table when applicable