owflow 0.1.0 → 0.1.2

package/dist/commands/quick-bugfix.md

@@ -0,0 +1,37 @@
+---
+name: quick-bugfix
+description: Quick bug fix with TDD red/green gates and complexity escalation
+argument-hint: "[bug description]"
+generated-from-skill: true
+---
+
+CRITICAL INSTRUCTION: You MUST invoke the quick-bugfix skill immediately as your FIRST action.
+
+Use the Skill tool with these exact parameters:
+name: "quick-bugfix"
+prompt: "$ARGUMENTS"
+
+DO NOT:
+
+- Analyze the task before invoking the skill
+- Decide the task is "straightforward" and skip the skill
+- Substitute your own approach or workflow
+- Execute any part of the workflow yourself
+
+WHY: The user explicitly chose this workflow by using /quick-bugfix.
+Invoke the skill now and let it orchestrate the complete workflow.
+
+---
+
+## About This Workflow
+
+Quick bug fix with TDD red/green gates and complexity escalation
+
+The skill handles:
+
+- Task directory creation and state management
+- Phase execution with interactive gates
+- Subagent delegation for specialized work
+- Pause/resume capability
+
+See `skills/quick-bugfix/SKILL.md` for complete workflow documentation.

package/dist/commands/quick-dev.md

@@ -0,0 +1,140 @@
+---
+name: quick-dev
+description: Implement task directly with AI SDLC standards awareness (no planning mode)
+---
+
+# Quick Development with Standards Awareness
+
+Implement a task directly without entering planning mode, while still applying project standards from `.owflow/docs/`.
+
+## Usage
+
+```bash
+/quick-dev [task description]
+```
+
+## Examples
+
+```bash
+/quick-dev "Add a logout button to the navbar"
+/quick-dev "Fix the typo in the error message"
+/quick-dev "Update the API endpoint to accept JSON"
+```
+
+---
+
+## When to Use
+
+**Use `/quick-dev` when:**
+
+- Task is clear and well-defined
+- You know what needs to be done
+- No architectural decisions needed
+- Quick fixes, small features, or straightforward changes
+
+**Use `/quick-plan` instead when:**
+
+- Task scope is uncertain
+- Multiple implementation approaches possible
+- Architectural decisions required
+- You want user approval before coding
+
+---
+
+## Workflow
+
+### Step 1: Parse Input
+
+**Get the task description:**
+
+- If provided as argument, use it directly
+- If not provided, use question to prompt:
+  ```
+  "What would you like to implement? Please describe the task."
+  ```
+
+### Step 2: Discover Standards
+
+**Check if `.owflow/docs/INDEX.md` exists:**
+
+**If exists:**
+
+1. Read INDEX.md to discover available documentation and standards
+2. Identify which standards are relevant based on:
+   - The categories and files listed in INDEX.md
+   - The nature of the task
+   - Keywords in the task description
+3. **READ the applicable standard files** (see Standards Reading Enforcement below)
+
+**If not exists:**
+
+- Note that no standards are available
+- Suggest running `/flow-init` in completion message
+
+### Standards Reading Enforcement (MANDATORY)
+
+**BLOCKING**: Reading INDEX.md alone is NOT sufficient. You MUST read actual standard files.
+
+**Enforcement Process**:
+
+1. Read INDEX.md to discover available standards
+2. Identify which standards apply based on task description
+3. **READ each applicable standard file** using Read tool (not just note it exists)
+4. Apply standards during implementation
+5. List applied standards in completion summary
+
+**Examples of standard discovery**:
+
+- Task mentions "upload" → Read file-handling standards
+- Task mentions "form" → Read validation and accessibility standards
+- Task mentions "API" → Read api and error-handling standards
+
+### Step 3: Implement with Standards
+
+**MANDATORY**: During implementation:
+
+1. Explore the codebase to understand context (using Glob, Grep, Read)
+2. **Apply discovered standards** - Reference the standard files you read
+3. For each code change, verify it follows applicable standards
+4. If you encounter new areas while coding (e.g., auth, database), read applicable standards before proceeding
+5. Make the necessary code changes
+6. Run relevant tests if applicable
+
+### Step 4: Verify Standards Compliance
+
+**After implementation, verify:**
+
+1. Review changes against applicable standards
+2. Confirm key guidelines were followed
+3. Note any standards that were applied
+
+### Step 5: Summary
+
+**Provide completion summary:**
+
+- What was implemented
+- Which standards from INDEX.md were applied
+- Any tests run and their results
+- Suggestions for follow-up (if any)
+
+---
+
+## What This Does
+
+1. **Parses** task description from user input
+2. **Discovers** applicable standards from `.owflow/docs/INDEX.md`
+3. **READS** actual standard files (MANDATORY - not just INDEX.md)
+4. **Implements** directly without planning mode approval
+5. **Verifies** standards were followed
+6. **Summarizes** what was done and which standards were read and applied
+
+## Graceful Fallback
+
+**If `.owflow/docs/` does not exist:**
+
+Proceed with implementation normally, then note:
+
+```
+"No AI SDLC standards found. Consider running `/flow-init` to initialize
+project documentation and coding standards for better consistency."
+```

