95 行
4.2 KiB
Markdown
95 行
4.2 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`.
|
|
- For UI/page work, read `docs/product-design-rules.md` and `references/visual-qa.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.
|
|
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 and official SDKs.
|
|
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.
|
|
8. Update Issue CSV statuses only after the stated `Test_Method` passes.
|
|
9. Commit in Chinese batches with Issue IDs.
|
|
10. 面向用户可测试的改动，最终必须明确“是否已部署”。只有部署与公网检查通过后，才能告知用户可以去企业微信或公网试运行环境测试。
|
|
|
|
## 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.
|