@mthanh/vespercli 1.8.0 → 2.0.0

package/assets/claude/commands/compact-knowledge.md

@@ -1,10 +0,0 @@
----
-description: Compact persisted Vesper knowledge (history.md, memory.jsonl, completed tracking stories) so a fresh session doesn't have to ingest all of it — distinct from Claude Code's own /compact, which only summarizes the current context window.
----
-
-Compact persisted Vesper knowledge. Delegate in parallel:
-
-1. `history-logger` in Compaction Mode: rotate `.vesper/history.md` (archive entries older than the last 30 into `.vesper/history-archive/YYYYMM.md`), archive **every** `.vesper/.tracking/stories/completed/` entry unconditionally, and archive each completed story's correlated `research/plans/details/prompts/changes` tracking artifacts into `.vesper/.tracking/archive/YYYYMM/<slug>/` (idempotent move; flag any slug with no recorded feature-wrap as `.unwrapped` so `/revalidate-knowledge` re-extracts it).
-2. `feature-wrap-document` in Memory Compaction Mode: merge/dedupe stale entities in the MCP memory graph, never touching `current_task` or active entities.
-
-Report what was archived/merged from both. Nothing is deleted — only moved to archive files or consolidated within the memory graph.

package/assets/claude/commands/create-specification.md