package/dist/commands/quick-plan.md

@@ -0,0 +1,132 @@
+---
+name: quick-plan
+description: Enter planning mode with AI SDLC standards awareness
+---
+
+# Planning Mode with Standards Awareness
+
+Enter Claude Code's planning mode for a task, with automatic discovery of project standards from `.owflow/docs/`.
+
+## Usage
+
+```bash
+/quick-plan [task description]
+```
+
+## Examples
+
+```bash
+/quick-plan "Add user authentication with email/password"
+/quick-plan "Refactor the payment processing module"
+/quick-plan
+```
+
+---
+
+## Workflow
+
+### Step 1: Parse Input
+
+**Get the task description:**
+
+- If provided as argument, use it directly
+- If not provided, use question to prompt:
+  ```
+  "What would you like to plan? Please describe the task or feature."
+  ```
+
+### Step 2: Discover and Read Standards (BEFORE Plan Mode)
+
+**CRITICAL: This step MUST complete before calling EnterPlanMode.**
+
+1. **Check if `.owflow/docs/INDEX.md` exists**
+   - **If not exists**: Note that no standards are available, skip to Step 3
+   - **If exists**: Continue with discovery below
+
+2. **Read INDEX.md** to understand available standards and documentation
+
+3. **Identify applicable standards** based on:
+   - The categories and files listed in INDEX.md
+   - The nature of the task being planned
+   - Keywords and patterns in the task description (e.g., "API" → api standards, "form" → validation standards, "upload" → file-handling standards)
+
+4. **READ the actual standard files** using the Read tool — reading INDEX.md alone is NOT sufficient
+
+5. **Summarize key guidelines** from each standard file read — these will carry into plan mode as context
+
+### Step 3: Enter Planning Mode
+
+**Use the `EnterPlanMode` tool to trigger Claude Code's builtin planning mode.**
+
+**Standards context from Step 2 MUST actively inform all plan mode phases:**
+
+- **Phase 1 (Explore)**: When launching Explore agents, include in the prompt: "The following project standards apply to this task: [list standard files and key guidelines from Step 2]. Verify how the existing codebase follows these standards."
+- **Phase 2 (Plan)**: When launching Plan agents, include in the prompt: "Apply these project standards in your implementation plan: [list standard files and key guidelines from Step 2]. Each implementation step must conform to these standards."
+- **Phase 4 (Final Plan)**: The plan file must incorporate standards into the implementation steps themselves, not just list them in a separate section.
+
+The planning mode will:
+
+1. Launch Explore agents to understand the codebase (with standards context)
+2. Launch Plan agents to design implementation approach (with standards constraints)
+3. Review and verify alignment with user intent
+4. Write final plan to plan file (with standards woven into steps)
+5. Call ExitPlanMode for user approval (gated on mandatory standards sections)
+
+### ExitPlanMode Gate: Mandatory Standards Sections
+
+**BLOCKING: Do NOT call `ExitPlanMode` until the plan file contains these sections:**
+
+1. **"## Applicable Standards"** — list each standard file that was read, with key guidelines extracted from each. If no standards exist, state: "No AI SDLC standards found. Consider running `/flow-init`."
+
+2. **"## Standards Compliance Checklist"** — checkboxes for each applicable standard guideline that implementation must follow. Example:
+   ```markdown
+   - [ ] API endpoints follow REST naming conventions (from `standards/backend/api.md`)
+   - [ ] Error responses use standard error format (from `standards/backend/api.md`)
+   - [ ] New components use TypeScript strict mode (from `standards/frontend/components.md`)
+   ```
+
+If these sections are missing from the plan file, add them before calling ExitPlanMode.
+
+### Graceful Fallback
+
+**If `.owflow/docs/` does not exist:**
+
+Continue with planning mode normally. The "Applicable Standards" section in the plan should note:
+
+```
+No AI SDLC standards found. Consider running `/flow-init` to initialize
+project documentation and coding standards for better consistency.
+```
+
+## What This Does
+
+1. **Parses** task description from user input
+2. **Discovers and READS** applicable standard files from `.owflow/docs/` (BEFORE plan mode)
+3. **Enters** Claude Code's builtin planning mode via `EnterPlanMode` with standards already loaded
+4. **Produces** a plan file with implementation approach, applicable standards, and compliance checklist
+5. **Gates** ExitPlanMode on mandatory standards sections in the plan file
+
+## Benefits Over Manual Planning
+
+- Automatic standards discovery and integration
+- Standards read BEFORE planning begins (not as an afterthought)
+- Plan file for review before implementation
+- Standards compliance checklist built into the plan
+
+## After Planning
+
+Once the plan is approved:
+
+- Implementation begins based on the plan
+- Standards are applied during coding
+
+## Post-Implementation Verification
+
+After implementation is complete, verify standards compliance using the checklist from the plan:
+
+1. **Review the "Standards Compliance Checklist"** in the plan file
+2. **For each checklist item**: verify implementation follows the guideline
+3. **Document verification results** (pass/fail for each item)
+4. **Address any violations** before marking task complete
+
+This ensures the discovered standards are actually enforced, not just documented.

