owflow 0.6.0 → 0.7.0

package/dist/skills/docs-manager/docs/standards/frontend/components.md

@@ -1,28 +1,28 @@
-## Components
-
-### Single Responsibility
-Each component should do one thing well.
-
-### Reusability
-Design components to work across different contexts with configurable props.
-
-### Composability
-Build complex UIs by combining smaller components rather than creating monoliths.
-
-### Clear Interface
-Define explicit, documented props with sensible defaults.
-
-### Encapsulation
-Keep implementation details private; expose only what's necessary.
-
-### Consistent Naming
-Use descriptive names that indicate purpose and follow team conventions.
-
-### Local State
-Keep state as close to where it's used as possible; lift only when needed.
-
-### Minimal Props
-If a component needs many props, consider composition or splitting it.
-
-### Documentation
-Document usage, props, and examples to help team adoption.
+## Components
+
+### Single Responsibility
+Each component should do one thing well.
+
+### Reusability
+Design components to work across different contexts with configurable props.
+
+### Composability
+Build complex UIs by combining smaller components rather than creating monoliths.
+
+### Clear Interface
+Define explicit, documented props with sensible defaults.
+
+### Encapsulation
+Keep implementation details private; expose only what's necessary.
+
+### Consistent Naming
+Use descriptive names that indicate purpose and follow team conventions.
+
+### Local State
+Keep state as close to where it's used as possible; lift only when needed.
+
+### Minimal Props
+If a component needs many props, consider composition or splitting it.
+
+### Documentation
+Document usage, props, and examples to help team adoption.

package/dist/skills/docs-manager/docs/standards/frontend/css.md

@@ -1,16 +1,16 @@
-## CSS
-
-### Consistent Methodology
-Stick to the project's chosen approach (Tailwind, BEM, CSS modules, etc.) across the entire codebase.
-
-### Work With the Framework
-Use framework patterns as intended rather than fighting them with excessive overrides.
-
-### Design Tokens
-Establish and document consistent values for colors, spacing, and typography.
-
-### Minimize Custom CSS
-Prefer framework utilities to reduce custom styling maintenance.
-
-### Production Optimization
-Use CSS purging or tree-shaking to remove unused styles.
+## CSS
+
+### Consistent Methodology
+Stick to the project's chosen approach (Tailwind, BEM, CSS modules, etc.) across the entire codebase.
+
+### Work With the Framework
+Use framework patterns as intended rather than fighting them with excessive overrides.
+
+### Design Tokens
+Establish and document consistent values for colors, spacing, and typography.
+
+### Minimize Custom CSS
+Prefer framework utilities to reduce custom styling maintenance.
+
+### Production Optimization
+Use CSS purging or tree-shaking to remove unused styles.

package/dist/skills/docs-manager/docs/standards/frontend/responsive.md

@@ -1,28 +1,28 @@
-## Responsive Design
-
-### Mobile-First
-Start with mobile layout and progressively enhance for larger screens.
-
-### Standard Breakpoints
-Use consistent breakpoints (mobile, tablet, desktop) across the application.
-
-### Fluid Layouts
-Use percentage-based widths and flexible containers that adapt to screen size.
-
-### Relative Units
-Prefer rem/em over fixed pixels for better scalability.
-
-### Cross-Device Testing
-Test across multiple screen sizes to ensure a balanced experience.
-
-### Touch-Friendly
-Size tap targets appropriately (minimum 44x44px) for mobile users.
-
-### Mobile Performance
-Optimize images and assets for mobile network conditions.
-
-### Readable Typography
-Maintain readable font sizes across all breakpoints.
-
-### Content Priority
-Show the most important content first on smaller screens.
+## Responsive Design
+
+### Mobile-First
+Start with mobile layout and progressively enhance for larger screens.
+
+### Standard Breakpoints
+Use consistent breakpoints (mobile, tablet, desktop) across the application.
+
+### Fluid Layouts
+Use percentage-based widths and flexible containers that adapt to screen size.
+
+### Relative Units
+Prefer rem/em over fixed pixels for better scalability.
+
+### Cross-Device Testing
+Test across multiple screen sizes to ensure a balanced experience.
+
+### Touch-Friendly
+Size tap targets appropriately (minimum 44x44px) for mobile users.
+
+### Mobile Performance
+Optimize images and assets for mobile network conditions.
+
+### Readable Typography
+Maintain readable font sizes across all breakpoints.
+
+### Content Priority
+Show the most important content first on smaller screens.

package/dist/skills/docs-manager/docs/standards/global/coding-style.md

