hyb-oa/.agents/skills/hyb-oa-delivery/SKILL.md

name, description

name	description
hyb-oa-delivery	Use for hyb-oa project delivery tasks: natural-language triage, planning with Issue CSV, implementing Fastify/Prisma or React/Vite changes, refining PC/mobile/WeCom UI, reimbursement/invoice/OCR/attachment work, trial-run troubleshooting, automated/visual verification, and Chinese batch commits.

hyb-oa Delivery

Use this skill when working in /home/shunli/Projects/hyb-oa or when the user asks to continue planning, implementation, trial-run validation, visual QA, reimbursement/invoice improvements, Enterprise WeChat checks, deployment preparation, or project-wide review.

Required Reading

Read only what is relevant:

• Always read AGENTS.md and the newest relevant issues/*.csv.
• After R5, first check the main R5/R6 contract status before planning trial-run or follow-up work; R5 must remain the completed gate and R6 must have its own Issue CSV before expanding scope.
• For UI/page work, PC/mobile/WeCom experience, approval UX, or domestic OA benchmarking, read docs/product-design-rules.md and references/visual-qa.md. Mobile page work must treat docs/product-design-rules.md as the source of truth for the unified mobile shell, icon grid, card lists, deep Push pages, sticky actions, safe-area, and cross-viewport matrix. 移动页必须先对齐该设计事实源，再进入实现或验证。
• For approval workflow, roles, self-approval, notification, deeplink, reminder, or escalation work, read docs/需求-统一审批中心规约.md.
• For reimbursement, invoice, OCR, duplicate invoice, or attachment work, read docs/reimbursement-invoice-rules.md and references/reimbursement.md.
• For local/WeCom/public trial-run, OCR runtime, Caddy, or DB drift work, read docs/trialrun-runbook.md and references/trialrun.md.
• For how this skill should evolve, read docs/agent-development-practices.md.

Natural-Language Triage

Users may assign work with a plain paragraph. Before asking follow-up questions, classify the request into defect, feature, acceptance feedback, plan, review, QA, deployment, design, or product-flow optimization.

Default behavior:

1. Extract intent, target surface, constraints, approval state, and next action.
2. Check existing assets before declaring a blocker: issues/, docs/, artifacts/, output/, scripts, Playwright tests, runbooks, and prior trial-run evidence.
3. Ask only when required by AGENTS.md or safety: missing approval for non-trivial coding, destructive data work, production config, secrets/accounts, conflicting goals, or unclear high-risk acceptance.
4. Treat a plain "确认" as approval for the immediately preceding explicit plan or Issue CSV, unless multiple candidates exist.
5. If the user asks whether a problem is real, verify first with automation, code inspection, public checks, or visual evidence before proposing broad changes.

Delivery Loop

1. Check git status --short; do not revert unrelated user changes.
2. Identify or create the current Issue CSV before non-trivial work; after R5, distinguish R6 preparation from actual trial-run execution.
3. State the implementation approach before editing code; if already approved, proceed.
4. Keep changes scoped to the current Issue.
5. Prefer existing project patterns, official SDKs, and principles from documented domestic OA/approval/mobile references; do not copy competitor flows or text directly.
6. Verify with the narrowest relevant automated tests, then expand by risk.
7. Use Playwright screenshots or visual metrics for PC/mobile/WeCom UI changes. New or changed mobile pages must join the unified responsive system and the 320/360/375/390/393/414/430px 统一视觉矩阵 rather than adding page-specific layout fixes.
8. Dedicated /mobile pages must use the shared mobile slot/card/list/sticky-action system from docs/product-design-rules.md: fixed icon/avatar/status slots, minmax(0, 1fr) copy slots, mobile-card/mobile list cards, mobile tokens, and no desktop card-std p-4 as a mobile main container.
9. Update Issue CSV statuses only after the stated Test_Method passes.
10. Commit in Chinese batches with Issue IDs.
11. 面向用户可测试的改动，最终必须明确“是否已部署”。只有部署与公网检查通过后，才能告知用户可以去企业微信或公网试运行环境测试。

Default Verification Matrix

Backend:

cd server && npm run prisma:validate
cd server && node --check src/routes/reimbursements.js
cd server && node --check src/routes/workflow.js

Frontend:

cd client && npm run typecheck
cd client && npm run build

Cross-device UI:

cd client && npx playwright test <relevant-spec> --workers=1 --reporter=list

Docs/Skill:

python3 /home/shunli/.codex/skills/plan/scripts/validate_issues_csv.py <issue.csv>
python3 /home/shunli/.codex/skills/.system/skill-creator/scripts/quick_validate.py .agents/skills/hyb-oa-delivery
git diff --check

Stop Conditions

Pause for user confirmation before:

• Resetting, rebuilding, or destructively modifying a database.
• Resolving Prisma migration drift by editing migration history.
• Changing production Caddy/systemd/remote deployment state.
• Using or exposing real secrets.
• Reverting unrelated dirty files.

Output Contract

Final responses should include:

• What changed.
• What was verified, with commands.
• 面向用户可测改动的部署状态：commit hash、公网 URL、/ready、公网前端资源/文案检查，以及用户现在是否可以测试。
• What remains blocked and why.
• Commit hashes when commits were made.

R6 and Trial-Run Defaults

• R6 can start only from a new Issue CSV that fixes users, roles, time window, rollback contact, issue log, and daily closeout rhythm.
• R6 scope defaults to reimbursement, leave, procurement, approval, Enterprise WeChat entry/notification, finance payment/export.
• Do not expand to budget, ERP, AI, full travel, or complex BPM during R6; record those as follow-up Issues.
• Enterprise WeChat personal app message is the formal approval notification channel after R5; mock and group bots are not acceptance evidence for R6 business notification.
• Approval-chain correctness can be proven by PC or automation, while Enterprise WeChat validates entry, binding,免登录, notification, deeplink, and mobile layout.
• If real-device mobile validation is paused after automation passes, record the gate as PAUSED; do not close RS6/UI6/R6 mobile blockers until representative real-device confirmation is recorded.
• Role-specific pages should use one shared OA/mobile framework and tailor summaries, entries, actions, and sensitive fields by role. Do not create unrelated UI systems for employee, approver, finance, admin, or CEO views.
• After MUD6, R6-ISSUE-001 is treated as resolved based on representative real-device confirmation; future mobile regressions should be recorded as new Issues rather than reopening the old WCM6/MME6 gate unless the same production behavior returns.
• After AP6, approval reminder, overdue reminder, and workflow productivity summary are current product facts, not open planning items. Reuse POST /api/workflow/tasks/:taskId/remind, GET /api/workflow/tasks/summary, job:workflow-overdue-reminders, existing workflow history, audit logs, notifications, and WeCom personal app delivery semantics. Do not add a parallel reminder channel, change approval status from reminders, or expand into complex BPM/SLA escalation without a new Issue.
• After AP6 and FL6, the default next implementation batch is RI6 reimbursement/invoice experience unless the user explicitly redirects. Keep existing RI6/LP6/ME6/QG6 CSV contracts instead of creating duplicate roadmap contracts.