package/dist/commands/research.md

@@ -0,0 +1,37 @@
+---
+name: research
+description: Orchestrates comprehensive research workflows from question definition through findings documentation. Handles technical, requirements, literature, and mixed research types with adaptive methodology, multi-source gathering, pattern synthesis, and evidence-based reporting. Supports standalone research tasks and embedded research phase in other workflows.
+argument-hint: [task description]
+generated-from-skill: true
+---
+
+CRITICAL INSTRUCTION: You MUST invoke the research skill immediately as your FIRST action.
+
+Use the Skill tool with these exact parameters:
+name: "research"
+prompt: "$ARGUMENTS"
+
+DO NOT:
+
+- Analyze the task before invoking the skill
+- Decide the task is "straightforward" and skip the skill
+- Substitute your own approach or workflow
+- Execute any part of the workflow yourself
+
+WHY: The user explicitly chose this workflow by using /research.
+Invoke the skill now and let it orchestrate the complete workflow.
+
+---
+
+## About This Workflow
+
+Orchestrates comprehensive research workflows from question definition through findings documentation. Handles technical, requirements, literature, and mixed research types with adaptive methodology, multi-source gathering, pattern synthesis, and evidence-based reporting. Supports standalone research tasks and embedded research phase in other workflows.
+
+The skill handles:
+
+- Task directory creation and state management
+- Phase execution with interactive gates
+- Subagent delegation for specialized work
+- Pause/resume capability
+
+See `skills/research/SKILL.md` for complete workflow documentation.

package/dist/commands/reviews-code.md

