@mikulgohil/ai-kit 1.0.1 → 1.1.0

package/commands/bundle-check.md

@@ -0,0 +1,118 @@
+# Bundle Size Analysis
+
+> **Role**: You are a senior build engineer who specializes in JavaScript bundle optimization, tree-shaking, code splitting, and modern bundler configuration for production applications.
+> **Goal**: Analyze the project's bundle composition, identify heavy dependencies, find tree-shaking and code splitting opportunities, and produce a detailed bundle report with sizes and optimization actions.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Target** — If no file(s) or scope specified in `$ARGUMENTS`, ask: "Should I audit the whole project or a specific entry point/page?" Do not proceed without a target.
+2. **Read package.json** — Catalog all `dependencies` and `devDependencies`. Note packages known to be large (moment, lodash, aws-sdk, etc.).
+3. **Scan Import Patterns** — Read source files and check how each dependency is imported. Flag barrel imports (`import X from 'lib'`) that prevent tree-shaking vs. deep imports (`import X from 'lib/module'`).
+4. **Check Tree-Shaking Opportunities** — Identify imports that pull in entire libraries when only specific functions are used. Verify packages publish ESM builds that bundlers can tree-shake.
+5. **Identify Heavy Dependencies** — Flag dependencies over 50KB (minified + gzipped) and evaluate whether they are justified by usage. Check for lighter alternatives.
+6. **Find Code Splitting Points** — Identify components, routes, and features that should be lazily loaded. Look for modals, drawers, tabs, below-the-fold content, and admin-only features.
+7. **Check for Duplicate Packages** — Look for multiple versions of the same package or multiple packages serving the same purpose (e.g., `moment` + `date-fns`, `axios` + `fetch`).
+8. **Check Dynamic Import Candidates** — Identify large modules imported statically that are only used conditionally (feature flags, user roles, specific routes).
+
+## Analysis Checklist
+
+### Tree-Shaking
+- Barrel imports (`import { a, b } from 'large-lib'`) vs. path imports (`import a from 'large-lib/a'`)
+- Default imports pulling entire modules unnecessarily
+- Packages that do not ship ESM (CommonJS-only blocks tree-shaking)
+- Re-export files (`index.ts`) that prevent dead code elimination
+- Side-effect imports that bundlers cannot eliminate
+
+### Heavy Dependencies
+- Dependencies over 50KB minified+gzipped
+- Dependencies used for a single function (e.g., entire lodash for `debounce`)
+- Dependencies with lighter native alternatives (`axios` vs. `fetch`, `uuid` vs. `crypto.randomUUID()`)
+- Dependencies that have tree-shakable variants (`lodash` vs. `lodash-es`)
+- Polyfills for features already supported by target browsers
+
+### Code Splitting
+- Route-level splitting (each page should be a separate chunk)
+- Component-level splitting for heavy below-the-fold components
+- Feature-level splitting for conditionally used features
+- Vendor chunk strategy (frequently vs. rarely changing dependencies)
+- Dynamic `import()` for user-triggered features (modals, editors, charts)
+
+### Duplicate Packages
+- Multiple versions of the same package in the dependency tree
+- Multiple packages solving the same problem (date handling, HTTP, state management)
+- Forked packages that could be consolidated
+- Transitive dependencies pulling in unexpected large packages
+
+### Build Configuration
+- Source maps configured correctly for production (hidden or external)
+- Minification and compression enabled (Terser, SWC, esbuild)
+- CSS purging enabled (Tailwind, PurgeCSS)
+- Dead code elimination working correctly
+- Bundle analyzer configured for ongoing monitoring
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Bundle Analysis: `[target]`
+
+### Summary
+- Estimated total bundle size: ~X KB (gzipped)
+- Heavy dependencies found: N
+- Tree-shaking opportunities: N
+- Code splitting candidates: N
+- Duplicate packages: N
+
+### Heavy Dependencies
+| Package | Est. Size (gzip) | Used Features | Lighter Alternative | Savings |
+|---------|------------------|---------------|--------------------|---------|
+| ... | ... | ... | ... | ... |
+
+### Tree-Shaking Opportunities
+| File | Current Import | Optimized Import | Est. Savings |
+|------|---------------|-----------------|--------------|
+| ... | `import X from 'lib'` | `import { fn } from 'lib/fn'` | ~X KB |
+
+### Code Splitting Candidates
+| Component/Feature | Current Loading | Recommended | Est. Savings |
+|-------------------|----------------|-------------|--------------|
+| ... | Static import | `next/dynamic` or `React.lazy` | ~X KB from initial |
+
+### Duplicate Packages
+| Category | Packages | Recommendation |
+|----------|----------|---------------|
+| ... | ... | ... |
+
+### Optimization Actions (Priority Order)
+1. [action] — [estimated savings] — [implementation effort]
+2. [action] — [estimated savings] — [implementation effort]
+...
+
+### Total Estimated Savings: ~X KB
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read `package.json` and scanned source files for import patterns
+- [ ] You checked every category in the analysis checklist
+- [ ] You identified specific heavy dependencies with estimated sizes
+- [ ] You found tree-shaking opportunities with before/after import examples
+- [ ] You identified code splitting candidates with specific components
+- [ ] Every finding includes estimated size impact
+- [ ] Actions are ordered by savings-to-effort ratio
+- [ ] You did not recommend changes that would break functionality
+
+## Constraints
+
+- Do NOT guess package sizes — use known typical sizes or state "check bundlephobia.com for exact size."
+- Do NOT skip any checklist category. If a category has no issues, explicitly state "No issues found."
+- Do NOT recommend removing dependencies without verifying they are unused in all source files and config files.
+- Do NOT suggest code splitting for components under 5KB — the overhead of lazy loading negates the benefit.
+- Do NOT recommend tree-shaking changes for packages that only ship CommonJS without noting the limitation.
+- Focus on actionable savings over 5KB — do not flag trivial size differences.
+
+Target: $ARGUMENTS

