codeply-cli 0.3.1 → 0.4.1

package/skills/laravel-verification/SKILL.md

@@ -1,180 +1,180 @@
----
-name: laravel-verification
-description: "Verification loop for Laravel projects: env checks, linting, static analysis, tests with coverage, security scans, and deployment readiness."
-metadata:
-  origin: ECC
----
-
-# Laravel Verification Loop
-
-Run before PRs, after major changes, and pre-deploy.
-
-## When to Use
-
-- Before opening a pull request for a Laravel project
-- After major refactors or dependency upgrades
-- Pre-deployment verification for staging or production
-- Running full lint -> test -> security -> deploy readiness pipeline
-
-## How It Works
-
-- Run phases sequentially from environment checks through deployment readiness so each layer builds on the last.
-- Environment and Composer checks gate everything else; stop immediately if they fail.
-- Linting/static analysis should be clean before running full tests and coverage.
-- Security and migration reviews happen after tests so you verify behavior before data or release steps.
-- Build/deploy readiness and queue/scheduler checks are final gates; any failure blocks release.
-
-## Phase 1: Environment Checks
-
-```bash
-php -v
-composer --version
-php artisan --version
-```
-
-- Verify `.env` is present and required keys exist
-- Confirm `APP_DEBUG=false` for production environments
-- Confirm `APP_ENV` matches the target deployment (`production`, `staging`)
-
-If using Laravel Sail locally:
-
-```bash
-./vendor/bin/sail php -v
-./vendor/bin/sail artisan --version
-```
-
-## Phase 1.5: Composer and Autoload
-
-```bash
-composer validate
-composer dump-autoload -o
-```
-
-## Phase 2: Linting and Static Analysis
-
-```bash
-vendor/bin/pint --test
-vendor/bin/phpstan analyse
-```
-
-If your project uses Psalm instead of PHPStan:
-
-```bash
-vendor/bin/psalm
-```
-
-## Phase 3: Tests and Coverage
-
-```bash
-php artisan test
-```
-
-Coverage (CI):
-
-```bash
-XDEBUG_MODE=coverage php artisan test --coverage
-```
-
-CI example (format -> static analysis -> tests):
-
-```bash
-vendor/bin/pint --test
-vendor/bin/phpstan analyse
-XDEBUG_MODE=coverage php artisan test --coverage
-```
-
-## Phase 4: Security and Dependency Checks
-
-```bash
-composer audit
-```
-
-## Phase 5: Database and Migrations
-
-```bash
-php artisan migrate --pretend
-php artisan migrate:status
-```
-
-- Review destructive migrations carefully
-- Ensure migration filenames follow `Y_m_d_His_*` (e.g., `2025_03_14_154210_create_orders_table.php`) and describe the change clearly
-- Ensure rollbacks are possible
-- Verify `down()` methods and avoid irreversible data loss without explicit backups
-
-## Phase 6: Build and Deployment Readiness
-
-```bash
-php artisan optimize:clear
-php artisan config:cache
-php artisan route:cache
-php artisan view:cache
-```
-
-- Ensure cache warmups succeed in production configuration
-- Verify queue workers and scheduler are configured
-- Confirm `storage/` and `bootstrap/cache/` are writable in the target environment
-
-## Phase 7: Queue and Scheduler Checks
-
-```bash
-php artisan schedule:list
-php artisan queue:failed
-```
-
-If Horizon is used:
-
-```bash
-php artisan horizon:status
-```
-
-If `queue:monitor` is available, use it to check backlog without processing jobs:
-
-```bash
-php artisan queue:monitor default --max=100
-```
-
-Active verification (staging only): dispatch a no-op job to a dedicated queue and run a single worker to process it (ensure a non-`sync` queue connection is configured).
-
-```bash
-php artisan tinker --execute="dispatch((new App\\Jobs\\QueueHealthcheck())->onQueue('healthcheck'))"
-php artisan queue:work --once --queue=healthcheck
-```
-
-Verify the job produced the expected side effect (log entry, healthcheck table row, or metric).
-
-Only run this on non-production environments where processing a test job is safe.
-
-## Examples
-
-Minimal flow:
-
-```bash
-php -v
-composer --version
-php artisan --version
-composer validate
-vendor/bin/pint --test
-vendor/bin/phpstan analyse
-php artisan test
-composer audit
-php artisan migrate --pretend
-php artisan config:cache
-php artisan queue:failed
-```
-
-CI-style pipeline:
-
-```bash
-composer validate
-composer dump-autoload -o
-vendor/bin/pint --test
-vendor/bin/phpstan analyse
-XDEBUG_MODE=coverage php artisan test --coverage
-composer audit
-php artisan migrate --pretend
-php artisan optimize:clear
-php artisan config:cache
-php artisan route:cache
-php artisan view:cache
-php artisan schedule:list
-```
+---
+name: laravel-verification
+description: "Verification loop for Laravel projects: env checks, linting, static analysis, tests with coverage, security scans, and deployment readiness."
+metadata:
+  origin: ECC
+---
+
+# Laravel Verification Loop
+
+Run before PRs, after major changes, and pre-deploy.
+
+## When to Use
+
+- Before opening a pull request for a Laravel project
+- After major refactors or dependency upgrades
+- Pre-deployment verification for staging or production
+- Running full lint -> test -> security -> deploy readiness pipeline
+
+## How It Works
+
+- Run phases sequentially from environment checks through deployment readiness so each layer builds on the last.
+- Environment and Composer checks gate everything else; stop immediately if they fail.
+- Linting/static analysis should be clean before running full tests and coverage.
+- Security and migration reviews happen after tests so you verify behavior before data or release steps.
+- Build/deploy readiness and queue/scheduler checks are final gates; any failure blocks release.
+
+## Phase 1: Environment Checks
+
+```bash
+php -v
+composer --version
+php artisan --version
+```
+
+- Verify `.env` is present and required keys exist
+- Confirm `APP_DEBUG=false` for production environments
+- Confirm `APP_ENV` matches the target deployment (`production`, `staging`)
+
+If using Laravel Sail locally:
+
+```bash
+./vendor/bin/sail php -v
+./vendor/bin/sail artisan --version
+```
+
+## Phase 1.5: Composer and Autoload
+
+```bash
+composer validate
+composer dump-autoload -o
+```
+
+## Phase 2: Linting and Static Analysis
+
+```bash
+vendor/bin/pint --test
+vendor/bin/phpstan analyse
+```
+
+If your project uses Psalm instead of PHPStan:
+
+```bash
+vendor/bin/psalm
+```
+
+## Phase 3: Tests and Coverage
+
+```bash
+php artisan test
+```
+
+Coverage (CI):
+
+```bash
+XDEBUG_MODE=coverage php artisan test --coverage
+```
+
+CI example (format -> static analysis -> tests):
+
+```bash
+vendor/bin/pint --test
+vendor/bin/phpstan analyse
+XDEBUG_MODE=coverage php artisan test --coverage
+```
+
+## Phase 4: Security and Dependency Checks
+
+```bash
+composer audit
+```
+
+## Phase 5: Database and Migrations
+
+```bash
+php artisan migrate --pretend
+php artisan migrate:status
+```
+
+- Review destructive migrations carefully
+- Ensure migration filenames follow `Y_m_d_His_*` (e.g., `2025_03_14_154210_create_orders_table.php`) and describe the change clearly
+- Ensure rollbacks are possible
+- Verify `down()` methods and avoid irreversible data loss without explicit backups
+
+## Phase 6: Build and Deployment Readiness
+
+```bash
+php artisan optimize:clear
+php artisan config:cache
+php artisan route:cache
+php artisan view:cache
+```
+
+- Ensure cache warmups succeed in production configuration
+- Verify queue workers and scheduler are configured
+- Confirm `storage/` and `bootstrap/cache/` are writable in the target environment
+
+## Phase 7: Queue and Scheduler Checks
+
+```bash
+php artisan schedule:list
+php artisan queue:failed
+```
+
+If Horizon is used:
+
+```bash
+php artisan horizon:status
+```
+
+If `queue:monitor` is available, use it to check backlog without processing jobs:
+
+```bash
+php artisan queue:monitor default --max=100
+```
+
+Active verification (staging only): dispatch a no-op job to a dedicated queue and run a single worker to process it (ensure a non-`sync` queue connection is configured).
+
+```bash
+php artisan tinker --execute="dispatch((new App\\Jobs\\QueueHealthcheck())->onQueue('healthcheck'))"
+php artisan queue:work --once --queue=healthcheck
+```
+
+Verify the job produced the expected side effect (log entry, healthcheck table row, or metric).
+
+Only run this on non-production environments where processing a test job is safe.
+
+## Examples
+
+Minimal flow:
+
+```bash
+php -v
+composer --version
+php artisan --version
+composer validate
+vendor/bin/pint --test
+vendor/bin/phpstan analyse
+php artisan test
+composer audit
+php artisan migrate --pretend
+php artisan config:cache
+php artisan queue:failed
+```
+
+CI-style pipeline:
+
+```bash
+composer validate
+composer dump-autoload -o
+vendor/bin/pint --test
+vendor/bin/phpstan analyse
+XDEBUG_MODE=coverage php artisan test --coverage
+composer audit
+php artisan migrate --pretend
+php artisan optimize:clear
+php artisan config:cache
+php artisan route:cache
+php artisan view:cache
+php artisan schedule:list
+```

