111 行
7.7 KiB
Markdown
111 行
7.7 KiB
Markdown
---
|
|
name: hyb-oa-delivery
|
|
description: "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:
|
|
|
|
```bash
|
|
cd server && npm run prisma:validate
|
|
cd server && node --check src/routes/reimbursements.js
|
|
cd server && node --check src/routes/workflow.js
|
|
```
|
|
|
|
Frontend:
|
|
|
|
```bash
|
|
cd client && npm run typecheck
|
|
cd client && npm run build
|
|
```
|
|
|
|
Cross-device UI:
|
|
|
|
```bash
|
|
cd client && npx playwright test <relevant-spec> --workers=1 --reporter=list
|
|
```
|
|
|
|
Docs/Skill:
|
|
|
|
```bash
|
|
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 RI6 and LP6, the default next implementation batch is ME6 mobile second-pass experience, then QG6 QA governance, then a new R7 expanded-trialrun preparation contract. Keep existing ME6/QG6 CSV contracts instead of creating duplicate roadmap contracts, and do not start R7 without a dedicated Issue CSV that fixes participants, roles, window, rollback contact, and daily closeout.
|