gemiterm 2.0.0 → 2.1.1

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

@@ -1,143 +0,0 @@
-# Search Workflow
-
-Tool detection and search strategy for finding GitHub repositories.
-
-<critical_rules priority="highest">
-<rule>NEVER use `site:github.com` with search tools - returns full URLs that get misparsed</rule>
-<rule>Only fetch EXTERNAL search engines, NEVER github.com URLs</rule>
-<rule>Cycle through engines on failure: Brave → DuckDuckGo → Google</rule>
-</critical_rules>
-
-## Tool Priority
-
-```yaml
-detection:
-  IF gh auth status succeeds:
-    → Use gh search repos (PREFERRED - direct API)
-  ELSE IF search_tool exists:
-    → Use search tool with keywords (NOT site:github.com)
-  ELSE IF fetch_tool exists:
-    → Use URI-based search with engine cycling
-  ELSE:
-    → Report: "No search capability available"
-    → fallback to internal knowledge
-```
-
-## GitHub CLI (Preferred)
-
-<detection>
-```bash
-gh auth status  # Exit 0 = available
-```
-</detection>
-
-<search_patterns priority="try_in_order">
-```bash
-# 1. Full query with topics and language
-gh search repos "{query}" --topic={topics} --language={lang} --json fullName,stargazersCount,createdAt,updatedAt,description --limit 10
-
-# 2. Query with language only
-gh search repos "{query}" --language={lang} --json fullName,stargazersCount,createdAt,updatedAt,description --limit 10
-
-# 3. Topic-based search (no query string)
-gh search repos --topic={topics} --language={lang} --json fullName,stargazersCount,createdAt,updatedAt,description --limit 10
-
-# 4. Broader keyword search
-gh search repos "{query}" --json fullName,stargazersCount,createdAt,updatedAt,description --limit 10
-```
-</search_patterns>
-
-<process>
-1. Infer topics from query (framework/library names → topics)
-2. Infer language if mentioned
-3. Sort by stargazersCount, return top 5
-4. Skip to DeepWiki query
-</process>
-
-See @gh-cli.md for detailed syntax.
-
-## Search Tool (Fallback #1)
-
-<constraint>DO NOT use `site:github.com` - it returns full GitHub URLs that get misparsed as repos.</constraint>
-
-<query_format>
-```json
-{ "query": "{technology} {feature} {language} library package" }
-```
-</query_format>
-
-<example>
-```json
-{ "query": "typescript semver validation library npm package" }
-```
-</example>
-
-<result_processing>
-- Look for package names in snippets
-- Find `github.com/owner/repo` references in descriptions
-- Ignore navigation/ads
-</result_processing>
-
-## URI-Based Search (Fallback #2)
-
-When only fetch tools available, cycle through engines:
-
-| Priority | Engine | URL |
-|----------|--------|-----|
-| 1 | Brave | `https://search.brave.com/search?q={terms}` |
-| 2 | DuckDuckGo | `https://duckduckgo.com/?q={terms}` |
-| 3 | Google | `https://www.google.com/search?q={terms}` |
-
-<error_handling>
-```yaml
-FOR each engine IN [brave, duckduckgo, google]:
-  result = fetch(engine_url)
-  IF success AND has_search_results:
-    RETURN result
-  CONTINUE
-RETURN error: all engines failed
-```
-</error_handling>
-
-<failure_causes>
-- JavaScript redirects (Google)
-- Captchas (DuckDuckGo)
-- HTML parsing issues
-</failure_causes>
-
-<example>
-```json
-{
-  "url": "https://search.brave.com/search?q=typescript%20semver%20validation%20library",
-  "format": "markdown",
-  "timeout": 10
-}
-```
-</example>
-
-## Query Construction
-
-<keyword_based>
-```
-{technology} {feature} {language} library package
-```
-</keyword_based>
-
-<examples>
-- `react hooks typescript library`
-- `semver validation nodejs package`
-- `graph database python library`
-</examples>
-
-<result_extraction>
-- Look for `github.com/owner/repo` in snippet descriptions
-- Find package names that map to known repos
-- Follow links in documentation references
-</result_extraction>
-
-## References
-
-- @gh-cli.md - GitHub CLI syntax
-- @google-search.md - Google operators
-- @brave-search.md - Brave operators
-- @ddg-search.md - DuckDuckGo operators

package/.opencode/skills/intellisearch/references/workflow.md

