gemiterm 2.0.0 → 2.1.0

package/.opencode/commands/opsx-explore.md

@@ -1,169 +0,0 @@
----
-description: Enter explore mode - think through ideas, investigate problems, clarify requirements
----
-
-Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
-
-**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal. You MAY create OpenSpec artifacts (proposals, designs, specs) if the user asks—that's capturing thinking, not implementing.
-
-**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
-
-**Input**: The argument after `/opsx-explore` is whatever the user wants to think about. Could be:
-- A vague idea: "real-time collaboration"
-- A specific problem: "the auth system is getting unwieldy"
-- A change name: "add-dark-mode" (to explore in context of that change)
-- A comparison: "postgres vs sqlite for this"
-- Nothing (just enter explore mode)
-
----
-
-## The Stance
-
-- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
-- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
-- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
-- **Adaptive** - Follow interesting threads, pivot when new information emerges
-- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
-- **Grounded** - Explore the actual codebase when relevant, don't just theorize
-
----
-
-## What You Might Do
-
-Depending on what the user brings, you might:
-
-**Explore the problem space**
-- Ask clarifying questions that emerge from what they said
-- Challenge assumptions
-- Reframe the problem
-- Find analogies
-
-**Investigate the codebase**
-- Map existing architecture relevant to the discussion
-- Find integration points
-- Identify patterns already in use
-- Surface hidden complexity
-
-**Compare options**
-- Brainstorm multiple approaches
-- Build comparison tables
-- Sketch tradeoffs
-- Recommend a path (if asked)
-
-**Visualize**
-```
-┌─────────────────────────────────────────┐
-│     Use ASCII diagrams liberally        │
-├─────────────────────────────────────────┤
-│                                         │
-│      ┌────────┐         ┌────────┐      │
-│      │ State  │────────▶│ State  │      │
-│      │   A    │         │   B    │      │
-│      └────────┘         └────────┘      │
-│                                         │
-│   System diagrams, state machines,      │
-│   data flows, architecture sketches,    │
-│   dependency graphs, comparison tables  │
-│                                         │
-└─────────────────────────────────────────┘
-```
-
-**Surface risks and unknowns**
-- Identify what could go wrong
-- Find gaps in understanding
-- Suggest spikes or investigations
-
----
-
-## OpenSpec Awareness
-
-You have full context of the OpenSpec system. Use it naturally, don't force it.
-
-### Check for context
-
-At the start, quickly check what exists:
-```bash
-openspec list --json
-```
-
-This tells you:
-- If there are active changes
-- Their names, schemas, and status
-- What the user might be working on
-
-If the user mentioned a specific change name, read its artifacts for context.
-
-### When no change exists
-
-Think freely. When insights crystallize, you might offer:
-
-- "This feels solid enough to start a change. Want me to create a proposal?"
-- Or keep exploring - no pressure to formalize
-
-### When a change exists
-
-If the user mentions a change or you detect one is relevant:
-
-1. **Resolve and read existing artifacts for context**
-   - Run `openspec status --change "<name>" --json`.
-   - Use `changeRoot`, `artifactPaths`, and `actionContext` from the status JSON.
-   - Read existing files from `artifactPaths.<artifact>.existingOutputPaths`.
-
-2. **Reference them naturally in conversation**
-   - "Your design mentions using Redis, but we just realized SQLite fits better..."
-   - "The proposal scopes this to premium users, but we're now thinking everyone..."
-
-3. **Offer to capture when decisions are made**
-
-    | Insight Type               | Where to Capture               |
-    |----------------------------|--------------------------------|
-    | New requirement discovered | `specs/<capability>/spec.md` |
-    | Requirement changed        | `specs/<capability>/spec.md` |
-    | Design decision made       | `design.md`                  |
-    | Scope changed              | `proposal.md`                |
-    | New work identified        | `tasks.md`                   |
-    | Assumption invalidated     | Relevant artifact              |
-
-   Example offers:
-   - "That's a design decision. Capture it in design.md?"
-   - "This is a new requirement. Add it to specs?"
-   - "This changes scope. Update the proposal?"
-
-4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
-
----
-
-## What You Don't Have To Do
-
-- Follow a script
-- Ask the same questions every time
-- Produce a specific artifact
-- Reach a conclusion
-- Stay on topic if a tangent is valuable
-- Be brief (this is thinking time)
-
----
-
-## Ending Discovery
-
-There's no required ending. Discovery might:
-
-- **Flow into a proposal**: "Ready to start? I can create a change proposal."
-- **Result in artifact updates**: "Updated design.md with these decisions"
-- **Just provide clarity**: User has what they need, moves on
-- **Continue later**: "We can pick this up anytime"
-
-When things crystallize, you might offer a summary - but it's optional. Sometimes the thinking IS the value.
-
----
-
-## Guardrails
-
-- **Don't implement** - Never write code or implement features. Creating OpenSpec artifacts is fine, writing application code is not.
-- **Don't fake understanding** - If something is unclear, dig deeper
-- **Don't rush** - Discovery is thinking time, not task time
-- **Don't force structure** - Let patterns emerge naturally
-- **Don't auto-capture** - Offer to save insights, don't just do it
-- **Do visualize** - A good diagram is worth many paragraphs
-- **Do explore the codebase** - Ground discussions in reality
-- **Do question assumptions** - Including the user's and your own