@@ -1,25 +1,25 @@
-## Coding Style
-
-### Naming Consistency
-Follow established naming patterns for variables, functions, classes, and files throughout the project.
-
-### Automatic Formatting
-Use automated tools to enforce consistent indentation, spacing, and line breaks.
-
-### Descriptive Names
-Choose names that clearly communicate intent; avoid cryptic abbreviations or single-letter identifiers outside tight loops.
-
-### Focused Functions
-Write functions that do one thing well; smaller functions are easier to read, test, and maintain.
-
-### Uniform Indentation
-Standardize on spaces or tabs and enforce with editor/linter settings.
-
-### No Dead Code
-Remove unused imports, commented-out blocks, and orphaned functions instead of leaving them behind.
-
-### No Backward Compatibility Unless Required
-Avoid extra code paths for backward compatibility unless explicitly needed.
-
-### DRY (Don't Repeat Yourself)
-Extract repeated logic into reusable functions or modules.
+## Coding Style
+
+### Naming Consistency
+Follow established naming patterns for variables, functions, classes, and files throughout the project.
+
+### Automatic Formatting
+Use automated tools to enforce consistent indentation, spacing, and line breaks.
+
+### Descriptive Names
+Choose names that clearly communicate intent; avoid cryptic abbreviations or single-letter identifiers outside tight loops.
+
+### Focused Functions
+Write functions that do one thing well; smaller functions are easier to read, test, and maintain.
+
+### Uniform Indentation
+Standardize on spaces or tabs and enforce with editor/linter settings.
+
+### No Dead Code
+Remove unused imports, commented-out blocks, and orphaned functions instead of leaving them behind.
+
+### No Backward Compatibility Unless Required
+Avoid extra code paths for backward compatibility unless explicitly needed.
+
+### DRY (Don't Repeat Yourself)
+Extract repeated logic into reusable functions or modules.

package/dist/skills/docs-manager/docs/standards/global/commenting.md

@@ -1,10 +1,10 @@
-## Commenting
-
-### Let Code Speak
-Write code that explains itself through structure and naming.
-
-### Comment Sparingly
-Add brief comments only when the logic isn't self-evident from the code.
-
-### No Change Comments
-Avoid comments about recent fixes or changes; comments should be timeless explanations, not changelogs.
+## Commenting
+
+### Let Code Speak
+Write code that explains itself through structure and naming.
+
+### Comment Sparingly
+Add brief comments only when the logic isn't self-evident from the code.
+
+### No Change Comments
+Avoid comments about recent fixes or changes; comments should be timeless explanations, not changelogs.

package/dist/skills/docs-manager/docs/standards/global/conventions.md

@@ -1,31 +1,31 @@
-## Development Conventions
-
-### Predictable Structure
-Organize files and directories in a logical, navigable layout.
-
-### Up-to-Date Documentation
-Keep README files current with setup steps, architecture overview, and contribution guidelines.
-
-### Clean Version Control
-Write clear commit messages, use feature branches, and add meaningful descriptions to pull requests.
-
-### Environment Variables
-Store configuration in environment variables; never commit secrets or API keys.
-
-### Minimal Dependencies
-Keep dependencies lean and up-to-date; document why major ones are included.
-
-### Consistent Reviews
-Follow a defined code review process with clear expectations for reviewers and authors.
-
-### Testing Standards
-Define required test coverage (unit, integration, etc.) before merging.
-
-### Feature Flags
-Use flags for incomplete features instead of long-lived branches.
-
-### Changelog Updates
-Maintain a changelog or release notes for significant changes.
-
-### Build What's Needed
-Avoid speculative code and "just in case" additions (see minimal-implementation.md).
+## Development Conventions
+
+### Predictable Structure
+Organize files and directories in a logical, navigable layout.
+
+### Up-to-Date Documentation
+Keep README files current with setup steps, architecture overview, and contribution guidelines.
+
+### Clean Version Control
+Write clear commit messages, use feature branches, and add meaningful descriptions to pull requests.
+
+### Environment Variables
+Store configuration in environment variables; never commit secrets or API keys.
+
+### Minimal Dependencies
+Keep dependencies lean and up-to-date; document why major ones are included.
+
+### Consistent Reviews
+Follow a defined code review process with clear expectations for reviewers and authors.
+
+### Testing Standards
+Define required test coverage (unit, integration, etc.) before merging.
+
+### Feature Flags
+Use flags for incomplete features instead of long-lived branches.
+
+### Changelog Updates
+Maintain a changelog or release notes for significant changes.
+
+### Build What's Needed
+Avoid speculative code and "just in case" additions (see minimal-implementation.md).

package/dist/skills/docs-manager/docs/standards/global/error-handling.md

