@smartsoft001/pro-claude-plugins 0.2.0

package/plugins/flow/skills/commit/SKILL.md

@@ -0,0 +1,259 @@
+---
+name: commit
+description: Create a conventional commit message based on Linear task and staged changes. Fetches task details, analyzes changes, generates commit message, and optionally runs parallelization analysis.
+allowed-tools:
+  - Bash
+  - Read
+  - Glob
+  - Grep
+  - AskUserQuestion
+  - TaskCreate
+  - TaskUpdate
+  - TaskList
+  - TaskGet
+  - mcp__linear__get_issue
+  - mcp__linear__list_comments
+---
+
+# Commit Skill
+
+Create a conventional commit message based on Linear task and staged changes.
+
+## Usage
+
+```
+/commit [linearTaskId]
+```
+
+## Parameters
+
+- `linearTaskId` - Linear task ID (e.g., ENG-123)
+
+## Execution Checklist
+
+Execute each step in order. Do not skip any step marked as MANDATORY.
+
+- [ ] **1. Fetch Linear task** — get title, description, labels/type from MCP Linear server
+- [ ] **2. Analyze staged changes** — run `git diff --cached` to understand scope
+- [ ] **3. Verify completeness** — compare task requirements with staged changes; if incomplete, ask user whether to continue or stop
+- [ ] **4. Read commitlint config** — read `commitlint.config.js` for valid scopes and format
+- [ ] **5. Generate commit message** — draft `<type>(<scope>): <subject>` with body and `Refs: <linearTaskId>`
+- [ ] **6. Show message to user** — present commit message for approval before proceeding
+- [ ] **7. MANDATORY: Pre-commit preparation** — run `nvm use 24` then `npm run format`, stage any formatting changes
+- [ ] **8. Create commit** — execute `git commit` with the approved message
+- [ ] **9. Parallelization analysis (optional)** — fetch Linear comments, search for orchestration plan, delegate to `shared-parallelization-analyzer` if found
+
+### Task Progress Tracking
+
+**MANDATORY**: Use Claude Code's built-in task tracking to provide real-time progress visibility.
+
+**Task naming convention**: Every task subject MUST be prefixed with the Linear task ID:
+
+```
+<linearTaskId> <step description>
+```
+
+**At skill start**: Create tasks for each checklist step using `TaskCreate`:
+
+```
+TaskCreate({
+  subject: "MM-123 Fetch Linear task",
+  description: "Get title, description, labels/type from MCP Linear server",
+  activeForm: "MM-123 Fetching Linear task"
+})
+TaskCreate({
+  subject: "MM-123 Analyze staged changes",
+  description: "Run git diff --cached to understand scope",
+  activeForm: "MM-123 Analyzing staged changes"
+})
+```
+
+**During execution**:
+
+- Before starting a step → `TaskUpdate({ taskId, status: "in_progress" })`
+- After completing a step → `TaskUpdate({ taskId, status: "completed" })`
+
+**At checkpoints**: Use `TaskList` to review overall progress before presenting status to user.
+
+## Instructions
+
+You are tasked with creating a git commit based on a Linear task and staged changes.
+
+### Step 1: Fetch Linear Task Details
+
+Use the MCP Linear server to fetch task details for the provided `linearTaskId`. Extract:
+
+- Task title
+- Task description
+- Task labels/type (bug, feature, improve etc.)
+
+### Step 2: Analyze Staged Changes
+
+Run `git diff --cached` to see what files have been changed and understand the scope of changes.
+
+### Step 2.5: Verify Implementation Completeness
+
+Before proceeding with the commit, verify that all requirements from the Linear task have been implemented:
+
+1. **Compare task requirements with actual changes**:
+
+   - Review the Linear task description and acceptance criteria
+   - Analyze the staged changes from `git diff --cached`
+   - Identify any requirements from the task that are not reflected in the code changes
+
+2. **Ask user if implementation is incomplete**:
+
+   - If any task requirements appear to be missing from the staged changes, use `AskUserQuestion` to ask the user:
+     - Option 1: "Continue with commit" (Proceed with committing only the current changes)
+     - Option 2: "Complete implementation first" (Recommended) - Stop the commit process so user can implement missing requirements
+
+3. **Handle user decision**:
+   - If user chooses "Continue with commit": Proceed to Step 3
+   - If user chooses "Complete implementation first": Stop the commit process and inform the user about what's missing
+
+**Note**: This verification step helps ensure commits are complete and aligned with task requirements, reducing the need for follow-up commits.
+
+### Step 3: Read Commitlint Configuration
+
+Read the `commitlint.config.js` file to understand:
+
+- Available scopes (from the `scope-enum` rule)
+- Commit message format requirements
+
+### Step 4: Generate Commit Message
+
+Based on the Linear task details and code changes, generate a commit message following conventional commits format:
+
+```
+<type>(<scope>): <subject>
+
+<body>
+
+Refs: <linearTaskId>
+```
+
+Where:
+
+- **type**: Choose from: `feat`, `fix`, `refactor`, `test`, `docs`, `chore`, `build`, `ci`, `perf`, `style`
+  - Use task labels/type to determine (bug → fix, feature → feat, etc.)
+- **scope**: Select from available scopes in commitlint.config.js based on changed files
+  - If multiple scopes affected, choose the primary one or use a general scope
+  - The scope must be one of the valid scopes from commitlint config
+- **subject**: Brief description (use Linear task title as base, keep under 72 chars)
+- **body**: Optional detailed explanation if needed (from task description or complex changes)
+- **footer**: Always include `Refs: <linearTaskId>` to link to Linear task
+
+### Step 4.5: Pre-commit Preparation (Mandatory)
+
+Before creating the commit, **always** run the following commands:
+
+1. **Switch to Node.js 24**:
+
+   ```bash
+   source ~/.nvm/nvm.sh && nvm use 24
+   ```
+
+2. **Format the code**:
+
+   ```bash
+   npm run format
+   ```
+
+3. **Stage any formatting changes**:
+   - If `npm run format` modified any files, stage them with `git add`
+   - This ensures all committed code is properly formatted
+
+### Step 5: Create Commit
+
+Execute the commit with the generated message:
+
+```bash
+git commit -m "<type>(<scope>): <subject>" -m "<body>" -m "Refs: <linearTaskId>"
+```
+
+### Step 6: Post-Commit Parallelization Analysis (Optional)
+
+After the commit is created, perform an optional parallelization analysis:
+
+1. **Fetch Linear comments** for the task using the MCP Linear server
+2. **Search for `🎭 Agent Orchestration Plan` blocks** in the comments
+3. **If found**: Delegate analysis to `shared-parallelization-analyzer` agent:
+
+   ```
+   Analyze orchestration plan for parallelization opportunities:
+   - Linear Task ID: [linearTaskId]
+   - Orchestration Plan: [the 🎭 Agent Orchestration Plan block content]
+   ```
+
+   The agent will:
+
+   - Parse the orchestration plan (agents table, execution flow, TDD cycles)
+   - Build a dependency graph from file I/O analysis
+   - Identify false sequential dependencies and parallelization opportunities
+   - Generate a console report with current vs proposed execution
+
+4. **If not found**: Skip silently — no message needed (common for hotfixes, config-only commits)
+
+**IMPORTANT**:
+
+- This step is **non-blocking** and **advisory only**
+- The analysis report is shown to the user in the console but is NOT auto-applied
+- Recurring orchestrator improvement suggestions (if any) are filed as Linear issues in the "Framework 2.0" project via `linear-suggestion` skill — no user interaction required
+- A commit failure or missing orchestration plan should never cause this step to error
+
+### Guidelines
+
+1. Keep the subject line concise and imperative mood
+2. Choose the most appropriate type based on task nature and code changes
+3. Select scope based on the primary area of code changes
+4. If task type is unclear, analyze the code changes to determine type
+5. Always include the Linear task reference in the footer
+6. If there are no staged changes, warn the user and don't create commit
+7. After a successful commit, run the optional parallelization analysis (Step 6) to surface optimization opportunities from the orchestration plan. Recurring patterns are filed as Linear issues automatically via `linear-suggestion` skill
+
+### Example
+
+For Linear task "ENG-123: Add dark mode toggle to settings":
+
+- Type: `feat` (new feature)
+- Scope: `shared-angular` (if changes are in libs/shared/angular)
+- Subject: "add dark mode toggle to settings"
+- Result: `feat(shared-angular): add dark mode toggle to settings`
+
+**Post-commit analysis** (if orchestration plan exists in Linear comments):
+
+```
+## Parallelization Analysis Report
+
+**Task**: ENG-123 - Add dark mode toggle to settings
+
+### Opportunities Found
+
+| #   | Type                    | Agents Affected                        | Reason                       |
+| --- | ----------------------- | -------------------------------------- | ---------------------------- |
+| 1   | Independent scaffolding | scaffold-component, scaffold-service   | No shared output files       |
+
+### Estimated Impact
+
+- **Current steps**: 5 sequential
+- **Proposed steps**: 4 (1 parallel group + 3 sequential)
+- **Reduction**: 1 fewer sequential step
+
+### Orchestrator Improvement Suggestions
+
+**Suggestion**: Independent scaffolding agents are always falsely sequentialized
+**Target**: `shared-impl-orchestrator.md` → Parallel vs Sequential
+**Linear issue**: FRA-100 — https://linear.app/smartflow001/issue/FRA-100
+
+---
+
+_Analysis generated by shared-parallelization-analyzer_
+```
+
+If a recurring pattern is detected, a Linear issue is automatically created in "Framework 2.0" via `linear-suggestion` skill.
+
+If no orchestration plan is found in Linear comments, this step is silently skipped.
+
+---
+
+**Important**: Before committing, show the generated commit message to the user for approval.

