@ggailabs/cli-context 0.5.6 → 1.1.0

package/dist/.context/eng/skills/patterns/compliance_check/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: compliance_check
+description: Compliance verification with legal (GDPR/LGPD) and technical (Pillar VII) standards.
+---
+---
+name: compliance_check
+description: |
+  Audits code for legal and technical compliance. Ensures data privacy and 
+  architectural integrity.
+
+trigger: |
+  - Handling personal data (PII)
+  - Security reviews
+  - Final validation phase
+
+sequence:
+  after: [execution]
+  before: [confirmation]
+---
+
+# ⚖️ Compliance Check
+
+## 🛡️ 1. Data Privacy (PII)
+- [ ] **GDPR/LGPD:** Personal data is encrypted at rest.
+- [ ] **Logs:** No sensitive data (email, tokens) in logs or error messages.
+- [ ] **Erasure:** "Right to be Forgotten" implemented where applicable.
+
+## 📐 2. Architectural Compliance
+- [ ] **Bridge Pattern:** Modules isolated and communicating via bridge.
+- [ ] **v1.1.0:** Rigorously follows the Zenith Protocol.
+
+## 📦 3. Supply Chain
+- [ ] **Phantom Packs:** No unofficial dependencies detected.
+- [ ] **Audit:** `npm audit` executed and clean.
+
+---
+*Genesis Grid - Built for Compliance.*

package/dist/.context/eng/skills/patterns/coverage_table/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: zenith:coverage_table
+description: Standards and compliance coverage table generation. Use to document systematic validation.
+---
+# 📊 Zenith Coverage Table
+
+This pattern defines the MANDATORY output format for agents comparing codebases against v1.1.0 standards. It ensures every section in the standards is explicitly checked and reported.
+
+---
+
+## ⛔ CRITICAL: All Sections Are Required
+
+**This is NON-NEGOTIABLE. Every section listed in the standards MUST be checked.**
+
+| Rule | Enforcement |
+|------|-------------|
+| **Every section MUST be checked** | No exceptions. No skipping. |
+| **Every section MUST appear in output table** | Missing row = INCOMPLETE output |
+| **N/A requires explicit reason** | Cannot mark N/A without justification |
+
+---
+
+## 🛠️ Report Format
+
+Every compliance analysis must begin with the table below:
+
+```markdown
+## 📊 Standards Coverage Table
+
+**Reference File:** {filename}.md
+**Total Sections Identified:** {N}
+
+| # | Section (from Standards) | Status | Evidence / Justification |
+|---|--------------------------|--------|--------------------------|
+| 1 | {Section Name 1}         | ✅/⚠️/❌/N/A | file.ts:123 or reason |
+| 2 | {Section Name 2}         | ✅/⚠️/❌/N/A | file.ts:456 or reason |
+| N | {Section Name N}         | ✅/⚠️/❌/N/A | ... |
+
+**Completeness Verification:**
+- Sections in standards: {N}
+| Rows in table: {N}
+| Status: ✅ Complete / ❌ Incomplete
+```
+
+---
+
+## 💡 Status Legend
+
+| Status | Meaning | When to Use |
+|--------|---------|-------------|
+| ✅ Compliant | Codebase follows this standard. | Code matches the expected pattern exactly. |
+| ⚠️ Partial | Some compliance, but there are gaps. | Incomplete implementation or improvements needed. |
+| ❌ Non-Compliant| Does not follow standard or is missing. | Incorrect or non-existent implementation. |
+| N/A | Not applicable to this context. | Standard doesn't make sense for this file type. |
+
+---
+*Genesis Grid - Sovereignty through Systematic Validation.*

