| name | code-documentation |
| description | Update Dart documentation for completeness and helpfulness in FlexSeedScheme. Use when the user asks for documentation, and when creating or updating public API, comments, README, or CHANGELOG. |
Code Documentation
Document intent and purpose so humans and agents can maintain this package. The user may request a scope: file(s), folder(s), a selected change, or uncommitted work.
Never document the entire repository in one pass.
Existing comments
- Do not remove or shorten comments unless the user asks, or the comment is stale, wrong, or refers to removed APIs.
- When you touch a comment, leave it more accurate than before.
- Keep Google Apache-2.0 license headers on MCU files. Do not rewrite MCU comments into a new voice unless they are factually wrong.
Completeness
- Public classes, enums, constructors, and members in
lib/ need /// dartdoc. public_member_api_docs is enforced on the package; the example app turns it off.
- Private helpers use
//. Terse is fine when the code is obvious; add more when the logic is not (HCT, chroma caps, tone mapping, contrast curves).
- Explain purpose, defaults, and how parameters interact. Usage tutorials belong in README and .agents/skills/flex-seed-scheme/SKILL.md, not in every member doc.
Dartdoc references
// comments: Do not use [Type] or [member]. Dartdoc does not resolve them there. Use ASCII backticks./// comments: Use [Type] / [member] only when the symbol is in dartdoc scope (same rules as analyzer unresolved-identifier warnings). If it is not in scope, use backticks. Do not add imports only to bring a symbol into doc scope.
