@hienlh/ppm 0.9.81 → 0.9.82

package/.opencode/skills/research/SKILL.md

@@ -1,176 +0,0 @@
----
-name: ck:research
-description: "Research technical solutions, analyze architectures, gather requirements thoroughly. Use for technology evaluation, best practices research, solution design, scalability/security/maintainability analysis."
-license: MIT
-argument-hint: "[topic]"
-metadata:
-  author: claudekit
-  version: "1.0.0"
----
-
-# Research
-
-## Research Methodology
-
-Always honoring **YAGNI**, **KISS**, and **DRY** principles.
-**Be honest, be brutal, straight to the point, and be concise.**
-
-### Phase 1: Scope Definition
-
-First, you will clearly define the research scope by:
-- Identifying key terms and concepts to investigate
-- Determining the recency requirements (how current must information be)
-- Establishing evaluation criteria for sources
-- Setting boundaries for the research depth
-
-### Phase 2: Systematic Information Gathering
-
-You will employ a multi-source research strategy:
-
-1. **Search Strategy**:
-   - **Gemini Toggle**: Check `.opencode/.ck.json` (or `~/.opencode/.ck.json`) for `skills.research.useGemini` (default: `false`). If `false` or absent, skip Gemini and use WebSearch directly.
-   - **Gemini Model**: Read from `.opencode/.ck.json`: `gemini.model` (default: `gemini-3-flash-preview`)
-   - If `useGemini` is `true`: first validate Gemini CLI works by running `command -v gemini && echo "ping" | timeout 15 gemini -y -m <gemini.model>`. If validation fails or times out, fall back to WebSearch and warn: "Gemini CLI unavailable, falling back to WebSearch. Set `skills.research.useGemini: false` in `.opencode/.ck.json` to suppress this check."
-   - If validation passes, execute `echo "...your search prompt..." | timeout 180 gemini -y -m <gemini.model>` (timeout: 3 minutes) and save the output using `Report:` path from `## Naming` section (including all citations). If execution times out, fall back to WebSearch for that query.
-   - If `useGemini` is disabled or `gemini` bash command is not available, use `WebSearch` tool.
-   - Run multiple `gemini` bash commands or `WebSearch` tools in parallel to search for relevant information.
-   - Craft precise search queries with relevant keywords
-   - Include terms like "best practices", "2024", "latest", "security", "performance"
-   - Search for official documentation, GitHub repositories, and authoritative blogs
-   - Prioritize results from recognized authorities (official docs, major tech companies, respected developers)
-   - **IMPORTANT:** You are allowed to perform at most **5 researches (max 5 tool calls)**, user might request less than this amount, **strictly respect it**, think carefully based on the task before performing each related research topic.
-
-2. **Deep Content Analysis**:
-   - When you found a potential Github repository URL, use `ck:docs-seeker` skill to find read it.
-   - Focus on official documentation, API references, and technical specifications
-   - Analyze README files from popular GitHub repositories
-   - Review changelog and release notes for version-specific information
-
-3. **Video Content Research**:
-   - Prioritize content from official channels, recognized experts, and major conferences
-   - Focus on practical demonstrations and real-world implementations
-
-4. **Cross-Reference Validation**:
-   - Verify information across multiple independent sources
-   - Check publication dates to ensure currency
-   - Identify consensus vs. controversial approaches
-   - Note any conflicting information or debates in the community
-
-### Phase 3: Analysis and Synthesis
-
-You will analyze gathered information by:
-- Identifying common patterns and best practices
-- Evaluating pros and cons of different approaches
-- Assessing maturity and stability of technologies
-- Recognizing security implications and performance considerations
-- Determining compatibility and integration requirements
-
-### Phase 4: Report Generation
-
-**Notes:**
-- Research reports are saved using `Report:` path from `## Naming` section.
-- If `## Naming` section is not available, ask main agent to provide the output path.
-
-You will create a comprehensive markdown report with the following structure:
-
-```markdown
-# Research Report: [Topic]
-
-## Executive Summary
-[2-3 paragraph overview of key findings and recommendations]
-
-## Research Methodology
-- Sources consulted: [number]
-- Date range of materials: [earliest to most recent]
-- Key search terms used: [list]
-
-## Key Findings
-
-### 1. Technology Overview
-[Comprehensive description of the technology/topic]
-
-### 2. Current State & Trends
-[Latest developments, version information, adoption trends]
-
-### 3. Best Practices
-[Detailed list of recommended practices with explanations]
-
-### 4. Security Considerations
-[Security implications, vulnerabilities, and mitigation strategies]
-
-### 5. Performance Insights
-[Performance characteristics, optimization techniques, benchmarks]
-
-## Comparative Analysis
-[If applicable, comparison of different solutions/approaches]
-
-## Implementation Recommendations
-
-### Quick Start Guide
-[Step-by-step getting started instructions]
-
-### Code Examples
-[Relevant code snippets with explanations]
-
-### Common Pitfalls
-[Mistakes to avoid and their solutions]
-
-## Resources & References
-
-### Official Documentation
-- [Linked list of official docs]
-
-### Recommended Tutorials
-- [Curated list with descriptions]
-
-### Community Resources
-- [Forums, Discord servers, Stack Overflow tags]
-
-### Further Reading
-- [Advanced topics and deep dives]
-
-## Appendices
-
-### A. Glossary
-[Technical terms and definitions]
-
-### B. Version Compatibility Matrix
-[If applicable]
-
-### C. Raw Research Notes
-[Optional: detailed notes from research process]
-```
-
-## Quality Standards
-
-You will ensure all research meets these criteria:
-- **Accuracy**: Information is verified across multiple sources
-- **Currency**: Prioritize information from the last 12 months unless historical context is needed
-- **Completeness**: Cover all aspects requested by the user
-- **Actionability**: Provide practical, implementable recommendations
-- **Clarity**: Use clear language, define technical terms, provide examples
-- **Attribution**: Always cite sources and provide links for verification
-
-## Special Considerations
-
-- When researching security topics, always check for recent CVEs and security advisories
-- For performance-related research, look for benchmarks and real-world case studies
-- When investigating new technologies, assess community adoption and support levels
-- For API documentation, verify endpoint availability and authentication requirements
-- Always note deprecation warnings and migration paths for older technologies
-
-## Output Requirements
-**IMPORTANT:** Invoke "/ck:project-organization" skill to organize the outputs.
-
-Your final report must:
-1. Be saved using the `Report:` path from `## Naming` section with a descriptive filename
-2. Include a timestamp of when the research was conducted
-3. Provide clear section navigation with a table of contents for longer reports
-4. Use code blocks with appropriate syntax highlighting
-5. Include diagrams or architecture descriptions where helpful (in mermaid or ASCII art)
-6. Conclude with specific, actionable next steps
-
-**IMPORTANT:** Sacrifice grammar for the sake of concision when writing reports.
-**IMPORTANT:** In reports, list any unresolved questions at the end, if any.
-
-**Remember:** You are not just collecting information, but providing strategic technical intelligence that enables informed decision-making. Your research should anticipate follow-up questions and provide comprehensive coverage of the topic while remaining focused and practical.

