@williambeto/ai-workflow 1.19.1 → 2.2.0

package/.agents/skills/tester/SKILL.md

@@ -1,399 +0,0 @@
----
-name: tester
-description: Use when designing, reviewing, or improving tests, acceptance criteria, regression coverage, edge cases, and validation evidence.
----
-
-> Token economy active: keep output compact, context minimal. Reference: `token-economy` + `minimal-context` skills.
-
-# Tester Skill
-
-## Purpose
-
-Use this skill when Codex needs to validate a change before it is approved, merged, or used as a reference for the next step.
-
-The tester role is responsible for checking whether the work is correct, safe, testable, and aligned with the expected behavior.
-
-This skill does not focus on implementation. It focuses on verification, regression risk, edge cases, evidence, and approval criteria.
-
-## When to use this skill
-
-Use this skill when the task involves:
-
-- reviewing an implementation;
-- validating a pull request;
-- checking if a requirement was correctly implemented;
-- verifying acceptance criteria;
-- testing a bug fix;
-- reviewing changes before deployment;
-- checking if generated code introduced regressions;
-- validating documentation, prompts, templates, or runbooks;
-- deciding whether a task is ready to move to the next step.
-
-## Core responsibilities
-
-When acting as tester, Codex must:
-
-1. understand the expected behavior;
-2. identify the scope of the change;
-3. compare the result against the requirement, spec, or plan;
-4. check acceptance criteria;
-5. look for regressions;
-6. identify edge cases;
-7. verify error states and empty states when relevant;
-8. check accessibility, security, performance, and maintainability risks when relevant;
-9. confirm which validations were actually performed;
-10. separate confirmed issues from hypotheses;
-11. provide a clear approval or rejection recommendation.
-
-## Branch safety gate (mandatory if fixes are applied)
-
-Tester is primarily review/validation. If a validation task includes direct fixes:
-
-1. run `git status -sb`;
-2. if current branch is `main`, create/switch to a scoped branch before writing:
-
-```bash
-git switch -c fix/<short-task-slug>
-```
-
-Do not apply fixes directly on `main`.
-
-## Validation mindset
-
-Act as a skeptical reviewer.
-
-Do not assume that a change is correct because it looks reasonable.
-
-Validate based on evidence.
-
-Prefer small, specific findings over vague comments.
-
-A good tester response should answer:
-
-- What was tested?
-- What was not tested?
-- What passed?
-- What failed?
-- What is risky?
-- What evidence supports the conclusion?
-- Can this move forward?
-
-## Severity model
-
-Classify findings using the following severity levels.
-
-### High
-
-Use `High` when the issue can cause:
-
-- broken core functionality;
-- data loss;
-- security vulnerability;
-- deployment failure;
-- severe regression;
-- inaccessible critical flow;
-- incorrect business behavior;
-- failing required tests.
-
-### Medium
-
-Use `Medium` when the issue can cause:
-
-- incorrect behavior in secondary flows;
-- maintainability problems;
-- unclear implementation;
-- incomplete validation;
-- weak error handling;
-- fragile assumptions;
-- partial mismatch with requirements.
-
-### Low
-
-Use `Low` when the issue is mostly related to:
-
-- minor readability problems;
-- naming improvements;
-- small documentation gaps;
-- non-blocking cleanup;
-- small consistency issues.
-
-## Evidence rules
-
-Every finding must be classified as one of the following:
-
-### Confirmed issue
-
-Use this when there is direct evidence.
-
-Examples:
-
-- a failing test;
-- an error message;
-- a broken command;
-- a missing file;
-- a mismatch with an explicit requirement;
-- a visible behavior that contradicts the expected result.
-
-### Hypothesis
-
-Use this when the issue is plausible but not yet proven.
-
-A hypothesis must include a validation step.
-
-Example:
-
-```md
-Severity: Medium
-Type: Hypothesis
-Finding: The change may break empty-state rendering because no empty dataset test is present.
-How to validate: Add or run a test with an empty dataset and verify the expected empty-state UI.
-```
-
-### Observation
-
-Use this for neutral notes that may help reviewers but do not represent a defect.
-
-Example:
-
-```md
-Type: Observation
-Finding: The change follows the existing folder structure.
-```
-
-## Validation checklist
-
-Use the checklist proportionally to the risk and scope of the change.
-
-### Requirement validation
-
-- Is the expected behavior clearly defined?
-- Are the acceptance criteria present?
-- Does the result match the requirement?
-- Are there unresolved ambiguities?
-- Are assumptions explicitly stated?
-
-### Functional validation
-
-- Does the main happy path work?
-- Are relevant alternative paths covered?
-- Are empty states handled?
-- Are loading states handled?
-- Are error states handled?
-- Are boundary values handled?
-- Are invalid inputs handled when relevant?
-
-### Regression validation
-
-- Could this change affect existing behavior?
-- Were related flows checked?
-- Were existing tests run?
-- Were snapshots, generated files, or build outputs changed unexpectedly?
-- Are unrelated files modified?
-
-### Test validation
-
-- Are there automated tests?
-- Do the tests match the requirement?
-- Do the tests cover the critical behavior?
-- Are the tests deterministic?
-- Are the tests too coupled to implementation details?
-- Were the required commands executed?
-- Is there evidence of passing or failing results?
-
-### Documentation validation
-
-Use this section when validating documentation, prompts, templates, or runbooks.
-
-- Is the document clear and actionable?
-- Is the structure consistent?
-- Are code blocks correctly opened and closed?
-- Are examples accurate?
-- Are instructions specific enough?
-- Is there duplicated or conflicting guidance?
-- Is the document too generic?
-- Is the document too long for its purpose?
-
-### Accessibility validation
-
-Use this section when the change affects UI.
-
-- Can the flow be used with keyboard navigation?
-- Are labels associated with controls?
-- Are buttons and links correctly identified?
-- Is focus behavior reasonable?
-- Are modal dialogs accessible?
-- Is color alone used to communicate important information?
-- Are loading and error states understandable?
-
-### Security validation
-
-Use this section when the change affects authentication, authorization, user input, secrets, APIs, files, or deployment.
-
-- Are secrets exposed?
-- Is user input validated or safely handled?
-- Are authorization rules preserved?
-- Are tokens or credentials stored safely?
-- Are dangerous operations protected?
-- Are errors leaking sensitive information?
-
-### Performance validation
-
-Use this section when the change affects rendering, data loading, API calls, loops, assets, or build output.
-
-- Does the change add unnecessary network requests?
-- Does it introduce expensive loops or repeated computation?
-- Does it increase bundle size unnecessarily?
-- Does it block rendering?
-- Does it cause avoidable re-renders?
-- Does it affect caching?
-
-### Maintainability validation
-
-- Does the change follow the existing project pattern?
-- Is the solution simpler than the problem?
-- Are responsibilities separated?
-- Are names clear?
-- Is the code or documentation easy to change later?
-- Is there unnecessary abstraction?
-- Is there duplicated logic?
-
-## Output format
-
-When using this skill, Codex should respond using this structure:
-
-```md
-# Tester Review
-
-## Summary
-
-Short conclusion about whether the change is ready or not.
-
-## Scope validated
-
-- Files or areas reviewed.
-- Requirement, spec, prompt, or plan used as reference.
-
-## Result
-
-Status: Approved | Approved with notes | Changes requested | Blocked
-
-## Findings
-
-### Finding 1
-
-Severity: High | Medium | Low
-Type: Confirmed issue | Hypothesis | Observation
-
-Description:
-Explain the issue clearly.
-
-Evidence:
-Show the evidence, command result, file path, requirement mismatch, or behavior observed.
-
-Impact:
-Explain why it matters.
-
-Recommendation:
-Explain the smallest safe correction.
-
-How to validate:
-Explain the validation step after the fix.
-
-## Tests and checks
-
-### Executed
-
-- Command or manual check performed.
-- Result.
-
-### Not executed
-
-- Check not performed.
-- Reason.
-
-## Regression risks
-
-- List possible regressions.
-- Include what should be checked before approval.
-
-## Final recommendation
-
-Approve, approve with notes, request changes, or block.
-```
-
-## Approval criteria
-
-A change can be approved when:
-
-- the expected behavior is clear;
-- critical acceptance criteria are satisfied;
-- no high-severity confirmed issue remains;
-- relevant tests or validations were executed;
-- untested areas are explicitly listed;
-- regression risk is acceptable;
-- the final recommendation is clear.
-
-Use `Approved with notes` when the change is acceptable but still has minor risks, documentation gaps, or low-severity issues.
-
-Use `Changes requested` when there are medium or high issues that should be fixed before moving forward.
-
-Use `Blocked` when validation cannot continue because required information, files, environment, or commands are missing.
-
-## Boundaries
-
-When acting as tester, Codex must not:
-
-- implement fixes unless explicitly asked;
-- rewrite large parts of the solution without approval;
-- approve changes without evidence;
-- ignore failing tests;
-- treat hypotheses as confirmed issues;
-- invent test results;
-- hide untested areas;
-- expand the task scope unnecessarily;
-- request heavy validation for trivial low-risk changes.
-
-## Proportional validation rule
-
-Validation must be proportional to the risk of the change.
-
-For small documentation changes, check clarity, formatting, consistency, and broken Markdown.
-
-For small UI changes, check the affected flow, visual regressions, accessibility basics, and relevant states.
-
-For business-critical changes, check requirements, edge cases, automated tests, regression risks, security, and deployment impact.
-
-For deployment-related changes, check build commands, environment assumptions, rollback strategy, and operational risk.
-
-## Default final recommendation rules
-
-Use the following defaults:
-
-- If there is one or more confirmed `High` issue: `Blocked` or `Changes requested`.
-- If there are confirmed `Medium` issues: `Changes requested`.
-- If there are only `Low` issues: `Approved with notes`.
-- If there are only hypotheses and they are not critical: `Approved with notes` or `Changes requested`, depending on risk.
-- If there is not enough information to validate: `Blocked`.
-- If all relevant checks pass: `Approved`.
-
-## Good tester behavior
-
-A good tester is:
-
-- specific;
-- evidence-based;
-- skeptical;
-- proportional;
-- clear about uncertainty;
-- focused on regression prevention;
-- strict with critical flows;
-- practical with low-risk changes.
-
-The goal is not to find problems for its own sake.
-
-The goal is to protect the workflow from unsafe, unclear, or unvalidated changes.
-
-## Stop conditions
-
-- Stop when the review is complete and the final recommendation is clear.
-- Stop and report `Blocked` if required context, files, or validation evidence is missing.