@@ -1,22 +1,22 @@
-## Error Handling
-
-### Clear User Messages
-Show helpful, actionable messages without exposing internal details or security-sensitive information.
-
-### Fail Fast
-Validate inputs and check preconditions early; reject invalid data before it causes deeper issues.
-
-### Typed Exceptions
-Use specific exception types instead of generic ones to enable precise error handling.
-
-### Centralized Handling
-Catch and process errors at appropriate boundaries (controllers, API layers) rather than scattering try-catch throughout.
-
-### Graceful Degradation
-When non-critical services fail, continue operating with reduced functionality rather than crashing entirely.
-
-### Retry with Backoff
-Use exponential backoff for transient failures when calling external services.
-
-### Resource Cleanup
-Always release resources (file handles, connections) in finally blocks or equivalent cleanup mechanisms.
+## Error Handling
+
+### Clear User Messages
+Show helpful, actionable messages without exposing internal details or security-sensitive information.
+
+### Fail Fast
+Validate inputs and check preconditions early; reject invalid data before it causes deeper issues.
+
+### Typed Exceptions
+Use specific exception types instead of generic ones to enable precise error handling.
+
+### Centralized Handling
+Catch and process errors at appropriate boundaries (controllers, API layers) rather than scattering try-catch throughout.
+
+### Graceful Degradation
+When non-critical services fail, continue operating with reduced functionality rather than crashing entirely.
+
+### Retry with Backoff
+Use exponential backoff for transient failures when calling external services.
+
+### Resource Cleanup
+Always release resources (file handles, connections) in finally blocks or equivalent cleanup mechanisms.

package/dist/skills/docs-manager/docs/standards/global/minimal-implementation.md

@@ -1,22 +1,22 @@
-## Minimal Implementation
-
-### Build What You Need
-Create only methods, classes, and functions that will actually be called.
-
-### Clear Purpose
-Every method should either be called or improve code readability; nothing else.
-
-### Delete Exploration Artifacts
-Remove helper methods and utilities created during development that ended up unused.
-
-### No Future Stubs
-Avoid empty methods, placeholder functions, or interfaces "for future extensibility".
-
-### No Speculative Abstractions
-Skip factories, strategies, or adapters unless there's an immediate need.
-
-### Review Before Commit
-Verify all new methods have callers or serve a clear readability purpose before completing a task.
-
-### Unused Code Is Debt
-Remove dead code promptly; it confuses readers and adds maintenance burden.
+## Minimal Implementation
+
+### Build What You Need
+Create only methods, classes, and functions that will actually be called.
+
+### Clear Purpose
+Every method should either be called or improve code readability; nothing else.
+
+### Delete Exploration Artifacts
+Remove helper methods and utilities created during development that ended up unused.
+
+### No Future Stubs
+Avoid empty methods, placeholder functions, or interfaces "for future extensibility".
+
+### No Speculative Abstractions
+Skip factories, strategies, or adapters unless there's an immediate need.
+
+### Review Before Commit
+Verify all new methods have callers or serve a clear readability purpose before completing a task.
+
+### Unused Code Is Debt
+Remove dead code promptly; it confuses readers and adds maintenance burden.

package/dist/skills/docs-manager/docs/standards/global/validation.md

@@ -1,28 +1,28 @@
-## Validation
-
-### Server-Side Always
-Validate on the server; client-side validation alone is insufficient for security and data integrity.
-
-### Client-Side for Feedback
-Use client-side validation for immediate user feedback, but duplicate checks server-side.
-
-### Validate Early
-Check inputs as early as possible and reject invalid data before processing.
-
-### Specific Errors
-Provide clear, field-specific messages that help users correct their input.
-
-### Allowlists Over Blocklists
-Define what's allowed rather than trying to block everything else.
-
-### Type and Format Checks
-Validate data types, formats, ranges, and required fields systematically.
-
-### Input Sanitization
-Sanitize user input to prevent injection attacks (SQL, XSS, command injection).
-
-### Business Rules
-Validate business logic (sufficient balance, valid dates) at the appropriate layer.
-
-### Consistent Enforcement
-Apply validation uniformly across all entry points (forms, APIs, background jobs).
+## Validation
+
+### Server-Side Always
+Validate on the server; client-side validation alone is insufficient for security and data integrity.
+
+### Client-Side for Feedback
+Use client-side validation for immediate user feedback, but duplicate checks server-side.
+
+### Validate Early
+Check inputs as early as possible and reject invalid data before processing.
+
+### Specific Errors
+Provide clear, field-specific messages that help users correct their input.
+
+### Allowlists Over Blocklists
+Define what's allowed rather than trying to block everything else.
+
+### Type and Format Checks
+Validate data types, formats, ranges, and required fields systematically.
+
+### Input Sanitization
+Sanitize user input to prevent injection attacks (SQL, XSS, command injection).
+
+### Business Rules
+Validate business logic (sufficient balance, valid dates) at the appropriate layer.
+
+### Consistent Enforcement
+Apply validation uniformly across all entry points (forms, APIs, background jobs).