package/skills/latency-critical-systems/SKILL.md

@@ -1,75 +1,75 @@
----
-name: latency-critical-systems
-description: Use for latency-sensitive systems such as realtime dashboards, market data, streaming agents, execution gateways, queues, caches, or HFT-like infrastructure where freshness and p95 latency matter.
-license: MIT
-metadata:
-  origin: ECC
-tools: Read, Write, Edit, Bash, Grep, Glob
----
-
-# Latency Critical Systems
-
-Use this skill when the user cares about realtime behavior, hot paths, streaming
-freshness, or execution speed. This includes HFT-like infrastructure, but the
-skill is engineering-focused. It does not authorize live trading or financial
-advice.
-
-## Split The Metrics
-
-Do not collapse everything into "fast." Track:
-
-- p50, p95, and p99 latency;
-- throughput;
-- freshness age;
-- queue depth;
-- cache hit rate;
-- provider/API response time;
-- browser render time;
-- correctness under load;
-- failure and retry behavior.
-
-## Map The Hot Path
-
-Write the path from user/event to final visible state:
-
-```text
-source event -> provider API -> ingest worker -> queue -> cache -> edge route
--> client stream -> browser render -> user-visible state
-```
-
-Then measure each segment separately.
-
-## Optimization Order
-
-1. Remove unnecessary round trips.
-2. Cache stable reads with freshness metadata.
-3. Batch small calls and writes.
-4. Move compute closer to the data or the user.
-5. Split hot and cold paths.
-6. Apply backpressure before queues grow unbounded.
-7. Use streaming only when it improves freshness or user experience.
-8. Add canaries for stale data, degraded providers, and bad cache state.
-
-## Verification
-
-Use live readbacks when a deployed surface exists:
-
-- HTTP timing and response headers;
-- provider freshness timestamp;
-- queue or job state;
-- edge/cache state;
-- browser verification for actual UI freshness;
-- logs around retries and degraded mode.
-
-For market-data or execution-adjacent paths, also verify orderbook age, VWAP
-assumptions, provider status, and kill-switch behavior before calling the path
-ready.
-
-## Guardrails
-
-- Do not optimize latency by dropping required validation.
-- Do not hide stale data behind fast cache hits.
-- Do not claim millisecond behavior from client labels without measurement.
-- Do not run live orders, destructive migrations, or customer-impacting deploys
-  without an explicit approval gate.
-- Keep secrets and private payloads out of logs and benchmark artifacts.
+---
+name: latency-critical-systems
+description: Use for latency-sensitive systems such as realtime dashboards, market data, streaming agents, execution gateways, queues, caches, or HFT-like infrastructure where freshness and p95 latency matter.
+license: MIT
+metadata:
+  origin: ECC
+tools: Read, Write, Edit, Bash, Grep, Glob
+---
+
+# Latency Critical Systems
+
+Use this skill when the user cares about realtime behavior, hot paths, streaming
+freshness, or execution speed. This includes HFT-like infrastructure, but the
+skill is engineering-focused. It does not authorize live trading or financial
+advice.
+
+## Split The Metrics
+
+Do not collapse everything into "fast." Track:
+
+- p50, p95, and p99 latency;
+- throughput;
+- freshness age;
+- queue depth;
+- cache hit rate;
+- provider/API response time;
+- browser render time;
+- correctness under load;
+- failure and retry behavior.
+
+## Map The Hot Path
+
+Write the path from user/event to final visible state:
+
+```text
+source event -> provider API -> ingest worker -> queue -> cache -> edge route
+-> client stream -> browser render -> user-visible state
+```
+
+Then measure each segment separately.
+
+## Optimization Order
+
+1. Remove unnecessary round trips.
+2. Cache stable reads with freshness metadata.
+3. Batch small calls and writes.
+4. Move compute closer to the data or the user.
+5. Split hot and cold paths.
+6. Apply backpressure before queues grow unbounded.
+7. Use streaming only when it improves freshness or user experience.
+8. Add canaries for stale data, degraded providers, and bad cache state.
+
+## Verification
+
+Use live readbacks when a deployed surface exists:
+
+- HTTP timing and response headers;
+- provider freshness timestamp;
+- queue or job state;
+- edge/cache state;
+- browser verification for actual UI freshness;
+- logs around retries and degraded mode.
+
+For market-data or execution-adjacent paths, also verify orderbook age, VWAP
+assumptions, provider status, and kill-switch behavior before calling the path
+ready.
+
+## Guardrails
+
+- Do not optimize latency by dropping required validation.
+- Do not hide stale data behind fast cache hits.
+- Do not claim millisecond behavior from client labels without measurement.
+- Do not run live orders, destructive migrations, or customer-impacting deploys
+  without an explicit approval gate.
+- Keep secrets and private payloads out of logs and benchmark artifacts.