plugins/flow/skills/change-classification/SKILL.md
Classify code changes as in-context, uncertain, or out-of-context using primary signals (branch diff, issue keywords, active tasks), secondary signals (directory proximity, test naming), and red-flag patterns (secrets, large binaries). Use when preparing commits or reviewing staged changes. This skill MUST be consulted because committing without classification is how out-of-context changes, secrets, and unintended modifications reach the repository.
npx skillsauth add synaptiai/synapti-marketplace change-classificationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Domain skill for analyzing and classifying code changes before committing.
CLASSIFY BEFORE COMMITTING. Every changed file gets a classification. Unclassified files do not get staged.
Committing without classification is how out-of-context changes, secrets, and unintended modifications reach the repository.
For each changed file, evaluate signals to classify as: in-context, uncertain, or out-of-context.
| Signal | Classification | Detection |
|--------|---------------|-----------|
| File already in branch diff | in-context | git diff --name-only $DEFAULT_BRANCH...HEAD includes file |
| File matches issue keywords | in-context | File path contains words from issue title/body |
| File in active task | in-context | File path matches TaskList task descriptions |
| File matches task directory | in-context | Same top-level directory as task-related files |
| Signal | Classification | Detection |
|--------|---------------|-----------|
| Same directory as other changes | lean in-context | Sibling of already-classified in-context file |
| Test file for changed module | lean in-context | Naming convention match (e.g., foo.rb → foo_test.rb) |
| Config in project root | uncertain | Changes to dotfiles, config, package manifests |
| Unrelated directory | out-of-context | No connection to issue or tasks |
These always get flagged regardless of context:
| Pattern | Action |
|---------|--------|
| .env*, credentials*, *secret* | Block — never commit |
| *.lock, package-lock.json | Warn — verify intentional |
| Large binary files (>1MB) | Warn — verify intentional |
| Auto-generated files | Note — may need regeneration |
A file is "first touch" when:
git log $DEFAULT_BRANCH..HEAD -- file is empty)First-touch files get extra review attention.
Display classification as a table (finding-first pattern):
| File | Classification | Signal | Notes |
|------|---------------|--------|-------|
| src/auth/login.rb | in-context | matches issue keywords | |
| src/utils/format.rb | out-of-context | unrelated directory | first-touch |
| .env.example | RED FLAG | secret pattern | NEVER COMMIT |
After classification, group in-context files into atomic commits:
Each group gets one conventional commit with an accurate message.
| Excuse | Response | |--------|----------| | "It's obviously in-context" | Then classification takes 2 seconds. Do it. | | "I only changed one file" | One file, same process. One-file commits have leaked secrets. | | "The lock file changed automatically" | Automatic changes still need classification. Verify intentional. |
This skill is invoked by:
/flow:commit — Phase 1 (classify all changes)/flow:address — After fixes (verify no out-of-context changes)/flow:pr — Pre-flight (verify committed changes match intent)See references/classification-signals.md for the complete signal reference.
tools
Validate a FlowWorkflow YAML at `plugins/flow/workflows/<id>.workflow.yaml` against `schemas/v1/workflow.schema.json` AND cross-reference the referenced skills/agents exist + every Tier 3 action is confirm-gated + no native /goal or /loop dependency is declared. Use when /flow:workflow validate is invoked, when CI runs the workflow schema gates, or when a new workflow is being authored. This skill MUST be consulted because schema validation alone catches shape errors; cross-reference validation catches the silent-correctness failures (typo'd skill name, Tier 3 escape, /goal dependency) that would otherwise ship to users.
tools
Verify UI-facing changes by running a screenshot-analyze-verify loop across configured viewports, with a browser-tool priority cascade (Playwright MCP → Chrome DevTools MCP → CLI fallback → external skill fallback) and bounded iteration. Use after build/runtime verification passes and the diff includes `.tsx`/`.jsx`/`.vue`/`.html`/`.css`/`.scss`/`.svelte` files OR the acceptance criteria mention UI/page/render/display/visual. This skill MUST be consulted because UI changes that pass build and unit tests can still ship blank pages, render-blocking console errors, or broken responsive layouts that no other verification phase catches.
data-ai
Coordinate agent teams for adversarial review (paired skeptic/verifier per facet, challenge round with disposition vocabulary, consolidated findings with confidence) or parallel implementation (task sizing 5-6 per teammate, non-overlapping files). Enforces independent analysis before shared conclusions. Reference only (`disable-model-invocation: true`); loaded only when `agentTeams: true` in settings.
development
Conduct two-stage code review: Stage 1 verifies spec compliance (criterion-to-code mapping), Stage 2 evaluates security, correctness, performance, and maintainability across 6 parallel facets with P1/P2/P3 synthesis and deduplication by file:line. Use when reviewing code changes or pull requests. This skill MUST be consulted because reviewing quality on broken logic is wasted effort, and unmet acceptance criteria must block merge.