package/.opencode/skills/retro/SKILL.md

@@ -1,138 +0,0 @@
----
-name: ck:retro
-description: "Data-driven sprint retrospective. Gathers git metrics (commits, LOC, hotspots, churn), computes derived health indicators, and generates a structured markdown or HTML report. Use after sprints, weekly check-ins, or any review period."
-license: MIT
-argument-hint: "[timeframe] [--compare] [--team] [--format html|md]"
-metadata:
-  author: claudekit
-  version: "1.0.0"
----
-
-# Retro Skill
-
-You are a data-driven Engineering Retrospective Analyst. Your job is to collect objective git metrics, compute health indicators, and produce an actionable retrospective report — no guesswork, no invented data.
-
-## Flags
-
-| Flag | Default | Description |
-|------|---------|-------------|
-| `timeframe` | `7d` | Period to analyze. Accepts: `7d`, `2w`, `1m`, `sprint`, or `YYYY-MM-DD:YYYY-MM-DD` |
-| `--compare` | off | Compare metrics against the preceding equal-length period |
-| `--team` | off | Break down metrics per author |
-| `--format html\|md` | `md` | Output format. `html` generates a self-contained HTML report |
-
-## Step 1 — Parse Timeframe
-
-Resolve `timeframe` argument to a `--since` date for git commands:
-
-- `7d` → 7 days ago
-- `2w` → 14 days ago
-- `1m` → 1 month ago
-- `sprint` → ask user for sprint start date if not inferable from git tags
-- `YYYY-MM-DD:YYYY-MM-DD` → use `--since` / `--until` pair
-
-Store resolved dates as `SINCE` and `UNTIL` (default UNTIL = now).
-
-If `--compare` flag is set, also resolve the preceding period of equal length as `PREV_SINCE` / `PREV_UNTIL`.
-
-## Step 2 — Gather Raw Git Metrics
-
-Run each bash command. Capture output. If a command returns empty, record `0` or `N/A` — never fabricate values.
-
-```bash
-# Commits per day
-git log --since="$SINCE" --until="$UNTIL" --format="%ai" \
-  | cut -d' ' -f1 | sort | uniq -c
-
-# Total commits
-git log --since="$SINCE" --until="$UNTIL" --oneline | wc -l
-
-# LOC added / removed / net
-git log --since="$SINCE" --until="$UNTIL" --numstat --format="" \
-  | awk 'NF==3 {add+=$1; del+=$2} END {print "added="add, "removed="del, "net="add-del}'
-
-# File hotspots (top 10 most-changed files)
-git log --since="$SINCE" --until="$UNTIL" --name-only --format="" \
-  | sort | uniq -c | sort -rn | head -10
-
-# Commit type distribution (conventional commits)
-git log --since="$SINCE" --until="$UNTIL" --format="%s" \
-  | sed 's/(.*//' | sed 's/:.*//' | sort | uniq -c | sort -rn
-
-# Active authors
-git log --since="$SINCE" --until="$UNTIL" --format="%ae" \
-  | sort -u
-
-# Per-author commit count (used when --team flag set)
-git log --since="$SINCE" --until="$UNTIL" --format="%ae" \
-  | sort | uniq -c | sort -rn
-
-# Days with activity
-git log --since="$SINCE" --until="$UNTIL" --format="%ai" \
-  | cut -d' ' -f1 | sort -u | wc -l
-
-# Files changed (unique)
-git log --since="$SINCE" --until="$UNTIL" --name-only --format="" \
-  | sort -u | grep -c .
-
-# Test file changes
-git log --since="$SINCE" --until="$UNTIL" --name-only --format="" \
-  | grep -E "(\.test\.|\.spec\.|__tests__|test_)" | wc -l
-
-# Total file changes (for test ratio)
-git log --since="$SINCE" --until="$UNTIL" --name-only --format="" \
-  | grep -v "^$" | wc -l
-```
-
-## Step 3 — Compute Derived Metrics
-
-Compute from raw data. Show formula in report.
-
-| Metric | Formula |
-|--------|---------|
-| Commit frequency | `total_commits / days_in_period` |
-| Test-to-code ratio | `test_file_changes / total_file_changes * 100` |
-| Churn rate | `(LOC_added + LOC_removed) / max(LOC_net, 1)` |
-| Active day ratio | `days_with_commits / days_in_period * 100` |
-| Plan completion rate | Count closed GitHub issues in period (use `gh issue list --state closed --json closedAt,title --jq "[.[] | select(.closedAt >= \"$SINCE\")]"`) divided by opened; mark `N/A` if gh unavailable |
-
-## Step 4 — Check Plans Directory
-
-Scan `plans/` for any plan files updated in the period. Count completed vs total tasks from checkbox lists (`- [x]` vs `- [ ]`). Add to plan completion section.
-
-```bash
-# Create sentinel file with the period start timestamp (macOS/BSD date syntax)
-touch -t $(date -jf "%Y-%m-%d" "$SINCE" +%Y%m%d%H%M.%S 2>/dev/null   || date -d "$SINCE" +%Y%m%d%H%M.%S) /tmp/retro-since-sentinel
-
-# Find plan files modified in period
-find plans/ -name "*.md" -newer /tmp/retro-since-sentinel 2>/dev/null | head -20
-```
-
-## Step 5 — Generate Report
-
-Use the template from `references/report-template.md`.
-
-- Fill all table cells with real data
-- Mark cells `N/A` when data unavailable — never invent numbers
-- Add 3-5 specific Recommendations based on actual findings (e.g., high churn on specific files, low test ratio, uneven commit distribution)
-- Highlights: note standout positive metrics
-- If `--compare` flag set: add delta column (`+/-`) to Velocity and Code Health tables
-
-Output location: `plans/reports/retro-{YYMMDD}-{slug}.md`
-
-Where `YYMMDD` = today's date from `bash -c 'date +%y%m%d'` and `slug` = timeframe (e.g., `7d`, `1m`, `sprint`).
-
-## Step 6 — HTML Format (optional)
-
-If `--format html` flag is set:
-- Wrap report in a self-contained HTML page
-- Use inline CSS for table styling (no external deps)
-- Save as `plans/reports/retro-{YYMMDD}-{slug}.html`
-- Output `[OK] Report saved: plans/reports/retro-{YYMMDD}-{slug}.html`
-
-## Constraints
-
-- Read-only — never commit, push, or modify any source files
-- All metrics sourced from git history only (plus optional gh CLI for issues)
-- Do not hallucinate metrics; `N/A` is always correct when data is missing
-- Keep report under 200 lines; split into multiple files if needed

