\r \r

Role\r

\r This skill owns documentation updates that must accompany code changes. It keeps module README files, architecture notes, API descriptions, and change records accurate without dumping detailed fix logs into the repository root.\r \r

When To Use\r

\r

• Use for module README updates, architecture docs, API docs, usage docs, and change records.\r
• Use for keywords such as documentation, README, architecture doc, API doc, fix note, and change record.\r
• Use when a code change alters user behavior, module usage, architecture, or interfaces.\r \r

Source Material\r

\r

• AI-ENTRY.md\r
• AI-README.md\r
• CLAUDE.md\r
• dev/ai/skills/documentation-standards/SKILL.md\r
• dev/ai/skills/weline-framework-core/SKILL.md\r \r

Responsibilities\r

\r

• Update the right documentation at the right scope.\r
• Keep fix notes in related module doc directories instead of the repository root.\r
• Reflect design and interface changes accurately and concisely.\r
• Preserve the distinction between user-facing docs, architecture docs, and API docs.\r \r

Workflow\r

\r

1. Identify whether the change affects usage, architecture, interfaces, or only internal code.\r
2. Locate the owning module doc directory, README, architecture note, or API documentation path.\r
3. Update only the documents required by the actual change.\r
4. Keep the documentation outcome-focused rather than writing long process diaries.\r
5. Cross-check claims against the final implementation and validation evidence.\r
6. Confirm any bug-fix status note is reflected in the module README where required.\r
7. Report what was updated and why.\r \r

Weline Rules\r

\r

• Do not write detailed fix reports to the repository root.\r
• Write fix reports inside the related module doc directory.\r
• Update module README after fixing bugs.\r
• Update architecture docs if the design changes.\r
• Update API docs if interfaces change.\r \r

Inputs Required\r

\r

• The implemented change and its user, architecture, or interface impact.\r
• The owning module and documentation paths.\r
• Validation evidence that supports the documentation update.\r
• Any required wording scope, such as developer-facing or user-facing.\r \r

Expected Output\r

\r

• Updated documentation in the correct repository location.\r
• A concise record of behavior, design, or interface changes.\r
• Documentation aligned with the implemented and validated result.\r \r

Validation\r

\r

• Check that documentation location matches the owning module or architecture scope.\r
• Check that README, architecture, and API updates were made when required.\r
• Check that documentation does not promise behavior not proven by implementation.\r
• Check that no detailed fix report was written into the repository root.\r \r

Constraints\r

\r

• Do not create unnecessary documents when no user or interface impact exists.\r
• Do not dump step-by-step troubleshooting logs into repository docs.\r
• Do not update root-level files when the correct location is module-local documentation.\r
• Do not leave changed interfaces undocumented.\r \r