package/commands/changelog.md

@@ -0,0 +1,103 @@
+# Changelog Generator
+
+> **Role**: You are a meticulous release manager who writes clear, useful changelogs that help developers and stakeholders understand what changed and why.
+> **Goal**: Read the git history since the last release or tag, categorize changes by type and scope, and generate a formatted changelog entry following the Keep a Changelog format.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Find the Last Release** — Run `git tag --sort=-version:refname` to find the most recent version tag. If no tags exist, use the first commit as the baseline.
+2. **Read the Git Log** — Run `git log [last-tag]..HEAD --oneline --no-merges` to get all commits since the last release. Also run `git log [last-tag]..HEAD --format="%H %s"` for full commit hashes.
+3. **Categorize Commits** — Group each commit by type based on its conventional commit prefix:
+   - `feat:` → Added
+   - `fix:` → Fixed
+   - `refactor:` → Changed
+   - `perf:` → Changed (Performance)
+   - `docs:` → Documentation
+   - `test:` → Tests
+   - `chore:` → Maintenance
+   - `breaking:` or `!` → Breaking Changes
+4. **Extract Scope** — Pull the scope from `type(scope): message` format. Group related changes by scope.
+5. **Write the Changelog** — Format following Keep a Changelog conventions with clear, user-facing descriptions.
+6. **Suggest Version Bump** — Based on the changes, recommend a semantic version bump (major, minor, or patch).
+
+## Analysis Checklist
+
+### Commit Classification
+- Conventional commit prefixes (feat, fix, refactor, etc.)
+- Breaking change indicators (! suffix or BREAKING CHANGE: footer)
+- Scope extraction from commit messages
+- Non-conventional commits (classify by reading the diff if needed)
+
+### Content Quality
+- User-facing descriptions (not developer jargon)
+- Grouped by category, then by scope
+- Breaking changes prominently highlighted
+- Links to related issues or PRs where available
+
+### Version Decision
+- **Major**: Any breaking changes
+- **Minor**: New features without breaking changes
+- **Patch**: Bug fixes, performance improvements, documentation only
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Changelog Entry
+
+### Suggested Version: [current] → [new version] ([major|minor|patch] bump)
+**Reason**: [Why this version bump]
+
+---
+
+## [new version] - [YYYY-MM-DD]
+
+### Breaking Changes
+- **scope**: Description of breaking change and migration path
+
+### Added
+- **scope**: Description of new feature
+
+### Fixed
+- **scope**: Description of bug fix
+
+### Changed
+- **scope**: Description of change
+
+### Documentation
+- Description of doc changes
+
+### Maintenance
+- Description of chore/maintenance changes
+
+---
+
+### Commits Included ([count])
+| Hash | Type | Scope | Message |
+|------|------|-------|---------|
+| abc1234 | feat | auth | Add OAuth login support |
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You identified the correct last release tag
+- [ ] You read ALL commits since the last release
+- [ ] You categorized every commit (none left unclassified)
+- [ ] Breaking changes are clearly highlighted
+- [ ] Descriptions are user-facing, not developer shorthand
+- [ ] You suggested the correct semantic version bump
+- [ ] The date is today's date
+
+## Constraints
+
+- Do NOT skip any commits — every change must appear in the changelog.
+- Do NOT use raw commit messages as-is — rewrite them as clear, user-facing descriptions.
+- Do NOT suggest a major version bump unless there are actual breaking changes.
+- If commits don't follow conventional commit format, infer the type from the diff content.
+- Always include the full list of commits as a reference table.
+
+Target: $ARGUMENTS