package/.opencode/skills/retro/references/metrics-guide.md

@@ -1,133 +0,0 @@
-# Metrics Reference Guide
-
-Each metric: what it measures, why it matters, interpretation guidance, and the git command to compute it.
-
----
-
-## Velocity Metrics
-
-### Commits Per Day
-
-**Measures:** Delivery cadence — how often work lands in the repo.
-**Why it matters:** Low frequency may indicate large batched PRs (risky merges); high frequency with tiny commits suggests good trunk-based dev hygiene.
-**Interpretation:**
-- `< 1/day` — infrequent; check for blocked PRs or slow review cycles
-- `1-3/day` — healthy for a solo dev or small team
-- `> 5/day` — high activity; verify commits are meaningful, not noise
-
-```bash
-git log --since="$SINCE" --until="$UNTIL" --format="%ai" \
-  | cut -d' ' -f1 | sort | uniq -c
-```
-
-### Active Day Ratio
-
-**Measures:** What fraction of working days had at least one commit.
-**Why it matters:** Consistent daily progress vs burst-then-idle patterns.
-**Interpretation:** `> 70%` = consistent; `< 40%` = batchy; investigate blockers.
-
-```bash
-# Days with activity
-git log --since="$SINCE" --until="$UNTIL" --format="%ai" \
-  | cut -d' ' -f1 | sort -u | wc -l
-# Divide by total calendar days in period
-```
-
----
-
-## Code Health Metrics
-
-### LOC Added / Removed / Net
-
-**Measures:** Raw volume of code written and deleted.
-**Why it matters:** Net negative LOC (more deleted than added) is often a sign of healthy refactoring. Very high churn on specific files is a risk signal.
-**Interpretation:**
-- Net negative on non-test files = good (simplification)
-- Net positive > 500 LOC/day sustained = high velocity, watch for quality regression
-
-```bash
-git log --since="$SINCE" --until="$UNTIL" --numstat --format="" \
-  | awk 'NF==3 {add+=$1; del+=$2} END {print "added="add, "removed="del, "net="add-del}'
-```
-
-### File Hotspots
-
-**Measures:** Which files change most frequently.
-**Why it matters:** High-churn files are coupling magnets and defect attractors. Files appearing in > 30% of commits warrant refactoring.
-**Interpretation:** Top 3 hotspots in every sprint signal architectural debt.
-
-```bash
-git log --since="$SINCE" --until="$UNTIL" --name-only --format="" \
-  | sort | uniq -c | sort -rn | head -10
-```
-
-### Churn Rate
-
-**Measures:** `(LOC_added + LOC_removed) / max(LOC_net, 1)` — how much code was rewritten vs kept.
-**Why it matters:** Churn > 3x net LOC = significant rework; investigate root cause (unclear requirements, unstable APIs, poor initial design).
-**Interpretation:**
-- `1.0 - 1.5` = clean, additive work
-- `1.5 - 3.0` = moderate iteration (normal)
-- `> 3.0` = high rework; flag for retro discussion
-
----
-
-## Quality Metrics
-
-### Test-to-Code Ratio
-
-**Measures:** `test_file_changes / total_file_changes * 100`
-**Why it matters:** Proxy for whether tests accompany new code. Does not measure test quality, only presence.
-**Interpretation:**
-- `> 30%` = tests accompanying changes (healthy)
-- `10-30%` = some test coverage added
-- `< 10%` = tests lagging behind; technical debt accumulating
-
-```bash
-# Test file changes
-git log --since="$SINCE" --until="$UNTIL" --name-only --format="" \
-  | grep -E "(\.test\.|\.spec\.|__tests__|test_)" | wc -l
-
-# Total file changes
-git log --since="$SINCE" --until="$UNTIL" --name-only --format="" \
-  | grep -v "^$" | wc -l
-```
-
-### Commit Type Distribution
-
-**Measures:** Breakdown of conventional commit types (`feat`, `fix`, `chore`, `docs`, `refactor`, `test`, `hotfix`).
-**Why it matters:** Ratio reveals focus. Heavy `fix` ratio may indicate quality issues; heavy `chore` may mean infra debt; balanced mix = sustainable pace.
-**Interpretation:**
-- `feat > 40%` = feature-driven sprint
-- `fix > 40%` = reactive sprint (bugs dominating)
-- `refactor > 20%` = healthy investment in code quality
-
-```bash
-git log --since="$SINCE" --until="$UNTIL" --format="%s" \
-  | sed 's/(.*//' | sed 's/:.*//' | sort | uniq -c | sort -rn
-```
-
----
-
-## Plan Metrics
-
-### Plan Completion Rate
-
-**Measures:** Closed GitHub issues / total issues opened in period (or checkbox ratio in plan files).
-**Why it matters:** Tracks delivery predictability. Consistent undercompletion signals scope inflation or estimation issues.
-**Interpretation:**
-- `> 80%` = on track
-- `60-80%` = acceptable; review blockers
-- `< 60%` = scope or capacity mismatch; action needed
-
-```bash
-# Requires gh CLI
-gh issue list --state closed --json closedAt,createdAt \
-  --jq "[.[] | select(.closedAt >= \"$SINCE\")] | length"
-```
-
-```bash
-# Plan file checkbox scan (fallback)
-grep -r "\- \[x\]" plans/ | wc -l  # completed
-grep -r "\- \[ \]" plans/ | wc -l  # open
-```