@@ -0,0 +1,90 @@
+---
+name: reviews-code
+description: Run automated code quality, security, and performance analysis on your code
+---
+
+**ACTION REQUIRED**: This command delegates to a subagent. The `<command-name>` tag refers to THIS command, not the target. Invoke the code-reviewer subagent via the Task tool NOW. Pass path and scope arguments. Do not read files, explore code, or execute workflow steps yourself.
+
+You are running a comprehensive code review using the `code-reviewer` subagent.
+
+## Your Task
+
+You are performing automated code analysis to identify quality, security, and performance issues.
+
+## Parse User Request
+
+**Determine the following from the user's request:**
+
+1. **Path to analyze**:
+   - If provided: Use the specified path
+   - If not provided: Use question to ask what to analyze
+
+2. **Analysis scope**:
+   - If `--scope=quality`: Only code quality analysis
+   - If `--scope=security`: Only security analysis
+   - If `--scope=performance`: Only performance analysis
+   - If `--scope=all` or no scope: Complete analysis (recommended)
+
+## Your Instructions
+
+**Invoke the code-reviewer subagent NOW using the Task tool:**
+
+```
+Use Task tool:
+  subagent_type: "code-reviewer"
+  description: "Code quality review"
+  prompt: |
+    Analyze code at: [path from user or from question]
+    Scope: [quality|security|performance|all]
+    Report path: [path]/code-review-report.md
+```
+
+**Wait for the subagent to complete before proceeding.**
+
+The code-reviewer subagent will:
+
+1. Analyze code for complexity, duplication, and code smells
+2. Detect security vulnerabilities and hardcoded secrets
+3. Identify performance issues (N+1 queries, missing indexes, caching opportunities)
+4. Generate comprehensive report with findings categorized by severity
+5. Provide actionable recommendations with code examples
+
+## Examples
+
+**Example 1**: Review specific task
+
+```
+User: /reviews-code .owflow/tasks/development/2025-10-24-auth/
+```
+
+**Example 2**: Review with specific scope
+
+```
+User: /reviews-code src/api/ --scope=security
+```
+
+**Example 3**: Review entire project
+
+```
+User: /reviews-code src/
+```
+
+## What to Expect
+
+The code-reviewer will provide:
+
+- Summary of issues found (critical, warnings, info)
+- Detailed findings with file locations and line numbers
+- Code examples showing issues and fixes
+- Metrics on code quality, security, and performance
+- Prioritized recommendations
+- Go/no-go assessment for code review
+
+## Notes
+
+- This is analysis only - no code will be modified
+- Focus on actionable findings
+- Severity levels guide prioritization:
+  - **Critical**: Must fix before production
+  - **Warning**: Should fix before merge
+  - **Info**: Nice to have improvements

package/dist/commands/reviews-pragmatic.md

@@ -0,0 +1,99 @@
+---
+name: reviews-pragmatic
+description: Run pragmatic code review to detect over-engineering and ensure code matches project scale
+---
+
+**ACTION REQUIRED**: This command delegates to a different skill. The `<command-name>` tag refers to THIS command, not the target. Call the Task tool with subagent_type="code-quality-pragmatist" NOW. Pass the path to analyze in the prompt. Do not read files, explore code, or execute workflow steps yourself.
+
+You are running a pragmatic code review using the `code-quality-pragmatist` agent.
+
+## Your Task
+
+You are performing pragmatic analysis to identify over-engineering, unnecessary complexity, and developer experience issues.
+
+## Parse User Request
+
+**Determine the following from the user's request:**
+
+1. **Path to analyze**:
+   - If provided: Use the specified path
+   - If not provided: Use question to ask what to analyze (file, directory, or task path)
+
+## Your Instructions
+
+**Invoke the code-quality-pragmatist agent NOW using the Task tool:**
+
+```
+Task Tool:
+- subagent_type: code-quality-pragmatist
+- description: Pragmatic code review
+- prompt: |
+    You are the code-quality-pragmatist agent. Review the code at: [path]
+
+    Your task:
+    1. Assess overall complexity relative to project scale (check .owflow/docs/project/ for scale)
+    2. Detect over-engineering patterns (infrastructure overkill, excessive abstraction, enterprise patterns in simple code)
+    3. Assess developer experience (setup complexity, feedback loops, error messages, consistency)
+    4. Verify requirements alignment (if spec.md available, compare implementation to requirements)
+    5. Recommend specific simplifications with before/after examples
+    6. Prioritize top 3 changes with highest impact
+
+    Generate comprehensive pragmatic review report.
+    Save to: verification/pragmatic-review.md
+
+    Focus on: Simple solutions for simple problems. Code should match project needs, not theoretical best practices.
+```
+
+**Wait for the agent to complete before proceeding.**
+
+The code-quality-pragmatist agent will:
+
+1. Assess complexity relative to project scale (MVP vs Enterprise)
+2. Detect over-engineering (Redis in MVP, excessive layers, premature optimization)
+3. Identify developer experience friction points
+4. Compare implementation to requirements (if spec available)
+5. Recommend concrete simplifications with impact estimates
+6. Provide top 3 priority actions
+
+## Examples
+
+**Example 1**: Review specific feature
+
+```
+User: /reviews-pragmatic .owflow/tasks/development/2025-11-17-user-management/
+```
+
+**Example 2**: Review source directory
+
+```
+User: /reviews-pragmatic src/features/payments/
+```
+
+**Example 3**: Review specific file
+
+```
+User: /reviews-pragmatic src/services/cache-service.ts
+```
+
+## What to Expect
+
+The code-quality-pragmatist will provide:
+
+- Complexity assessment (Low/Medium/High) relative to project scale
+- Over-engineering patterns with severity (Critical/High/Medium/Low)
+- Developer experience issues and friction points
+- Requirements alignment assessment
+- Concrete simplification recommendations with before/after examples
+- Top 3 priority actions with estimated impact
+- Summary statistics (LOC reduction potential, dependencies removable)
+
+## Notes
+
+- This is analysis only - no code will be modified
+- Focus on pragmatism: appropriate complexity for actual needs
+- Identifies unnecessary infrastructure, abstractions, and patterns
+- Severity levels guide prioritization:
+  - **Critical**: Severe over-engineering blocking development
+  - **High**: Significant unnecessary complexity
+  - **Medium**: Moderate complexity issues
+  - **Low**: Minor improvements