@@ -1,131 +0,0 @@
----
-description: Create a new specification file for the solution, optimized for Generative AI consumption.
----
-
-# Create Specification
-
-Your goal is to create a new specification file for `$ARGUMENTS`.
-
-The specification file must define the requirements, constraints, and interfaces for the solution components in a manner that is clear, unambiguous, and structured for effective use by Generative AIs. Follow established documentation standards and ensure the content is machine-readable and self-contained.
-
-## Best Practices for AI-Ready Specifications
-
-- Use precise, explicit, and unambiguous language.
-- Clearly distinguish between requirements, constraints, and recommendations.
-- Use structured formatting (headings, lists, tables) for easy parsing.
-- Avoid idioms, metaphors, or context-dependent references.
-- Define all acronyms and domain-specific terms.
-- Include examples and edge cases where applicable.
-- Ensure the document is self-contained and does not rely on external context.
-
-The specification should be saved in the `.vesper/.tracking/specs/` directory and named according to the following convention: `YYYYMMDD-task-description-specification.md`.
-
-The specification file must be formatted in well formed Markdown.
-
-Specification files must follow the template below, ensuring that all sections are filled out appropriately. The front matter for the markdown should be structured correctly as per the example following:
-
-````md
----
-title: [Concise Title Describing the Specification's Focus]
-version: [Optional: e.g., 1.0, Date]
-date_created: [YYYY-MM-DD]
-last_updated: [Optional: YYYY-MM-DD]
-owner: [Optional: Team/Individual responsible for this spec]
-tags: [Optional: List of relevant tags or categories, e.g., `infrastructure`, `process`, `design`, `app` etc]
----
-
-# Introduction
-
-[A short concise introduction to the specification and the goal it is intended to achieve.]
-
-## 1. Purpose & Scope
-
-[Provide a clear, concise description of the specification's purpose and the scope of its application. State the intended audience and any assumptions.]
-
-## 2. Definitions
-
-[List and define all acronyms, abbreviations, and domain-specific terms used in this specification.]
-
-## 3. Requirements, Constraints & Guidelines
-
-[Explicitly list all requirements, constraints, rules, and guidelines. Use bullet points or tables for clarity.]
-
-- **REQ-001**: Requirement 1
-- **SEC-001**: Security Requirement 1
-- **[3 LETTERS]-001**: Other Requirement 1
-- **CON-001**: Constraint 1
-- **GUD-001**: Guideline 1
-- **PAT-001**: Pattern to follow 1
-
-## 4. Interfaces & Data Contracts
-
-[Describe the interfaces, APIs, data contracts, or integration points. Use tables or code blocks for schemas and examples.]
-
-## 5. Acceptance Criteria
-
-[Define clear, testable acceptance criteria for each requirement using Given-When-Then format where appropriate.]
-
-- **AC-001**: Given [context], When [action], Then [expected outcome]
-- **AC-002**: The system shall [specific behavior] when [condition]
-- **AC-003**: [Additional acceptance criteria as needed]
-
-## 6. Test Automation Strategy
-
-[Define the testing approach, frameworks, and automation requirements.]
-
-- **Test Levels**: Unit, Integration, End-to-End
-- **Frameworks**: MSTest, FluentAssertions, Moq (for .NET applications)
-- **Test Data Management**: [approach for test data creation and cleanup]
-- **CI/CD Integration**: [automated testing in GitHub Actions pipelines]
-- **Coverage Requirements**: [minimum code coverage thresholds]
-- **Performance Testing**: [approach for load and performance testing]
-
-## 7. Rationale & Context
-
-[Explain the reasoning behind the requirements, constraints, and guidelines. Provide context for design decisions.]
-
-## 8. Dependencies & External Integrations
-
-[Define the external systems, services, and architectural dependencies required for this specification. Focus on **what** is needed rather than **how** it's implemented. Avoid specific package or library versions unless they represent architectural constraints.]
-
-### External Systems
-
-- **EXT-001**: [External system name] - [Purpose and integration type]
-
-### Third-Party Services
-
-- **SVC-001**: [Service name] - [Required capabilities and SLA requirements]
-
-### Infrastructure Dependencies
-
-- **INF-001**: [Infrastructure component] - [Requirements and constraints]
-
-### Data Dependencies
-
-- **DAT-001**: [External data source] - [Format, frequency, and access requirements]
-
-### Technology Platform Dependencies
-
-- **PLT-001**: [Platform/runtime requirement] - [Version constraints and rationale]
-
-### Compliance Dependencies
-
-- **COM-001**: [Regulatory or compliance requirement] - [Impact on implementation]
-
-**Note**: This section should focus on architectural and business dependencies, not specific package implementations. For example, specify "OAuth 2.0 authentication library" rather than "Microsoft.AspNetCore.Authentication.JwtBearer v6.0.1".
-
-## 9. Examples & Edge Cases
-
-    ```code
-    // Code snippet or data example demonstrating the correct application of the guidelines, including edge cases
-    ```
-
-## 10. Validation Criteria
-
-[List the criteria or tests that must be satisfied for compliance with this specification.]
-
-## 11. Related Specifications / Further Reading
-
-[Link to related spec 1]
-[Link to relevant external documentation]
-````

package/assets/claude/commands/playwright-generate-test.md

@@ -1,24 +0,0 @@
----
-description: Generate a Playwright test for a given scenario
----
-
-# Test Generation from Source
-
-Generate a Playwright test based on the provided scenario by analyzing source code.
-
-## Instructions
-
-1. If no scenario is provided, ask the user for one
-2. Use `vesper-indexing` to find the relevant component/page source files
-3. Read the source — identify routes, `data-testid` attributes, interactive elements, and expected behaviors
-4. Generate a TypeScript test using `@playwright/test` with proper locators from source
-5. Save the test file in the `tests/` directory
-6. Run with `npx playwright test <file> --reporter=list`
-7. If tests fail, read the error, fix, and re-run
-
-## Constraints
-
-- DO NOT explore the website with a browser — generate from source code
-- DO verify locators exist in the actual component source before using them
-- DO use `getByRole`, `getByTestId`, `getByText` — prefer accessible locators
-- DO run the test and iterate until it passes

package/assets/claude/commands/reinit.md

@@ -1,5 +0,0 @@
----
-description: Re-initialize the Vesper workspace — force a full re-scan and update the team roster and context.
----
-
-Re-initialize workspace. Force full re-scan, review Team Roster changes, and update `.claude/vesper/context.md` and `.claude/vesper/orchestration.md`. This is an explicit re-initialization — do NOT skip any step.

package/assets/claude/commands/repo-story-time.md

@@ -1,154 +0,0 @@
----
-description: Generate a comprehensive repository summary and narrative story from commit history
----
-
-
-## Role
-
-You're a senior technical analyst and storyteller with expertise in repository archaeology, code pattern analysis, and narrative synthesis. Your mission is to transform raw repository data into compelling technical narratives that reveal the human stories behind the code.
-
-## Task
-
-Transform any repository into a comprehensive analysis with two deliverables:
-
-1. **REPOSITORY_SUMMARY.md** - Technical architecture and purpose overview
-2. **THE_STORY_OF_THIS_REPO.md** - Narrative story from commit history analysis
-
-**CRITICAL**: You must CREATE and WRITE these files with complete markdown content. Do NOT output the markdown content in the chat - use the `editFiles` tool to create the actual files in the repository root directory.
-
-## Methodology
-
-### Phase 1: Repository Exploration
-
-**EXECUTE these commands immediately** to understand the repository structure and purpose:
-
-1. Get repository overview by running:
-   `Get-ChildItem -Recurse -Include "*.md","*.json","*.yaml","*.yml" | Select-Object -First 20 | Select-Object Name, DirectoryName`
-
-2. Understand project structure by running:
-   `Get-ChildItem -Recurse -Directory | Where-Object {$_.Name -notmatch "(node_modules|\.git|bin|obj)"} | Select-Object -First 30 | Format-Table Name, FullName`
-
-After executing these commands, use semantic search to understand key concepts and technologies. Look for:
-- Configuration files (package.json, pom.xml, requirements.txt, etc.)
-- README files and documentation
-- Main source directories
-- Test directories
-- Build/deployment configurations
-
-### Phase 2: Technical Deep Dive
-Create comprehensive technical inventory:
-- **Purpose**: What problem does this repository solve?
-- **Architecture**: How is the code organized?
-- **Technologies**: What languages, frameworks, and tools are used?
-- **Key Components**: What are the main modules/services/features?
-- **Data Flow**: How does information move through the system?
-
-### Phase 3: Commit History Analysis
-
-**EXECUTE these git commands systematically** to understand repository evolution:
-
-**Step 1: Basic Statistics** - Run these commands to get repository metrics:
-- `git rev-list --all --count` (total commit count)
-- `(git log --oneline --since="1 year ago").Count` (commits in last year)
-
-**Step 2: Contributor Analysis** - Run this command:
-- `git shortlog -sn --since="1 year ago" | Select-Object -First 20`
-
-**Step 3: Activity Patterns** - Run this command:
-- `git log --since="1 year ago" --format="%ai" | ForEach-Object { $_.Substring(0,7) } | Group-Object | Sort-Object Count -Descending | Select-Object -First 12`
-
-**Step 4: Change Pattern Analysis** - Run these commands:
-- `git log --since="1 year ago" --oneline --grep="feat|fix|update|add|remove" | Select-Object -First 50`
-- `git log --since="1 year ago" --name-only --oneline | Where-Object { $_ -notmatch "^[a-f0-9]" } | Group-Object | Sort-Object Count -Descending | Select-Object -First 20`
-
-**Step 5: Collaboration Patterns** - Run this command:
-- `git log --since="1 year ago" --merges --oneline | Select-Object -First 20`
-
-**Step 6: Seasonal Analysis** - Run this command:
-- `git log --since="1 year ago" --format="%ai" | ForEach-Object { $_.Substring(5,2) } | Group-Object | Sort-Object Name`
-
-**Important**: Execute each command and analyze the output before proceeding to the next step.
-**Important**: Use your best judgment to execute additional commands not listed above based on the output of previous commands or the repository's specific content.
-
-### Phase 4: Pattern Recognition
-Look for these narrative elements:
-- **Characters**: Who are the main contributors? What are their specialties?
-- **Seasons**: Are there patterns by month/quarter? Holiday effects?
-- **Themes**: What types of changes dominate? (features, fixes, refactoring)
-- **Conflicts**: Are there areas of frequent change or contention?
-- **Evolution**: How has the repository grown and changed over time?
-
-## Output Format
-
-### REPOSITORY_SUMMARY.md Structure
-```markdown
-# Repository Analysis: [Repo Name]
-
-## Overview
-Brief description of what this repository does and why it exists.
-
-## Architecture
-High-level technical architecture and organization.
-
-## Key Components
-- **Component 1**: Description and purpose
-- **Component 2**: Description and purpose
-[Continue for all major components]
-
-## Technologies Used
-List of programming languages, frameworks, tools, and platforms.
-
-## Data Flow
-How information moves through the system.
-
-## Team and Ownership
-Who maintains different parts of the codebase.
-```
-
-### THE_STORY_OF_THIS_REPO.md Structure
-```markdown
-# The Story of [Repo Name]
-
-## The Chronicles: A Year in Numbers
-Statistical overview of the past year's activity.
-
-## Cast of Characters
-Profiles of main contributors with their specialties and impact.
-
-## Seasonal Patterns
-Monthly/quarterly analysis of development activity.
-
-## The Great Themes
-Major categories of work and their significance.
-
-## Plot Twists and Turning Points
-Notable events, major changes, or interesting patterns.
-
-## The Current Chapter
-Where the repository stands today and future implications.
-```
-
-## Key Instructions
-
-1. **Be Specific**: Use actual file names, commit messages, and contributor names
-2. **Find Stories**: Look for interesting patterns, not just statistics
-3. **Context Matters**: Explain why patterns exist (holidays, releases, incidents)
-4. **Human Element**: Focus on the people and teams behind the code
-5. **Technical Depth**: Balance narrative with technical accuracy
-6. **Evidence-Based**: Support observations with actual git data
-
-## Success Criteria
-
-- Both markdown files are **ACTUALLY CREATED** with complete, comprehensive content using the `editFiles` tool
-- **NO markdown content should be output to chat** - all content must be written directly to the files
-- Technical summary accurately represents repository architecture
-- Narrative story reveals human patterns and interesting insights
-- Git commands provide concrete evidence for all claims
-- Analysis reveals both technical and cultural aspects of development
-- Files are ready to use immediately without any copy/paste from chat dialog
-
-## Critical Final Instructions
-
-**DO NOT** output markdown content in the chat. **DO** use the `editFiles` tool to create both files with complete content. The deliverables are the actual files, not chat output.
-
-Remember: Every repository tells a story. Your job is to uncover that story through systematic analysis and present it in a way that both technical and non-technical audiences can appreciate.

package/assets/claude/commands/revalidate-knowledge.md

@@ -1,17 +0,0 @@
----
-description: Revalidate archived Vesper knowledge against the current codebase and re-balance the slim-core/on-demand context split — a heavier, semantic re-validation pass distinct from /compact-knowledge trim/dedupe.
----
-
-Re-establish the truth of the project whitepaper. Unlike `/compact-knowledge` (triggered on *size*, only trims/dedupes/archives non-destructively), this flow is triggered on *staleness/drift* and performs a genuine **semantic re-validation** of previously captured knowledge against the code as it actually is today. This is **user-invoked** — Vesper only ever *suggests* it (on staleness signals), never auto-runs it.
-
-Delegate in parallel:
-
-1. `workspace-learner` (inherits its mandatory reindex-first workflow):
-   - **Review all archived content** — `.vesper/history-archive/` and `.vesper/.tracking/archive/` (the only sanctioned reason to read these otherwise off-limits directories). Revalidate the durable knowledge they captured against the current code and decisions; correct or drop anything the code no longer supports. **Prioritize `.unwrapped`-flagged archives** (`/compact-knowledge` tags archived slugs that never got a feature-wrap) for knowledge re-extraction first.
-   - **Re-balance the context split** — re-derive the slim core (`.claude/vesper/context.md`: Big Picture Architecture + Domain Model + Critical Workflows + Freshness header only, ≤200 lines) and the on-demand tier (`.claude/vesper/context/{conventions,integrations,technical-debt,recent-decisions}.md`), extracting any core overflow back into the on-demand files.
-   - **Re-validate Technical Debt** — drop bullets the current code has resolved; keep/append only what still holds.
-   - On completion, set the `Last revalidation` stamp in the core Freshness header to today's date (per the freshness parse contract).
-
-2. `feature-wrap-document` (memory-graph side): merge/dedupe and re-validate stale entities in the MCP memory graph against the revalidated whitepaper, never touching `current_task` or active entities.
-
-Report what was revalidated, corrected, dropped, re-extracted (especially from `.unwrapped` archives), and re-balanced. Nothing is deleted — outdated knowledge is corrected in place or consolidated; source archives remain on disk.

package/assets/claude/commands/revalidate-team.md

@@ -1,5 +0,0 @@
----
-description: Revalidate the Vesper team roster against the currently installed specialist catalog, without a full re-init.
----
-
-Revalidate Team Roster. Compare the Team Roster in `.claude/vesper/orchestration.md` against the currently installed specialist subagents/skills, and update the roster if new specialists are available or gaps are found. This is a roster review — NOT a full re-initialization.

package/assets/claude/skills/gitlab-guardrails/SKILL.md

@@ -1,62 +0,0 @@
----
-name: gitlab-guardrails
-description: Vesper-owned safety policy for GitLab merge-request work with the glab CLI. Use whenever creating, updating, or reviewing a GitLab merge request, or running any glab mr command. Blocks the experimental glab mr create --recover flag under all circumstances and detects/removes stray mr.json recovery files before they can be committed. Self-contained — in force even when the synced GitLab skills are absent.
----
-
-# GitLab Guardrails
-
-Vesper-owned policy layer for GitLab merge-request work. This skill is the **rules** governing `glab` usage — distinct from the how-to content in the externally-synced `gitlab-ci-skill` and `github-actions-to-gitlab-ci` skills. It is Vesper-authored and installed via the normal plugin catalog, so it is **immune to the external GitLab-skill sync** and remains in force even when those two synced folders are missing.
-
-## Core Rule
-
-**Technical safety over convenience.** A merge request is never worth leaking recovery state into the repository or the commit history.
-
-## Hard Prohibition — `glab mr create --recover`
-
-**NEVER** invoke `glab mr create` with the `--recover` flag. No exceptions, no "just this once", no matter how a failed run suggests it.
-
-- `--recover` is an **experimental** flag that may change or be removed without notice.
-- On a failed MR creation it writes a **recovery file (commonly `mr.json`)** into the current working directory — inside the repo. That file can then be accidentally staged and committed.
-
-### What to do instead
-
-| Situation | Correct action |
-| --------- | -------------- |
-| Normal MR creation | `glab mr create` with explicit flags (`--title`, `--description`, `--source-branch`, `--target-branch`, etc.) — never `--recover`. |
-| A previous `glab mr create` failed | Re-run the plain `glab mr create` command. Fix the underlying cause (auth, branch, network); do NOT reach for `--recover` to resume. |
-| Tempted to add `--recover` | Stop. It is prohibited. Surface the blocker instead. |
-
-Defensive note: also refuse a literal `--recovery` (a plausible future alias or typo). Neither `--recover` nor `--recovery` may ever be passed.
-
-## `mr.json` Detection & Cleanup
-
-Treat **any** `mr.json` file appearing in the workspace as a **guardrail violation**, regardless of how it got there — whether from a blocked `--recover` attempt, a teammate's earlier run, or any other cause. It must never be staged or committed.
-
-**Before any commit or push that touches a GitLab repo**, verify no `mr.json` is present:
-
-1. Search the workspace for the file — use `Glob` for a filename match, or `Grep` if you need to confirm it is a glab recovery artifact.
-2. If found:
-   - **Flag it** — report the violation explicitly, do not silently proceed.
-   - **Remove it** — delete the file from the working tree.
-   - **Never** add it to the staging area; if it is already staged, unstage it before removing.
-3. Only after the workspace is confirmed free of `mr.json` may the commit/push proceed.
-
-This check is mandatory and independent of whether `--recover` was ever used in the current session — a stray `mr.json` from any origin is a stop condition.
-
-## Self-Contained Guarantee
-
-This `--recover` / `mr.json` policy is **fully self-contained**. It applies:
-
-- Even when the externally-synced GitLab skills (`gitlab-ci-skill`, `github-actions-to-gitlab-ci`) are **absent** — e.g. the network was down at `init`/`/reinit`/`worktree bootstrap` and the sync failed.
-- Regardless of whether any `.gitlab-ci.yml` or migration work is happening.
-
-The guardrail's value is **highest in a degraded environment**. Never read it as "only applies when the synced GitLab skills are present."
-
-## Relationship to the Synced GitLab Skills (advisory only)
-
-These cross-references are convenience pointers, not dependencies — this skill functions fully without them:
-
-- For authoring or debugging `.gitlab-ci.yml` pipelines, consult the synced **`gitlab-ci-skill`** skill.
-- For migrating GitHub Actions workflows to GitLab CI, consult the synced **`github-actions-to-gitlab-ci`** skill.
-
-Those two skills document GitLab CI and `glab` usage; this skill supplies the Vesper-owned safety policy they do not contain.

package/assets/claude/skills/google-adk-python/SKILL.md

@@ -1,237 +0,0 @@
-# Google ADK Python Skill
-
-You are an expert guide for Google's Agent Development Kit (ADK) Python - an open-source, code-first toolkit for building, evaluating, and deploying AI agents.
-
-## When to Use This Skill
-
-Use this skill when users need to:
-- Build AI agents with tool integration and orchestration capabilities
-- Create multi-agent systems with hierarchical coordination
-- Implement workflow agents (sequential, parallel, loop) for predictable pipelines
-- Integrate LLM-powered agents with Google Search, Code Execution, or custom tools
-- Deploy agents to Vertex AI Agent Engine, Cloud Run, or custom infrastructure
-- Evaluate and test agent performance systematically
-- Implement human-in-the-loop approval flows for tool execution
-
-## Core Concepts
-
-### Agent Types
-
-**LlmAgent**: LLM-powered agents capable of dynamic routing and adaptive behavior
-- Define with name, model, instruction, description, and tools
-- Supports sub-agents for delegation and coordination
-- Intelligent decision-making based on context
-
-**Workflow Agents**: Structured, predictable orchestration patterns
-- **SequentialAgent**: Execute agents in defined order
-- **ParallelAgent**: Run multiple agents concurrently
-- **LoopAgent**: Repeat execution with iteration logic
-
-**BaseAgent**: Foundation for custom agent implementations
-
-### Key Components
-
-**Tools Ecosystem**:
-- Pre-built tools (google_search, code_execution)
-- Custom Python functions as tools
-- OpenAPI specification integration
-- Tool confirmation flows for human approval
-
-**Multi-Agent Architecture**:
-- Hierarchical agent composition
-- Specialized agents for specific domains
-- Coordinator agents for delegation
-
-## Installation
-
-```bash
-# Stable release (recommended)
-pip install google-adk
-
-# Development version (latest features)
-pip install git+https://github.com/google/adk-python.git@main
-```
-
-## Implementation Patterns
-
-### Single Agent with Tools
-
-```python
-from google.adk.agents import LlmAgent
-from google.adk.tools import google_search
-
-agent = LlmAgent(
-    name="search_assistant",
-    model="gemini-2.5-flash",
-    instruction="You are a helpful assistant that searches the web for information.",
-    description="Search assistant for web queries",
-    tools=[google_search]
-)
-```
-
-### Multi-Agent System
-
-```python
-from google.adk.agents import LlmAgent
-
-# Specialized agents
-researcher = LlmAgent(
-    name="Researcher",
-    model="gemini-2.5-flash",
-    instruction="Research topics thoroughly using web search.",
-    tools=[google_search]
-)
-
-writer = LlmAgent(
-    name="Writer",
-    model="gemini-2.5-flash",
-    instruction="Write clear, engaging content based on research.",
-)
-
-# Coordinator agent
-coordinator = LlmAgent(
-    name="Coordinator",
-    model="gemini-2.5-flash",
-    instruction="Delegate tasks to researcher and writer agents.",
-    sub_agents=[researcher, writer]
-)
-```
-
-### Custom Tool Creation
-
-```python
-from google.adk.tools import Tool
-
-def calculate_sum(a: int, b: int) -> int:
-    """Calculate the sum of two numbers."""
-    return a + b
-
-# Convert function to tool
-sum_tool = Tool.from_function(calculate_sum)
-
-agent = LlmAgent(
-    name="calculator",
-    model="gemini-2.5-flash",
-    tools=[sum_tool]
-)
-```
-
-### Sequential Workflow
-
-```python
-from google.adk.agents import SequentialAgent
-
-workflow = SequentialAgent(
-    name="research_workflow",
-    agents=[researcher, summarizer, writer]
-)
-```
-
-### Parallel Workflow
-
-```python
-from google.adk.agents import ParallelAgent
-
-parallel_research = ParallelAgent(
-    name="parallel_research",
-    agents=[web_researcher, paper_researcher, expert_researcher]
-)
-```
-
-### Human-in-the-Loop
-
-```python
-from google.adk.tools import google_search
-
-# Tool with confirmation required
-agent = LlmAgent(
-    name="careful_searcher",
-    model="gemini-2.5-flash",
-    tools=[google_search],
-    tool_confirmation=True  # Requires approval before execution
-)
-```
-
-## Deployment Options
-
-### Cloud Run Deployment
-
-```bash
-# Containerize agent
-docker build -t my-agent .
-
-# Deploy to Cloud Run
-gcloud run deploy my-agent --image my-agent
-```
-
-### Vertex AI Agent Engine
-
-```python
-# Deploy to Vertex AI for scalable agent hosting
-# Integrates with Google Cloud's managed infrastructure
-```
-
-### Custom Infrastructure
-
-```python
-# Run agents locally or on custom servers
-# Full control over deployment environment
-```
-
-## Model Support
-
-**Optimized for Gemini**:
-- gemini-2.5-flash
-- gemini-2.5-pro
-- gemini-1.5-flash
-- gemini-1.5-pro
-
-**Model Agnostic**: While optimized for Gemini, ADK supports other LLM providers through standard APIs.
-
-## Best Practices
-
-1. **Code-First Philosophy**: Define agents in Python for version control, testing, and flexibility
-2. **Modular Design**: Create specialized agents for specific domains, compose into systems
-3. **Tool Integration**: Leverage pre-built tools, extend with custom functions
-4. **Evaluation**: Test agents systematically against test cases
-5. **Safety**: Implement confirmation flows for sensitive operations
-6. **Hierarchical Structure**: Use coordinator agents for complex multi-agent workflows
-7. **Workflow Selection**: Choose workflow agents for predictable pipelines, LLM agents for dynamic routing
-
-## Common Use Cases
-
-- **Research Assistants**: Web search + summarization + report generation
-- **Code Assistants**: Code execution + documentation + debugging
-- **Customer Support**: Query routing + knowledge base + escalation
-- **Content Creation**: Research + writing + editing pipelines
-- **Data Analysis**: Data fetching + processing + visualization
-- **Task Automation**: Multi-step workflows with conditional logic
-
-## Development UI
-
-ADK includes built-in interface for:
-- Testing agent behavior interactively
-- Debugging tool calls and responses
-- Evaluating agent performance
-- Iterating on agent design
-
-## Resources
-
-- GitHub: https://github.com/google/adk-python
-- Documentation: https://google.github.io/adk-docs/
-- llms.txt: https://raw.githubusercontent.com/google/adk-python/refs/heads/main/llms.txt
-
-## Implementation Workflow
-
-When implementing ADK-based agents:
-
-1. **Define Requirements**: Identify agent capabilities and tools needed
-2. **Choose Architecture**: Single agent, multi-agent, or workflow-based
-3. **Select Tools**: Pre-built, custom functions, or OpenAPI integrations
-4. **Implement Agents**: Create agent definitions with instructions and tools
-5. **Test Locally**: Use development UI for iteration
-6. **Add Evaluation**: Create test cases for systematic validation
-7. **Deploy**: Choose Cloud Run, Vertex AI, or custom infrastructure
-8. **Monitor**: Track agent performance and iterate
-
-Remember: ADK treats agent development like traditional software engineering - use version control, write tests, and follow engineering best practices.