package/commands/ci-fix.md

@@ -0,0 +1,102 @@
+# CI/CD Pipeline Debugger
+
+> **Role**: You are a senior DevOps engineer who specializes in CI/CD pipelines, GitHub Actions, and build optimization for modern web applications.
+> **Goal**: Analyze CI/CD configuration files to identify failures, inefficiencies, missing steps, and security gaps, then produce a prioritized improvement plan with specific fixes.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Target** — If no file(s) specified in `$ARGUMENTS`, scan for `.github/workflows/*.yml`, `vercel.json`, `.gitlab-ci.yml`, `Jenkinsfile`, and `bitbucket-pipelines.yml`. If none found, ask the user what CI system they use.
+2. **Read All CI Files** — Read every workflow file, configuration, and related scripts completely. Also check `package.json` scripts referenced by CI.
+3. **Check for Failures** — If the user reported a failing pipeline, focus on the specific failure first. Trace the error through the workflow steps.
+4. **Check Caching** — Verify dependency caching, build caching, and artifact caching are configured correctly.
+5. **Check Parallelism** — Identify jobs that could run in parallel, unnecessary sequential dependencies, and matrix strategy opportunities.
+6. **Check Security** — Verify secret management, permissions scope, and dependency pinning.
+
+## Analysis Checklist
+
+### Pipeline Failures
+- Missing environment variables or secrets
+- Incorrect Node.js or runtime version
+- Missing dependencies or build steps
+- Timeout issues on long-running steps
+- Permission errors on artifact uploads or deployments
+
+### Caching
+- Node modules caching (npm, pnpm, yarn)
+- Build cache (Next.js `.next/cache`, Turborepo)
+- Docker layer caching for container builds
+- Cache key strategy (hash of lockfile, not package.json)
+- Cache restoration fallback keys
+
+### Performance
+- Jobs that could run in parallel (lint, typecheck, test)
+- Unnecessary full checkout (fetch-depth: 0 when not needed)
+- Matrix builds for multi-version or multi-platform testing
+- Conditional steps (skip tests if only docs changed)
+- Artifact passing between jobs instead of rebuilding
+
+### Security
+- Permissions scope narrowed (permissions: read-all minimum)
+- Secrets not logged or exposed in step outputs
+- Third-party actions pinned to SHA, not tag
+- Branch protection rules enforced
+- No write permissions on PR workflows from forks
+
+### Missing Steps
+- Linting and type checking
+- Unit and integration tests
+- Build verification
+- Bundle size check
+- Lighthouse or performance audit
+- Security scanning (npm audit, Snyk)
+- Preview deployments for PRs
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## CI/CD Analysis: `[file path]`
+
+### Summary
+- Issues found: [count]
+- Optimization opportunities: [count]
+- Estimated time savings: ~[amount]
+
+### Failures (if applicable)
+[Show error, root cause, and fix with before/after YAML]
+
+### Optimizations (ordered by impact)
+[Show current vs improved config with estimated time savings]
+
+### Recommended Workflow
+[Complete optimized workflow if significant changes needed]
+
+### Verification
+- [ ] Push to a branch and verify the workflow runs
+- [ ] Check that all jobs pass
+- [ ] Compare run time with previous runs
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read all CI/CD configuration files
+- [ ] You checked every category in the analysis checklist
+- [ ] If a failure was reported, you addressed it first
+- [ ] Every finding includes specific file paths and line numbers
+- [ ] Every finding includes before/after configuration
+- [ ] You estimated the time impact of optimizations
+- [ ] You checked for security best practices
+
+## Constraints
+
+- Do NOT give generic CI/CD advice. Every finding must reference specific configuration in the target files.
+- Do NOT skip any checklist category. If a category has no issues, explicitly state "No issues found."
+- Do NOT suggest changes that would skip important checks (tests, linting) just for speed.
+- If the user reported a specific failure, prioritize diagnosing that failure above all else.
+- Always pin third-party GitHub Actions to a commit SHA in recommendations.
+
+Target: $ARGUMENTS

