compound-workflow 1.8.0 → 1.9.0

package/src/.agents/skills/react-ddd-mvc-frontend/SKILL.md

@@ -1,51 +0,0 @@
----
-name: react-ddd-mvc-frontend
-description: Apply React frontend architecture standards using a DDD + MVC hybrid. Use when planning or reviewing frontend work to enforce domain-based feature structure, clear layer boundaries, composable pure components, container-driven composition, and XState controller integration.
----
-
-# React DDD + MVC Frontend Standards
-
-Use this skill as a reference standard during brainstorming, planning, implementation, and code review for frontend work.
-
-## Workflow
-
-1. Confirm frontend applicability.
-- Use this skill when work changes React UI architecture, feature structure, components, containers, hooks, services, or controller state flow.
-- Skip when no frontend surface is affected.
-
-2. Load standards baseline.
-- Start with [references/source-map.md](references/source-map.md).
-- Load [references/feature-structure.md](references/feature-structure.md) and [references/responsibility-gates.md](references/responsibility-gates.md) first.
-
-3. Enforce feature-by-domain structure.
-- Group items into domains.
-- Default location: `src/features/<feature-name>/`.
-- Allow shared concerns under `src/features/common/` only when genuinely cross-domain.
-
-4. Enforce DDD + MVC boundaries.
-- Keep domain entities in `domain/entities`.
-- Keep presentation concerns in `presentation`.
-- Keep orchestration and composition in `application`.
-- Keep IO adapters in `infrastructure`.
-
-5. Apply controller/machine guidance.
-- Controllers are XState machines in `application/controller`.
-- For XState orchestration patterns, defer to `xstate-actor-orchestration`.
-
-6. Apply coding style constraints.
-- Prefer immutability and functional patterns.
-- Apply YAGNI to avoid speculative abstractions.
-- Optimize for simplicity, maintainability, and readability.
-
-## Output Contract
-
-When used in planning:
-- Use applicable MUST gates as a checklist to shape acceptance criteria.
-- Call out any boundary exceptions and rationale.
-
-When used in review:
-- Report MUST violations as high-priority findings by default.
-- Report SHOULD violations as improvement findings.
-
-When used in brainstorm/work:
-- Use the structure and gates as reference guidance, not as a hard precondition.

package/src/.agents/skills/react-ddd-mvc-frontend/references/feature-structure.md

@@ -1,25 +0,0 @@
-# Feature Structure (DDD + MVC Hybrid)
-
-Default structure for each frontend feature:
-
-```text
-src/features/<feature-name>/
-  application/
-    containers/
-    controller/
-  domain/
-    entities/
-  presentation/
-    components/
-    layout/
-  infrastructure/
-    services/
-    mock-services/
-```
-
-## Notes
-
-- Group work by domain.
-- Use `src/features/common/` only for cross-domain shared concerns.
-- Keep the shape consistent across features unless there is a clear, documented reason to deviate.
-

package/src/.agents/skills/react-ddd-mvc-frontend/references/implementation-principles.md

@@ -1,21 +0,0 @@
-# Implementation Principles
-
-## Hooks
-
-- Use hooks to provide common access patterns and shared feature wiring.
-- Keep hooks focused and reusable; avoid mixing unrelated responsibilities.
-
-## Immutability and Functional Style
-
-- Prefer immutable updates and pure transformations.
-- Avoid hidden in-place mutation across layers.
-
-## Simplicity (YAGNI)
-
-- Do not add speculative abstractions or layers before they are needed.
-- Optimize for readability and maintainability over cleverness.
-
-## Boundary Reminder
-
-- If a change requires complex machine orchestration, use `xstate-actor-orchestration` as the source of truth for machine patterns.
-

package/src/.agents/skills/react-ddd-mvc-frontend/references/responsibility-gates.md

@@ -1,41 +0,0 @@
-# Responsibility Gates
-
-Apply these gates as default guidance in planning and review.
-Use pragmatic judgment and allow justified deviations when context requires.
-
-## MUST Gates
-
-1. Feature placement:
-- Frontend feature code is placed in `src/features/<feature-name>/` using the canonical layer layout.
-
-2. Presentation purity:
-- `presentation/components` remain composable and controlled/pure.
-- UI components do not perform API calls or domain decision logic.
-
-3. Container ownership:
-- `application/containers` own composition, state wiring, translations, and context wiring.
-
-4. Controller ownership:
-- `application/controller` contains XState machine controllers for feature state flow.
-- Any advanced orchestration patterns defer to `xstate-actor-orchestration`.
-
-5. Domain isolation:
-- `domain/entities` owns domain entities and related core domain representation.
-
-6. Infrastructure isolation:
-- `infrastructure/services` and `infrastructure/mock-services` own IO integrations and test/mock adapters.
-
-## SHOULD Gates
-
-1. Reuse hooks for common access patterns instead of duplicating wiring logic.
-2. Keep files single-purpose and avoid multi-layer mixing in one module.
-3. Keep naming consistent with feature and domain language.
-
-## Planning Gate
-
-- Use applicable MUST gates to inform acceptance criteria.
-
-## Review Gate
-
-- MUST violations are high-priority by default.
-- SHOULD violations are non-blocking unless repeated patterns create maintainability risk.

package/src/.agents/skills/react-ddd-mvc-frontend/references/source-map.md

@@ -1,11 +0,0 @@
-# Source Map
-
-Load these references as needed:
-
-- Feature folder and canonical layout:
-  - [feature-structure.md](feature-structure.md)
-- Layer responsibilities and review gates:
-  - [responsibility-gates.md](responsibility-gates.md)
-- Hooks, immutability, and simplicity rules:
-  - [implementation-principles.md](implementation-principles.md)
-