package/.agents/skills/token-economy/SKILL.md

@@ -1,137 +0,0 @@
----
-name: token-economy
-description: Use when outputs must stay compact while preserving technical accuracy, evidence, severity, validation commands, and acceptance criteria.
----
-
-# Token Economy Skill
-
-## Purpose
-
-Reduce response verbosity for coding workflows without removing critical context, validation evidence, or safety constraints.
-
-## Use when
-
-- Output is too long for routine implementation, audits, handoffs, or fixes.
-- Team needs consistent compact response contracts.
-- Repeated explanations create token waste.
-- User explicitly requests compact, terse, audit, or handoff mode.
-
-## Modes
-
-### `compact`
-
-- Short, clear bullets.
-- Keep decisions, assumptions, changed files, validation commands, and risks.
-
-### `terse`
-
-- Facts and actions only.
-- No narrative or teaching text.
-- Keep exact command names, file paths, and statuses.
-
-### `audit`
-
-- Tables only.
-- Every finding must include evidence (file, line, command output, or diff reference).
-- Include severity (`High`/`Medium`/`Low`).
-
-### `handoff`
-
-- Fixed sections only:
-  - Summary
-  - Changed files
-  - Validations
-  - Risks
-  - Next action
-
-## Input vs Output distinction
-
-`token-economy` reduces OUTPUT tokens (what the model sends back).
-`minimal-context` reduces INPUT tokens (what is sent to the model).
-
-Use both together for full token savings.
-
-| Token type | What it is | How to reduce |
-|---|---|---|
-| **Input** | Files, history, context sent TO the model | `minimal-context` skill |
-| **Output** | Model response verbosity | `token-economy` skill |
-
-## Core responsibilities
-
-1. Select correct mode for task and risk.
-2. Preserve technical correctness and no-regression rules.
-3. Keep evidence explicit (commands, outputs, files, lines when available).
-4. Keep acceptance criteria visible.
-5. Keep outputs short but executable by next owner.
-
-## Constraints
-
-- Do not remove critical context needed for safe execution.
-- Do not hide assumptions.
-- Do not omit validation commands or validation status.
-- Do not use vague phrases like "improve code", "some changes", or "various fixes".
-- Do not run broad repository scans unless explicitly requested (use `minimal-context` skill for input discipline).
-- Do not claim success without evidence.
-
-## Output contracts
-
-### Implementation
-
-- Scope
-- Files changed
-- Validation commands + results
-- Risks
-- Acceptance status
-
-### Audit
-
-- Findings table (severity, evidence, impact, fix)
-- Validation gaps
-- Final recommendation
-
-### Bugfix
-
-- Root cause
-- Fix applied
-- Files changed
-- Validation commands + results
-- Regression risks
-
-### Handoff
-
-- Summary
-- Changed files
-- Validations
-- Risks
-- Next action
-
-## Validation
-
-- Confirm mode was applied.
-- Confirm output kept evidence and acceptance criteria.
-- Confirm no required safety/validation detail was removed.
-
-## Severity model
-
-### High
-
-- Missing validation commands or validation status.
-- Missing evidence for blocking findings.
-- Compaction removed safety-critical context.
-
-### Medium
-
-- Assumptions not explicit.
-- Output contract sections incomplete.
-- Important risk or acceptance detail missing.
-
-### Low
-
-- Minor wording noise.
-- Redundant bullet that does not affect execution.
-- Formatting inconsistency in compact output.
-
-## Stop conditions
-
-- Stop when output is compact and still operationally complete.
-- Stop and report `Blocked` if compacting would remove required safety, evidence, or acceptance details.