package/.opencode/skills/retro/references/report-template.md

@@ -1,110 +0,0 @@
-# Retrospective Report — {TIMEFRAME}
-
-**Period:** {SINCE} → {UNTIL}
-**Generated:** {TODAY}
-**Repo:** {REPO_NAME}
-**Authors:** {AUTHOR_COUNT} active
-
----
-
-## Velocity
-
-| Metric | Value | {COMPARE_COL} |
-|--------|-------|---------------|
-| Total commits | {TOTAL_COMMITS} | {DELTA_COMMITS} |
-| Commits / day | {COMMITS_PER_DAY} | {DELTA_COMMITS_DAY} |
-| Active days | {ACTIVE_DAYS} / {PERIOD_DAYS} ({ACTIVE_PCT}%) | {DELTA_ACTIVE} |
-| Files changed | {FILES_CHANGED} | {DELTA_FILES} |
-
-*Remove delta column if `--compare` not set.*
-
----
-
-## Code Health
-
-| Metric | Value | {COMPARE_COL} |
-|--------|-------|---------------|
-| LOC added | {LOC_ADDED} | {DELTA_LOC_ADDED} |
-| LOC removed | {LOC_REMOVED} | {DELTA_LOC_REMOVED} |
-| Net LOC | {LOC_NET} | {DELTA_LOC_NET} |
-| Churn rate | {CHURN_RATE}x | {DELTA_CHURN} |
-| Test-to-code ratio | {TEST_RATIO}% | {DELTA_TEST_RATIO} |
-
-*Remove delta column if `--compare` not set.*
-
----
-
-## Commit Distribution
-
-```
-{COMMIT_TYPE_BAR_OR_TABLE}
-```
-
-Example format:
-```
-feat     ████████████ 12 (40%)
-fix      ████████     8  (27%)
-chore    ████         4  (13%)
-refactor ███          3  (10%)
-test     ██           2  (7%)
-docs     █            1  (3%)
-```
-
----
-
-## File Hotspots
-
-Top files by change frequency:
-
-| Rank | File | Changes |
-|------|------|---------|
-| 1 | {FILE_1} | {COUNT_1} |
-| 2 | {FILE_2} | {COUNT_2} |
-| 3 | {FILE_3} | {COUNT_3} |
-| ... | ... | ... |
-
----
-
-## Plan Progress
-
-| Metric | Value |
-|--------|-------|
-| Completed tasks | {TASKS_DONE} |
-| Open tasks | {TASKS_OPEN} |
-| Completion rate | {PLAN_PCT}% |
-| Issues closed (period) | {ISSUES_CLOSED} |
-
----
-
-## Team Breakdown
-
-*Include only when `--team` flag is set. Otherwise omit this section.*
-
-| Author | Commits | LOC Net | Types |
-|--------|---------|---------|-------|
-| {AUTHOR_1} | {COMMITS_1} | {LOC_1} | {TYPES_1} |
-| {AUTHOR_2} | {COMMITS_2} | {LOC_2} | {TYPES_2} |
-
----
-
-## Highlights
-
-- [OK] {POSITIVE_FINDING_1}
-- [OK] {POSITIVE_FINDING_2}
-- [!] {NOTABLE_FINDING}
-
-*Replace with 2-4 factual observations from the data. No invented praise.*
-
----
-
-## Recommendations
-
-1. **{ACTION_1}** — {RATIONALE_1} (based on {METRIC})
-2. **{ACTION_2}** — {RATIONALE_2} (based on {METRIC})
-3. **{ACTION_3}** — {RATIONALE_3} (based on {METRIC})
-
-*3-5 specific, actionable items grounded in the metrics above. No generic advice.*
-
----
-
-*Generated by `ck:retro` — data sourced from git history only*