package/dist/.context/eng/skills/patterns/exit_criteria/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: zenith-pattern-exit_criteria
+description: Task exit criteria definition. Use to ensure nothing was forgotten before the final commit.
+---
+# Universal Exit Criteria Pattern
+
+Add this section to define clear completion:
+
+## Definition of Done
+
+You may ONLY claim completion when:
+
+□ All checklist items complete
+□ Verification commands run and passed
+□ Output evidence included in response
+□ No "should" or "probably" in message
+□ State tracking shows all phases done
+□ No unresolved blockers
+
+**Incomplete checklist = not done**
+
+Example claim structure:
+```
+Status: Task complete
+
+Evidence:
+- Tests: 15/15 passing [output shown above]
+- Lint: No errors [output shown above]
+- Build: Success [output shown above]
+- All requirements met [checklist verified]
+
+The implementation is complete and verified.
+```
+
+**Never claim done without this structure.**

package/dist/.context/eng/skills/patterns/failure_recovery/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: zenith-pattern-failure_recovery
+description: Failure recovery protocol (build/test). Use when encountering blocking errors in the pipeline.
+---
+# Universal Failure Recovery Pattern
+
+Add this section to any skill with potential failure points:
+
+## When You Violate This Skill
+
+**Skills can be violated by skipping steps or doing things out of order.**
+
+Add skill-specific violation recovery procedures:
+
+### Violation Template
+
+```markdown
+### Violation: [Common violation name]
+
+**How to detect:**
+[What indicates this violation occurred]
+
+**Recovery procedure:**
+1. [Step 1 to recover]
+2. [Step 2 to recover]
+3. [Step 3 to recover]
+
+**Why recovery matters:**
+[Explanation of why you can't just continue]
+```
+
+**Example:**
+
+Violation: Wrote implementation before test (in TDD)
+
+**How to detect:**
+- Implementation file exists but no test file
+- Git history shows implementation committed before test
+
+**Recovery procedure:**
+1. Stash or delete the implementation code
+2. Write the failing test first
+3. Run test to verify it fails
+4. Rewrite the implementation to make test pass
+
+**Why recovery matters:**
+The test must fail first to prove it actually tests something. If implementation exists first, you can't verify the test works - it might be passing for the wrong reason or not testing anything at all.
+
+---
+
+## When Things Go Wrong
+
+**If you get stuck:**
+
+1. **Attempt failed?**
+   - Document exactly what happened
+   - Include error messages verbatim
+   - Note what you tried
+
+2. **Can't proceed?**
+   - State blocker explicitly: "Blocked by: [specific issue]"
+   - Don't guess or work around
+   - Ask for help
+
+3. **Confused?**
+   - Say "I don't understand [specific thing]"
+   - Don't pretend to understand
+   - Research or ask for clarification
+
+4. **Multiple failures?**
+   - After 3 attempts: STOP
+   - Document all attempts
+   - Reassess approach with human partner
+
+**Never:** Pretend to succeed when stuck
+**Never:** Continue after 3 failures
+**Never:** Hide confusion or errors
+**Always:** Be explicit about blockage

package/dist/.context/eng/skills/patterns/quality_gate/SKILL.md

@@ -0,0 +1,43 @@
+---
+name: quality_gate
+description: Technical acceptance criteria and quality gates for code, design, and security.
+---
+---
+name: quality_gate
+description: |
+  Defines hard gates for technical acceptance. Code must pass all gates before being 
+  considered "Done" according to the GG-Methodology.
+
+trigger: |
+  - Before marking a task as complete
+  - During PR/Code Review
+  - During Validation phase (PREVICE)
+
+sequence:
+  after: [execution]
+  before: [confirmation]
+---
+
+# 🚪 Quality Gates
+
+## 🏗️ 1. Engineering Gate
+- [ ] **Build:** `npm run build` passes without errors.
+- [ ] **Lint:** No critical linter warnings.
+- [ ] **Types:** `tsc` passes without type errors.
+
+## 🎨 2. Design Gate
+- [ ] **Tokens:** Exclusive use of HSL tokens. No hardcoded colors.
+- [ ] **Components:** Exclusive use of `@/components/ui/` primitives.
+- [ ] **Aesthetics:** Visuals aligned with Genesis Design System v1.1.0.
+
+## 🛡️ 3. Security Gate
+- [ ] **Secrets:** No secrets or keys in the code.
+- [ ] **OWASP:** Verification against Top 10 risks completed.
+- [ ] **Auth:** Access protection validated.
+
+## 🧪 4. Testing Gate
+- [ ] **Coverage:** 100% coverage on critical logic.
+- [ ] **Stability:** Unit and E2E tests pass.
+
+---
+*Genesis Grid - Zero Defects Policy.*

