@abarcenas/ai-workflow-template 1.1.0 → 1.13.0

package/.agents/instructions/learned-knowledge.instructions.md

@@ -0,0 +1,46 @@
+---
+applyTo: "**"
+description: "Persistent project knowledge accumulated across sessions. This file grows over time as agents discover patterns, conventions, gotchas, and preferences during work. It enables self-improvement — each session learns from the last."
+---
+
+# Learned Project Knowledge
+
+This file is the project's cumulative memory. It is read at the start of every session and updated at the end of every orchestrated pipeline.
+
+## How to Use
+
+- **Read this file** at the beginning of every task to apply previously discovered patterns and conventions.
+- **Append new entries** when you discover something that would help future sessions (patterns, gotchas, preferences).
+- **Never overwrite** — only append. This is a living log.
+
+---
+
+## Project Overview
+
+<!-- High-level project description filled in over time -->
+
+## Conventions & Patterns
+
+<!-- Coding conventions, architectural patterns, naming conventions discovered in this project -->
+
+## Gotchas & Deviations
+
+<!-- Unexpected behaviors, tricky configs, known pitfalls -->
+
+## Preferences
+
+<!-- User preferences about tooling, style, approach, etc. -->
+
+## Architecture Decisions
+
+<!-- Key technical decisions and their rationale -->
+
+## Agent Tuning Notes
+
+<!-- Per-agent prompt improvements discovered during sessions -->
+
+---
+
+## Session Log
+
+<!-- New entries are appended here by the orchestrator after each pipeline -->

package/{.github → .agents}/instructions/memory-bank.instructions.md

