菜单
Generate and update S3Mock project documentation. Use when asked to document code, update CHANGELOG.md, update README.md, update AGENTS.md files, or fix formatting, wording, or style in any existing documentation file. Also invoked at the end of the implement skill workflow.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Write, update, and fix tests in S3Mock. Use when asked to add test coverage, create test cases, fix failing tests, or verify test correctness. Covers unit tests (*Test.kt in server/), controller slice tests (@WebMvcTest), and integration tests (*IT.kt in integration-tests/ against a live Docker container).
Fix code style issues and ensure linting CI gates pass in S3Mock. Use when ktlint or Checkstyle violations are reported, when asked to fix formatting, or as a required final step after any code change. Runs ktlint for Kotlin source files and Checkstyle for Java and XML files.
Implement features, fix bugs, and modify production source code in S3Mock. Use when asked to add functionality, change behavior, or modify source files in server/, integration-tests/, or testsupport/. Not for documentation-only or test-only changes. Orchestrates lint, test, and document skills as part of the complete workflow.
Improve code readability, enforce idiomatic Kotlin conventions, and enhance documentation quality in S3Mock without changing behavior. Use when asked to clean up code, improve naming, add KDoc, or align with Kotlin/project idioms. Also invoked by the implement and test skills before adding new code to messy areas.
Review code changes in pull requests or local diffs for S3Mock. Use when asked to review a PR, inspect changes, or provide structured feedback on correctness, conventions, test quality, and documentation. Outputs findings structured as Must fix / Should fix / Nit.
| name | document |
| description | Generate and update S3Mock project documentation. Use when asked to document code, update CHANGELOG.md, update README.md, update AGENTS.md files, or fix formatting, wording, or style in any existing documentation file. Also invoked at the end of the implement skill workflow. |
Use this skill when asked to:
CHANGELOG.md for a new feature or bug fixREADME.md (operations table, configuration, usage examples)AGENTS.md (root or module) for architectural or convention changesdocs/ (KOTLIN.md, SPRING.md, TESTING.md, JAVA.md)| File | Audience | Purpose |
|---|---|---|
README.md | End users | Usage, configuration, S3 operations table |
CHANGELOG.md | End users | Version history, breaking changes |
docs/TESTING.md | Contributors / agents | Testing strategy, base classes, patterns |
docs/KOTLIN.md | Contributors / agents | Kotlin idioms, naming, anti-patterns, KDoc |
docs/SPRING.md | Contributors / agents | Spring Boot patterns, DI, exception handling |
docs/JAVA.md | Contributors / agents | Java idioms, naming, Javadoc |
AGENTS.md (root + modules) | Agents | Architecture, conventions, guardrails |
.github/CONTRIBUTING.md | Contributors | Dev setup, CLA, code reviews |
New S3 operation: Update the operations table in README.md (:x: → :white_check_mark:), add entry to CHANGELOG.md, update server/AGENTS.md if new patterns were introduced.
New API surface / new port: Add a dedicated section in README.md covering: how to enable (Spring profile), ports (HTTP/HTTPS), configuration variables, and a supported-operations table. Also add to the Docker examples, Configuration table, and Spring Profiles table. Add entry to CHANGELOG.md. Update server/AGENTS.md if new architectural patterns were introduced.
Configuration change: Update configuration table in README.md, update the Configuration section in AGENTS.md, add entry to CHANGELOG.md.
Architecture change: Update the relevant module's AGENTS.md, update root AGENTS.md if cross-cutting, add entry to CHANGELOG.md.
Spring Boot pattern change: Update docs/SPRING.md and server/AGENTS.md if it affects how controllers, services, or stores are structured.
Kotlin/Java style change: Update docs/KOTLIN.md or docs/JAVA.md; update root AGENTS.md DO/DON'T if a new guardrail is introduced.
Group changes under the current version heading. If the heading doesn't exist yet, add it under # CURRENT - 5.x - THIS VERSION IS UNDER ACTIVE DEVELOPMENT. Follow the existing bullet structure:
* Features and fixes
* Refactorings
* Version updates (deliverable dependencies)
* Version updates (build dependencies)
Use clear, user-facing language. Note breaking changes explicitly. Reference GitHub issues/PRs where relevant.
AGENTS.md (root + relevant module).CHANGELOG.md updated if the change is user-facingREADME.md operations or configuration table updated if applicableAGENTS.md updated if architecture or conventions changedAGENTS.md — authoritative source for architecture and conventionsAGENTS.mdCHANGELOG.md — existing entries to match formatREADME.md — operations table and configuration table to update