You're Invited:Meet the Socket Team at RSAC and BSidesSF 2026, March 23–26.RSVP →
@mind-fold/open-flow
Advanced tools
@mind-fold/open-flow - npm Package Compare versions
@@ -1,519 +0,360 @@ | ||
| A new developer needs onboarding. | ||
| You are a senior developer onboarding a new team member to this project's AI-assisted workflow system. | ||
| Execute these steps in order: | ||
| YOUR ROLE: Be a mentor and teacher. Don't just execute commands - EXPLAIN why each step matters, what problems it solves, and what happens if skipped. | ||
| 1. **Explain the workflow system** - Describe how open-flow works: | ||
| - `workflow/` directory structure | ||
| - Guidelines in `workflow/structure/` | ||
| - Progress tracking in `workflow/agent-progress/` | ||
| TEACHING APPROACH: | ||
| - First explain the CORE PHILOSOPHY: why this workflow exists | ||
| - Then walk through the system structure with clear explanations | ||
| - For each example, explain the PURPOSE of every step, not just what to do | ||
| - Help them understand the "why" behind each command | ||
| 2. **Initialize their identity**: | ||
| ```bash | ||
| ./workflow/scripts/init-developer.sh <developer-name> | ||
| ``` | ||
| 3. **Guide them through first task**: | ||
| - Use `./workflow/scripts/get-context.sh` to get full context | ||
| - Use `./workflow/scripts/feature.sh list` to see active features | ||
| - Read relevant guidelines in `workflow/structure/` | ||
| - Start coding | ||
| 4. **Key scripts to know**: | ||
| | Script | Purpose | | ||
| |--------|---------| | ||
| | `get-context.sh` | Get full session context | | ||
| | `feature.sh` | Manage features (create/archive/list) | | ||
| | `add-session.sh` | One-click session recording | | ||
| | `update-index.sh` | Auto-update index.md | | ||
| --- | ||
| ## Slash Commands Detailed Guide | ||
| ## CORE PHILOSOPHY | ||
| ### Core Workflow Commands | ||
| This workflow system solves three critical problems in AI-assisted development: | ||
| #### `/init-agent` - Initialize AI Session | ||
| 1. **Context Loss**: AI starts each session with zero memory. Without a system to capture and restore context, every session starts from scratch, leading to repeated explanations and inconsistent code. | ||
| **What it does**: | ||
| Reads project context and prepares AI for development work. This is the FIRST command to run at the start of every session. | ||
| 2. **Multi-Developer Conflicts**: When multiple developers (human or AI) work on the same codebase, they can overwrite each other's work or make conflicting changes. | ||
| **What AI will do**: | ||
| 1. Run `./workflow/scripts/get-context.sh` to get: | ||
| - Developer identity (who am I?) | ||
| - Git status (which branch? uncommitted changes?) | ||
| - Recent commits (what happened recently?) | ||
| - Active features (what's in progress?) | ||
| - Progress file status (where to record work?) | ||
| 2. Check if developer identity exists, guide initialization if not | ||
| 3. Read relevant structure guidelines based on upcoming task | ||
| 4. Report ready status with a summary table | ||
| 3. **Quality Drift**: Without enforced guidelines, AI generates code that "works" but doesn't follow project conventions, leading to technical debt. | ||
| **Benefits**: | ||
| - AI understands the current state before making changes | ||
| - Avoids conflicts with ongoing work from other developers | ||
| - Knows which guidelines to follow for this project | ||
| - Can continue previous work seamlessly | ||
| The solution: A structured workflow with checkpoints that ensure AI reads context before coding, follows guidelines during coding, and records progress after coding. | ||
| **If skipped**: | ||
| - AI may work on wrong branch or conflict with others' work | ||
| - AI doesn't know project conventions, writes inconsistent code | ||
| - AI can't find previous context, asks redundant questions | ||
| - Progress tracking breaks, work history is lost | ||
| --- | ||
| #### `/record-agent-flow` - Record Work Progress | ||
| ## SYSTEM STRUCTURE | ||
| **What it does**: | ||
| Records completed work to progress files AFTER human has tested and committed code. | ||
| Explain the `workflow/` directory to the developer: | ||
| **What AI will do**: | ||
| 1. Get current context with `get-context.sh` | ||
| 2. Run `add-session.sh` with session details: | ||
| - Title: Brief description of work done | ||
| - Commit: Git commit hash(es) | ||
| - Summary/Content: Detailed changes, lessons learned | ||
| 3. Auto-update index.md with new session count and history | ||
| ``` | ||
| workflow/ | ||
| |-- .developer # Developer identity file (gitignored) | ||
| |-- flow.md # Complete workflow documentation | ||
| |-- agent-progress/ # Progress tracking (per-developer) | ||
| | |-- index.md # Main index with all developers | ||
| | \-- {developer}/ # Individual developer directory | ||
| | |-- index.md # Personal index | ||
| | |-- features/ # Active feature tracking | ||
| | \-- progress-N.md # Session records (max 2000 lines each) | ||
| |-- structure/ # Development guidelines (MUST READ) | ||
| | |-- frontend/ # Frontend coding standards | ||
| | |-- backend/ # Backend coding standards | ||
| | \-- flows/ # Cross-layer development guides | ||
| \-- scripts/ # Automation scripts | ||
| |-- get-context.sh # Get full session context | ||
| |-- init-developer.sh # Initialize new developer | ||
| |-- feature.sh # Manage features | ||
| |-- add-session.sh # Record session progress | ||
| \-- update-index.sh # Update index files | ||
| ``` | ||
| **Benefits**: | ||
| - Creates searchable history for future sessions | ||
| - Next AI session can understand what was done before | ||
| - Tracks lessons learned and patterns discovered | ||
| - Enables multi-developer collaboration without conflicts | ||
| **If skipped**: | ||
| - Next session starts from zero, no context | ||
| - Same bugs may be re-investigated | ||
| - Lessons learned are forgotten | ||
| - Team loses visibility into AI-assisted work | ||
| --- | ||
| #### `/onboard-developer` - Guide New Developer | ||
| ## INITIALIZE DEVELOPER | ||
| **What it does**: | ||
| Walks a new developer (human or AI) through the complete setup process. | ||
| Ask for their name and run: | ||
| ```bash | ||
| ./workflow/scripts/init-developer.sh <developer-name> | ||
| ``` | ||
| **What AI will do**: | ||
| 1. Explain workflow system structure | ||
| 2. Run `init-developer.sh` to create identity | ||
| 3. Demonstrate key scripts and commands | ||
| 4. Guide through first task with examples | ||
| Then demonstrate context retrieval: | ||
| ```bash | ||
| ./workflow/scripts/get-context.sh | ||
| ``` | ||
| --- | ||
| Explain what each output section means and why it matters. | ||
| ### Before Coding Commands | ||
| #### `/before-frontend-dev` - Read Frontend Guidelines | ||
| **What it does**: | ||
| Reads frontend development guidelines BEFORE writing any frontend code. | ||
| **What AI will do**: | ||
| 1. Read `workflow/structure/frontend/index.md` to find relevant sections | ||
| 2. Extract specific guideline sections based on task type: | ||
| - Component guidelines for UI work | ||
| - Hook guidelines for data fetching | ||
| - State management for complex state | ||
| 3. Understand coding standards and patterns to follow | ||
| 4. Identify reference examples to learn from | ||
| **Benefits**: | ||
| - Code follows project conventions from the start | ||
| - Avoids common mistakes documented in guidelines | ||
| - Uses established patterns instead of inventing new ones | ||
| - Reduces review cycles and rework | ||
| **If skipped**: | ||
| - Code style inconsistent with rest of codebase | ||
| - Reinvents patterns that already exist | ||
| - Makes mistakes that guidelines warn against | ||
| - Requires significant refactoring after review | ||
| --- | ||
| #### `/before-backend-dev` - Read Backend Guidelines | ||
| ## CORE SLASH COMMANDS | ||
| **What it does**: | ||
| Reads backend development guidelines BEFORE writing any backend code. | ||
| Explain each command's PURPOSE, not just what it does: | ||
| **What AI will do**: | ||
| 1. Read `workflow/structure/backend/index.md` to find relevant sections | ||
| 2. Extract specific guideline sections: | ||
| - Database operations for DB work | ||
| - Type safety for API contracts | ||
| - Error handling patterns | ||
| - Logging standards | ||
| 3. Understand project-specific conventions | ||
| ### Session Lifecycle Commands | ||
| **Benefits**: | ||
| - Database queries follow established patterns | ||
| - Error handling is consistent across codebase | ||
| - Logging provides useful debugging information | ||
| - API contracts are type-safe | ||
| | Command | When | Purpose | | ||
| |---------|------|---------| | ||
| | `/init-agent` | Session start | Restore context so AI doesn't start blind | | ||
| | `/record-agent-flow` | After commit | Preserve context for next session | | ||
| | `/finish-work` | Before commit | Final quality gate before human review | | ||
| **If skipped**: | ||
| - N+1 query problems in database code | ||
| - Inconsistent error handling | ||
| - Missing or unhelpful logs | ||
| - Type safety holes in APIs | ||
| ### Development Commands | ||
| --- | ||
| | Command | When | Purpose | | ||
| |---------|------|---------| | ||
| | `/before-frontend-dev` | Before frontend code | Load project conventions into AI context | | ||
| | `/before-backend-dev` | Before backend code | Load project conventions into AI context | | ||
| | `/check-frontend` | After frontend code | Verify code meets standards before commit | | ||
| | `/check-backend` | After backend code | Verify code meets standards before commit | | ||
| | `/check-cross-layer` | Full-stack changes | Ensure frontend/backend stay in sync | | ||
| ### Code Check Commands | ||
| ### Investigation Commands | ||
| #### `/check-frontend` - Check Frontend Code | ||
| | Command | When | Purpose | | ||
| |---------|------|---------| | ||
| | `/break-loop` | After debugging | Stop investigation and capture findings | | ||
| | `/record-question` | Solved hard problem | Document solution for future reference | | ||
| **What it does**: | ||
| Verifies frontend code against guidelines AFTER writing code, BEFORE committing. | ||
| **What AI will do**: | ||
| 1. Run type check (`tsc --noEmit`) | ||
| 2. Run linter and check for errors | ||
| 3. Review code against frontend guidelines | ||
| 4. Check for common issues: | ||
| - Semantic HTML usage | ||
| - Accessibility compliance | ||
| - Performance patterns | ||
| 5. Report violations and suggest fixes | ||
| **Benefits**: | ||
| - Catches errors before human review | ||
| - Ensures consistent code quality | ||
| - Documents what was checked for transparency | ||
| **If skipped**: | ||
| - Type errors slip into codebase | ||
| - Lint errors accumulate | ||
| - Accessibility issues go unnoticed | ||
| - Review cycles increase | ||
| --- | ||
| #### `/check-backend` - Check Backend Code | ||
| ## REAL-WORLD WORKFLOW EXAMPLES | ||
| **What it does**: | ||
| Verifies backend code against guidelines AFTER writing code, BEFORE committing. | ||
| For each example below, explain: | ||
| - The SCENARIO context | ||
| - WHY each step is needed | ||
| - WHAT PROBLEM that step solves | ||
| - WHAT HAPPENS if that step is skipped | ||
| **What AI will do**: | ||
| 1. Run type check | ||
| 2. Run linter | ||
| 3. Review against backend guidelines: | ||
| - No non-null assertions (`!`) | ||
| - All inputs/outputs have Zod schemas | ||
| - Structured logging (no console.log) | ||
| - No await in loops | ||
| 4. Check API documentation is updated | ||
| 5. Report issues and fixes | ||
| ### Example 1: Bug Fix Session | ||
| **Benefits**: | ||
| - Catches type safety issues early | ||
| - Ensures API documentation stays in sync | ||
| - Validates database operation patterns | ||
| **Scenario**: UI component missing after refactor | ||
| **If skipped**: | ||
| - Runtime errors from type mismatches | ||
| - API docs become outdated | ||
| - Performance issues from N+1 queries | ||
| ``` | ||
| Step 1: /init-agent | ||
| ``` | ||
| PURPOSE: AI needs to understand current state before making changes. | ||
| - Reads developer identity, git status, active features | ||
| - Without this: AI might work on wrong branch, conflict with others, or repeat already-done work | ||
| --- | ||
| ``` | ||
| Step 2: ./workflow/scripts/feature.sh create fix-sync-indicator | ||
| ``` | ||
| PURPOSE: Create isolated tracking for this work. | ||
| - Links all changes to a named feature | ||
| - Without this: Progress scattered, hard to track what changed and why | ||
| #### `/check-cross-layer` - Cross-Layer Verification | ||
| ``` | ||
| Step 3: /before-frontend-dev | ||
| ``` | ||
| PURPOSE: Load project's frontend conventions into AI context. | ||
| - AI learns component patterns, naming conventions, state management rules | ||
| - Without this: AI writes "working" code that doesn't match project style | ||
| **What it does**: | ||
| Verifies consistency between frontend and backend when changes span multiple layers. | ||
| ``` | ||
| Step 4: Investigate and fix the bug | ||
| ``` | ||
| PURPOSE: The actual development work. | ||
| - AI now has context + guidelines, can write consistent code | ||
| **What AI will do**: | ||
| 1. Identify all layers touched by the change | ||
| 2. Verify type contracts match across layers | ||
| 3. Check data flow consistency | ||
| 4. Validate API request/response alignment | ||
| ``` | ||
| Step 5: /check-frontend | ||
| ``` | ||
| PURPOSE: Quality gate before human review. | ||
| - Runs type check, linter, guideline compliance | ||
| - Without this: Errors slip through, human review catches preventable issues | ||
| **Benefits**: | ||
| - Catches integration issues early | ||
| - Ensures frontend and backend stay in sync | ||
| - Prevents runtime type mismatches | ||
| ``` | ||
| Step 6: /finish-work | ||
| ``` | ||
| PURPOSE: Final checklist before commit. | ||
| - Ensures nothing forgotten: docs updated, all files staged | ||
| - Without this: Partial commits, missing documentation | ||
| **If skipped**: | ||
| - Frontend expects data backend doesn't provide | ||
| - Type mismatches cause runtime errors | ||
| - Integration bugs found late in testing | ||
| ``` | ||
| Step 7: Human tests and commits | ||
| ``` | ||
| PURPOSE: Human-in-the-loop verification. | ||
| - AI NEVER commits - human is responsible for testing | ||
| - Without this: Untested code enters codebase | ||
| --- | ||
| ``` | ||
| Step 8: /record-agent-flow | ||
| ``` | ||
| PURPOSE: Preserve context for future sessions. | ||
| - Records what was done, lessons learned, commit hashes | ||
| - Without this: Next session starts from zero, same bugs re-investigated | ||
| ### Work Completion Commands | ||
| ``` | ||
| Step 9: ./workflow/scripts/feature.sh archive fix-sync-indicator | ||
| ``` | ||
| PURPOSE: Clean up after completion. | ||
| - Moves feature to archive, keeps active list clean | ||
| #### `/finish-work` - Pre-Commit Checklist | ||
| **What it does**: | ||
| Final verification before human commits. Ensures nothing is forgotten. | ||
| **What AI will do**: | ||
| 1. Run all relevant checks (type, lint) | ||
| 2. Verify all changes are intentional | ||
| 3. Check documentation is updated | ||
| 4. Prepare commit message suggestion | ||
| 5. List files to be committed | ||
| 6. Confirm ready for human review | ||
| **Benefits**: | ||
| - Nothing is forgotten before commit | ||
| - Clean commit history | ||
| - Documentation stays in sync | ||
| - Human knows exactly what to review | ||
| **If skipped**: | ||
| - Partial commits with missing files | ||
| - Documentation drift | ||
| - Unclear what changed for reviewer | ||
| --- | ||
| #### `/break-loop` - End Investigation Loop | ||
| ### Example 2: Planning Session (No Code) | ||
| **What it does**: | ||
| Stops an investigation/debugging loop and summarizes findings. Use when debugging or researching, BEFORE `/finish-work`. | ||
| **Scenario**: Audit migration docs and plan consolidation | ||
| **What AI will do**: | ||
| 1. Summarize what was investigated | ||
| 2. Document root cause (if found) | ||
| 3. List temporary vs permanent fixes | ||
| 4. Record lessons learned | ||
| 5. Suggest next steps or follow-up tasks | ||
| 6. Prepare knowledge for `/record-question` if applicable | ||
| ``` | ||
| Step 1: /init-agent | ||
| ``` | ||
| PURPOSE: Understand current state even for non-coding work. | ||
| - See what's already in progress, avoid duplicate planning | ||
| **Benefits**: | ||
| - Prevents endless investigation loops | ||
| - Captures debugging knowledge | ||
| - Creates actionable next steps | ||
| - Knowledge is preserved for future | ||
| ``` | ||
| Step 2: ./workflow/scripts/feature.sh create migration-docs-consolidation | ||
| ``` | ||
| PURPOSE: Track planning work same as code work. | ||
| - Planning is valuable work that needs recording | ||
| **If skipped**: | ||
| - Investigation goes in circles | ||
| - Findings are lost when session ends | ||
| - Same debugging repeated later | ||
| - No clear resolution or next steps | ||
| ``` | ||
| Step 3: Review docs, create subtask list | ||
| ``` | ||
| PURPOSE: The actual planning work. | ||
| - Compare existing docs, identify gaps, prioritize | ||
| --- | ||
| ``` | ||
| Step 4: /record-agent-flow (with --summary, no --commit) | ||
| ``` | ||
| PURPOSE: Record planning output even without code commits. | ||
| - Use --summary flag for non-code sessions | ||
| - Without this: Planning decisions lost, team doesn't know what was decided | ||
| ### Utility Commands | ||
| #### `/create-command` - Create New Slash Command | ||
| **What it does**: | ||
| Creates a new slash command when a repeated workflow pattern is identified. | ||
| **What AI will do**: | ||
| 1. Analyze the workflow pattern | ||
| 2. Design command structure | ||
| 3. Create command file in `.cursor/commands/` or `.claude/commands/` | ||
| 4. Document usage and examples | ||
| --- | ||
| #### `/record-question` - Document Solved Problems | ||
| ### Example 3: Code Review Fixes | ||
| **What it does**: | ||
| Documents a solved problem for future reference when a tricky issue is resolved. | ||
| **Scenario**: Fix issues from CR round 2 | ||
| **What AI will do**: | ||
| 1. Summarize the problem | ||
| 2. Document the root cause | ||
| 3. Record the solution | ||
| 4. Add to appropriate location (big-question/ or guidelines) | ||
| ``` | ||
| Step 1: /init-agent | ||
| ``` | ||
| PURPOSE: Resume context from previous session. | ||
| - AI sees the feature is already in progress | ||
| - Reads previous progress to understand what was already done | ||
| **Benefits**: | ||
| - Knowledge is preserved | ||
| - Same problem won't need re-investigation | ||
| - Team learns from each other's discoveries | ||
| ``` | ||
| Step 2: /before-backend-dev | ||
| ``` | ||
| PURPOSE: Refresh guidelines before fixing backend issues. | ||
| - CR comments often point to guideline violations | ||
| - AI needs guidelines in context to fix properly | ||
| --- | ||
| ``` | ||
| Step 3: Fix each CR issue | ||
| ``` | ||
| PURPOSE: Address review feedback. | ||
| - With guidelines loaded, fixes follow project conventions | ||
| #### `/integrate-skill` - Integrate Claude Skills | ||
| ``` | ||
| Step 4: /check-backend | ||
| ``` | ||
| PURPOSE: Verify fixes don't introduce new issues. | ||
| - Each fix could break something else | ||
| **What it does**: | ||
| Integrates external Claude skills into project guidelines. | ||
| ``` | ||
| Step 5: /finish-work | ||
| ``` | ||
| PURPOSE: Document lessons learned from CR. | ||
| - CR feedback reveals patterns to remember | ||
| - Example: "All queries with workspaceId must include WHERE clause" | ||
| --- | ||
| ``` | ||
| Step 6: Human commits, then /record-agent-flow | ||
| ``` | ||
| PURPOSE: Preserve CR lessons for future. | ||
| - Next time AI writes similar code, it knows the patterns | ||
| #### `/extract-llm-docs` - Extract from LLM Documentation | ||
| **What it does**: | ||
| Extracts useful patterns from LLM documentation (like llms.txt files) into project guidelines. | ||
| --- | ||
| #### `/extract-to-rules` - Extract Rules from Source | ||
| ### Example 4: Large Refactoring | ||
| **What it does**: | ||
| Extracts coding rules and patterns from existing source code into guidelines. | ||
| **Scenario**: Adapt workflow system for monorepo | ||
| --- | ||
| ``` | ||
| Step 1: /init-agent | ||
| ``` | ||
| PURPOSE: Establish baseline before major changes. | ||
| - Large refactors need clear starting point | ||
| #### `/sync-from-runtime` - Sync Knowledge | ||
| ``` | ||
| Step 2: Plan phases | ||
| ``` | ||
| PURPOSE: Break large work into manageable chunks. | ||
| - Phase 1: Root directory restructure | ||
| - Phase 2: Sub-project workflow cleanup | ||
| - Phase 3: Slash commands rewrite | ||
| - Phase 4: Core docs update | ||
| **What it does**: | ||
| Syncs knowledge and patterns from runtime documentation. | ||
| ``` | ||
| Step 3: Execute phase by phase with /check-* after each | ||
| ``` | ||
| PURPOSE: Incremental verification. | ||
| - Catch issues early, don't let errors compound | ||
| --- | ||
| ``` | ||
| Step 4: /finish-work | ||
| ``` | ||
| PURPOSE: Final verification across all phases. | ||
| - Ensure all phases are complete and consistent | ||
| ## Real-World Workflow Examples | ||
| ### Example 1: Bug Fix Session | ||
| **Scenario**: UI component missing after refactor | ||
| ``` | ||
| 1. /init-agent | ||
| -> See context: Branch "main", 2 uncommitted files | ||
| -> Active feature: none | ||
| Step 5: Record with multiple commit hashes | ||
| ``` | ||
| PURPOSE: Link all commits to one logical feature. | ||
| - ./workflow/scripts/add-session.sh --title "Monorepo Adaptation" --commit "hash1,hash2,hash3" | ||
| 2. Create feature: | ||
| ./workflow/scripts/feature.sh create fix-sync-indicator | ||
| --- | ||
| 3. /before-frontend-dev | ||
| -> Read component guidelines | ||
| ### Example 5: Debug Session with Break Loop | ||
| 4. Investigate and fix: | ||
| - Analyze old vs new architecture | ||
| - Import missing component | ||
| - Add CSS styles | ||
| **Scenario**: Investigating a complex sync bug | ||
| 5. /check-frontend | ||
| -> Type check: [OK] passed | ||
| -> Lint: [OK] 0 errors | ||
| 6. /finish-work | ||
| -> Pre-commit checklist | ||
| -> Confirm all changes are ready | ||
| 7. Human tests and commits: | ||
| git commit -m "fix(ui): restore SyncIndicator to TabBar" | ||
| 8. /record-agent-flow | ||
| -> ./workflow/scripts/add-session.sh --title "Fix SyncIndicator" --commit "abc123" | ||
| 9. Archive feature: | ||
| ./workflow/scripts/feature.sh archive fix-sync-indicator | ||
| ``` | ||
| ### Example 2: Planning Session (No Code) | ||
| **Scenario**: Audit migration docs and plan consolidation | ||
| Step 1: /init-agent | ||
| ``` | ||
| 1. /init-agent | ||
| -> Understand current state | ||
| PURPOSE: Get context on the bug being investigated. | ||
| - See previous investigation attempts if any | ||
| 2. Create feature: | ||
| ./workflow/scripts/feature.sh create migration-docs-consolidation | ||
| 3. Review docs, compare with existing guidelines | ||
| 4. Create subtask list in feature.json: | ||
| - Critical: Update outdated timestamp format | ||
| - High: Add missing validation rules | ||
| - Medium: Consolidate scattered docs | ||
| 5. /record-agent-flow (no commit) | ||
| -> ./workflow/scripts/add-session.sh --title "Migration Docs Planning" --summary "Created 14 subtasks" | ||
| ``` | ||
| Step 2: /before-backend-dev | ||
| ``` | ||
| PURPOSE: Load relevant guidelines for the area being debugged. | ||
| - Guidelines often contain hints about known issues | ||
| ### Example 3: Code Review Fixes | ||
| **Scenario**: Fix issues from CR round 2 | ||
| ``` | ||
| 1. /init-agent | ||
| -> Continue feature: entity-filesystem-refactor | ||
| Step 3: Investigation loop | ||
| ``` | ||
| PURPOSE: The actual debugging work. | ||
| - Analyze data, check logs, form hypotheses, test fixes | ||
| 2. /before-backend-dev | ||
| -> Read database and error handling guidelines | ||
| 3. Fix each CR issue: | ||
| - Add missing workspaceId filter (data isolation) | ||
| - Fix meta double-stringify bug | ||
| - Add LWW conflict resolution | ||
| 4. /check-backend | ||
| -> All checks passed | ||
| 5. /finish-work | ||
| -> Pre-commit checklist | ||
| -> Document lessons learned: | ||
| - "All queries with workspaceId column must include WHERE clause" | ||
| - "buildXxxValues must match *DataSchema types" | ||
| 6. Human commits, then /record-agent-flow | ||
| ``` | ||
| Step 4: /check-backend | ||
| ``` | ||
| PURPOSE: Verify debug changes don't break other things. | ||
| - Debug code can be sloppy - this catches issues | ||
| ### Example 4: Large Refactoring | ||
| **Scenario**: Adapt workflow system for monorepo | ||
| ``` | ||
| 1. /init-agent | ||
| -> Create feature: workflow-monorepo-adaptation | ||
| Step 5: /break-loop | ||
| ``` | ||
| PURPOSE: CRITICAL - Stop investigation and capture findings. | ||
| - Summarizes: what was investigated, root cause, fixes tried | ||
| - Documents: temporary vs permanent fix, follow-up needed | ||
| - Without this: Investigation goes in circles, findings lost | ||
| 2. Plan phases: | ||
| - Phase 1: Root directory restructure | ||
| - Phase 2: Sub-project workflow cleanup | ||
| - Phase 3: Slash commands rewrite | ||
| - Phase 4: Core docs update | ||
| 3. Execute phase by phase, running /check-* after each | ||
| 4. /finish-work | ||
| -> Final verification checklist | ||
| 5. Human commits multiple times, record with multiple commit hashes: | ||
| ./workflow/scripts/add-session.sh --title "Monorepo Adaptation" --commit "hash1,hash2,hash3" | ||
| ``` | ||
| Step 6: /finish-work | ||
| ``` | ||
| PURPOSE: Prepare debug findings for commit. | ||
| - Even investigation sessions produce valuable output | ||
| ### Example 5: Debug Session with Break Loop | ||
| **Scenario**: Investigating a complex sync bug | ||
| ``` | ||
| 1. /init-agent | ||
| -> Continue feature: fix-sync-data-inconsistency | ||
| Step 7: Human commits, then /record-agent-flow | ||
| ``` | ||
| PURPOSE: Preserve debugging knowledge. | ||
| - Next time same bug appears, AI has context | ||
| 2. /before-backend-dev | ||
| -> Read sync and database guidelines | ||
| --- | ||
| 3. Investigation loop: | ||
| - Analyze cloud vs local data | ||
| - Check sync event timestamps | ||
| - Review applyEvent logic | ||
| - Add debug logging | ||
| ## KEY RULES TO EMPHASIZE | ||
| 4. /check-backend | ||
| -> All checks passed | ||
| 1. **AI NEVER commits** - Human tests and commits. AI prepares, human approves. | ||
| 5. /break-loop (when investigation is complete) | ||
| -> Summarize findings: | ||
| - Root cause: Transaction failure without error logging | ||
| - Temporary fix: Manual SQL update | ||
| - Permanent fix: Add detailed logging in applyEvent | ||
| -> Document for future reference | ||
| 2. **Guidelines before code** - /before-*-dev commands are MANDATORY, not optional. | ||
| 6. /finish-work | ||
| -> Pre-commit checklist | ||
| 3. **Progress tracking** - Every session should end with /record-agent-flow. | ||
| 7. Human tests and commits | ||
| 4. **Break investigation loops** - Use /break-loop to stop research and capture findings. | ||
| 8. /record-agent-flow | ||
| -> Include lessons learned in session record | ||
| ``` | ||
| 5. **Planning is valid work** - Non-code sessions use --summary flag in add-session.sh. | ||
| --- | ||
| ## Key Points to Emphasize | ||
| After explaining, ask the developer: | ||
| 1. What kind of work will they be doing? (frontend/backend/full-stack) | ||
| 2. Do they have a specific task to start with? | ||
| - AI should NOT execute `git commit` - human is responsible for testing and committing | ||
| - Each developer has their own progress directory | ||
| - Read guidelines before coding (mandatory) | ||
| - Use `/record-question` to document solved problems for future reference | ||
| - Planning sessions (no code) are valid - record with `--summary` instead of `--commit` | ||
| - `/break-loop` is for ending debug/investigation loops, use BEFORE `/finish-work` | ||
| Then guide them through their first task using the appropriate workflow. |
+1
-1
| { | ||
| "name": "@mind-fold/open-flow", | ||
| "version": "0.2.12", | ||
| "version": "0.2.13", | ||
| "description": "AI-assisted development workflow initializer for Cursor, Claude Code and more", | ||
@@ -5,0 +5,0 @@ "type": "module", |
New alerts
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Found 1 instance in 1 package
Fixed alerts
Long strings
Supply chain riskContains long string literals, which may be a sign of obfuscated or packed code.
Found 1 instance in 1 package
Worsened metrics
- Total package byte prevSize
309935
-1.06%No dependency changes