@@ -1,115 +0,0 @@
-# Search Pipeline & Decision Points
-
-Detailed workflow for repository discovery and analysis.
-
-<critical_rules priority="highest">
-<rule>NEVER fetch github.com URLs - use DeepWiki instead</rule>
-<rule>Limit to 5-10 repository candidates before filtering</rule>
-<rule>Select only TOP 3 repos for DeepWiki queries</rule>
-<rule>Max 3 repos per DeepWiki call</rule>
-</critical_rules>
-
-## Pipeline Phases
-
-```yaml
-phases:
-  - name: TOOL_DETECTION
-    priority: [gh_cli, search_tool, fetch_tool]
-    constraint: NEVER fetch github.com URLs
-
-  - name: REPOSITORY_DISCOVERY
-    actions: [execute_search, extract_owner_repo, validate_format]
-    constraint: limit 5-10 candidates
-
-  - name: CANDIDATE_FILTERING
-    sort: [stars_DESC, recency, language_match]
-    constraint: SELECT_TOP_3
-
-  - name: DEEPWIKI_QUERY
-    strategy: [multi_repo_first, fallback_individual]
-    constraint: max 3 repos per call
-
-  - name: ANSWER_SYNTHESIS
-    format: [overview, trade_offs, implementation, links]
-    constraint: include_comparison_recommendations
-```
-
-## Decision Matrix
-
-| Condition | Action |
-|-----------|--------|
-| `gh` CLI available | Use `gh search repos` with JSON output |
-| No `gh`, search tool exists | Query external search engine |
-| No search tool | Fetch external search engine URL |
-| Multi-repo DeepWiki fails | Query repos individually |
-| All DeepWiki queries fail | Report repos found but not indexed |
-
-## Tool Selection Strategy
-
-<priority_order>
-1. gh CLI (Preferred) - Direct API access, structured JSON, topic/language filtering
-2. Search Tool (Fallback #1) - Query external engines, NO `site:github.com` operator
-3. Fetch Tool (Fallback #2) - URI-based search with engine cycling
-</priority_order>
-
-See @search-workflow.md for detailed tool usage.
-
-## Repository Extraction
-
-<validation_rules>
-<pattern type="standard">`github\.com/([\w-]+)/([\w.-]+)` → Example: `github.com/npm/node-semver`</pattern>
-<pattern type="pages">`([\w-]+)\.github\.io/([\w.-]+)` → Example: `npm.github.io/semver`</pattern>
-<constraint>Owner: alphanumeric, `-`, `_` only</constraint>
-<constraint>Repo: alphanumeric, `-`, `_`, `.` only</constraint>
-<constraint>Owner NOT in blocked list (see @deepwiki-tools.md)</constraint>
-</validation_rules>
-
-## Candidate Filtering
-
-Select **top 3 repositories** before DeepWiki query.
-
-<prioritization>
-1. Stars - Higher count = community validation
-2. Recency - Recent commits = active maintenance
-3. Language match - Prefer repos matching query language
-</prioritization>
-
-**Do not query DeepWiki for repos you won't recommend.**
-
-## DeepWiki Query Strategy
-
-<query_format>
-<multi_repo>Try first: `repoName=["owner1/repo1", "owner2/repo2"]` (2+ items)</multi_repo>
-<single_repo>Fallback: `repoName="owner/repo"` (string)</single_repo>
-<forbidden>Never: `repoName=["owner/repo"]` (single-item array fails)</forbidden>
-</query_format>
-
-<efficiency_rules>
-- Query max 3 repos per request
-- If multi-repo fails, query top candidate only (not all individually)
-</efficiency_rules>
-
-See @deepwiki-tools.md for detailed usage.
-
-## Answer Synthesis
-
-<output_format>
-1. Best options with trade-offs
-2. Specific implementation guidance
-3. Code examples if available
-4. Repository links
-</output_format>
-
-**Efficiency:** If you found more than 3 repos, prioritize by: stars > recency > language match. Only include details for your top 3 candidates.
-
-## Failure Handling
-
-| Failure | Action |
-|---------|--------|
-| gh CLI not available | Fall back to search tool |
-| Search tool not available | Fall back to fetch tool + URI cycling |
-| URI search fails (captcha/redirect) | Try next engine in cycle |
-| All URI searches fail | Report: "Unable to search - no working search method" |
-| DeepWiki multi-repo fails | Query repos individually |
-| DeepWiki single repo fails | Try next repo in list |
-| All DeepWiki queries fail | Report: "Repos found but not indexed by DeepWiki" |

package/.opencode/skills/openspec-apply-change/SKILL.md

@@ -1,159 +0,0 @@
----
-name: openspec-apply-change
-description: Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.4.1"
----
-
-Implement tasks from an OpenSpec change.
-
-**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
-
-**Steps**
-
-1. **Select the change**
-
-   If a name is provided, use it. Otherwise:
-   - Infer from conversation context if the user mentioned a change
-   - Auto-select if only one active change exists
-   - If ambiguous, run `openspec list --json` to get available changes and use the **AskUserQuestion tool** to let the user select
-
-   Always announce: "Using change: <name>" and how to override (e.g., `/opsx-apply <other>`).
-
-2. **Check status to understand the schema**
-   ```bash
-   openspec status --change "<name>" --json
-   ```
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used (e.g., "spec-driven")
-   - `planningHome`, `changeRoot`, and `actionContext`: planning scope and edit constraints
-   - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others)
-
-3. **Get apply instructions**
-
-   ```bash
-   openspec instructions apply --change "<name>" --json
-   ```
-
-   This returns:
-   - `contextFiles`: artifact ID -> array of concrete file paths (varies by schema - could be proposal/specs/design/tasks or spec/tests/implementation/docs)
-   - Progress (total, complete, remaining)
-   - Task list with status
-   - Dynamic instruction based on current state
-
-   **Handle states:**
-   - If `state: "blocked"` (missing artifacts): show message, suggest using openspec-continue-change
-   - If `state: "all_done"`: congratulate, suggest archive
-   - Otherwise: proceed to implementation
-
-   **Workspace guard:** If status JSON reports `actionContext.mode: "workspace-planning"` and `allowedEditRoots` is empty, explain that full workspace apply is not supported in this slice. Treat linked repos and folders as read-only context, ask the user to select an affected area through an explicit implementation workflow, and STOP before editing files.
-
-4. **Read context files**
-
-   Read every file path listed under `contextFiles` from the apply instructions output.
-   The files depend on the schema being used:
-   - **spec-driven**: proposal, specs, design, tasks
-   - Other schemas: follow the contextFiles from CLI output
-
-5. **Show current progress**
-
-   Display:
-   - Schema being used
-   - Progress: "N/M tasks complete"
-   - Remaining tasks overview
-   - Dynamic instruction from CLI
-
-6. **Implement tasks (loop until done or blocked)**
-
-   For each pending task:
-   - Show which task is being worked on
-   - Make the code changes required
-   - Keep changes minimal and focused
-   - Mark task complete in the tasks file: `- [ ]` → `- [x]`
-   - Continue to next task
-
-   **Pause if:**
-   - Task is unclear → ask for clarification
-   - Implementation reveals a design issue → suggest updating artifacts
-   - Error or blocker encountered → report and wait for guidance
-   - User interrupts
-
-7. **On completion or pause, show status**
-
-   Display:
-   - Tasks completed this session
-   - Overall progress: "N/M tasks complete"
-   - If all done: suggest archive
-   - If paused: explain why and wait for guidance
-
-**Output During Implementation**
-
-```
-## Implementing: <change-name> (schema: <schema-name>)
-
-Working on task 3/7: <task description>
-[...implementation happening...]
-✓ Task complete
-
-Working on task 4/7: <task description>
-[...implementation happening...]
-✓ Task complete
-```
-
-**Output On Completion**
-
-```
-## Implementation Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 7/7 tasks complete ✓
-
-### Completed This Session
-- [x] Task 1
-- [x] Task 2
-...
-
-All tasks complete! Ready to archive this change.
-```
-
-**Output On Pause (Issue Encountered)**
-
-```
-## Implementation Paused
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Progress:** 4/7 tasks complete
-
-### Issue Encountered
-<description of the issue>
-
-**Options:**
-1. <option 1>
-2. <option 2>
-3. Other approach
-
-What would you like to do?
-```
-
-**Guardrails**
-- Keep going through tasks until done or blocked
-- Always read context files before starting (from the apply instructions output)
-- If task is ambiguous, pause and ask before implementing
-- If implementation reveals issues, pause and suggest artifact updates
-- Keep code changes minimal and scoped to each task
-- Update task checkbox immediately after completing each task
-- Pause on errors, blockers, or unclear requirements - don't guess
-- Use contextFiles from CLI output, don't assume specific file names
-
-**Fluid Workflow Integration**
-
-This skill supports the "actions on a change" model:
-
-- **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions
-- **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly

package/.opencode/skills/openspec-archive-change/SKILL.md

@@ -1,117 +0,0 @@
----
-name: openspec-archive-change
-description: Archive a completed change in the experimental workflow. Use when the user wants to finalize and archive a change after implementation is complete.
-license: MIT
-compatibility: Requires openspec CLI.
-metadata:
-  author: openspec
-  version: "1.0"
-  generatedBy: "1.4.1"
----
-
-Archive a completed change in the experimental workflow.
-
-**Input**: Optionally specify a change name. 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 only active changes (not already archived).
-   Include the schema used for each change if available.
-
-   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
-
-2. **Check artifact completion status**
-
-   Run `openspec status --change "<name>" --json` to check artifact completion.
-
-   Parse the JSON to understand:
-   - `schemaName`: The workflow being used
-   - `planningHome`, `changeRoot`, `artifactPaths`, and `actionContext`: path and scope context
-   - `artifacts`: List of artifacts with their status (`done` or other)
-
-   If status reports `actionContext.mode: "workspace-planning"`, explain that workspace archive is not supported in this slice and STOP. Do not move workspace changes into repo-local archives or edit linked repos.
-
-   **If any artifacts are not `done`:**
-   - Display warning listing incomplete artifacts
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-3. **Check task completion status**
-
-   Read the tasks file (typically `tasks.md`) to check for incomplete tasks.
-
-   Count tasks marked with `- [ ]` (incomplete) vs `- [x]` (complete).
-
-   **If incomplete tasks found:**
-   - Display warning showing count of incomplete tasks
-   - Use **AskUserQuestion tool** to confirm user wants to proceed
-   - Proceed if user confirms
-
-   **If no tasks file exists:** Proceed without task-related warning.
-
-4. **Assess delta spec sync state**
-
-   Use `artifactPaths.specs.existingOutputPaths` from status JSON to check for delta specs. If none exist, proceed without sync prompt.
-
-   **If delta specs exist:**
-   - Compare each delta spec with its corresponding main spec at `openspec/specs/<capability>/spec.md`
-   - Determine what changes would be applied (adds, modifications, removals, renames)
-   - Show a combined summary before prompting
-
-   **Prompt options:**
-   - If changes needed: "Sync now (recommended)", "Archive without syncing"
-   - If already synced: "Archive now", "Sync anyway", "Cancel"
-
-   If user chooses sync, use Task tool (subagent_type: "general-purpose", prompt: "Use Skill tool to invoke openspec-sync-specs for change '<name>'. Delta spec analysis: <include the analyzed delta spec summary>"). Proceed to archive regardless of choice.
-
-5. **Perform the archive**
-
-   Create an `archive` directory under `planningHome.changesDir` if it doesn't exist:
-   ```bash
-   mkdir -p "<planningHome.changesDir>/archive"
-   ```
-
-   Generate target name using current date: `YYYY-MM-DD-<change-name>`
-
-   **Check if target already exists:**
-   - If yes: Fail with error, suggest renaming existing archive or using different date
-   - If no: Move `changeRoot` to the archive directory
-
-   ```bash
-   mv "<changeRoot>" "<planningHome.changesDir>/archive/YYYY-MM-DD-<name>"
-   ```
-
-6. **Display summary**
-
-   Show archive completion summary including:
-   - Change name
-   - Schema that was used
-   - Archive location
-   - Whether specs were synced (if applicable)
-   - Note about any warnings (incomplete artifacts/tasks)
-
-**Output On Success**
-
-```
-## Archive Complete
-
-**Change:** <change-name>
-**Schema:** <schema-name>
-**Archived to:** the archive path derived from `planningHome.changesDir`/YYYY-MM-DD-<name>/
-**Specs:** ✓ Synced to main specs (or "No delta specs" or "Sync skipped")
-
-All artifacts complete. All tasks complete.
-```
-
-**Guardrails**
-- Always prompt for change selection if not provided
-- Use artifact graph (openspec status --json) for completion checking
-- Don't block archive on warnings - just inform and confirm
-- Preserve .openspec.yaml when moving to archive (it moves with the directory)
-- Show clear summary of what happened
-- If sync is requested, use openspec-sync-specs approach (agent-driven)
-- If delta specs exist, always run the sync assessment and show the combined summary before prompting