Menu
Use this skill when asked to update versions, prepare a release, sync changelogs, rebuild README files, fix README drift, validate package dependencies, or handle prerelease bumps in ISpect, including "release prep", "bump dev version", "sync docs", "README check failed", or "version mismatch".
Create a well-structured git commit for staged or unstaged changes — analyze the diff, match the project's existing commit style, write a clear message, and create the commit. Use this skill when the user asks to commit, save changes, check in code, write a commit message, prepare changes for push, or wrap up a piece of work — even when they don't say "commit" explicitly (e.g. "let's save this", "ship it", "сохрани изменения").
Use this skill when modifying ISpect network, WebSocket, database, BLoC, or trace logging behavior, including requests like "add capture", "fix redaction", "interceptor logs wrong data", "DB trace broken", "request IDs missing", or "payload should not leak". It preserves correlation IDs, redaction defaults, and package boundaries.
Scaffold a new database or storage interceptor in `packages/ispectify_db/example` using the shared ISpect DB tracing API. Use when adding support for a new backend such as Hive, SharedPreferences, Drift, Isar, Realm, Sembast, ObjectBox, Firestore, secure storage, or another storage driver.
Use this skill when asked to test, verify, validate, run checks, fix analyzer failures, or confirm CI readiness for an ISpect package, including vague requests like "check this package", "проверь тесты", "why CI fails", or "make it green". It chooses the correct Dart vs Flutter commands and adds README/version checks only when relevant.
Write or update CHANGELOG.md entries following the project's established style. Use when adding features, fixing bugs, or making any changes that need changelog documentation. Trigger on "/changelog" or when the user asks to update the changelog.
Scaffold a new network interceptor package (e.g. Chopper, Retrofit) using the shared ispectify base. Trigger on "/new-network-package" or when the user asks to add support for a new HTTP client.
| name | release-docs-version-sync |
| description | Use this skill when asked to update versions, prepare a release, sync changelogs, rebuild README files, fix README drift, validate package dependencies, or handle prerelease bumps in ISpect, including "release prep", "bump dev version", "sync docs", "README check failed", or "version mismatch". |
Use the repository scripts for version, changelog, README, and publish-preflight workflows.
version.config to identify the current VERSION../bash/update_versions.sh --dry-run./bash/release_prep.sh./bash/release_prep.sh --skip-bump./bash/release_prep.sh --carry-changelogCHANGELOG.md, then run:
./bash/update_changelog.sh --version <VERSION>docs/readme/**, then run:
./bash/build_readme.sh./bash/check_version_sync.sh./bash/check_dependencies.sh./bash/build_readme.sh --check./bash/publish.sh --dry-runversion.config is the source of truth; do not hand-edit package version: fields or internal ^<VERSION> constraints.docs/readme/**; direct README edits will be overwritten../bash/publish.sh --auto performs a real publish and should only run after an explicit user request.dependency_overrides for local package paths are intentional in this monorepo.