package/.opencode/skills/scout/SKILL.md

@@ -1,82 +0,0 @@
----
-name: ck:scout
-description: Fast codebase scouting using parallel agents. Use for file discovery, task context gathering, quick searches across directories. Supports internal (Explore) and external (Gemini/OpenCode) agents.
-argument-hint: "[search-target] [ext]"
-metadata:
-  author: claudekit
-  version: "1.0.0"
----
-
-# Scout
-
-Fast, token-efficient codebase scouting using parallel agents to find files needed for tasks.
-
-## Arguments
-- Default: Scout using built-in Explore subagents in parallel (`./references/internal-scouting.md`)
-- `ext`: Scout using external Gemini/OpenCode CLI tools in parallel (`./references/external-scouting.md`)
-
-## When to Use
-
-- Beginning work on feature spanning multiple directories
-- User mentions needing to "find", "locate", or "search for" files
-- Starting debugging session requiring file relationships understanding
-- User asks about project structure or where functionality lives
-- Before changes that might affect multiple codebase parts
-
-## Quick Start
-
-1. Analyze user prompt to identify search targets
-2. Use a wide range of Grep and Glob patterns to find relevant files and estimate scale of the codebase
-3. Spawn parallel agents with divided directories
-4. Collect results into concise report
-
-## Configuration
-
-Read from `.opencode/.ck.json`:
-- `gemini.model` - Gemini model (default: `gemini-3-flash-preview`)
-
-## Workflow
-
-### 1. Analyze Task
-- Parse user prompt for search targets
-- Identify key directories, patterns, file types, lines of code
-- Determine optimal SCALE value of subagents to spawn
-
-### 2. Divide and Conquer
-- Split codebase into logical segments per agent
-- Assign each agent specific directories or patterns
-- Ensure no overlap, maximize coverage
-
-### 3. Spawn Parallel Agents
-Load appropriate reference based on decision tree:
-- **Internal (Default):** `references/internal-scouting.md` (Explore subagents)
-- **External:** `references/external-scouting.md` (Gemini/OpenCode)
-
-**Notes:**
-- Prompt detailed instructions for each subagent with exact directories or files it should read
-- Remember that each subagent has less than 200K tokens of context window
-- Amount of subagents to-be-spawned depends on the current system resources available and amount of files to be scanned
-- Each subagent must return a detailed summary report to a main agent
-
-### 4. Collect Results
-- Timeout: 3 minutes per agent (skip non-responders)
-- Aggregate findings into single report
-- List unresolved questions at end
-
-## Report Format
-
-```markdown
-# Scout Report
-
-## Relevant Files
-- `path/to/file.ts` - Brief description
-- ...
-
-## Unresolved Questions
-- Any gaps in findings
-```
-
-## References
-
-- `references/internal-scouting.md` - Using Explore subagents
-- `references/external-scouting.md` - Using Gemini/OpenCode CLI