@sallmarta/eye-hate-agent 1.0.1 → 1.0.3

package/docs/templates/project-docs-template/technical/error-handling.md

@@ -0,0 +1,54 @@
+# Error Handling
+
+Last update: YYYY-MM-DD
+
+Status: [Proposed | Draft | Live | Deprecated | Archived]
+
+---
+
+## 1. Description
+Briefly describe the purpose of this document and what it contains.
+
+## 2. Important
+Notes of important findings or critical constraints. Can be empty.
+
+## 3. Table of Contents
+[Generate a hyperlinked table of contents here containing ALL headings in this file (1 through N). Use standard markdown links, e.g., - [1. Description](#1-description)]
+
+## 4. Scope
+The boundaries of what this document covers.
+
+## 5. Goals
+What we aim to achieve with this specific document.
+
+## 6. Non Goals
+What is explicitly excluded from the scope of this document.
+
+## 7. Standard Error Payload
+The exact JSON shape returned on failure.
+
+## 8. Global Error Codes
+A registry of specific business logic errors.
+
+## 9. Client-Side Handling Rules
+How the frontend should display or retry failures.
+
+## 10. Server-Side Fallbacks
+Circuit breakers and degraded modes. Diagram of fallback flow is preferred. Use mermaid.
+
+```mermaid
+graph TD
+    A[Request] --> B{Service Online?}
+    B -- Yes --> C[Process Request]
+    B -- No --> D[Trigger Circuit Breaker]
+    D --> E[Return Fallback Payload]
+```
+
+## 11. Success Metrics
+How we measure if the goals of this document are achieved.
+
+## 12. Related Documents
+[Link to related document](path) - Short brief note about why it's related.
+
+## 13. Open Questions
+Any unresolved questions or assumptions. Can be empty.

package/docs/templates/project-docs-template/technical/internationalization.md

@@ -0,0 +1,46 @@
+# Internationalization & Localization
+
+Last update: YYYY-MM-DD
+
+Status: [Proposed | Draft | Live | Deprecated | Archived]
+
+---
+
+## 1. Description
+Briefly describe the purpose of this document and what it contains.
+
+## 2. Important
+Notes of important findings or critical constraints. Can be empty.
+
+## 3. Table of Contents
+[Generate a hyperlinked table of contents here containing ALL headings in this file (1 through N). Use standard markdown links, e.g., - [1. Description](#1-description)]
+
+## 4. Scope
+The boundaries of what this document covers.
+
+## 5. Goals
+What we aim to achieve with this specific document.
+
+## 6. Non Goals
+What is explicitly excluded from the scope of this document.
+
+## 7. Supported Languages / Locales
+The explicit list of target regions.
+
+## 8. Translation Workflow (TMS)
+How strings are extracted, translated, and merged.
+
+## 9. Fallback Locales
+The default language when a string is missing.
+
+## 10. Date & Currency Formats
+Regional formatting rules.
+
+## 11. Success Metrics
+How we measure if the goals of this document are achieved.
+
+## 12. Related Documents
+[Link to related document](path) - Short brief note about why it's related.
+
+## 13. Open Questions
+Any unresolved questions or assumptions. Can be empty.

package/docs/templates/project-docs-template/technical/testing.md

@@ -0,0 +1,57 @@
+# Testing & Verification
+
+Last update: YYYY-MM-DD
+
+Status: [Proposed | Draft | Live | Deprecated | Archived]
+
+---
+
+## 1. Description
+Briefly describe the purpose of this document and what it contains.
+
+## 2. Important
+Notes of important findings or critical constraints. Can be empty.
+
+## 3. Table of Contents
+[Generate a hyperlinked table of contents here containing ALL headings in this file (1 through N). Use standard markdown links, e.g., - [1. Description](#1-description)]
+
+## 4. Scope
+The boundaries of what this document covers.
+
+## 5. Goals
+What we aim to achieve with this specific document.
+
+## 6. Non Goals
+What is explicitly excluded from the scope of this document.
+
+## 7. Verification Policy & Objectives
+Define the overarching philosophy for how this repository chooses, runs, and reports testing. What are we trying to prove with our test suite?
+
+## 8. Verification Matrix & Coverage
+The required types of testing (Blackbox, Unit, Security) mapping against expected coverage metrics (e.g., 85% branch coverage).
+
+| Change type | Preferred validation | Fallback |
+| --- | --- | --- |
+| Code change | TBD | TBD |
+| Documentation change | TBD | TBD |
+
+## 9. Test Layers & Environments
+Detail the exact split of Unit, Component, Integration, and E2E tests. Include the required infrastructure, mocks, and seed data needed to run them.
+
+## 10. Commands & CI Gates
+The exact terminal commands for linting and testing. Outline the required pre-merge CI checks (blocking vs advisory).
+
+## 11. Naming & File Conventions
+Where tests live, how test files are named (e.g., `*.spec.ts`), and how fixtures are stored.
+
+## 12. Manual Checks & Fallbacks
+Necessary manual testing steps and fallback procedures for human verification when automation is impossible.
+
+## 13. Success Metrics
+How we measure if the goals of this document are achieved.
+
+## 14. Related Documents
+[Link to related document](path) - Short brief note about why it's related.
+
+## 15. Open Questions
+Any unresolved questions or assumptions. Can be empty.

package/docs/templates/project-docs-template/technical/ui-ux.md

@@ -0,0 +1,68 @@
+# UI/UX
+
+Last update: YYYY-MM-DD
+
+Status: [Proposed | Draft | Live | Deprecated | Archived]
+
+---
+
+## 1. Description
+Briefly describe the purpose of this document and what it contains.
+
+## 2. Important
+Notes of important findings or critical constraints. Can be empty.
+
+## 3. Table of Contents
+[Generate a hyperlinked table of contents here containing ALL headings in this file (1 through N). Use standard markdown links, e.g., - [1. Description](#1-description)]
+
+## 4. Scope
+The boundaries of what this document covers.
+
+## 5. Goals
+What we aim to achieve with this specific document.
+
+## 6. Non Goals
+What is explicitly excluded from the scope of this document.
+
+## 7. Design Philosophy
+The core principles guiding the user experience.
+
+## 8. Design System & Theme
+Colors, typography, and visual guidelines.
+
+## 9. Wireframing & Prototyping
+Links to external tools (Figma, Adobe) or raw UI specs generated by humans/AI in the repo.
+
+## 10. Screen Layouts
+Core page structures and navigation flows. Wireframes are preferred. Use mermaid.
+
+```mermaid
+graph TD
+    A[Home Page] --> B[Dashboard]
+    A --> C[Profile Settings]
+    B --> D[Details View]
+```
+
+## 11. Component Library
+Reusable UI elements (buttons, modals).
+
+## 12. Responsive Breakpoints
+Behavior across mobile, tablet, and desktop.
+
+## 13. Accessibility (a11y) Requirements
+Contrast ratios, ARIA labels.
+
+## 14. Implementation Backlog
+List of UI tasks (e.g., `Task-ID: Description`).
+
+## 15. Design Handoff Approaches
+How designs are explicitly transferred to developers.
+
+## 16. Success Metrics
+How we measure if the goals of this document are achieved.
+
+## 17. Related Documents
+[Link to related document](path) - Short brief note about why it's related.
+
+## 18. Open Questions
+Any unresolved questions or assumptions. Can be empty.

package/docs/{vibes → templates}/project-docs-template/technical-guidelines/index.md

@@ -7,7 +7,7 @@ Status: [Proposed | Draft | Live | Deprecated | Archived]
 ---
 
 ## 1. Summary
-> [!NOTE] Use this index to list the active technical guideline documents for the repository. Core project docs explain the repository generally. Guidelines explain the durable technical rules that recurring implementation and review work should follow. This index is the authoritative registry for active guideline types; starter template files are recommended references, not the activation mechanism.
+Use this index to list the active technical guideline documents for the repository. Core project docs explain the repository generally. Guidelines explain the durable technical rules that recurring implementation and review work should follow. This index is the authoritative registry for active guideline types; starter template files are recommended references, not the activation mechanism.
 
 ## 2. When To Add A Guideline
 - Add a guideline when a technical domain has cross-cutting rules that would otherwise be repeated across tasks.
@@ -31,7 +31,7 @@ Status: [Proposed | Draft | Live | Deprecated | Archived]
 | `technical-guidelines/ui-ux.md` | UI/UX | Rules for UI components, accessibility standards, and design system usage | TBD | Design system or component library changes |
 | `technical-guidelines/your-new-guideline.md` | State the domain of the next guideline here | State the purpose of the next guideline here | TBD | State the review trigger for the next guideline here |
 
-> [!NOTE] Remove rows for inactive domains and add a new row in the `## 3. Active Guidelines` table above for any other active guideline files.
+Remove rows for inactive domains and add a new row in the `## 3. Active Guidelines` table above for any other active guideline files.
 
 ## 4. Ownership And Review
 - Keep this index aligned with the files that actually exist under `technical-guidelines/`.
@@ -41,7 +41,7 @@ Status: [Proposed | Draft | Live | Deprecated | Archived]
 - Cross-reference owning project docs such as `architecture.md` or `testing.md` when a guideline depends on them.
 
 ## 5. Stable Headings
-> [!NOTE] New guideline files must include the standard numbered headings below to keep all rulebooks consistent. Feel free to add extra domain-specific headings if needed.
+New guideline files must include the standard numbered headings below to keep all rulebooks consistent. Feel free to add extra domain-specific headings if needed.
 
 1. **`## 1. Summary`**: A brief overview of what rules this guideline documents.
 2. **`## 2. Scope`**: The explicit boundaries of what these rules cover (and don't cover).

package/docs/{vibes → templates}/reusable-prompts/00-project-docs-bootstrap.md

@@ -1,6 +1,4 @@
-# Project Docs Bootstrap Reusable Prompt (v2.0.0)
-
-Read `docs/eyehateagent-contract.md` first.
+# Project Docs Bootstrap Reusable Prompt
 
 Generate the **initial project documentation set** for a repository. 
 You must dynamically adjust your behavior based on the current state of the repository.
@@ -12,7 +10,7 @@ Before writing any documents, analyze the workspace to determine its state:
 3. **Mature Docs:** Existing legacy documentation exists but isn't in the EHA format. Map the existing docs into the new 4-layer taxonomy `docs/project-docs/` format without losing historical context.
 
 ## Required Behavior
-1. Follow the 4-layer file structure defined in `docs/eyehateagent-contract.md` (`foundation/`, `operations/`, `technical/`, `technical-guidelines/`).
+1. Follow the 4-layer file structure defined in the EHA Project Doc Rules above (`foundation/`, `operations/`, `technical/`, `technical-guidelines/`).
 2. Create project-specific truth in `docs/project-docs/`, not in the reusable prompt output itself.
 3. Do not invent details. Mark uncertain facts as `TBD` or `Assumption`.
 4. If reverse-engineering from code, explicitly state "Inferred from codebase" in the generated document until the user confirms it.

package/docs/{vibes → templates}/reusable-prompts/00-project-docs-parity.md

@@ -1,7 +1,5 @@
 # Project Docs Parity Reusable Prompt
 
-Read `docs/eyehateagent-contract.md` first.
-
 Audit the repository for **documentation-system drift**.
 
 ## Goal
@@ -18,8 +16,8 @@ Check at least these areas when present:
 - relevant code, tests, configs, or runtime-facing artifacts when a finding depends on current implementation behavior or source-of-truth ownership
 - clearly named reference or archive folders such as `docs-legacy/`, `docs-old/`, `archive/`, or `reference/`
 - platform instruction surfaces (mirrored rule files)
-- `docs/vibes/skills/`
-- `docs/vibes/reusable-prompts/`
+- `docs/templates/skills/`
+- `docs/templates/reusable-prompts/`
 - workflow docs and handoff docs
 
 ### High-Value Drift Categories
@@ -40,7 +38,7 @@ Check at least these areas when present:
 ## Required Behavior
 
 1. Use project docs as the primary source of truth for documentation ownership and doc-to-doc drift unless the repository explicitly states otherwise.
-2. Treat `docs/eyehateagent-contract.md` as the ownership map.
+2. Use the EHA Project Doc Rules above as the ownership map.
 3. Treat `docs/project-docs/index.md` and `docs/project-docs/technical-guidelines/index.md` as the authoritative inventories for optional regular docs and guideline docs when present.
 4. Treat clearly named reference or archive folders such as `docs-legacy/`, `docs-old/`, `archive/`, or `reference/` as migration input only, not as owner-doc paths.
 5. When evaluating legacy material, classify it by the durable concern it governs rather than by its legacy name or path. Treat names such as `epic`, `milestone`, `roadmap`, `protocol`, `procedure`, `policy`, or `standard` as hints only.

package/docs/{vibes → templates}/reusable-prompts/00-project-docs-refresh.md

@@ -1,7 +1,5 @@
 # Project Docs Refresh Reusable Prompt
 
-Read `docs/eyehateagent-contract.md` first.
-
 Refresh the existing project documentation after a change in scope, stack, workflow, architecture, testing policy, or product behavior.
 
 ## Goal
@@ -11,7 +9,7 @@ Update **only the docs that own the changed information** while keeping the docu
 ## Required Behavior
 
 1. Read the current project docs before editing anything.
-2. Use `docs/eyehateagent-contract.md` to identify which files own the changed information.
+2. Use the EHA Project Doc Rules above to identify which files own the changed information.
 3. Read `docs/project-docs/index.md` and `docs/project-docs/technical-guidelines/index.md` when present and treat them as the authoritative inventories for optional docs and guideline docs.
 4. When clearly named reference or archive folders such as `docs-legacy/`, `docs-old/`, `archive/`, or `reference/` exist, read them as migration input only and do not treat them as owner-doc paths.
 5. Update only the affected docs and any documents that summarize them.
@@ -72,7 +70,7 @@ Your result should state:
 
 Before finishing, check that:
 
-1. the updated docs still match the contract in `docs/eyehateagent-contract.md`
+1. the updated docs still match the EHA Project Doc Rules above
 2. platform instruction surfaces and skills would now read the correct project-specific truth
 3. no stale summary remains in `foundation/status.md`, `docs/project-docs/index.md`, `technical-guidelines/index.md`, or other index docs
 

package/docs/{vibes → templates}/reusable-prompts/02-sdd-discuss.md

@@ -23,5 +23,5 @@ Act as a Senior Engineer / Agile Product Manager to help the user brainstorm and
 ## Inputs
 
 - The user's rough feature idea or concept.
-- `docs/project-docs/foundation/prd.md` (to understand current scope)
-- `docs/project-docs/foundation/architecture.md` (to understand current stack constraints)
+- Read `docs/project-docs/foundation/prd.md` if it exists (to understand current scope).
+- Read `docs/project-docs/foundation/architecture.md` if it exists (to understand current stack constraints).

package/{.agents/rules/agent.md → docs/templates/rules/agent-rules.md}

@@ -1,11 +1,3 @@
----
-trigger: always_on
----
-
----
-description: "Lean always-on rules for guardrails, context, intake, verification, and doc sync."
----
-
 # Agent Rules
 
 ## 1. Guardrails & Approach
@@ -22,7 +14,10 @@ Protect the prompt prefix cache and manage context-window capacity to preserve t
 
 - **2.1** Keep always-on context small. Keep rules generic and leave project-specific facts in project docs under `docs/project-docs/`.
 - **2.2** Read the smallest owning doc that resolves the decision rather than scanning the entire repository.
-- **2.3** **Prefix Stability (Gemini):** Never reorder tool definitions, system instructions, or serialized schemas mid-session — the implicit prefix cache requires a byte-identical prompt prefix for the 90% cached-token discount. Do not inject dynamic content (timestamps, session IDs, reordered JSON keys) before or between stable blocks. Append all per-turn dynamic data after the stable prefix. If cache-hit rates drop unexpectedly, suspect non-deterministic serialization or framework-injected metadata before other causes.
+- **2.3** **Agent-Specific Cache Strategies:**
+  - **Claude (Prefix & Lookback Integrity):** Cache reads cost 90% less but require a byte-identical prefix in tools -> system -> messages order. Never reorder, add, or remove tool definitions mid-session. Never inject dynamic content (timestamps, per-request IDs) into the system prompt. In heavy agentic loops, be aware of the ~20-block lookback window; explicitly request the user to perform a minor conversational interaction to prevent silent cache misses.
+  - **Antigravity (Prefix Stability):** Never reorder tool definitions, system instructions, or serialized schemas mid-session. The implicit prefix cache requires a byte-identical prompt prefix for the 90% cached-token discount. Append all per-turn dynamic data after the stable prefix. If cache-hit rates drop unexpectedly, suspect non-deterministic serialization.
+  - **Copilot (Context Efficiency):** Under usage-based billing, cached tokens still cost AI Credits — keep instruction files and session context lean rather than exhaustive. Prefer explicit context (`#file`, `#selection`) over broad implicit context. Start a fresh session or use `/clear` when switching to an unrelated task to prevent context clutter.
 - **2.4** **Session Continuity (No Dynamic Compaction):** Never modify, compact, or delete prior chat turns mid-session—this destroys the hardware prefix cache. If context reaches ~65% capacity, compile a comprehensive session-handoff.md to `active-repo/memories/session/session-handoff.md` (overwriting any previous handoff, and ensure `active-repo/memories/session/` is added to `.gitignore` if created). The handoff must contain a full, detailed summary of the active conversation's progress, decisions, and open threads, strictly redact all sensitive information (such as API keys, passwords, credentials, or PII), and incorporate any user-provided compaction arguments as next-session focus areas. Prompt the user to run `/clear` or open a new session with this file loaded, providing a copy-pasteable short prompt (e.g., "Resume session from memories/session/session-handoff.md") to load the handoff instantly.
 
 ## 3. Intake & Scope Alignment
@@ -58,9 +53,9 @@ Embed the critical behavioral rules from the contract so agents follow them with
 - **5.2 Decision Precedence:** Resolve routing, conflict, and behavior decisions in this strict order:
   1. User's requested goal and output.
   2. User's explicit constraints or preferences.
-  3. The active contract (`docs/eyehateagent-contract.md`) and the owning project docs under `docs/project-docs/`.
+  3. The active EHA rules and the owning project docs under `docs/project-docs/`.
   4. Attached context (skills, notes, or examples) treated as relevance hints unless made mandatory.
   5. Automatic agent judgment.
 - **5.3 Failure & Fallback:** If a required project doc is missing, note the gap and create the smallest owning doc that unblocks the task. If code, tests, configs, or runtime-facing artifacts conflict with active docs and authority is unclear, do not guess: surface the conflict, cite the evidence, and ask the user before choosing the fix path.
 - **5.4 Codebase & Comment Integrity:** Maintain absolute documentation and codebase integrity when making modifications. Preserve all existing comments, docstrings, formatting, and structures that are unrelated to your changes unless explicitly instructed otherwise. Never delete unrelated comments or placeholder code silently.
-- **5.5 Completion & Verification:** End each task with the requested output and the narrowest applicable validation from `docs/project-docs/testing.md` (or a structural review with an explicit limitation if no executable check exists). Re-read output for correctness, edge cases, and unexpected side effects before finishing. Include a doc-sync check when ownership changed.
+- **5.5 Completion & Verification:** End each task with the requested output and the narrowest applicable validation from `docs/project-docs/testing.md` (or a structural review with an explicit limitation if no executable check exists). Re-read output for correctness, edge cases, and unexpected side effects before finishing. Include a doc-sync check when ownership changed.

package/docs/templates/skills/architecture/db-schema-design/SKILL.md

@@ -0,0 +1,14 @@
+# Database Schema Design Skill
+
+You are an expert Database Architect. Your task is to design robust, scalable, and normalized database schemas (or optimized NoSQL data models) based on the project's requirements.
+
+## Responsibilities
+1. Analyze `docs/project-docs/foundation/prd.md` to understand data storage needs.
+2. Design tables/collections, defining strict types, primary keys, and foreign keys.
+3. Establish proper indexes for common query patterns to ensure high performance.
+4. Document the relationships (1:1, 1:N, M:N) clearly in `docs/project-docs/technical/database.md`.
+
+## Output Constraints
+- Always use standard Entity-Relationship terminology.
+- When generating SQL schemas, prefer standard ANSI SQL unless a specific dialect (e.g., PostgreSQL, MySQL) is requested.
+- Highlight any potential bottlenecks (e.g., heavily joined tables, wide rows).

package/docs/{vibes/skills → templates/skills/auditing}/full-verification/SKILL.md

@@ -18,7 +18,7 @@ This skill is intentionally **not tied to any single stack or framework**. When
 
 | Document | Why it matters |
 | --- | --- |
-| `docs/eyehateagent-contract.md` | Defines routing, ownership, precedence, and the active skill model |
+| EHA Rules | Defines routing, ownership, precedence, and the active skill model |
 
 | `docs/project-docs/technical/testing.md` | Defines executable and non-executable verification rules, commands, and fallback policy |
 | `docs/project-docs/foundation/architecture.md` | Defines boundaries, stack, interfaces, dependency rules, and runtime assumptions |

package/docs/{vibes/skills → templates/skills/auditing}/parity/SKILL.md

@@ -16,7 +16,7 @@ This skill is the reusable complement to the parity reusable prompt. Use it when
 
 | Document | Why it matters |
 | --- | --- |
-| `docs/eyehateagent-contract.md` | Ownership map and canonical doc contract |
+| EHA Rules | Ownership map and canonical doc taxonomy |
 | `docs/project-docs/foundation/prd.md` | Active project identity and scope |
 | `docs/project-docs/foundation/architecture.md` | Active stack and architecture truth |
 | `docs/project-docs/technical/testing.md` | Active verification truth |
@@ -59,7 +59,7 @@ Check for disagreement across:
 
 ### Step 1 — Establish the source of truth
 
-Use the project docs defined by `docs/eyehateagent-contract.md` as the default source of truth for documentation ownership unless the repository explicitly states otherwise.
+Use the active EHA rules as the default source of truth for documentation ownership unless the repository explicitly states otherwise.
 
 ### Step 2 — Compare dependent layers
 

package/docs/templates/skills/engineering/refactor-specialist/SKILL.md

@@ -0,0 +1,13 @@
+# Refactoring Specialist Skill
+
+You are a strict, senior Software Architect specialized in cleaning up technical debt, reducing cyclomatic complexity, and improving maintainability.
+
+## Responsibilities
+1. Analyze target files for anti-patterns, duplicated logic, and overly complex control flows.
+2. Break down monolithic functions into smaller, highly testable, pure functions.
+3. Apply SOLID principles and appropriate design patterns without over-engineering.
+
+## Output Constraints
+- Ensure all refactored code has identical external behavior (unless explicitly fixing a bug).
+- Preserve all existing comments and docstrings unless they are invalidated by the new architecture.
+- Briefly explain the core structural changes before writing the code.

package/docs/{vibes/skills → templates/skills/engineering}/test-authoring/SKILL.md

@@ -145,7 +145,7 @@ Separate:
 | Interface, handler, adapter, or contract boundary | Contract or integration test | `testing.md`, API / integration docs |
 | Interactive or end-user-visible flow | UI or end-to-end test | `testing.md`, app-flow / UI docs |
 | Asynchronous, scheduled, staged, or event-driven processing | Integration or component test | `testing.md`, `architecture.md`, workflow docs |
-| Rule, skill, reusable prompt, or documentation change | Consistency review or structural validation | `docs/eyehateagent-contract.md`, `testing.md` |
+| Rule, skill, reusable prompt, or documentation change | Consistency review or structural validation | EHA rules, `testing.md` |
 
 ---
 
@@ -199,3 +199,179 @@ When using this skill, the output should include:
 - "What tests should cover this API contract update?"
 - "Write a test plan for this migration change"
 - "This repo has no code yet — how should I validate a reusable prompt or platform instruction surface update?"
+
+
+---
+
+# Test Patterns Reference — Project-Aware
+
+Quick reference for common test-pattern shapes. Use these as **structural examples**, then adapt them using the repository's `testing.md`, `architecture.md`, and local conventions.
+
+---
+
+## Pattern A: Narrow Unit Or Component Test
+
+Use when you want the fastest check at a clear boundary.
+
+### Pattern A Skeleton
+
+```text
+Arrange inputs and collaborators
+Act on one function, method, or component boundary
+Assert on the returned value, state change, or emitted effect
+```
+
+### Pattern A Good Fit
+
+- pure functions
+- mappers or transformers
+- validators
+- repository or service methods with mocked dependencies
+- small boundary-level business logic
+
+### Pattern A Checklist
+
+- isolate one behavior
+- keep collaborators fake or mocked when helpful
+- assert on outcomes, not internal implementation noise
+- name tests by observable behavior
+
+---
+
+## Pattern B: Persistence Or Contract Test
+
+Use when you need confidence in schema, queries, serialization, or boundary compatibility.
+
+### Pattern B Skeleton
+
+```text
+Set up an isolated persistence or contract environment
+Insert or send representative inputs
+Read back or decode the resulting output
+Assert on correctness, constraints, and error cases
+```
+
+### Pattern B Good Fit
+
+- database queries
+- repository persistence rules
+- schema evolution
+- migration behavior
+- request / response or message serialization
+- interface compatibility checks
+
+### Pattern B Checklist
+
+- include one happy path
+- include one invalid or edge case
+- assert on durable outcomes, not just returned status
+- use representative fixtures where that improves clarity
+
+---
+
+## Pattern C: Flow Or Interaction Test
+
+Use when the value lies in verifying a user, operator, or system flow instead of an isolated unit.
+
+### Pattern C Skeleton
+
+```text
+Start from a realistic entry point
+Drive the interaction or workflow
+Wait for the expected state transition
+Assert on visible output, routed behavior, or side effects
+```
+
+### Pattern C Good Fit
+
+- UI interactions
+- endpoint-to-service flow
+- command or job workflows
+- integration boundaries
+- navigation or routing flows
+
+### Pattern C Checklist
+
+- keep the flow focused on one meaningful outcome
+- mock or isolate irrelevant external dependencies when possible
+- assert on the behavior the caller or user experiences
+- avoid testing multiple unrelated journeys in one case
+
+---
+
+## Common Assertions To Prefer
+
+- returned values or result envelopes
+- persisted state
+- emitted events or messages
+- visible UI state
+- boundary calls that materially define behavior
+- error category and recovery path
+
+Prefer observable behavior over internal implementation details.
+
+---
+
+## Common Anti-Patterns
+
+- testing too many branches in one test
+- asserting on private implementation details
+- using full integration tests when a narrow unit or contract test would falsify the same assumption
+- naming tests after implementation rather than behavior
+- copying framework-specific scaffolds without checking `testing.md`
+
+
+---
+
+# Test Type Decision Table — Project-Aware
+
+Use this table to choose the smallest verification type that matches the actual boundary being changed. Confirm the final choice against the repository's `testing.md`.
+
+| Scenario | Preferred check type | Why |
+| --- | --- | --- |
+| Pure function, mapper, validator, parser | Unit | Fastest falsifiable check with minimal setup |
+| Internal service or repository rule | Unit or component | Verifies business behavior without unnecessary system setup |
+| Persistence query, migration, or schema rule | Persistence / migration test | Verifies durable state and compatibility at the right boundary |
+| Request, handler, controller, or public API contract | Contract or integration test | Verifies visible boundary behavior and schema expectations |
+| UI or operator interaction flow | Flow / interaction test | Verifies user-visible behavior rather than isolated internals |
+| Async job, workflow, or queue behavior | Component or integration test | Verifies sequencing, retry, and side-effect behavior |
+| Documentation, reusable prompt, or platform instruction surfaces change | Structural consistency review | Executable tests may not exist; consistency becomes the real boundary |
+
+---
+
+## Test Type Summary
+
+| Type | Best for | Typical cost | Isolation |
+| --- | --- | --- | --- |
+| Unit | Pure logic and narrow behavior | Lowest | Highest |
+| Component | One internal boundary with collaborators | Low to medium | High |
+| Persistence / contract | Durable state or schema behavior | Low to medium | Medium to high |
+| Flow / interaction | User or system-visible path | Medium | Medium |
+| Integration | Real dependency or end-to-end boundary | Highest | Lowest |
+| Consistency review | Docs, reusable prompts, platform instruction surfaces, and template systems | Low | High |
+
+---
+
+## Selection Rules
+
+1. Prefer the narrowest check that can prove the change is correct.
+2. Escalate to broader tests only when the boundary truly requires it.
+3. Use project docs to choose commands, harnesses, and file placement.
+4. When no executable validation exists, make the structural review explicit rather than pretending the repo is fully testable.
+
+---
+
+## Naming Guidance
+
+Prefer behavior-driven names such as:
+
+- `returns empty result when no records match`
+- `rejects invalid payload when required field is missing`
+- `shows retry state after dependency timeout`
+- `persists latest progress after successful update`
+
+Avoid placeholder names such as:
+
+- `test1`
+- `happy path`
+- `error case`

package/docs/templates/skills/engineering/ui-ux-implementation/SKILL.md

@@ -0,0 +1,13 @@
+# UI/UX Implementation Skill
+
+You are a Senior Frontend Engineer specialized in translating design requirements into pixel-perfect, accessible, and responsive user interfaces.
+
+## Responsibilities
+1. Translate conceptual designs or `ui-ux.md` requirements into modular component code (React, Vue, HTML/CSS, etc.).
+2. Enforce mobile-first responsive design principles.
+3. Ensure strict adherence to Web Content Accessibility Guidelines (WCAG 2.1 AA), including proper ARIA labels, semantic HTML, and keyboard navigation.
+
+## Output Constraints
+- Write clean, modular, and reusable frontend components.
+- Do not introduce new CSS frameworks unless strictly permitted by the repository's configuration.
+- Always include hover, focus, and active states for interactive elements.

package/docs/templates/skills/operations/ci-cd-authoring/SKILL.md

@@ -0,0 +1,13 @@
+# CI/CD Authoring Skill
+
+You are a DevOps Engineer specializing in Continuous Integration and Continuous Deployment pipelines.
+
+## Responsibilities
+1. Generate automation scripts (GitHub Actions, GitLab CI, Jenkinsfiles, etc.) based on the project's build, test, and deployment requirements.
+2. Write optimized `Dockerfile` and `docker-compose.yml` configurations utilizing multi-stage builds for minimal production image sizes.
+3. Configure secure handling of secrets and environment variables.
+
+## Output Constraints
+- Prioritize security: Never hardcode secrets. Always use native secret injection mechanisms.
+- Prioritize performance: Utilize caching mechanisms for dependencies (e.g., node_modules, maven layers).
+- Keep pipeline YAML configurations extremely clean and well-commented.