package/.agents/skills/vue-nuxt/SKILL.md

@@ -1,102 +0,0 @@
----
-name: vue-nuxt
-description: Use when structuring Vue, Nuxt, or Quasar frontend code — architecture decisions, dashboard workflows, CRUD patterns, stores, composables, services, and TypeScript contracts.
----
-
-> Token economy active: keep output compact, context minimal. Reference: `token-economy` + `minimal-context` skills.
-
-# vue-nuxt Skill
-
-## Purpose
-
-Guide scoped Vue and Nuxt frontend work while preserving shell consistency, route protection, CRUD patterns, clean architecture boundaries, and validation evidence.
-
-## Use when
-
-- Working on Nuxt 4, Vue 3, TypeScript, Nuxt UI, or Tailwind CSS projects.
-- Implementing authenticated dashboard shells, CRUD pages, or DummyJSON-backed screens.
-- Adding loading, empty, error, pagination, search, or form states.
-- Deciding where business rules, API access, stores, composables, services, repositories, adapters, or domain models belong.
-- Reviewing Clean Architecture, DDD, or Hexagonal Architecture boundaries in frontend code.
-- Planning or implementing small PRs for Vue/Nuxt features.
-
-## Guidance
-
-- Keep each PR small and focused on one workflow.
-- Preserve the existing shell, navigation, layout density, and interaction patterns.
-- Protect authenticated routes and avoid leaking data into public routes.
-- Keep CRUD patterns consistent across resources.
-- Pages should orchestrate data, state, and layout; extract repeated behavior when duplication becomes meaningful.
-- Prefer existing Nuxt UI and Tailwind patterns before adding new styling conventions.
-- Avoid overengineering simple screens.
-- Keep domain boundaries clear and named after project concepts, not framework mechanics alone.
-- Stores should coordinate shared state; they should not become service or repository dumps.
-- Composables should expose reusable UI or workflow behavior, not hide broad infrastructure coupling.
-- Repositories and adapters should isolate external API or persistence details.
-- Introduce layers incrementally through small PRs with clear payoff.
-- Preserve no-regression expectations for existing routes, auth flow, loading, empty, and error states.
-
-## Core responsibilities
-
-1. Keep PRs small and scoped to one workflow.
-2. Preserve shell, navigation, layout, and interaction patterns.
-3. Protect authenticated routes and verify route protection for touched areas.
-4. Keep CRUD patterns consistent across resources.
-5. Decide where business rules, API access, stores, composables, services, repositories, adapters, or domain models belong.
-6. Review Clean Architecture, DDD, or Hexagonal Architecture boundaries.
-7. Plan TypeScript contracts between UI, domain, and infrastructure layers.
-8. Handle loading, empty, error, and success states for touched resources.
-9. Keep architecture proportional to project complexity.
-10. Validate with small PRs that preserve existing behavior.
-
-## Constraints
-
-- Do not expand one CRUD PR into a full dashboard refactor.
-- Do not create page-specific shell variants without a product reason.
-- Do not skip empty or error states for touched resources.
-- Do not treat DummyJSON behavior as production API behavior.
-- Do not claim route protection is valid without checking protected and public routes.
-- Do not add new styling conventions when Nuxt UI or Tailwind patterns exist.
-- Do not add architecture layers before complexity requires them.
-- Do not put API calls, mapping, validation, and UI state all in a page.
-- Do not let stores become global service locators.
-- Do not create domain models that only mirror API JSON without adding clarity.
-- Do not move files without validating route and import behavior.
-- Do not invent architecture when existing patterns are sufficient.
-
-## Expected output
-
-- PR summary with scoped changes, CRUD states validated, and auth validation evidence.
-- Implementation notes for where business logic and data access belong.
-- List of changed files and boundary decisions.
-- List of untested browser or API behavior explicitly documented.
-- Validation evidence from lint, typecheck, and build commands.
-- Final status: `Approved`, `Approved with notes`, `Changes requested`, or `Blocked`.
-
-## Validation
-
-- Run the repository's lint, typecheck, test, and build commands when available.
-- Validate login/logout and route protection when auth changes.
-- Validate CRUD create, read, update, delete, loading, empty, and error states for the touched resource.
-- Check imports to confirm architecture boundaries are respected.
-- Capture any untested browser or API behavior explicitly.
-- Document trade-offs and any boundary that remains intentionally pragmatic.
-
-## Common mistakes
-
-- Expanding one CRUD PR into a full dashboard refactor.
-- Creating page-specific shell variants without a product reason.
-- Skipping empty or error states.
-- Treating DummyJSON behavior as production API behavior without noting the assumption.
-- Claiming route protection is valid without checking protected and public routes.
-- Adding architecture layers before complexity requires them.
-- Putting API calls, mapping, validation, and UI state all in a page.
-- Letting stores become global service locators.
-- Creating domain models that only mirror API JSON without adding clarity.
-- Moving files without validating route and import behavior.
-
-## Stop conditions
-
-- Stop when the PR is small, scoped, and all affected UI states are validated.
-- Stop when architecture boundaries are clear and implementation is scoped.
-- Stop and report `Blocked` if required project structure, dashboard patterns, or validation commands are missing.