package/dist/skills/docs-manager/docs/standards/testing/test-writing.md

@@ -1,25 +1,25 @@
-## Test Writing
-
-### Test Behavior
-Focus on what code does, not how it does it, to allow safe refactoring.
-
-### Clear Names
-Use descriptive names explaining what's tested and expected (`shouldReturnErrorWhenUserNotFound`).
-
-### Mock External Dependencies
-Isolate tests by mocking databases, APIs, and external services.
-
-### Fast Execution
-Keep unit tests fast (milliseconds) so developers run them frequently.
-
-### Risk-Based Testing
-Prioritize testing based on business criticality and likelihood of bugs.
-
-### Balance Coverage and Velocity
-Adjust test coverage based on project needs and team workflow.
-
-### Critical Path Focus
-Ensure core user workflows and critical business logic are well-tested.
-
-### Appropriate Depth
-Match edge case testing to the risk profile of the code.
+## Test Writing
+
+### Test Behavior
+Focus on what code does, not how it does it, to allow safe refactoring.
+
+### Clear Names
+Use descriptive names explaining what's tested and expected (`shouldReturnErrorWhenUserNotFound`).
+
+### Mock External Dependencies
+Isolate tests by mocking databases, APIs, and external services.
+
+### Fast Execution
+Keep unit tests fast (milliseconds) so developers run them frequently.
+
+### Risk-Based Testing
+Prioritize testing based on business criticality and likelihood of bugs.
+
+### Balance Coverage and Velocity
+Adjust test coverage based on project needs and team workflow.
+
+### Critical Path Focus
+Ensure core user workflows and critical business logic are well-tested.
+
+### Appropriate Depth
+Match edge case testing to the risk profile of the code.

package/dist/skills/docs-manager/references/agents-md-template.md

@@ -1,29 +1,29 @@
-# AGENTS.md Documentation Section Template
-
-Add this section to the project's `AGENTS.md` file. Place it prominently near the top. Verify the INDEX.md path is correct and the file exists before adding.
-
-```markdown
-## Coding Standards & Conventions
-
-Read @.owflow/docs/INDEX.md before starting any task. It indexes the project's coding standards and conventions:
-
-- Coding standards organized by domain (frontend, backend, testing, etc.)
-- Project vision, tech stack, and architecture decisions
-
-Follow standards in `.owflow/docs/standards/` when writing code — they represent team decisions. If standards conflict with the task, ask the user.
-
-### Standards Evolution
-
-When you notice recurring patterns, fixes, or conventions during implementation that aren't yet captured in standards — suggest adding them. Examples:
-
-- A bug fix reveals a pattern that should be standardized (e.g., "always validate X before Y")
-- PR review feedback identifies a convention the team wants enforced
-- The same type of fix is needed across multiple files
-- A new library/pattern is adopted that should be documented
-
-When this happens, briefly suggest the standard to the user. If approved, invoke `/owflow:standards-update` with the identified pattern.
-
-## owflow Workflows
-
-This project uses the owflow plugin for structured development workflows. When any `/*` command is invoked, execute it via the Skill tool immediately — do not skip workflows for "straightforward" tasks. The user chose the workflow intentionally; complexity assessment is the workflow's job.
-```
+# AGENTS.md Documentation Section Template
+
+Add this section to the project's `AGENTS.md` file. Place it prominently near the top. Verify the INDEX.md path is correct and the file exists before adding.
+
+```markdown
+## Coding Standards & Conventions
+
+Read @.owflow/docs/INDEX.md before starting any task. It indexes the project's coding standards and conventions:
+
+- Coding standards organized by domain (frontend, backend, testing, etc.)
+- Project vision, tech stack, and architecture decisions
+
+Follow standards in `.owflow/docs/standards/` when writing code — they represent team decisions. If standards conflict with the task, ask the user.
+
+### Standards Evolution
+
+When you notice recurring patterns, fixes, or conventions during implementation that aren't yet captured in standards — suggest adding them. Examples:
+
+- A bug fix reveals a pattern that should be standardized (e.g., "always validate X before Y")
+- PR review feedback identifies a convention the team wants enforced
+- The same type of fix is needed across multiple files
+- A new library/pattern is adopted that should be documented
+
+When this happens, briefly suggest the standard to the user. If approved, invoke `/owflow:standards-update` with the identified pattern.
+
+## owflow Workflows
+
+This project uses the owflow plugin for structured development workflows. When any `/*` command is invoked, execute it via the Skill tool immediately — do not skip workflows for "straightforward" tasks. The user chose the workflow intentionally; complexity assessment is the workflow's job.
+```