Use this skill to create developer-facing Markdown API documentation for 泛微 OA E10 OpenAPI integrations. Focus on external system developers: how to authenticate, which endpoint to call, what parameters to send, how workflow form fields map to request payloads, and how to handle responses.
## Hard boundary: read-only operation
Never modify the E10 system while using this skill.
Allowed actions:
- Navigate pages, view content, take screenshots, and extract rendered text.
- Use authenticated browser-session read calls to retrieve workflow, form, and field metadata.
- Inspect E10 OpenAPI documentation pages.
- Generate documentation outside the E10 system.
Forbidden actions:
- Create, update, delete, publish, enable, disable, submit, approve, or reject any workflow, form, system object, or business data.
- Call any endpoint or UI action that changes E10 configuration or data.
- Save credentials to memory, files, logs, examples, or final documentation.
If an endpoint or UI action might write data, stop and ask the user before continuing.
## Required inputs
Before accessing E10, collect or confirm:
- E10 base URL, expressed as `https://<E10_BASE>` in final documentation.
- Login account and password for the current task only.
- Target documentation type: general E10 OpenAPI documentation or workflow-instance API documentation.
- Target workflow name when documenting workflow instance creation.
- Desired output location and filename if the user cares; otherwise save as `E10_<workflow-or-api-name>_API.md`.
Do not reuse cached credentials. Do not expose real IPs, real credentials, real tokens, internal IDs, database names, or internal API paths in the final external-facing document unless the user explicitly requests an internal-only diagnostic note.
## Workflow decision tree
1. Determine whether the request is for a general E10 API or for creating a workflow instance.
2. If the task needs live E10 inspection, read `references/login-and-browser-harness.md` and log in through an isolated browser session.
3. For OpenAPI documentation pages, read `references/openapi-doc-navigation.md` and extract rendered documentation text.
4. For workflow-instance documentation, read `references/workflow-field-discovery.md` and use the internal read-only API chain described in `references/internal-apis.md` to discover workflow, form, and field metadata.
5. If the API involves attachments, read the file-upload section in `references/openapi-doc-navigation.md` and include an upload prerequisite section.
6. Generate the final Markdown using `assets/templates/e10-api-doc-template.md`.
7. Validate the output with `references/output-document-standard.md` and `evals/test-cases.md` before presenting or saving it.
8. If live access fails, provide the missing inputs or evidence needed instead of inventing field definitions, endpoint details, owners, dates, IDs, or examples.
## External documentation rules
The final output must be written for external integration developers, not E10 administrators.
Always include:
- OAuth2 `code` to `access_token` flow.
- A clear statement that `access_token` is passed as a request-body parameter, not as an HTTP Bearer header.
- Identity mapping guidance: `userType`, `deptType`, and field-level `dataOptions` for employee, department, subcompany, file, and related object fields.