package/.agents/skills/wordpress-engineer/SKILL.md

@@ -1,75 +0,0 @@
----
-name: wordpress-engineer
-description: Use when working on WordPress, WooCommerce, ACF, custom themes or plugins, shortcodes, hooks, templates, and PHP 7-compatible code.
----
-
-> Token economy active: keep output compact, context minimal. Reference: `token-economy` + `minimal-context` skills.
-
-# WordPress Engineer Skill
-
-## Purpose
-
-Guide WordPress engineering with PHP 7 compatibility, platform APIs, security basics, and minimal regression risk.
-
-## Use when
-
-- Working on WordPress themes, plugins, hooks, filters, shortcodes, widgets, templates, ACF, or WooCommerce.
-- Reviewing PHP 7-compatible WordPress code.
-- Handling forms, admin actions, AJAX, REST endpoints, queries, or template output.
-- Deciding whether behavior belongs in a theme or plugin.
-
-## Guidance
-
-- Preserve PHP 7 compatibility unless the project explicitly allows newer syntax.
-- Escape output with the appropriate WordPress escaping function.
-- Sanitize and validate input before use.
-- Use nonces for state-changing actions.
-- Check capabilities before privileged actions.
-- Prefer WordPress APIs over direct database access.
-- Use direct database access only with clear justification, prepared queries, and validation.
-- Keep plugin logic and theme presentation boundaries clear.
-
-## Core responsibilities
-
-1. Write PHP 7-compatible WordPress code (themes, plugins, hooks, filters, shortcodes, widgets, templates, ACF, WooCommerce).
-2. Escape output with appropriate WordPress escaping functions.
-3. Sanitize and validate input before use.
-4. Use nonces for state-changing actions and check capabilities before privileged operations.
-5. Prefer WordPress APIs over direct database access.
-6. Validate touched templates, hooks, forms, shortcodes, or WooCommerce flows.
-7. Document PHP version and WordPress assumptions explicitly.
-
-## Constraints
-
-- Do not use PHP 8-only syntax in PHP 7 projects.
-- Do not echo unescaped values in templates.
-- Do not trust request data without sanitization.
-- Do not add state-changing actions without nonces.
-- Do not query the database directly when WordPress APIs are sufficient.
-- Do not mix plugin logic and theme presentation without clear boundaries.
-- Do not claim validation passed without evidence.
-
-## Expected output
-
-- WordPress implementation notes with PHP version assumptions and security handling.
-- List of changed files and hook/filter/template impacts.
-- Validation evidence from PHP lint, tests, or manual checks.
-- Final status: `Approved`, `Approved with notes`, `Changes requested`, or `Blocked`.
-
-## Validation
-
-- Run available PHP lint, unit, integration, or project validation commands.
-- Manually check affected templates, hooks, forms, shortcodes, or WooCommerce flows when automated coverage is absent.
-- Verify escaping, sanitization, nonce, and capability handling for touched surfaces.
-- State any WordPress or PHP version assumptions.
-
-## Stop conditions
-
-- Stop when WordPress implementation is scoped, validated, and PHP 7 compatible.
-- Stop and report `Blocked` if required theme/plugin context, validation commands, or PHP version info is missing.
-
-- Using PHP 8-only syntax in PHP 7 projects.
-- Echoing unescaped values in templates.
-- Trusting request data without sanitization.
-- Adding state-changing actions without nonces.
-- Querying the database directly when WordPress APIs are sufficient.