Create, reconstruct, synchronize, or automatically record durable repository documentation and curated implementation memory from current code, configuration, tests, accepted user intent, existing docs, and Git history. Use for project context, architecture, decisions, implementation change records, timelines, build and distribution guides, maintenance handoffs, or cross-session continuity. After verified material implementation work, record the outcome by default unless the user explicitly opts out. Do not use for incidental comments, raw prompt archiving, or non-material edits.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Build documentation that lets a future maintainer recover the project's current shape, important decisions, and safe operating procedures without relying on chat history. Documentation is a maintained view of evidence, not a second source of invented truth.
docs/ system where none exists.Do not ask the user to choose when the request already determines the mode.
After verified material changes to code, configuration, schema, API behavior, security controls, build behavior, or user-visible functionality, create or update an implementation record unless the user explicitly asks not to create or update documentation.
Read references/automatic-change-recording.md whenever another implementation skill completes material work. It defines the default path, minimum bootstrap, entry schema, opt-out behavior, and exclusions.
Read references/curated-implementation-memory.md when user requirements, acceptance criteria, implementation decisions, or maintenance constraints should remain useful across sessions. Curate the accepted outcome and verified execution; never store raw prompts, chat transcripts, or hidden reasoning as project memory.
Do not wait for a separate documentation request and do not ask for routine permission. Treat an explicit opt-out such as “skip docs,” “do not document this,” or an equivalent project instruction as authoritative. An opt-out for one task is not a permanent preference unless the user says so.
Inspect the relevant code paths, configuration, tests, scripts, deployment files, existing documentation, and repository instructions. Use Git history when historical sequence or releases are in scope.
Inspect repository status and the task's actual diff before attributing a change. In a dirty worktree, preserve unrelated user edits and do not describe pre-existing changes as outcomes of the current task.
Classify statements as:
Never turn a commit message, stale document, unused file, or plausible architecture into a current fact without corroboration.
Read references/documentation-map.md when bootstrapping or reorganizing docs/. Always create an index and the three core documents when the user requests the full continuity system. Add specialized sections only when the repository has corresponding evidence and maintenance value.
Automatic change recording is a smaller bootstrap: when no documentation system exists, create only docs/README.md, docs/implementation-timeline/README.md, a stable feature-domain subfolder with its index, and the first verified change record. Do not fabricate the three core documents merely to satisfy the recording default.
Do not create empty directories, placeholder guides, or one file per imagined subsystem. A smaller linked set that stays accurate is better than an impressive tree nobody can trust.
Read references/core-files.md when writing the documentation index, project context, architecture, or decisions ledger.
Read references/history-and-handoff.md when using commits, releases, migrations, or earlier documentation to build timelines and handoffs.
Summarize change by outcome and architectural consequence. Do not dump every commit, treat commit order as causality, or claim a feature shipped because a branch once contained related code. Link facts to commits or tags when stable identifiers are available.
After a change, update only documents whose claims became incomplete or false. Preserve useful history and append decisions when the repository follows an append-oriented record. Replace current-state descriptions when reality changed; do not retain both versions as if both remain active.
If documentation conflicts with working code or configuration:
Recording and synchronization are related but distinct. A material implementation receives a concise timeline record by default. Update current-state architecture, decisions, guides, or build documents only when their claims or procedures actually changed.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Review or implement interface accessibility for semantics, keyboard operation, focus, contrast, status communication, zoom, and assistive technology. Use when accessibility is explicitly requested, required by the product contract, or a changed interaction creates substantial accessibility risk. Do not activate for every visual edit or use it as a generic design audit.
The English summary is being prepared. Showing the original description.
Implement, harden, or review defensive security controls for REST APIs, including authentication and authorization boundaries, validation, rate limiting, abuse prevention, resource limits, SSRF defenses, safe errors, logging, and security tests. Use when API security, endpoint hardening, threat review, rate limiting, token handling, or sensitive business-flow protection is an explicit concern. Do not use for ordinary endpoint logic without meaningful security scope or for offensive exploitation.
The English summary is being prepared. Showing the original description.
Design, implement, or assess project structure, module ownership, dependency boundaries, and safe file or folder organization. Use when project architecture, feature placement, separation of responsibilities, or architectural refactoring is a primary concern, including new framework projects. For a read-only assessment, do not modify files unless the user also requests changes; do not activate merely because ordinary feature work adds a file.
The English summary is being prepared. Showing the original description.
Review a code change, diff, commit, branch, or pull request for actionable defects, regressions, security risks, compatibility breaks, and missing verification. Use when code review is the primary requested outcome. Keep the review read-only unless the user explicitly asks to implement fixes; do not use as a substitute for implementation or a specialized visual audit.
The English summary is being prepared. Showing the original description.
Add, revise, or remove source-code comments while preserving executable behavior. Use for comment-only cleanup, documentation comments, TODO quality, and reducing narration. Do not use when the requested change modifies logic.
The English summary is being prepared. Showing the original description.
Write or revise user-facing product and marketing copy with a specific voice, verifiable claims, natural rhythm, and useful actions. Use for interface labels, onboarding, landing pages, help text, and product messaging. Do not use for code comments or neutral technical documentation unless tone editing is requested.
The English summary is being prepared. Showing the original description.