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/产品设计规则.md and references/visual-qa.md. Mobile page work must treat docs/产品设计规则.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/报销发票附件规则.md and references/reimbursement.md.
• For local/WeCom/public trial-run, OCR runtime, Caddy, or DB drift work, read docs/试运行与自动化验证手册.md and references/trialrun.md.
• For how this skill should evolve, read docs/Agent开发交付实践.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/产品设计规则.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. Mobile homepage, approval, notification, and business cards must follow the display dedupe rules in docs/产品设计规则.md: one pending/progress summary per page, notifications as event stream with direct target links, bottom badges as counts only, and one visible business identifier/status per card or row.
10. Update Issue CSV statuses only after the stated Test_Method passes.
11. Commit in Chinese batches with Issue IDs.
12. 面向用户可测试的改动，最终必须明确“是否已部署”。只有部署与公网检查通过后，才能告知用户可以去企业微信或公网试运行环境测试。

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 DG7/MRF7, mobile approval is an "approval and progress" entry: employees may use it for submitted-item progress, while approvers use it for assigned tasks. Do not reintroduce disabled approval tabs for ordinary employees, duplicated home pending lists, or notification cards that only bounce users back to the notification center when a business target exists.
• After RI6, LP6, ME6 automation, QG6, MIF7/MIF7T, MIF7TD, R7/OPS7/DOC7 draft materials, R7EP automatic gates, and OPS8 remote read-only checks, treat ME6-3 as closed by representative iPhone 12, iPhone 14, and Redmi K60 Enterprise WeChat feedback. R7EP may conclude that the project can enter R7E human confirmation, but R7E-* true execution rows must stay TODO until the user confirms participants, roles, window, rollback contact, issue owner, daily closeout, and pause/rollback decision maker. Do not start real R7 from documentation or automation gates alone; future mobile or real-device regressions must be recorded as new Issues such as UX8/R7E follow-ups.
• After DCL7, document governance must start from docs/文档索引.md and docs/文档事实源状态矩阵.md. Use Chinese-first current docs. Confirmed obsolete docs may be physically removed from the current tree and restored from git history when needed; do not create docs/archive/ just to move clutter. Do not rewrite old Issue CSV snapshots when cleaning current docs.