Menu
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.
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.
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".
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 | changelog |
| description | 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. |
Write concise, user-facing changelog entries that match the project's existing style.
Code Quality — refactors, cleanup, deprecationsBehavioral Changes — defaults changed, new behaviorsSecurity — redaction, data protection, vulnerability fixesBug Fixes — resolved issuesImprovements — new features, UI enhancements, DX improvementsCI — pipeline, workflow changesTests — new or updated tests- bullet per entry, one or two lines max.- **Feature name:** Brief description.Good:
- **HTTP transaction grouping** enabled by default — correlated request/response/error logs displayed as expandable transaction cards with duration and status badges. Configurable via `ISpectViewController(groupHttpLogs:)`.
- **Search** now matches across all log fields: key, title, log level, time, message, exception, error, and additional data.
- **Desktop layout:** Resizable split view for log details, column resizing, keyboard navigation, sticky headers, and persistent split ratio.
- **Log cards:** Context menu on long press, improved action buttons with tooltips, conditional background on expand.
Bad (too detailed):
- **Request-Response correlation via `requestId`** — HTTP request, response, and error logs are now explicitly linked with a unique transaction ID generated by `RequestIdGenerator` using a monotonic counter with session prefix format `net-{session6hex}-{counter}`.
- **Dio**: `requestId` injected via `RequestOptions.extra['_ispect_rid']`, preserved through redaction using `ignoredKeys` set in `DioRequestData.toJson()`.
CHANGELOG.md to find the active version and existing sections.