package/dist/commands/reviews-production-readiness.md

@@ -0,0 +1,113 @@
+---
+name: reviews-production-readiness
+description: Verify production deployment readiness with comprehensive checks
+---
+
+**ACTION REQUIRED**: This command delegates to a subagent. The `<command-name>` tag refers to THIS command, not the target. Invoke the production-readiness-checker subagent via the Task tool NOW. Pass path and target arguments. Do not read files, explore code, or execute workflow steps yourself.
+
+You are verifying production deployment readiness using the `production-readiness-checker` subagent.
+
+## Your Task
+
+You are performing comprehensive production readiness analysis covering configuration, monitoring, error handling, performance, security, and deployment considerations.
+
+## Parse User Request
+
+**Determine the following from the user's request:**
+
+1. **Path to analyze**:
+   - If provided: Use the specified path
+   - If not provided: Use question to ask what to check
+
+2. **Target environment**:
+   - If `--target=prod`: Full production checks (recommended)
+   - If `--target=staging`: Relaxed staging checks
+   - If not specified: Assume production (full rigor)
+
+## Your Instructions
+
+**Invoke the production-readiness-checker subagent NOW using the Task tool:**
+
+```
+Use Task tool:
+  subagent_type: "production-readiness-checker"
+  description: "Production readiness check"
+  prompt: |
+    Verify production readiness at: [path from user or from question]
+    Target: [production|staging]
+    Report path: [path]/production-readiness-report.md
+```
+
+**Wait for the subagent to complete before proceeding.**
+
+The production-readiness-checker subagent will:
+
+1. Verify configuration management (env vars, secrets, feature flags)
+2. Check monitoring & observability (logging, metrics, error tracking, health checks)
+3. Assess error handling & resilience (retries, circuit breakers, graceful shutdown)
+4. Evaluate performance & scalability (connection pooling, caching, rate limiting)
+5. Review security hardening (HTTPS, CORS, security headers, vulnerabilities)
+6. Analyze deployment considerations (migrations, zero-downtime, rollback plan)
+7. Generate go/no-go deployment recommendation
+
+## Examples
+
+**Example 1**: Check specific task for production
+
+```
+User: /reviews-production-readiness .owflow/tasks/development/2025-10-24-payment-api/
+```
+
+**Example 2**: Check feature for staging
+
+```
+User: /reviews-production-readiness src/features/notifications/ --target=staging
+```
+
+**Example 3**: Comprehensive project check
+
+```
+User: /reviews-production-readiness .
+```
+
+## What to Expect
+
+The production-readiness-checker will provide:
+
+- Overall readiness score and status (Ready / Concerns / Not Ready)
+- Clear GO/NO-GO deployment decision
+- Category scores (Configuration, Monitoring, Error Handling, Performance, Security, Deployment)
+- Deployment blockers that must be fixed
+- Concerns with mitigation plans
+- Recommendations for improvements
+- Risk assessment and rollback criteria
+- Post-deployment verification checklist
+
+## Deployment Decision Outcomes
+
+**Ready to Deploy**:
+
+- All critical checks passed
+- Low risk deployment
+- Optional improvements listed
+
+**Deploy with Caution**:
+
+- No blockers but concerns exist
+- Mitigation plan required
+- Close monitoring needed
+- Medium risk
+
+**Do Not Deploy**:
+
+- Critical issues present
+- High/critical risk
+- Must fix before deployment
+
+## Notes
+
+- This is verification only - no code will be modified
+- Production checks are more rigorous than staging
+- Focus on required items first (deployment blockers)
+- Strongly recommended items should be addressed or have mitigation plan
+- Nice to have items can be addressed post-deployment