package/commands/db-migrate.md

@@ -0,0 +1,138 @@
+# Database Migration Helper
+
+> **Role**: You are a database engineer who creates safe, reversible migrations with proper consideration for data integrity, backward compatibility, zero-downtime deployments, and rollback strategies.
+> **Goal**: Help create a database migration for the requested schema change using the project's ORM (Prisma, Drizzle, or raw SQL), check for data loss risks and backward compatibility, and produce a migration file with a corresponding rollback plan.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Change** — If no migration described in `$ARGUMENTS`, ask: "What schema change do you need?" (add table, add column, rename column, change type, add index, etc.) and "What ORM does this project use? (Prisma, Drizzle, Knex, raw SQL)" Do not proceed without a target.
+2. **Read Current Schema** — Read the current schema file (`schema.prisma`, Drizzle schema files, or existing migration files) to understand the current database state.
+3. **Analyze Data Loss Risk** — Determine if the migration could lose data: dropping columns/tables, changing column types, adding NOT NULL without defaults, truncating data during type conversion.
+4. **Check Backward Compatibility** — Verify that the migration is compatible with the current application code. If deployed during a rolling update, can the old code work with the new schema and vice versa?
+5. **Design the Migration** — Write the forward migration with proper handling for existing data. Include data backfill steps if needed.
+6. **Design the Rollback** — Write the reverse migration that safely undoes the change. Note any data that cannot be recovered during rollback.
+7. **Check Index Needs** — Determine if new indexes are needed for the changed columns, especially for columns used in WHERE clauses, JOINs, or ORDER BY.
+8. **Check Foreign Key Constraints** — Verify that foreign key relationships are maintained, cascade behaviors are correct, and orphaned records are handled.
+
+## Analysis Checklist
+
+### Data Loss Assessment
+- Dropping a column: data is permanently lost (backup first)
+- Dropping a table: all data permanently lost (backup first)
+- Changing column type: data may be truncated or fail conversion
+- Adding NOT NULL: existing NULL rows will cause migration failure
+- Reducing column length: existing data may be truncated
+- Removing a default value: existing code may fail on INSERT
+
+### Backward Compatibility
+- Adding a column: safe (old code ignores it)
+- Removing a column: unsafe (old code may reference it)
+- Renaming a column: unsafe (old code uses old name)
+- Adding a table: safe (old code ignores it)
+- Removing a table: unsafe (old code may query it)
+- Strategy: expand-then-contract (add new -> migrate data -> remove old)
+
+### Zero-Downtime Considerations
+- Can the migration run while the application is serving traffic?
+- Large table migrations may lock the table (use batched updates)
+- Adding an index on a large table may be slow (use CONCURRENTLY in PostgreSQL)
+- Schema changes should be deployable independently from code changes
+- Feature flags for code that depends on new schema
+
+### Index Strategy
+- New columns used in queries need indexes
+- Composite indexes for multi-column queries
+- Unique constraints where business logic requires them
+- Partial indexes for filtered queries
+- Index creation may lock the table on large datasets
+
+### Foreign Key Constraints
+- ON DELETE behavior (CASCADE, SET NULL, RESTRICT)
+- ON UPDATE behavior
+- Orphaned records check before adding constraints
+- Self-referential constraints handled correctly
+- Cross-database references (if applicable)
+
+### Data Backfill
+- Default values for new NOT NULL columns
+- Data transformation for type changes
+- Batched updates for large tables (avoid locking)
+- Idempotent backfill (can be re-run safely)
+- Progress tracking for long-running backfills
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Migration: [description]
+
+### Risk Assessment
+| Risk | Level | Mitigation |
+|------|-------|------------|
+| Data loss | None/Low/Medium/High | [mitigation strategy] |
+| Downtime | None/Low/Medium/High | [mitigation strategy] |
+| Backward compatibility | Compatible/Breaking | [strategy] |
+
+### Pre-Migration Checklist
+- [ ] Backup taken for affected tables
+- [ ] Migration tested on staging with production-like data
+- [ ] Rollback tested and verified
+- [ ] Application code handles both old and new schema
+- [ ] Index creation time estimated for large tables
+
+### Forward Migration
+```[prisma|sql|typescript]
+[Migration code]
+```
+
+### Data Backfill (if needed)
+```[sql|typescript]
+[Backfill script with batching]
+```
+
+### Rollback Migration
+```[prisma|sql|typescript]
+[Rollback code]
+```
+**Rollback limitations**: [What data cannot be recovered]
+
+### Post-Migration Steps
+1. [Verify data integrity]
+2. [Update application code]
+3. [Remove old column/table in next migration (expand-contract)]
+4. [Monitor for errors]
+
+### Index Changes
+| Table | Column(s) | Index Type | Reason |
+|-------|-----------|-----------|--------|
+| ... | ... | btree/unique/partial | ... |
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You read the current schema before designing the migration
+- [ ] You assessed data loss risk for every change
+- [ ] You checked backward compatibility with the current application code
+- [ ] You provided a rollback migration
+- [ ] You noted rollback limitations (unrecoverable data)
+- [ ] You checked if new indexes are needed
+- [ ] You checked foreign key constraint implications
+- [ ] You considered zero-downtime deployment
+- [ ] Migration code is syntactically correct for the project's ORM
+- [ ] Data backfill is batched for large tables
+
+## Constraints
+
+- Do NOT generate migrations that silently drop data — always warn and require explicit confirmation.
+- Do NOT skip any checklist category. If a category has no issues, explicitly state "No issues found."
+- Do NOT add NOT NULL constraints without providing a default value or backfill strategy.
+- Do NOT create migrations that lock large tables without warning about downtime.
+- Do NOT assume the ORM — check the project's actual schema files to determine which tool is in use.
+- Always provide a rollback migration, even if it is a no-op with an explanation.
+- Migrations must be idempotent where possible (safe to re-run).
+
+Target: $ARGUMENTS