package/.opencode/commands/opsx-propose.md

@@ -1,104 +0,0 @@
----
-description: Propose a new change - create it and generate all artifacts in one step
----
-
-Propose a new change - create the change and generate all artifacts in one step.
-
-I'll create a change with artifacts:
-- proposal.md (what & why)
-- design.md (how)
-- tasks.md (implementation steps)
-
-When ready to implement, run /opsx-apply
-
----
-
-**Input**: The argument after `/opsx-propose` is the change name (kebab-case), OR a description of what the user wants to build.
-
-**Steps**
-
-1. **If no input provided, ask what they want to build**
-
-   Use the **AskUserQuestion tool** (open-ended, no preset options) to ask:
-   > "What change do you want to work on? Describe what you want to build or fix."
-
-   From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
-
-   **IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
-
-2. **Create the change directory**
-   ```bash
-   openspec new change "<name>"
-   ```
-   This creates a scaffolded change in the planning home resolved by the CLI with `.openspec.yaml`.
-
-3. **Get the artifact build order**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to get:
-   - `applyRequires`: array of artifact IDs needed before implementation (e.g., `["tasks"]`)
-   - `artifacts`: list of all artifacts with their status and dependencies
-   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context. Use these instead of assuming repo-local paths.
-
-4. **Create artifacts in sequence until apply-ready**
-
-   Use the **TodoWrite tool** to track progress through the artifacts.
-
-   Loop through artifacts in dependency order (artifacts with no pending dependencies first):
-
-   a. **For each artifact that is `ready` (dependencies satisfied)**:
-      - Get instructions:
-        ```bash
-        openspec instructions <artifact-id> --change "<name>" --json
-        ```
-      - The instructions JSON includes:
-        - `context`: Project background (constraints for you - do NOT include in output)
-        - `rules`: Artifact-specific rules (constraints for you - do NOT include in output)
-        - `template`: The structure to use for your output file
-        - `instruction`: Schema-specific guidance for this artifact type
-        - `resolvedOutputPath`: Resolved path or pattern to write the artifact
-        - `dependencies`: Completed artifacts to read for context
-      - Read any completed dependency files for context
-      - Create the artifact file using `template` as the structure and write it to `resolvedOutputPath`
-      - Apply `context` and `rules` as constraints - but do NOT copy them into the file
-      - Show brief progress: "Created <artifact-id>"
-
-   b. **Continue until all `applyRequires` artifacts are complete**
-      - After creating each artifact, re-run `openspec status --change "<name>" --json`
-      - Check if every artifact ID in `applyRequires` has `status: "done"` in the artifacts array
-      - Stop when all `applyRequires` artifacts are done
-
-   c. **If an artifact requires user input** (unclear context):
-      - Use **AskUserQuestion tool** to clarify
-      - Then continue with creation
-
-5. **Show final status**
-   ```bash
-   openspec status --change "<name>"
-   ```
-
-**Output**
-
-After completing all artifacts, summarize:
-- Change name and location
-- List of artifacts created with brief descriptions
-- What's ready: "All artifacts created! Ready for implementation."
-- Prompt: "Run `/opsx-apply` to start implementing."
-
-**Artifact Creation Guidelines**
-
-- Follow the `instruction` field from `openspec instructions` for each artifact type
-- The schema defines what each artifact should contain - follow it
-- Read dependency artifacts for context before creating new ones
-- Use `template` as the structure for your output file - fill in its sections
-- **IMPORTANT**: `context` and `rules` are constraints for YOU, not content for the file
-  - Do NOT copy `<context>`, `<rules>`, `<project_context>` blocks into the artifact
-  - These guide what you write, but should never appear in the output
-
-**Guardrails**
-- Create ALL artifacts needed for implementation (as defined by schema's `apply.requires`)
-- Always read dependency artifacts before creating a new one
-- If context is critically unclear, ask the user - but prefer making reasonable decisions to keep momentum
-- If a change with that name already exists, ask if user wants to continue it or create a new one
-- Verify each artifact file exists after writing before proceeding to next

package/.opencode/commands/opsx-sync.md

@@ -1,140 +0,0 @@
----
-description: Sync delta specs from a change to main specs
----
-
-Sync delta specs from a change to main specs.
-
-This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
-
-**Input**: Optionally specify a change name after `/opsx-sync` (e.g., `/opsx-sync add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **If no change name provided, prompt for selection**
-
-   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
-
-   Show changes that have delta specs (under `specs/` directory).
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Resolve change context**
-
-   Run:
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-
-   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace spec sync is not supported in this slice and STOP. Do not fall back to repo-local paths or edit linked repos.
-
-3. **Find delta specs**
-
-   Use `artifactPaths.specs.existingOutputPaths` from the status JSON as the list of delta spec files.
-
-   Each delta spec file contains sections like:
-   - `## ADDED Requirements` - New requirements to add
-   - `## MODIFIED Requirements` - Changes to existing requirements
-   - `## REMOVED Requirements` - Requirements to remove
-   - `## RENAMED Requirements` - Requirements to rename (FROM:/TO: format)
-
-   If no delta specs found, inform user and stop.
-
-4. **For each delta spec, apply changes to main specs**
-
-   For each repo-local capability delta spec path returned by the CLI:
-
-   a. **Read the delta spec** to understand the intended changes
-
-   b. **Read the main spec** at `openspec/specs/<capability>/spec.md` (may not exist yet)
-
-   c. **Apply changes intelligently**:
-
-      **ADDED Requirements:**
-      - If requirement doesn't exist in main spec → add it
-      - If requirement already exists → update it to match (treat as implicit MODIFIED)
-
-      **MODIFIED Requirements:**
-      - Find the requirement in main spec
-      - Apply the changes - this can be:
-        - Adding new scenarios (don't need to copy existing ones)
-        - Modifying existing scenarios
-        - Changing the requirement description
-      - Preserve scenarios/content not mentioned in the delta
-
-      **REMOVED Requirements:**
-      - Remove the entire requirement block from main spec
-
-      **RENAMED Requirements:**
-      - Find the FROM requirement, rename to TO
-
-   d. **Create new main spec** if capability doesn't exist yet:
-      - Create `openspec/specs/<capability>/spec.md`
-      - Add Purpose section (can be brief, mark as TBD)
-      - Add Requirements section with the ADDED requirements
-
-5. **Show summary**
-
-   After applying all changes, summarize:
-   - Which capabilities were updated
-   - What changes were made (requirements added/modified/removed/renamed)
-
-**Delta Spec Format Reference**
-
-```markdown
-## ADDED Requirements
-
-### Requirement: New Feature
-The system SHALL do something new.
-
-#### Scenario: Basic case
-- **WHEN** user does X
-- **THEN** system does Y
-
-## MODIFIED Requirements
-
-### Requirement: Existing Feature
-#### Scenario: New scenario to add
-- **WHEN** user does A
-- **THEN** system does B
-
-## REMOVED Requirements
-
-### Requirement: Deprecated Feature
-
-## RENAMED Requirements
-
-- FROM: `### Requirement: Old Name`
-- TO: `### Requirement: New Name`
-```
-
-**Key Principle: Intelligent Merging**
-
-Unlike programmatic merging, you can apply **partial updates**:
-- To add a scenario, just include that scenario under MODIFIED - don't copy existing scenarios
-- The delta represents *intent*, not a wholesale replacement
-- Use your judgment to merge changes sensibly
-
-**Output On Success**
-
-```
-## Specs Synced: <change-name>
-
-Updated main specs:
-
-**<capability-1>**:
-- Added requirement: "New Feature"
-- Modified requirement: "Existing Feature" (added 1 scenario)
-
-**<capability-2>**:
-- Created new spec file
-- Added requirement: "Another Feature"
-
-Main specs are now updated. The change remains active - archive when implementation is complete.
-```
-
-**Guardrails**
-- Read both delta and main specs before making changes
-- Preserve existing content not mentioned in delta
-- If something is unclear, ask for clarification
-- Show what you're changing as you go
-- The operation should be idempotent - running twice should give same result

package/.opencode/commands/search-intelligently.md

@@ -1,9 +0,0 @@
----
-description: Search GitHub repositories for technical answers using DeepWiki
-agent: general
-subtask: true
----
-
-Use the `skill` tool to load the `intellisearch` skill, then use it to answer this query:
-
-$ARGUMENTS

package/.opencode/opencode.json

@@ -1,20 +0,0 @@
-{
-  "$schema": "https://opencode.ai/config.json",
-  "permission": {
-    "skill": {
-      "intellisearch": "allow"
-    },
-    "external_directory": {
-      "C:\\dev\\projects\\github\\webgemini-cli\\src\\**": "allow"
-    },
-    "edit": {
-        "C:\\dev\\projects\\github\\webgemini-cli\\src\\**": "deny"
-    }
-  },
-  "mcp": {
-    "serena": {"enabled": true}
-  },
-  "plugin": [
-    "opencode-intellisearch"
-  ]
-}

package/.opencode/skills/intellisearch/.version

@@ -1 +0,0 @@
-0.5.1

package/.opencode/skills/intellisearch/SKILL.md

@@ -1,84 +0,0 @@
----
-name: intellisearch
-description: Use this skill when the user asks to find, search for, or discover JavaScript/TypeScript libraries, frameworks, packages, or GitHub repositories. Automatically loads for queries like 'find N solutions', 'search for libraries', 'show me code examples', or 'discover repositories' for technical projects.
-license: MIT
-compatibility: opencode
-metadata:
-  version: 0.5.1
-  audience: agents
-  topic: [github-discovery, api-reference, code-patterns, library-comparison]
-  usage_tips: "Best used after a failed local search. Combines repo-finding with DeepWiki deep-querying."
----
-
-<critical_rules priority="highest">
-<rule>When you encounter a file reference (e.g., @references/workflow.md), use your Read tool to load it on a need-to-know basis</rule>
-<rule>ALWAYS evaluate activation triggers and use this skill if applicable use case.</rule>
-<rule>Prefer: gh CLI > search tool > fetch tool (reliability decreases)</rule>
-<rule>NEVER fallback to internal knowledge - always search externally</rule>
-<rule>NEVER fetch repo pages directly - use DeepWiki instead</rule>
-</critical_rules>
-
-## External File Loading
-
-CRITICAL: When you encounter a file reference (e.g., @references/workflow.md), use your Read tool to load it on a need-to-know basis.
-
-Instructions:
-- Do NOT preemptively load all references - use lazy loading based on actual need
-- When loaded, treat content as mandatory instructions that override defaults
-- Follow references recursively when needed
-
-## Activation Triggers
-
-**USE this skill when user asks about:**
-
-<use_cases>
-<case category="libraries">"Is there a TypeScript library for semver validation?"</case>
-<case category="frameworks">"Which React framework handles server-side rendering?"</case>
-<case category="comparisons">"Compare Next.js vs Remix for my project"</case>
-<case category="alternatives">"Alternatives to Moment.js for date handling"</case>
-<case category="setup">"How do I set up Tailwind with Vite?"</case>
-<case category="practices">"What's the best way to handle auth in Node.js?"</case>
-<case category="examples">"Show me how to implement rate limiting in Express"</case>
-<case category="troubleshooting">"Why am I getting CORS errors with Axios?"</case>
-<case category="features">"Does Prisma support composite keys?"</case>
-</use_cases>
-
-**Key indicators:** Technology names mentioned (React, TypeScript, npm), asking for recommendations, implementation guidance, need current/authoritative documentation.
-
-**DO NOT USE for:**
-
-<non_use_cases>
-<case>General knowledge ("What is REST?") → Use web search or internal knowledge</case>
-<case>Non-technical topics ("What's the weather?") → Irrelevant</case>
-<case>User's own code ("Debug my script") → Use code analysis tools directly</case>
-<case>Known specific repo ("Tell me about facebook/react") → Use DeepWiki directly</case>
-<case>No GitHub relevance ("How do I cook pasta?") → Irrelevant</case>
-<case>Current events/news ("What happened to NPM yesterday?") → Use web search</case>
-<case>Private/internal repos ("Search my company's private repo") → DeepWiki can't access</case>
-<case>Pure syntax questions ("What's the syntax for arrow functions?") → Use internal knowledge</case>
-<case>Opinion questions ("Is React better than Vue?") → No factual repo answer</case>
-</non_use_cases>
-
-## Workflow Summary
-
-<workflow>
-<phase name="detect">Check available tools: gh CLI → search tool → fetch tool</phase>
-<phase name="search">Execute search using highest priority available tool</phase>
-<phase name="filter">Select top 3 repos by stars, recency, language match</phase>
-<phase name="query">Query DeepWiki with repos (multi-repo first, fallback to individual)</phase>
-<phase name="synthesize">Return answer with trade-offs, implementation guidance, links</phase>
-</workflow>
-
-## References
-
-**Read immediately:**
-- @references/examples.md - Few-shot examples (library discovery, comparison, fallback)
-- @references/workflow.md - Pipeline phases, decision matrix, failure handling
-- @references/search-workflow.md - Tool detection, URI cycling
-
-**Load on-demand:**
-- @references/gh-cli.md - GitHub CLI search syntax
-- @references/deepwiki-tools.md - DeepWiki usage, blocked paths, validation
-- @references/google-search.md - Google operators
-- @references/brave-search.md - Brave operators
-- @references/ddg-search.md - DuckDuckGo operators

package/.opencode/skills/intellisearch/references/brave-search.md

@@ -1,67 +0,0 @@
-# Brave Search Operators
-
-Source: https://search.brave.com/help/operators
-
-## File & Content Operators
-
-| Operator | Syntax | Example | Purpose |
-|----------|--------|---------|---------|
-| File extension | `ext:ext` | `honda gx120 manual ext:pdf` | Specific file extension |
-| File type | `filetype:type` | `evaluation filetype:pdf` | File type (pdf, doc, etc.) |
-| In body | `inbody:term` | `nvidia 1080 ti inbody:"founders edition"` | Term in page body |
-| In title | `intitle:term` | `seo conference intitle:2023` | Term in page title |
-| In page | `inpage:term` | `oscars 2024 inpage:"best costume"` | Term in title or body |
-
-## Location & Language Operators
-
-| Operator | Syntax | Example | Purpose |
-|----------|--------|---------|---------|
-| Language | `lang:code` or `language:code` | `visas lang:es` | Language (ISO 639-1 code) |
-| Location | `loc:code` or `location:code` | `niagara falls loc:ca` | Country/region (ISO 3166-1 alpha-2) |
-
-## Site & Term Operators
-
-| Operator | Syntax | Example | Purpose |
-|----------|--------|---------|---------|
-| Site | `site:domain.com` | `goggles site:brave.com` | Search specific site |
-| Include | `+term` | `gpu +freesync` | Must contain term |
-| Exclude | `-term` | `office -microsoft` | Must not contain term |
-| Exact match | `"phrase"` | `"order of the phoenix"` | Exact phrase |
-
-## Logical Operators
-
-| Operator | Syntax | Example | Purpose |
-|----------|--------|---------|---------|
-| AND | `term AND term` | `visa loc:gb AND lang:en` | All conditions met |
-| OR | `term OR term` | `inpage:australia OR inpage:"new zealand"` | Any condition met |
-| NOT | `term NOT condition` | `brave search NOT site:brave.com` | Excludes condition |
-
-## Usage Notes
-
-<important>
-- Search operators are experimental and in early development
-- Can place operators anywhere in query
-- Language codes: ISO 639-1 (en, es, fr, etc.)
-- Country codes: ISO 3166-1 alpha-2 (us, ca, gb, etc.)
-</important>
-
-## Common Patterns for Technical Search
-
-<patterns>
-```bash
-# Find documentation files
-"user guide" filetype:pdf
-
-# Language-specific results
-react hooks typescript tutorial lang:en
-
-# Combined conditions
-typescript validator intitle:library AND loc:us
-
-# Exclude specific results
-graph database library -mongodb
-
-# Package search
-npm package semver validation
-```
-</patterns>

package/.opencode/skills/intellisearch/references/ddg-search.md

@@ -1,79 +0,0 @@
-# DuckDuckGo Search Operators
-
-Source: https://duckduckgo.com/duckduckgo-help-pages/results/syntax
-
-## Basic Operators
-
-| Operator | Syntax | Example | Purpose |
-|----------|--------|---------|---------|
-| Exact match | `"phrase"` | `"cats and dogs"` | Exact phrase match |
-| Semantic similar | `~"phrase"` | `~"cats and dogs"` | Semantically similar results (experimental) |
-| Include more | `term +term2` | `cats +dogs` | More emphasis on term |
-| Exclude | `term -term2` | `cats -dogs` | Exclude term from results |
-
-## File & Site Operators
-
-| Operator | Syntax | Example | Purpose |
-|----------|--------|---------|---------|
-| File type | `filetype:type` | `cats filetype:pdf` | Specific file type |
-| Site search | `site:domain.com` | `dogs site:example.com` | Search specific site |
-| Exclude site | `-site:domain.com` | `cats -site:example.com` | Exclude specific site |
-
-## Page Location Operators
-
-| Operator | Syntax | Example | Purpose |
-|----------|--------|---------|---------|
-| In title | `intitle:term` | `intitle:dogs` | Term in page title |
-| In URL | `inurl:term` | `inurl:cats` | Term in page URL |
-
-## Navigation Operators
-
-| Operator | Syntax | Example | Purpose |
-|----------|--------|---------|---------|
-| Go to first | `\term` | `\futurama` | Navigate to first result |
-| Bang shortcut | `!site term` | `!a blink182` | Search on other site directly |
-| Safe search on | `!safeon` | `term !safeon` | Enable safe search |
-| Safe search off | `!safeoff` | `term !safeoff` | Disable safe search |
-
-## Supported File Types
-
-<file_types>
-- `pdf` - PDF documents
-- `doc` / `docx` - Word documents
-- `xls` / `xlsx` - Excel spreadsheets
-- `ppt` / `pptx` - PowerPoint presentations
-- `html` - HTML files
-</file_types>
-
-## Usage Notes
-
-<important>
-- If no results found with advanced syntax, related results may be shown
-- Bang shortcuts search other sites' search engines (subject to that site's policies)
-- Thousands of bang shortcuts available (see: https://duckduckgo.com/bang)
-- Note: Some advanced syntax may not work correctly on all queries
-</important>
-
-## Common Patterns for Technical Search
-
-<patterns>
-```bash
-# Find libraries
-typescript validation library
-
-# Exact phrase
-"semantic versioning" npm package
-
-# File type filter
-"readme" filetype:md tutorial
-
-# Title search
-intitle:react hooks typescript
-
-# Combined
-semver validation -test intitle:library
-
-# Package search
-nodejs graph database library
-```
-</patterns>