package/plugins/flow/skills/debug-helper/SKILL.md

@@ -0,0 +1,375 @@
+---
+name: debug-helper
+description: Cross-stack debugging workflows for Angular, NestJS, and MongoDB applications
+---
+
+# Debug Helper
+
+This skill provides debugging workflows and techniques for this project's tech stack.
+
+## 1. Angular Debugging
+
+### Component Not Rendering
+
+1. **Check selector usage**
+
+   ```typescript
+   // Verify selector matches
+   @Component({ selector: 'app-my-component' })
+   // Template: <app-my-component />
+   ```
+
+2. **Check imports (standalone)**
+
+   ```typescript
+   @Component({
+     standalone: true,
+     imports: [MyComponent], // Is it imported?
+   })
+   ```
+
+3. **Check module exports (non-standalone)**
+   ```typescript
+   @NgModule({
+     exports: [MyComponent], // Is it exported?
+   })
+   ```
+
+### Signal/Reactive Issues
+
+1. **Signal not updating**
+
+   ```typescript
+   // Wrong: mutating object
+   items()[0].name = 'new'; // Won't trigger update
+
+   // Correct: create new reference
+   items.update((arr) =>
+     arr.map((item) => (item.id === id ? { ...item, name: 'new' } : item)),
+   );
+   ```
+
+2. **Effect not running**
+
+   ```typescript
+   // Ensure signal is read inside effect
+   effect(() => {
+     const value = this.mySignal(); // Must call signal
+     console.log('Value changed:', value);
+   });
+   ```
+
+3. **Computed not recalculating**
+   ```typescript
+   // Ensure all dependencies are read
+   readonly filtered = computed(() => {
+     const items = this.items();    // Dependency
+     const filter = this.filter();  // Dependency
+     return items.filter(i => i.name.includes(filter));
+   });
+   ```
+
+### Change Detection Issues
+
+```typescript
+// Force change detection
+constructor(private cdr: ChangeDetectorRef) {}
+
+// After async operation
+this.cdr.detectChanges();
+
+// Or mark for check (OnPush)
+this.cdr.markForCheck();
+```
+
+### HTTP Debugging
+
+```typescript
+// Add HTTP interceptor for logging
+export const loggingInterceptor: HttpInterceptorFn = (req, next) => {
+  console.log('Request:', req.method, req.url);
+  return next(req).pipe(
+    tap({
+      next: (event) => {
+        if (event instanceof HttpResponse) {
+          console.log('Response:', event.status, event.body);
+        }
+      },
+      error: (error) => console.error('HTTP Error:', error),
+    }),
+  );
+};
+```
+
+### Browser DevTools
+
+1. **Angular DevTools** - Install Chrome extension
+2. **Component inspector** - Click "Components" tab
+3. **Profiler** - Record change detection cycles
+4. **Network tab** - Check API calls
+
+## 2. NestJS Debugging
+
+### Request Not Reaching Controller
+
+1. **Check route path**
+
+   ```typescript
+   @Controller('features')  // /features
+   @Get(':id')              // /features/:id
+   ```
+
+2. **Check module imports**
+
+   ```typescript
+   @Module({
+     imports: [FeatureModule], // Is module imported?
+   })
+   export class AppModule {}
+   ```
+
+3. **Check guards/interceptors**
+   ```typescript
+   @UseGuards(AuthGuard)  // Is guard blocking?
+   ```
+
+### Dependency Injection Errors
+
+```
+Error: Nest can't resolve dependencies of FeatureService
+```
+
+**Solutions:**
+
+1. Check provider is in module
+
+   ```typescript
+   @Module({
+     providers: [FeatureService, FeatureRepository],
+   })
+   ```
+
+2. Check circular dependencies
+
+   ```typescript
+   // Use forwardRef
+   @Inject(forwardRef(() => OtherService))
+   private readonly other: OtherService,
+   ```
+
+3. Check module exports
+   ```typescript
+   @Module({
+     providers: [SharedService],
+     exports: [SharedService], // Must export if used elsewhere
+   })
+   ```
+
+### Logging
+
+```typescript
+import { Logger } from '@nestjs/common';
+
+@Injectable()
+export class FeatureService {
+  private readonly logger = new Logger(FeatureService.name);
+
+  async findAll() {
+    this.logger.log('Finding all features');
+    this.logger.debug('Debug info');
+    this.logger.warn('Warning');
+    this.logger.error('Error occurred', error.stack);
+  }
+}
+```
+
+### Exception Debugging
+
+```typescript
+// Global exception filter
+@Catch()
+export class AllExceptionsFilter implements ExceptionFilter {
+  private readonly logger = new Logger('ExceptionFilter');
+
+  catch(exception: unknown, host: ArgumentsHost) {
+    const ctx = host.switchToHttp();
+    const response = ctx.getResponse();
+    const request = ctx.getRequest();
+
+    this.logger.error(
+      `${request.method} ${request.url}`,
+      exception instanceof Error ? exception.stack : exception,
+    );
+
+    // Return error response
+  }
+}
+```
+
+## 3. MongoDB/Mongoose Debugging
+
+### Connection Issues
+
+```typescript
+// Log connection events
+mongoose.connection.on('connected', () => console.log('MongoDB connected'));
+mongoose.connection.on('error', (err) => console.error('MongoDB error:', err));
+mongoose.connection.on('disconnected', () =>
+  console.log('MongoDB disconnected'),
+);
+```
+
+### Query Debugging
+
+```typescript
+// Enable Mongoose debug mode
+mongoose.set('debug', true);
+
+// Or for specific query
+const result = await this.model.find({ status: 'active' });
+console.log('Query:', this.model.find({ status: 'active' }).getQuery());
+```
+
+### Aggregation Debugging
+
+```typescript
+// Log pipeline
+const pipeline = [
+  { $match: { status: 'active' } },
+  { $group: { _id: '$category', count: { $sum: 1 } } },
+];
+console.log('Pipeline:', JSON.stringify(pipeline, null, 2));
+
+// Explain query
+const explanation = await this.model.aggregate(pipeline).explain();
+console.log('Explain:', explanation);
+```
+
+### Index Issues
+
+```bash
+# Check indexes in MongoDB shell
+db.features.getIndexes()
+
+# Check query uses index
+db.features.find({ status: 'active' }).explain('executionStats')
+```
+
+## 4. Common Debugging Patterns
+
+### Console Debugging
+
+```typescript
+// Temporary debug logs (remove before commit)
+console.log('DEBUG:', variable);
+console.table(arrayOfObjects);
+console.group('Group');
+console.log('Item 1');
+console.log('Item 2');
+console.groupEnd();
+console.time('Operation');
+// ... operation
+console.timeEnd('Operation');
+```
+
+### Breakpoint Debugging
+
+```typescript
+// Add debugger statement
+function processData(data: Data) {
+  debugger; // Execution pauses here in DevTools
+  return transform(data);
+}
+```
+
+### VS Code Launch Configuration
+
+```json
+// .vscode/launch.json
+{
+  "version": "0.2.0",
+  "configurations": [
+    {
+      "type": "node",
+      "request": "launch",
+      "name": "Debug NestJS",
+      "runtimeArgs": ["-r", "ts-node/register"],
+      "args": ["${workspaceFolder}/apps/api/src/main.ts"],
+      "cwd": "${workspaceFolder}"
+    },
+    {
+      "type": "chrome",
+      "request": "launch",
+      "name": "Debug Angular",
+      "url": "http://localhost:4210",
+      "webRoot": "${workspaceFolder}/apps/web/src"
+    }
+  ]
+}
+```
+
+## 5. Error Investigation Workflow
+
+### Step 1: Reproduce
+
+- Get exact steps to reproduce
+- Note environment (browser, Node version)
+
+### Step 2: Isolate
+
+- Identify component/service causing issue
+- Check if issue is frontend, backend, or database
+
+### Step 3: Trace
+
+- Add logging at key points
+- Use debugger to step through code
+- Check network requests/responses
+
+### Step 4: Root Cause
+
+- Identify the actual cause (not symptoms)
+- Document findings
+
+### Step 5: Fix & Verify
+
+- Apply fix
+- Write test that catches the bug
+- Verify fix doesn't introduce regressions
+
+## 6. Quick Fixes
+
+### "Cannot read property of undefined"
+
+```typescript
+// Use optional chaining
+const name = user?.profile?.name;
+
+// With nullish coalescing
+const name = user?.profile?.name ?? 'Unknown';
+```
+
+### "Expression has changed after it was checked"
+
+```typescript
+// Option 1: setTimeout
+ngAfterViewInit() {
+  setTimeout(() => this.value = newValue);
+}
+
+// Option 2: ChangeDetectorRef
+ngAfterViewInit() {
+  this.value = newValue;
+  this.cdr.detectChanges();
+}
+```
+
+### "Circular dependency detected"
+
+```typescript
+// Use forwardRef
+@Inject(forwardRef(() => ServiceB))
+private serviceB: ServiceB
+
+// Or refactor to remove circular dependency
+```