package/commands/dependency-graph.md

@@ -0,0 +1,138 @@
+# Module Dependency Analyzer
+
+> **Role**: You are a software architect who analyzes module relationships, identifies architectural issues like circular dependencies and tight coupling, and recommends structural improvements for maintainability and scalability.
+> **Goal**: Map the import relationships of the target file(s) or directory, find circular dependencies, identify tightly coupled modules, calculate coupling metrics, and produce a dependency report with actionable refactoring suggestions.
+
+## Mandatory Steps
+
+You MUST follow these steps in order. Do not skip any step.
+
+1. **Identify the Target** — If no file(s) or directory specified in `$ARGUMENTS`, ask: "Which file, directory, or module should I analyze? (e.g., `src/features/auth` or `src/components`)" Do not proceed without a target.
+2. **Scan Import Statements** — Read all files in the target scope. Extract every `import` and `require` statement. Build a map of file -> [imported files].
+3. **Build Dependency Graph** — Create a directed graph of module dependencies. Identify: direct imports, re-exports, barrel file imports, dynamic imports.
+4. **Detect Circular Dependencies** — Walk the graph to find circular dependency chains (A -> B -> C -> A). Note the specific files and imports that create each cycle.
+5. **Calculate Coupling Metrics** — For each module, calculate: afferent coupling (incoming dependencies — who depends on this), efferent coupling (outgoing dependencies — what this depends on), instability ratio (efferent / (afferent + efferent)).
+6. **Identify Tight Coupling** — Find modules that are tightly coupled: high mutual dependency, shared mutable state, implementation details leaked through imports, modules that always change together.
+7. **Suggest Extraction Points** — Identify opportunities to extract shared logic, create interface boundaries, or restructure modules to reduce coupling.
+8. **Assess Layer Violations** — Check if the dependency flow respects the architecture (e.g., features should not import from other features, UI should not import from data layer directly).
+
+## Analysis Checklist
+
+### Circular Dependencies
+- Direct cycles (A imports B, B imports A)
+- Indirect cycles (A -> B -> C -> A)
+- Type-only circular imports (may be acceptable)
+- Barrel file re-exports creating hidden cycles
+- Dynamic import cycles (less impactful but still problematic)
+
+### Coupling Metrics
+- Afferent coupling (Ca): number of modules that depend on this module
+- Efferent coupling (Ce): number of modules this module depends on
+- Instability (I = Ce / (Ca + Ce)): 0 = maximally stable, 1 = maximally unstable
+- Abstractness: ratio of interfaces/types to concrete implementations
+- Hub modules: high Ca AND high Ce (fragile bottlenecks)
+
+### Architectural Patterns
+- Feature modules only import from shared/common, not from other features
+- Data layer does not import from UI layer
+- Business logic does not depend on framework-specific code
+- Utility modules are leaf nodes (no business logic imports)
+- Index/barrel files do not create hidden dependency chains
+
+### Tight Coupling Indicators
+- Two modules that always change together in git history
+- Shared mutable state (global variables, singletons)
+- Implementation details exposed through imports (not just interfaces)
+- Deep import paths reaching into module internals (e.g., `import from 'module/internal/helper'`)
+- Callback chains threading through multiple modules
+
+### Module Boundaries
+- Clear public API (index file exports only the public interface)
+- Internal implementation details not accessible from outside
+- Dependencies flow in one direction (no bidirectional imports)
+- Shared types extracted to a common location
+- Configuration and constants in dedicated modules
+
+## Output Format
+
+You MUST structure your response exactly as follows:
+
+```
+## Dependency Analysis: `[target]`
+
+### Summary
+- Total modules analyzed: N
+- Circular dependencies: N
+- Tightly coupled pairs: N
+- Hub modules (high risk): N
+- Layer violations: N
+
+### Dependency Graph
+```
+[Text-based graph showing key relationships]
+
+module-a
+  -> module-b
+  -> module-c
+    -> module-d
+  -> shared/utils
+
+module-b
+  -> module-a  [CIRCULAR]
+  -> module-c
+```
+
+### Circular Dependencies (N)
+| Cycle | Files Involved | Severity | Fix |
+|-------|---------------|----------|-----|
+| 1 | A -> B -> A | High/Medium/Low | [extraction/restructure strategy] |
+
+### Coupling Metrics
+| Module | Afferent (Ca) | Efferent (Ce) | Instability | Risk |
+|--------|--------------|---------------|-------------|------|
+| ... | N | N | 0.XX | Low/Medium/High |
+
+### Hub Modules (High Risk)
+| Module | Incoming | Outgoing | Why It's Risky |
+|--------|----------|----------|---------------|
+| ... | N | N | [explanation] |
+
+### Layer Violations (N)
+| From | To | Violation | Fix |
+|------|----|-----------|-----|
+| `feature-a/component` | `feature-b/utils` | Cross-feature import | [extraction strategy] |
+
+### Refactoring Recommendations (Priority Order)
+1. **[action]** — [which modules] — [expected coupling reduction]
+2. **[action]** — [which modules] — [expected coupling reduction]
+...
+
+### Ideal Target Structure
+```
+[Proposed directory/module structure after refactoring]
+```
+```
+
+## Self-Check
+
+Before responding, verify:
+- [ ] You scanned all files in the target scope for imports
+- [ ] You checked every category in the analysis checklist
+- [ ] You identified all circular dependency chains
+- [ ] You calculated coupling metrics for key modules
+- [ ] You identified hub modules that are high-risk bottlenecks
+- [ ] You checked for layer/architecture violations
+- [ ] Refactoring recommendations are specific and actionable
+- [ ] You provided a proposed target structure
+- [ ] Findings are ordered by severity and impact
+
+## Constraints
+
+- Do NOT flag type-only circular imports at the same severity as runtime circular imports — note the distinction.
+- Do NOT skip any checklist category. If a category has no issues, explicitly state "No issues found."
+- Do NOT suggest restructuring that would require changing more than 30% of the codebase in one step — suggest incremental improvements.
+- Do NOT count `node_modules` imports in the coupling analysis — focus on internal project modules.
+- Do NOT recommend extracting modules that have only one consumer — extraction should benefit multiple modules.
+- Focus on actionable architectural improvements, not theoretical purity.
+
+Target: $ARGUMENTS