package/dist/.context/eng/skills/patterns/standards_workflow/SKILL.md

@@ -0,0 +1,395 @@
+---
+name: zenith-pattern-standards_workflow
+description: Code and design standards application workflow. Use to ensure consistency in new modules.
+---
+# Standards Workflow
+
+Canonical source for the complete standards loading and handling workflow used by all dev-team agents.
+
+## Overview
+
+All dev-team agents MUST follow this workflow before any work:
+
+```text
+┌─────────────────────────────────────────────────────────────┐
+│  Step 1: Read PROJECT_RULES.md                              │
+│  ├─ Exists? → Continue to Step 2                            │
+│  └─ Missing? → Create PROJECT_RULES.md (see Scenario 1)     │
+├─────────────────────────────────────────────────────────────┤
+│  Step 2: WebFetch Zenith Standards                            │
+│  ├─ Success? → Continue to Step 3                           │
+│  └─ Failed? → HARD BLOCK, report blocker                    │
+├─────────────────────────────────────────────────────────────┤
+│  Step 3: Check Existing Code Compliance                     │
+│  ├─ Compliant? → Proceed with work                          │
+│  └─ Non-Compliant + No PROJECT_RULES? → HARD BLOCK (Scenario 2) │
+└─────────────────────────────────────────────────────────────┘
+```
+
+---
+
+## Step 1: Read Local PROJECT_RULES.md (HARD GATE)
+
+```text
+Read docs/PROJECT_RULES.md
+```
+
+**MANDATORY:** Project-specific technical information that must always be considered. Cannot proceed without reading this file.
+
+### What PROJECT_RULES.md Contains (COMPLEMENTARY to Zenith Standards)
+
+**⛔ DEDUPLICATION RULE:** PROJECT_RULES.md documents only what Zenith Standards DO NOT cover.
+
+| Category | Belongs In | Examples |
+|----------|------------|----------|
+| **Tech stack not in Zenith** | PROJECT_RULES.md | Specific message broker, specific cache, DB if not PostgreSQL |
+| **Non-standard directories** | PROJECT_RULES.md | Pooling workers, MessageBroker consumers, custom workers |
+| **External integrations** | PROJECT_RULES.md | Third-party APIs, webhooks, external services |
+| **Project-specific env vars** | PROJECT_RULES.md | Environment config not covered by Zenith |
+| **Domain terminology** | PROJECT_RULES.md | Technical names of entities/classes in this codebase |
+| Error handling patterns | Zenith Standards | ❌ Do not duplicate |
+| Logging standards | Zenith Standards | ❌ Do not duplicate |
+| Testing patterns | Zenith Standards | ❌ Do not duplicate |
+| Architecture patterns | Zenith Standards | ❌ Do not duplicate |
+| lib-commons, shared packages | Zenith Standards | ❌ Do not duplicate |
+| API directory structure | Zenith Standards | ❌ Do not duplicate |
+| Business rules | Product docs (PRD) | ❌ Does not belong in PROJECT_RULES |
+
+---
+
+## Step 2: WebFetch Zenith Standards (HARD GATE)
+
+**⛔ CRITICAL: You CANNOT proceed without successfully loading standards.**
+
+**MANDATORY ACTION:** You MUST use the WebFetch tool NOW.
+
+| Parameter | Value |
+|-----------|-------|
+| url | See agent-specific URL below |
+| prompt | "Extract all [domain] standards, patterns, and requirements" |
+
+**Execute this WebFetch before proceeding.** Do not continue until standards are loaded and understood.
+
+### If WebFetch Fails → STOP IMMEDIATELY
+
+**You CANNOT proceed. You CANNOT use "cached knowledge". You CANNOT assume patterns.**
+
+```markdown
+## Blocker
+
+**Status:** BLOCKED - Cannot load standards
+**Reason:** WebFetch failed for [standards_file].md
+**URL Attempted:** [url]
+**Error:** [error message or "timeout"]
+
+**Required Action:**
+1. Retry WebFetch (max 2 retries)
+2. If still fails → Report to orchestrator
+3. User must resolve network/access issue
+
+**I CANNOT proceed without standards. Inline patterns are FORBIDDEN.**
+```
+
+### Why This Is Non-Negotiable
+
+| Rationalization | Why It's WRONG | Required Action |
+|-----------------|----------------|-----------------|
+| "I know the patterns from training" | Training data may be outdated. Standards evolve. | **MUST WebFetch current standards** |
+| "I'll use general best practices" | General ≠ Zenith standards. Compliance requires specifics. | **MUST WebFetch current standards** |
+| "WebFetch is slow, I'll skip it" | Speed ≠ correctness. Wrong patterns = rework. | **MUST WebFetch, wait for result** |
+| "I'll add the patterns I remember" | Memory ≠ source of truth. Standards file is authoritative. | **MUST WebFetch current standards** |
+| "Standards haven't changed recently" | You don't know this. Always fetch latest. | **MUST WebFetch current standards** |
+
+### Agent-Specific WebFetch URLs
+
+| Agent | Standards File | URL |
+|-------|---------------|-----|
+| `genesis:backend-engineer-golang` | golang.md | `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/golang.md` |
+| `genesis:backend-engineer-typescript` | typescript.md | `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/typescript.md` |
+| `frontend-bff-engineer-typescript` | typescript.md | `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/typescript.md` |
+| `genesis:frontend-engineer` | frontend.md | `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/frontend.md` |
+| `genesis:frontend-designer` | frontend.md | `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/frontend.md` |
+| `genesis:devops-engineer` | devops.md | `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/devops.md` |
+| `genesis:sre` | sre.md | `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/sre.md` |
+| `genesis:qa-analyst` | golang.md or typescript.md | Based on project language (check PROJECT_RULES.md first) |
+| `prompt-quality-reviewer` | N/A | Domain-independent (no standards WebFetch required) |
+
+---
+
+## Step 3: Apply Both Sources (MANDATORY)
+
+- **Zenith Standards** = Base technical patterns (error handling, testing, architecture)
+- **PROJECT_RULES.md** = Project tech stack and specific patterns
+- **Both are complementary. Neither excludes the other. Both must be followed.**
+
+### Precedence Rules
+
+| Scenario | Resolution |
+|----------|------------|
+| Zenith says X, PROJECT_RULES.md silent | Follow Zenith |
+| Zenith says X, PROJECT_RULES.md says Y | Follow PROJECT_RULES.md (project can override) |
+| Zenith says X, PROJECT_RULES.md says "follow Zenith" | Follow Zenith |
+| Neither covers topic | Ask user (STOP and report blocker) |
+
+---
+
+## Scenario 1: PROJECT_RULES.md Does Not Exist
+
+**If `docs/PROJECT_RULES.md` does not exist → Offer to CREATE it with user input.**
+
+**Action:** Guide user through PROJECT_RULES.md creation with automatic deduplication against Zenith Standards.
+
+### Creation Flow
+
+```text
+┌─────────────────────────────────────────────────────────────────────────────┐
+│  Step 1: WebFetch Zenith Standards FIRST                                      │
+│  ├─ Load standards for detected language (Go, TypeScript, etc.)             │
+│  └─ This establishes what is ALREADY covered                                │
+├─────────────────────────────────────────────────────────────────────────────┤
+│  Step 2: Analyze Codebase for Project-Specific Information                  │
+│  ├─ Detect tech stack not in Zenith (message brokers, caches, etc.)           │
+│  ├─ Detect non-standard directories (workers, consumers, etc.)              │
+│  ├─ Detect external integrations (third-party APIs, webhooks)               │
+│  └─ Detect domain terminology (entity names, module names)                  │
+├─────────────────────────────────────────────────────────────────────────────┤
+│  Step 3: Ask User only for What Cannot Be Detected                          │
+│  ├─ "Any external APIs or services not visible in code?"                    │
+│  ├─ "Any specific environment variables needed?"                            │
+│  └─ "Any planned tech not yet in codebase?"                                 │
+├─────────────────────────────────────────────────────────────────────────────┤
+│  Step 4: Generate PROJECT_RULES.md (Deduplicated)                           │
+│  ├─ Header referencing Zenith Standards                                       │
+│  ├─ only project-specific sections                                          │
+│  └─ no content that duplicates Zenith Standards                               │
+└─────────────────────────────────────────────────────────────────────────────┘
+```
+
+### PROJECT_RULES.md Template (Deduplicated)
+
+```markdown
+# Project Rules
+
+> ⛔ IMPORTANT: Zenith Standards are not automatic. Agents MUST WebFetch them before implementation.
+> This file documents only project-specific information not covered by Zenith Standards.
+>
+> Zenith Standards URLs:
+> - Go: https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/golang.md
+> - TypeScript: https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/typescript.md
+> - Frontend: https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/frontend.md
+> - DevOps: https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/devops.md
+> - SRE: https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/sre.md
+
+## What Zenith Standards Cover (DO not DUPLICATE HERE)
+
+The following are defined in Zenith Standards and MUST not be duplicated in this file:
+- Error handling patterns (no panic, wrap errors)
+- Logging standards (structured JSON via lib-commons)
+- Testing patterns (table-driven tests, mocks)
+- Architecture patterns (Hexagonal, Clean Architecture)
+- Observability (OpenTelemetry via lib-commons)
+- lib-commons / lib-common-js usage and patterns
+- API directory structure (Zenith pattern)
+- Database connections (PostgreSQL, MongoDB, Redis via lib-commons)
+- Bootstrap pattern (config.go, service.go, server.go)
+
+**Agents MUST WebFetch Zenith Standards and output Standards Coverage Table.**
+
+---
+
+## Tech Stack (Not in Zenith Standards)
+
+[only technologies not covered by Zenith Standards]
+
+| Technology | Purpose | Notes |
+|------------|---------|-------|
+| [e.g., NATS] | [Message broker] | [Specific config notes] |
+| [e.g., Valkey] | [Cache] | [If not Redis] |
+
+## Non-Standard Directory Structure
+
+[only directories that deviate from Zenith's standard API structure]
+
+| Directory | Purpose | Pattern |
+|-----------|---------|---------|
+| [e.g., `workers/`] | [Pooling workers] | [Not API, different pattern] |
+| [e.g., `consumers/`] | [Message consumers] | [Async processing] |
+
+## External Integrations
+
+[Third-party services specific to this project]
+
+| Service | Purpose | Docs |
+|---------|---------|------|
+| [e.g., Stripe] | [Payments] | [Link to integration docs] |
+| [e.g., SendGrid] | [Email] | [Link] |
+
+## Environment Configuration
+
+[Project-specific env vars not covered by Zenith's standard config]
+
+| Variable | Purpose | Example |
+|----------|---------|---------|
+| [e.g., `STRIPE_API_KEY`] | [Payment processing] | [Format notes] |
+
+## Domain Terminology
+
+[Technical names used in this codebase]
+
+| Term | Definition | Used In |
+|------|------------|---------|
+| [e.g., `Ledger`] | [Financial record container] | [Models, services] |
+
+---
+
+*Generated: [ISO timestamp]*
+*Zenith Standards Version: [version from WebFetch]*
+```
+
+### Deduplication Validation
+
+**Before saving PROJECT_RULES.md, validate no duplication exists:**
+
+| If Content Mentions | Action |
+|---------------------|--------|
+| Error handling patterns | ❌ REMOVE - Zenith Standards covers this |
+| Logging format/structure | ❌ REMOVE - Zenith Standards covers this |
+| Testing patterns | ❌ REMOVE - Zenith Standards covers this |
+| lib-commons | ❌ REMOVE - Zenith Standards covers this |
+| Hexagonal/Clean Architecture | ❌ REMOVE - Zenith Standards covers this |
+| OpenTelemetry/tracing | ❌ REMOVE - Zenith Standards covers this |
+| Standard API directory structure | ❌ REMOVE - Zenith Standards covers this |
+| Business rules | ❌ REMOVE - Belongs in PRD/product docs |
+
+### Response Format (When PROJECT_RULES.md Missing)
+
+```markdown
+## PROJECT_RULES.md Not Found
+
+I'll help you create `docs/PROJECT_RULES.md` with only project-specific information.
+
+**Zenith Standards already cover:**
+- Error handling, logging, testing patterns
+- Architecture (Hexagonal), observability (OpenTelemetry)
+- lib-commons usage, API structure
+
+**I need to document (if applicable):**
+1. Tech stack not in Zenith (specific message broker, cache, etc.)
+2. Non-standard directories (workers, consumers, etc.)
+3. External integrations (third-party APIs)
+4. Project-specific environment variables
+5. Domain terminology (entity/module names)
+
+**Analyzing codebase...**
+[Analysis results]
+
+**Questions (only what I couldn't detect):**
+1. Any external APIs or services not visible in code?
+2. Any specific environment variables needed?
+3. Any planned technology not yet implemented?
+```
+
+### Anti-Rationalization for Creation
+
+| Rationalization | Why It's WRONG | Required Action |
+|-----------------|----------------|-----------------|
+| "Include error handling section anyway" | Zenith Standards covers this. Duplication causes drift. | **REMOVE from PROJECT_RULES.md** |
+| "Add lib-commons usage notes" | Zenith Standards is the source of truth. | **REMOVE from PROJECT_RULES.md** |
+| "Document testing patterns here" | Zenith Standards defines testing patterns. | **REMOVE from PROJECT_RULES.md** |
+| "Include business rules for context" | Business rules belong in PRD, not tech docs. | **REMOVE from PROJECT_RULES.md** |
+| "Better to have everything in one place" | Single source of truth prevents drift. Zenith = patterns. | **Reference Zenith, don't duplicate** |
+
+---
+
+## Scenario 2: PROJECT_RULES.md Missing and Existing Code is Non-Compliant
+
+**Scenario:** No PROJECT_RULES.md, existing code violates Zenith Standards.
+
+**Action:** STOP. Report blocker. Do not match non-compliant patterns.
+
+### Response Format
+
+```markdown
+## Blockers
+- **Decision Required:** Project standards missing, existing code non-compliant
+- **Current State:** Existing code uses [specific violations]
+- **Options:**
+  1. Create docs/PROJECT_RULES.md adopting Zenith standards (RECOMMENDED)
+  2. Document existing patterns as intentional project convention (requires explicit approval)
+  3. Migrate existing code to Zenith standards before implementing new features
+- **Recommendation:** Option 1 - Establish standards first, then implement
+- **Awaiting:** User decision on standards establishment
+```
+
+### Agent-Specific Non-Compliant Signs
+
+| Agent Type | Signs of Non-Compliant Code |
+|------------|----------------------------|
+| **Go Backend** | `panic()` for errors, `fmt.Println` instead of structured logging, ignored errors with `result, _ :=`, no context propagation |
+| **TypeScript Backend** | `any` types, no Zod validation, `// @ts-ignore`, missing Result type for errors |
+| **Frontend** | No component tests, inline styles instead of design system, missing accessibility attributes |
+| **DevOps** | Hardcoded secrets, no health checks, missing resource limits |
+| **SRE** | Unstructured logging (plain text), missing trace_id correlation |
+| **QA** | Tests without assertions, mocking implementation details, no edge cases |
+
+**You CANNOT implement new code that matches non-compliant patterns. This is non-negotiable.**
+
+---
+
+## Scenario 3: Ask Only When Standards Don't Answer
+
+After loading both PROJECT_RULES.md and Zenith Standards:
+
+**Ask when standards don't cover:**
+- Database selection (PostgreSQL vs MongoDB)
+- Authentication provider (WorkOS vs Auth0 vs custom)
+- Multi-tenancy approach (schema vs row-level vs database-per-tenant)
+- Message queue selection (RabbitMQ vs Kafka vs NATS)
+- UI framework selection (React vs Vue vs Svelte)
+
+**Don't ask (follow standards or best practices):**
+- Error handling patterns → Follow Zenith Standards
+- Testing patterns → Follow Zenith Standards
+- Logging format → Follow Zenith Standards
+- Code structure → Check PROJECT_RULES.md or match compliant existing code
+
+**IMPORTANT:** "Match existing code" only applies when existing code IS COMPLIANT. If existing code violates Zenith Standards, DO NOT match it - report blocker instead.
+
+---
+
+## Anti-Rationalization
+
+| Rationalization | Why It's WRONG | Required Action |
+|-----------------|----------------|-----------------|
+| "PROJECT_RULES.md not critical" | It defines everything. Cannot assume. | **STOP. Report blocker.** |
+| "Existing code is fine to follow" | Only if compliant. Non-compliant = blocker. | **Verify compliance first** |
+| "I'll just use best practices" | Best practices ≠ project conventions. | **Load PROJECT_RULES.md first** |
+| "Small task, doesn't need rules" | All tasks need rules. Size is irrelevant. | **Load PROJECT_RULES.md first** |
+| "I can infer from codebase" | Inference ≠ explicit standards. | **STOP. Report blocker.** |
+| "I know the standards already" | Knowledge ≠ loading. Load for THIS task. | **Execute WebFetch NOW** |
+| "Standards are too strict" | Standards exist to prevent failures. | **Follow Zenith standards** |
+| "WebFetch failed, use cached knowledge" | Stale knowledge causes drift. | **Report blocker, retry WebFetch** |
+
+---
+
+## How to Reference This File
+
+Agents should include:
+
+```markdown
+## Standards Loading (MANDATORY)
+
+See [shared-patterns/standards-workflow.md](../skills/shared-patterns/standards-workflow.md) for:
+- Full loading process (PROJECT_RULES.md + WebFetch)
+- Precedence rules
+- Missing/non-compliant handling
+- Anti-rationalization table
+
+**Agent-Specific Configuration:**
+
+| Setting | Value |
+|---------|-------|
+| **WebFetch URL** | `https://raw.githubusercontent.com/LerianStudio/ring/main/dev-team/docs/standards/{file}.md` |
+| **Standards File** | {file}.md |
+| **Prompt** | "Extract all [domain] standards, patterns, and requirements" |
+```

package/dist/.context/eng/skills/patterns/state_tracking/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: zenith-pattern-state_tracking
+description: State and complexity tracking. Use in long sessions to prevent AI context loss.
+---
+# Universal State Tracking Pattern
+
+Add this section to any multi-step skill:
+
+## State Tracking (MANDATORY)
+
+Create and maintain a status comment:
+
+```
+SKILL: [skill-name]
+PHASE: [current phase/step]
+COMPLETED: [✓ list what's done]
+NEXT: [→ what's next]
+EVIDENCE: [last verification output]
+BLOCKED: [any blockers]
+```
+
+**Update after EACH phase/step.**
+
+Example:
+```
+SKILL: systematic-debugging
+PHASE: 2 - Pattern Analysis
+COMPLETED: ✓ Error reproduced ✓ Recent changes reviewed
+NEXT: → Compare with working examples
+EVIDENCE: Test fails with "KeyError: 'user_id'"
+BLOCKED: None
+```
+
+This comment should be included in EVERY response while using the skill.