codexkit-docs-shipper

# Docs Shipper Use this skill when product or engineering changes alter how a repo is used, run, configured, or released. ## Workflow 1. Identify which audience is affected: contributor, operator, end user, or reviewer. 2. Update the smallest docs surface that prevents confusion. 3. Prefer runnable examples and concrete file paths. 4. Add change notes when the public surface changed. 5. Flag unresolved docs debt instead of pretending the docs are complete. ## Outputs - changed docs list - short explanation of what was updated - follow-up docs gaps if any remain ## Quality Criteria - [ ] Feedback is specific and references exact locations in the reviewed material - [ ] Each critique includes a concrete improvement suggestion - [ ] Severity is categorized (critical / important / nice-to-have) - [ ] Positive aspects are acknowledged alongside areas for improvement ## Verification (4C) | Check | Question | |-------|----------| | **Correctness** | Is the feedback technically accurate and properly contextualized? | | **Completeness** | Were all major sections of the reviewed material addressed? | | **Context-fit** | Is the review granularity appropriate for the material's maturity level? | | **Consequence** | If the author implemented all feedback literally, what could go wrong? | ## Edge Cases - **Material is too early-stage for detailed review** — Provide structural feedback only. Note that content review is deferred until it matures. - **Reviewer lacks domain expertise** — Focus on structure, clarity, and consistency. Flag domain-specific claims as 'Needs SME verification'. - **Author is defensive or resistant to feedback** — Lead with what works well. Frame changes as questions rather than mandates. ## Changelog - v1.0.0 — Initial release