@@ -125,6 +125,20 @@ flowchart TD
     Complete -->|No| Execute
 ```
 
+### Audit Trail Requirement
+
+All planning, implementation, and execution work must be recorded in Markdown files.
+
+For every task:
+
+- Create or update a task file in `tasks/` with the request, plan, progress, and decisions.
+- Record implementation progress in the task progress log as work advances.
+- Keep `tasks/_index.md` current.
+- Use `progress.md` and `activeContext.md` for broader project status when relevant.
+- Do not rely on chat alone for durable tracking of plans or execution history.
+
+The Markdown record is the source of truth for auditing, traceability, and recovery after session resets.
+
 ## Documentation Updates
 
 Memory Bank updates occur when:

package/{.github → .agents}/instructions/task-implementation.instructions.md

@@ -11,6 +11,14 @@ Implementation progress MUST be tracked in a corresponding changes files located
 
 ## Core Implementation Process
 
+### Markdown Audit Trail
+
+All planning, implementation, and execution work must be recorded in Markdown files.
+
+- Keep the plan file, the changes file, and any task-specific notes current as work progresses.
+- Do not rely on chat alone for durable tracking of implementation decisions or progress.
+- Treat the Markdown record as the source of truth for auditability and session recovery.
+
 ### 1. Plan Analysis and Preparation
 
 **MUST complete before starting implementation:**

package/.agents/skills/architecture-blueprint-generator/SKILL.md

@@ -0,0 +1,378 @@
+---
+name: architecture-blueprint-generator
+description: 'Comprehensive project architecture blueprint generator that analyzes codebases to create detailed architectural documentation. Automatically detects technology stacks and architectural patterns, generates visual diagrams, documents implementation patterns, and provides extensible blueprints for maintaining architectural consistency and guiding new development.'
+---
+
+# Comprehensive Project Architecture Blueprint Generator
+
+## Configuration Variables
+${PROJECT_TYPE="Auto-detect|.NET|Java|React|Angular|Python|Node.js|Flutter|Other"} <!-- Primary technology -->
+${ARCHITECTURE_PATTERN="Auto-detect|Clean Architecture|Microservices|Layered|MVVM|MVC|Hexagonal|Event-Driven|Serverless|Monolithic|Other"} <!-- Primary architectural pattern -->
+${DIAGRAM_TYPE="C4|UML|Flow|Component|None"} <!-- Architecture diagram type -->
+${DETAIL_LEVEL="High-level|Detailed|Comprehensive|Implementation-Ready"} <!-- Level of detail to include -->
+${INCLUDES_CODE_EXAMPLES=true|false} <!-- Include sample code to illustrate patterns -->
+${INCLUDES_IMPLEMENTATION_PATTERNS=true|false} <!-- Include detailed implementation patterns -->
+${INCLUDES_DECISION_RECORDS=true|false} <!-- Include architectural decision records -->
+${FOCUS_ON_EXTENSIBILITY=true|false} <!-- Emphasize extension points and patterns -->
+
+## Generated Prompt
+
+"Create a comprehensive 'Project_Architecture_Blueprint.md' document that thoroughly analyzes the architectural patterns in the codebase to serve as a definitive reference for maintaining architectural consistency. Use the following approach:
+
+### 1. Architecture Detection and Analysis
+- ${PROJECT_TYPE == "Auto-detect" ? "Analyze the project structure to identify all technology stacks and frameworks in use by examining:
+  - Project and configuration files
+  - Package dependencies and import statements
+  - Framework-specific patterns and conventions
+  - Build and deployment configurations" : "Focus on ${PROJECT_TYPE} specific patterns and practices"}
+  
+- ${ARCHITECTURE_PATTERN == "Auto-detect" ? "Determine the architectural pattern(s) by analyzing:
+  - Folder organization and namespacing
+  - Dependency flow and component boundaries
+  - Interface segregation and abstraction patterns
+  - Communication mechanisms between components" : "Document how the ${ARCHITECTURE_PATTERN} architecture is implemented"}
+
+### 2. Architectural Overview
+- Provide a clear, concise explanation of the overall architectural approach
+- Document the guiding principles evident in the architectural choices
+- Identify architectural boundaries and how they're enforced
+- Note any hybrid architectural patterns or adaptations of standard patterns
+
+### 3. Architecture Visualization
+${DIAGRAM_TYPE != "None" ? `Create ${DIAGRAM_TYPE} diagrams at multiple levels of abstraction:
+- High-level architectural overview showing major subsystems
+- Component interaction diagrams showing relationships and dependencies
+- Data flow diagrams showing how information moves through the system
+- Ensure diagrams accurately reflect the actual implementation, not theoretical patterns` : "Describe the component relationships based on actual code dependencies, providing clear textual explanations of:
+- Subsystem organization and boundaries
+- Dependency directions and component interactions
+- Data flow and process sequences"}
+
+### 4. Core Architectural Components
+For each architectural component discovered in the codebase:
+
+- **Purpose and Responsibility**:
+  - Primary function within the architecture
+  - Business domains or technical concerns addressed
+  - Boundaries and scope limitations
+
+- **Internal Structure**:
+  - Organization of classes/modules within the component
+  - Key abstractions and their implementations
+  - Design patterns utilized
+
+- **Interaction Patterns**:
+  - How the component communicates with others
+  - Interfaces exposed and consumed
+  - Dependency injection patterns
+  - Event publishing/subscription mechanisms
+
+- **Evolution Patterns**:
+  - How the component can be extended
+  - Variation points and plugin mechanisms
+  - Configuration and customization approaches
+
+### 5. Architectural Layers and Dependencies
+- Map the layer structure as implemented in the codebase
+- Document the dependency rules between layers
+- Identify abstraction mechanisms that enable layer separation
+- Note any circular dependencies or layer violations
+- Document dependency injection patterns used to maintain separation
+
+### 6. Data Architecture
+- Document domain model structure and organization
+- Map entity relationships and aggregation patterns
+- Identify data access patterns (repositories, data mappers, etc.)
+- Document data transformation and mapping approaches
+- Note caching strategies and implementations
+- Document data validation patterns
+
+### 7. Cross-Cutting Concerns Implementation
+Document implementation patterns for cross-cutting concerns:
+
+- **Authentication & Authorization**:
+  - Security model implementation
+  - Permission enforcement patterns
+  - Identity management approach
+  - Security boundary patterns
+
+- **Error Handling & Resilience**:
+  - Exception handling patterns
+  - Retry and circuit breaker implementations
+  - Fallback and graceful degradation strategies
+  - Error reporting and monitoring approaches
+
+- **Logging & Monitoring**:
+  - Instrumentation patterns
+  - Observability implementation
+  - Diagnostic information flow
+  - Performance monitoring approach
+
+- **Validation**:
+  - Input validation strategies
+  - Business rule validation implementation
+  - Validation responsibility distribution
+  - Error reporting patterns
+
+- **Configuration Management**:
+  - Configuration source patterns
+  - Environment-specific configuration strategies
+  - Secret management approach
+  - Feature flag implementation
+
+### 8. Service Communication Patterns
+- Document service boundary definitions
+- Identify communication protocols and formats
+- Map synchronous vs. asynchronous communication patterns
+- Document API versioning strategies
+- Identify service discovery mechanisms
+- Note resilience patterns in service communication
+
+### 9. Technology-Specific Architectural Patterns
+${PROJECT_TYPE == "Auto-detect" ? "For each detected technology stack, document specific architectural patterns:" : `Document ${PROJECT_TYPE}-specific architectural patterns:`}
+
+${(PROJECT_TYPE == ".NET" || PROJECT_TYPE == "Auto-detect") ? 
+"#### .NET Architectural Patterns (if detected)
+- Host and application model implementation
+- Middleware pipeline organization
+- Framework service integration patterns
+- ORM and data access approaches
+- API implementation patterns (controllers, minimal APIs, etc.)
+- Dependency injection container configuration" : ""}
+
+${(PROJECT_TYPE == "Java" || PROJECT_TYPE == "Auto-detect") ? 
+"#### Java Architectural Patterns (if detected)
+- Application container and bootstrap process
+- Dependency injection framework usage (Spring, CDI, etc.)
+- AOP implementation patterns
+- Transaction boundary management
+- ORM configuration and usage patterns
+- Service implementation patterns" : ""}
+
+${(PROJECT_TYPE == "React" || PROJECT_TYPE == "Auto-detect") ? 
+"#### React Architectural Patterns (if detected)
+- Component composition and reuse strategies
+- State management architecture
+- Side effect handling patterns
+- Routing and navigation approach
+- Data fetching and caching patterns
+- Rendering optimization strategies" : ""}
+
+${(PROJECT_TYPE == "Angular" || PROJECT_TYPE == "Auto-detect") ? 
+"#### Angular Architectural Patterns (if detected)
+- Module organization strategy
+- Component hierarchy design
+- Service and dependency injection patterns
+- State management approach
+- Reactive programming patterns
+- Route guard implementation" : ""}
+
+${(PROJECT_TYPE == "Python" || PROJECT_TYPE == "Auto-detect") ? 
+"#### Python Architectural Patterns (if detected)
+- Module organization approach
+- Dependency management strategy
+- OOP vs. functional implementation patterns
+- Framework integration patterns
+- Asynchronous programming approach" : ""}
+
+### 10. Implementation Patterns
+${INCLUDES_IMPLEMENTATION_PATTERNS ? 
+"Document concrete implementation patterns for key architectural components:
+
+- **Interface Design Patterns**:
+  - Interface segregation approaches
+  - Abstraction level decisions
+  - Generic vs. specific interface patterns
+  - Default implementation patterns
+
+- **Service Implementation Patterns**:
+  - Service lifetime management
+  - Service composition patterns
+  - Operation implementation templates
+  - Error handling within services
+
+- **Repository Implementation Patterns**:
+  - Query pattern implementations
+  - Transaction management
+  - Concurrency handling
+  - Bulk operation patterns
+
+- **Controller/API Implementation Patterns**:
+  - Request handling patterns
+  - Response formatting approaches
+  - Parameter validation
+  - API versioning implementation
+
+- **Domain Model Implementation**:
+  - Entity implementation patterns
+  - Value object patterns
+  - Domain event implementation
+  - Business rule enforcement" : "Mention that detailed implementation patterns vary across the codebase."}
+
+### 11. Testing Architecture
+- Document testing strategies aligned with the architecture
+- Identify test boundary patterns (unit, integration, system)
+- Map test doubles and mocking approaches
+- Document test data strategies
+- Note testing tools and frameworks integration
+
+### 12. Deployment Architecture
+- Document deployment topology derived from configuration
+- Identify environment-specific architectural adaptations
+- Map runtime dependency resolution patterns
+- Document configuration management across environments
+- Identify containerization and orchestration approaches
+- Note cloud service integration patterns
+
+### 13. Extension and Evolution Patterns
+${FOCUS_ON_EXTENSIBILITY ? 
+"Provide detailed guidance for extending the architecture:
+
+- **Feature Addition Patterns**:
+  - How to add new features while preserving architectural integrity
+  - Where to place new components by type
+  - Dependency introduction guidelines
+  - Configuration extension patterns
+
+- **Modification Patterns**:
+  - How to safely modify existing components
+  - Strategies for maintaining backward compatibility
+  - Deprecation patterns
+  - Migration approaches
+
+- **Integration Patterns**:
+  - How to integrate new external systems
+  - Adapter implementation patterns
+  - Anti-corruption layer patterns
+  - Service facade implementation" : "Document key extension points in the architecture."}
+
+${INCLUDES_CODE_EXAMPLES ? 
+"### 14. Architectural Pattern Examples
+Extract representative code examples that illustrate key architectural patterns:
+
+- **Layer Separation Examples**:
+  - Interface definition and implementation separation
+  - Cross-layer communication patterns
+  - Dependency injection examples
+
+- **Component Communication Examples**:
+  - Service invocation patterns
+  - Event publication and handling
+  - Message passing implementation
+
+- **Extension Point Examples**:
+  - Plugin registration and discovery
+  - Extension interface implementations
+  - Configuration-driven extension patterns
+
+Include enough context with each example to show the pattern clearly, but keep examples concise and focused on architectural concepts." : ""}
+
+${INCLUDES_DECISION_RECORDS ? 
+"### 15. Architectural Decision Records
+Document key architectural decisions evident in the codebase:
+
+- **Architectural Style Decisions**:
+  - Why the current architectural pattern was chosen
+  - Alternatives considered (based on code evolution)
+  - Constraints that influenced the decision
+
+- **Technology Selection Decisions**:
+  - Key technology choices and their architectural impact
+  - Framework selection rationales
+  - Custom vs. off-the-shelf component decisions
+
+- **Implementation Approach Decisions**:
+  - Specific implementation patterns chosen
+  - Standard pattern adaptations
+  - Performance vs. maintainability tradeoffs
+
+For each decision, note:
+- Context that made the decision necessary
+- Factors considered in making the decision
+- Resulting consequences (positive and negative)
+- Future flexibility or limitations introduced" : ""}
+
+### ${INCLUDES_DECISION_RECORDS ? "16" : INCLUDES_CODE_EXAMPLES ? "15" : "14"}. Architecture Governance
+- Document how architectural consistency is maintained
+- Identify automated checks for architectural compliance
+- Note architectural review processes evident in the codebase
+- Document architectural documentation practices
+
+### ${INCLUDES_DECISION_RECORDS ? "17" : INCLUDES_CODE_EXAMPLES ? "16" : "15"}. Blueprint for New Development
+Create a clear architectural guide for implementing new features:
+
+- **Development Workflow**:
+  - Starting points for different feature types
+  - Component creation sequence
+  - Integration steps with existing architecture
+  - Testing approach by architectural layer
+
+- **Implementation Templates**:
+  - Base class/interface templates for key architectural components
+  - Standard file organization for new components
+  - Dependency declaration patterns
+  - Documentation requirements
+
+- **Common Pitfalls**:
+  - Architecture violations to avoid
+  - Common architectural mistakes
+  - Performance considerations
+  - Testing blind spots
+
+Include information about when this blueprint was generated and recommendations for keeping it updated as the architecture evolves.
+
+### ${INCLUDES_DECISION_RECORDS ? "18" : INCLUDES_CODE_EXAMPLES ? "17" : "16"}. Populate Agent Knowledge Base
+
+Write the discovered architecture details into the persistent knowledge system so all orchestrator agents (researcher, architect, implementer, coder, tracker) inherit this context without rediscovery:
+
+1. **Update `learned-knowledge.instructions.md`**:
+   - Append session entry with:
+     - **Pipeline:** `architecture-blueprint-generator`
+     - **New knowledge** section: detected tech stack, architectural pattern, layer structure, dependency rules, key abstractions
+   - Organize findings under the relevant sections (Conventions & Patterns, Architecture Decisions, Gotchas)
+
+2. **Create/update `docs/.architecture-context.md`**:
+   A concise, agent-readable reference (~50-150 lines) with:
+
+   ```markdown
+   # Architecture Context (Auto-Detected)
+
+   **Generated:** {date}
+   **Source:** architecture-blueprint-generator skill
+
+   ## Tech Stack
+   | Layer | Technology | Version |
+   |---|---|---|
+   | Frontend | {detected} | {version} |
+   | Backend | {detected} | {version} |
+   | Database | {detected} | {version} |
+   | Infrastructure | {detected} | {version} |
+
+   ## Architectural Pattern
+   {detected pattern} — {brief description, e.g., "Clean Architecture with CQRS"}
+
+   ## Layer Structure
+   | Layer | Directory | Purpose | Depends On |
+   |---|---|---|---|
+   | {name} | {path} | {responsibility} | {layer names} |
+
+   ## Key Abstractions
+   | Interface/Class | Location | Purpose | Implementations |
+   |---|---|---|---|
+   | `{name}` | `{path}` | {what it does} | {concrete classes} |
+
+   ## Dependency Rules
+   - {direction rule}: e.g., "Presentation → Application → Domain ← Infrastructure"
+   - {enforcement}: e.g., "Enforced via ArchUnit tests in tests/Architecture"
+
+   ## Notable Deviations / Gotchas
+   - {issue or quirk found}: {brief description}
+
+   ## Extension Points
+   - {how to add new feature type}: {pattern to follow}
+   ```
+
+3. **After writing both files**, summarize in your output:
+   - `docs/.architecture-context.md` created/updated
+   - `learned-knowledge.instructions.md` appended
+   - Key findings that were persisted (3-5 bullet points)"

package/.agents/skills/cavecrew/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: cavecrew
+description: >
+  Decision guide for delegating to caveman-style subagents. Tells the main
+  thread WHEN to spawn `cavecrew-investigator` (locate code), `cavecrew-builder`
+  (1-2 file edit), or `cavecrew-reviewer` (diff review) instead of doing the
+  work inline or using vanilla `Explore`. Subagent output is caveman-compressed
+  so the tool-result injected back into main context is ~60% smaller — main
+  context lasts longer across long sessions.
+  Trigger: "delegate to subagent", "use cavecrew", "spawn investigator/builder/reviewer",
+  "save context", "compressed agent output".
+---
+
+Cavecrew = three subagent presets that emit caveman output. Same job as Anthropic defaults (`Explore`, edit-style agents, reviewer); difference is the tool-result they return is compressed, so main context shrinks per delegation.
+
+## When to use cavecrew vs alternatives
+
+| Task | Use |
+|---|---|
+| "Where is X defined / what calls Y / list uses of Z" | `cavecrew-investigator` |
+| Same but you also want suggestions/architecture commentary | `Explore` (vanilla) |
+| Surgical edit, ≤2 files, scope obvious | `cavecrew-builder` |
+| New feature / 3+ files / cross-cutting refactor | Main thread or `feature-dev:code-architect` |
+| Review diff, branch, or file for bugs | `cavecrew-reviewer` |
+| Deep code review with rationale + alternatives | `Code Reviewer` (vanilla) |
+| One-line answer you already know | Main thread, no subagent |
+
+Rule of thumb: **if you'd want the subagent's output in 1/3 the tokens, pick cavecrew. If you'd want prose, pick vanilla.**
+
+## Why this exists (the real win)
+
+Subagent tool results get injected into main context verbatim. A vanilla `Explore` that returns 2k tokens of prose costs 2k tokens of main-context budget every time. The same finding from `cavecrew-investigator` returns ~700 tokens. Across 20 delegations in one session that's the difference between context exhaustion and finishing the task.
+
+## Output contracts
+
+What main thread can rely on per agent:
+
+**`cavecrew-investigator`**
+```
+<Header>:
+- path:line — `symbol` — short note
+totals: <counts>.
+```
+Or `No match.` Always file-path-first, line-number-attached, backticked symbols. Safe to grep with `path:\d+`.
+
+**`cavecrew-builder`**
+```
+<path:line-range> — <change ≤10 words>.
+verified: <re-read OK | mismatch @ path:line>.
+```
+Or one of: `too-big.` / `needs-confirm.` / `ambiguous.` / `regressed.` (terminal first token).
+
+**`cavecrew-reviewer`**
+```
+path:line: <emoji> <severity>: <problem>. <fix>.
+totals: N🔴 N🟡 N🔵 N❓
+```
+Or `No issues.` Findings sorted file → line ascending.
+
+## Chaining patterns
+
+**Locate → fix → verify** (most common):
+1. `cavecrew-investigator` returns site list.
+2. Main thread picks 1-2 sites, hands paths to `cavecrew-builder`.
+3. `cavecrew-reviewer` audits the diff.
+
+**Parallel scout** (when investigation is broad):
+Spawn 2-3 `cavecrew-investigator` calls in one message (different angles: defs vs callers vs tests). Aggregate in main thread.
+
+**Single-shot edit** (when site is already known):
+Skip investigator. Hand exact path:line to `cavecrew-builder` directly.
+
+## What NOT to do
+
+- Don't use `cavecrew-builder` when you don't already know the file. Spawn investigator first or main thread will eat tokens passing context.
+- Don't chain `cavecrew-investigator → cavecrew-builder` for a 5-file refactor. Builder will return `too-big.` and you'll have wasted a turn.
+- Don't ask `cavecrew-reviewer` for "general feedback" — it returns findings only, no architecture opinions. Use `Code Reviewer` for that.
+- Don't expect prose. Cavecrew output is structured, sometimes terse to the point of cryptic. If a human will read it directly, paraphrase.
+
+## Auto-clarity (inherited)
+
+Subagents drop caveman → normal English for security warnings, irreversible-action confirmations, and any output where fragment ambiguity could be misread. Resume caveman after.

package/.agents/skills/caveman/SKILL.md

@@ -0,0 +1,74 @@
+---
+name: caveman
+description: >
+  Ultra-compressed communication mode. Cuts token usage ~75% by speaking like caveman
+  while keeping full technical accuracy. Supports intensity levels: lite, full (default), ultra,
+  wenyan-lite, wenyan-full, wenyan-ultra.
+  Use when user says "caveman mode", "talk like caveman", "use caveman", "less tokens",
+  "be brief", or invokes /caveman. Also auto-triggers when token efficiency is requested.
+---
+
+Respond terse like smart caveman. All technical substance stay. Only fluff die.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE. No revert after many turns. No filler drift. Still active if unsure. Off only: "stop caveman" / "normal mode".
+
+Default: **full**. Switch: `/caveman lite|full|ultra`.
+
+## Rules
+
+Drop: articles (a/an/the), filler (just/really/basically/actually/simply), pleasantries (sure/certainly/of course/happy to), hedging. Fragments OK. Short synonyms (big not extensive, fix not "implement a solution for"). Technical terms exact. Code blocks unchanged. Errors quoted exact.
+
+Pattern: `[thing] [action] [reason]. [next step].`
+
+Not: "Sure! I'd be happy to help you with that. The issue you're experiencing is likely caused by..."
+Yes: "Bug in auth middleware. Token expiry check use `<` not `<=`. Fix:"
+
+## Intensity
+
+| Level | What change |
+|-------|------------|
+| **lite** | No filler/hedging. Keep articles + full sentences. Professional but tight |
+| **full** | Drop articles, fragments OK, short synonyms. Classic caveman |
+| **ultra** | Abbreviate prose words (DB/auth/config/req/res/fn/impl), strip conjunctions, arrows for causality (X → Y), one word when one word enough. Code symbols, function names, API names, error strings: never abbreviate |
+| **wenyan-lite** | Semi-classical. Drop filler/hedging but keep grammar structure, classical register |
+| **wenyan-full** | Maximum classical terseness. Fully 文言文. 80-90% character reduction. Classical sentence patterns, verbs precede objects, subjects often omitted, classical particles (之/乃/為/其) |
+| **wenyan-ultra** | Extreme abbreviation while keeping classical Chinese feel. Maximum compression, ultra terse |
+
+Example — "Why React component re-render?"
+- lite: "Your component re-renders because you create a new object reference each render. Wrap it in `useMemo`."
+- full: "New object ref each render. Inline object prop = new ref = re-render. Wrap in `useMemo`."
+- ultra: "Inline obj prop → new ref → re-render. `useMemo`."
+- wenyan-lite: "組件頻重繪，以每繪新生對象參照故。以 useMemo 包之。"
+- wenyan-full: "物出新參照，致重繪。useMemo .Wrap之。"
+- wenyan-ultra: "新參照→重繪。useMemo Wrap。"
+
+Example — "Explain database connection pooling."
+- lite: "Connection pooling reuses open connections instead of creating new ones per request. Avoids repeated handshake overhead."
+- full: "Pool reuse open DB connections. No new connection per request. Skip handshake overhead."
+- ultra: "Pool = reuse DB conn. Skip handshake → fast under load."
+- wenyan-full: "池reuse open connection。不每req新開。skip handshake overhead。"
+- wenyan-ultra: "池reuse conn。skip handshake → fast。"
+
+## Auto-Clarity
+
+Drop caveman when:
+- Security warnings
+- Irreversible action confirmations
+- Multi-step sequences where fragment order or omitted conjunctions risk misread
+- Compression itself creates technical ambiguity (e.g., `"migrate table drop column backup first"` — order unclear without articles/conjunctions)
+- User asks to clarify or repeats question
+
+Resume caveman after clear part done.
+
+Example — destructive op:
+> **Warning:** This will permanently delete all rows in the `users` table and cannot be undone.
+> ```sql
+> DROP TABLE users;
+> ```
+> Caveman resume. Verify backup exist first.
+
+## Boundaries
+
+Code/commits/PRs: write normal. "stop caveman" or "normal mode": revert. Level persist until changed or session end.

package/.agents/skills/caveman-commit/SKILL.md

@@ -0,0 +1,65 @@
+---
+name: caveman-commit
+description: >
+  Ultra-compressed commit message generator. Cuts noise from commit messages while preserving
+  intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why"
+  isn't obvious. Use when user says "write a commit", "commit message", "generate commit",
+  "/commit", or invokes /caveman-commit. Auto-triggers when staging changes.
+---
+
+Write commit messages terse and exact. Conventional Commits format. No fluff. Why over what.
+
+## Rules
+
+**Subject line:**
+- `<type>(<scope>): <imperative summary>` — `<scope>` optional
+- Types: `feat`, `fix`, `refactor`, `perf`, `docs`, `test`, `chore`, `build`, `ci`, `style`, `revert`
+- Imperative mood: "add", "fix", "remove" — not "added", "adds", "adding"
+- ≤50 chars when possible, hard cap 72
+- No trailing period
+- Match project convention for capitalization after the colon
+
+**Body (only if needed):**
+- Skip entirely when subject is self-explanatory
+- Add body only for: non-obvious *why*, breaking changes, migration notes, linked issues
+- Wrap at 72 chars
+- Bullets `-` not `*`
+- Reference issues/PRs at end: `Closes #42`, `Refs #17`
+
+**What NEVER goes in:**
+- "This commit does X", "I", "we", "now", "currently" — the diff says what
+- "As requested by..." — use Co-authored-by trailer
+- "Generated with Claude Code" or any AI attribution
+- Emoji (unless project convention requires)
+- Restating the file name when scope already says it
+
+## Examples
+
+Diff: new endpoint for user profile with body explaining the why
+- ❌ "feat: add a new endpoint to get user profile information from the database"
+- ✅
+  ```
+  feat(api): add GET /users/:id/profile
+
+  Mobile client needs profile data without the full user payload
+  to reduce LTE bandwidth on cold-launch screens.
+
+  Closes #128
+  ```
+
+Diff: breaking API change
+- ✅
+  ```
+  feat(api)!: rename /v1/orders to /v1/checkout
+
+  BREAKING CHANGE: clients on /v1/orders must migrate to /v1/checkout
+  before 2026-06-01. Old route returns 410 after that date.
+  ```
+
+## Auto-Clarity
+
+Always include body for: breaking changes, security fixes, data migrations, anything reverting a prior commit. Never compress these into subject-only — future debuggers need the context.
+
+## Boundaries
+
+Only generates the commit message. Does not run `git commit`, does not stage files, does not amend. Output the message as a code block ready to paste. "stop caveman-commit" or "normal mode": revert to verbose commit style.