doc-view-contract-design

Use when defining or reviewing Doc View behavior contracts before changing PSI parsing, DTOs, Markdown output, uploads, exports, settings, UI-visible behavior, or IntelliJ compatibility.

Jump to install

Repository: liuzhihang/doc-view
Last source activity: July 11, 2026 at 14:02
Detected SKILL.md language: English
Stars: 207
Forks: 53

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/liuzhihang/doc-view --skill doc-view-contract-design

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

Doc View Contract Design

Use this skill before implementation work that changes user-visible or integration-visible behavior. OpenSpec owns proposal/design/spec/tasks; this skill supplies Doc View domain checks.

Read First

AGENTS.md

docs/contract-design.md

The active change status and every contextFiles path returned by openspec instructions apply --change <name> --json

docs/architecture.md when package, service, DTO, settings, extension, or data flow boundaries are involved

docs/performance-guide.md when PSI, UI, rendering, export, upload, recursion, or cache performance can change

docs/intellij-compatibility.md when IntelliJ API, Gradle platform, descriptor, extension, or compatibility behavior is involved

Steps

Identify the observable area: Spring/Feign/Dubbo PSI, DTO, Markdown, export, upload, settings, UI, performance, or compatibility.

Confirm an apply-ready OpenSpec change exists for behavior work; write normative requirements to its specs/**, not docs/contracts/**.

Define Java/settings/platform/external-service inputs and assumptions.

Define expected DocView/Body/Param/Header, Markdown, payload, UI, notification, or compatibility outputs.

Define unsupported, fallback, sensitive-data, and explicitly unchanged cases.

Choose direct validation: PSI fixture, DTO assertion, golden Markdown, payload check, runIde, or Plugin Verifier.

Review recursion, user-template, IntelliJ lifecycle, EDT, and secret-handling risks.

Guardrails

Do not change Java while only designing the contract.

Do not create a parallel contract under docs/contracts/**; OpenSpec specs are normative.

Do not include real tokens, production URLs, or private user code in artifacts or fixtures.

Do not make implementation details normative unless users or integrations observe them.

Keep later production implementation Java-only.