oh-my-agent-commandcode 0.0.0-stage → 20.38.3

package/skills/oma-qa/resources/execution-protocol.md

@@ -0,0 +1,169 @@
+# QA Agent - Execution Protocol
+
+## Preparation
+Use the task's scope, existing project conventions, and acceptance criteria. Follow `../../_shared/core/execution-policy.md` when it has not already been supplied. Read only references needed by the selected operation; consult lessons or recovery guides for an observed issue. Expand planning depth only when the change requires it.
+
+## Step 1: Scope
+- Identify what to review: new feature, full audit, or specific concern
+- List all files/modules to inspect
+- Determine review depth: quick check vs. comprehensive audit
+- Follow `../../_shared/core/code-intelligence.md` to discover configured code
+  navigation/search tools. If unavailable or timed out, use native search only
+  for paths outside this project or ignored paths, record that limit, and continue the review.
+
+## Step 2: Audit
+Review in this priority order:
+1. **Security** (CRITICAL): OWASP Top 10, auth, injection, data protection
+2. **Performance**: API latency, N+1 queries, bundle size, Core Web Vitals
+3. **Accessibility**: WCAG 2.2 AA, keyboard nav, screen reader, contrast
+4. **Code Quality**: task-defined coverage expectations, complexity, architecture adherence
+
+When applicable, map findings and gaps to:
+- **ISO/IEC 25010** quality characteristics
+- **ISO/IEC 29119** test planning, design, traceability, and exit criteria
+
+Use `resources/checklist.md` (renamed qa-checklist) as the comprehensive review guide.
+
+## Step 2.5: Runtime Verification
+
+Static code review misses entire categories of bugs: display-only features,
+stubbed functionality, broken user flows, and edge cases that only surface
+at runtime. This step requires interacting with the running application.
+
+### When to Execute
+- Web app with UI: ALWAYS for Medium/Complex tasks
+- API-only: ALWAYS (curl/httpie verification)
+- Simple tasks (single file, no UI): SKIP
+
+### Execution by App Type
+
+#### Web Applications
+
+Browser verification uses the installed MCPs selected in `mcp.devtools_browsers`: Aside (`aside`, default), Chrome DevTools MCP (`chrome`), and Firefox DevTools MCP (`firefox`). Multiple selections are supported; use `oma update mcp` to change them. Discover the selected server’s actual tools before use; tool names and capabilities differ between servers. An empty selection disables browser MCP verification; report any unverified UI checks.
+
+Run the following checks with a selected, available server. Prefer a separate test context when supported. The tool calls below are Chrome DevTools MCP examples only; for Aside and Firefox DevTools MCP, discover and use their supported equivalents. Record missing capabilities instead of silently changing servers.
+
+1. Start the application (`bun run dev`, `uv run manage.py runserver`, etc.)
+2. Open the app in an **isolated browser context** to avoid contaminating the user's session:
+   ```
+   new_page(url: "http://localhost:PORT", isolatedContext: "qa-test")
+   ```
+   - Pages in the same `isolatedContext` share cookies/storage
+   - Pages in different contexts are fully isolated
+   - When using Chrome DevTools MCP, use `isolatedContext: "qa-test"` for QA verification
+3. Navigate and inspect:
+   ```
+   navigate_page(url)            → navigate within the isolated context (SPA routes, sub-pages)
+   take_snapshot()               → a11y tree snapshot with uid-tagged elements (prefer over screenshots)
+   ```
+4. Interact with modified features:
+   ```
+   click(uid)                    → click buttons/links
+   fill(uid, value)              → fill input/textarea/select fields
+   fill_form(elements)           → fill multiple fields at once
+   type_text(text, submitKey)    → type into focused input
+   press_key(key)                → keyboard shortcuts, Enter, Tab
+   hover(uid)                    → hover for tooltips, dropdown menus, state changes
+   drag(from_uid, to_uid)        → drag-and-drop
+   ```
+5. Verify functional correctness:
+   - `list_console_messages(types: ["error", "warn"])` → detect JS errors
+   - `list_network_requests()` → verify API calls fired and returned expected status
+   - `get_network_request(reqid)` → inspect request/response bodies
+   - `evaluate_script(function)` → check DOM state, global variables, computed styles
+   - `wait_for(text)` → confirm expected content appears after interaction
+6. Visual and accessibility verification:
+   - `take_screenshot()` → visual output matches acceptance criteria
+   - `lighthouse_audit(mode: "snapshot")` → accessibility, SEO, best practices scores
+   - `emulate(viewport: "375x812x3,mobile,touch")` → responsive/mobile verification
+7. Performance profiling (when performance criteria exist):
+   - `performance_start_trace(reload: true)` → capture Core Web Vitals
+   - `performance_stop_trace()` → analyze LCP, INP, CLS
+   - `take_heapsnapshot(filePath)` → detect memory leaks
+8. Cleanup:
+   ```
+   close_page(pageId)  → close isolated test pages after verification
+   ```
+9. **Fallback** (no selected browser MCP available):
+   - Use curl/httpie to hit rendered endpoints
+   - Verify HTTP status codes and response bodies; record that HTTP checks do not verify browser interactions
+   - Check redirects, auth flows, and error pages
+
+#### API Endpoints
+1. Start the server
+2. Execute acceptance criteria as actual HTTP requests:
+   ```bash
+   # Example: verify auth flow end-to-end
+   curl -s -X POST localhost:8000/api/auth/register \
+     -H "Content-Type: application/json" \
+     -d '{"email":"test@test.com","password":"secure123"}'
+
+   # Verify rate limiting actually triggers
+   for i in $(seq 1 20); do
+     curl -s -o /dev/null -w "%{http_code}" localhost:8000/api/auth/login
+   done
+   ```
+3. Verify database state after operations (query directly or via API)
+
+#### Mobile Applications
+1. If emulator/simulator available: launch and interact
+2. If not: verify via API layer + widget test execution
+
+### Recording Results
+
+Append to the QA report under a new section:
+
+```markdown
+## Runtime Verification Results
+
+| Feature | Method | Expected | Actual | Status |
+|---------|--------|----------|--------|--------|
+| User registration | curl POST /api/auth/register | 201 + user created | 201 + user in DB | PASS |
+| Rate limiting | 20x rapid POST /api/auth/login | 429 after threshold | 429 after 10 req | PASS |
+| Empty state UI | navigate_page + take_snapshot | Empty state message | Blank white page | FAIL |
+| Button handler | click(uid) + list_network_requests | POST /api/save fired | No request fired | FAIL |
+| Console errors | list_console_messages(["error"]) | 0 errors | TypeError at app.js:42 | FAIL |
+```
+
+### Stubbed Feature Detection
+
+Specifically check for these patterns that static review cannot catch:
+- Buttons/forms that render but have no backend handler → `click(uid)` + `list_network_requests()` to verify
+- Features that display placeholder data instead of real data → `evaluate_script()` to check data binding
+- Interactive elements that don't respond to user input → `click(uid)` + `take_snapshot()` to compare before/after
+- Audio/video/file upload controls with no actual processing → `upload_file(uid, filePath)` + verify response
+
+---
+
+## Evaluator Posture: Evidence-based
+
+Apply this posture when making verdict decisions in Step 3 and Step 4:
+- Base defect findings on reproducible evidence; track unconfirmed hypotheses separately.
+- "Probably works" or "should be fine" is NOT valid evidence. Run it, show output, prove it.
+- If a required feature cannot be verified at runtime, record the missing check, reason, and next action. Mark review completeness `partial`, or `blocked` when no independent verification can proceed, following the shared execution policy and host rules.
+- A skipped check, missing tool, or interrupted command is not evidence that the product works or that it contains a defect. A failed verification command must not count as a passing check; diagnose whether it demonstrates a product defect or an environment/configuration problem.
+- Never downgrade a real bug to "non-critical" just to pass a gate.
+- Use WARNING when all remaining issues are MEDIUM or lower and none block deployment.
+- When evidence is insufficient, report the verification gap and continue available checks. Do not invent a defect or issue PASS to force a binary verdict.
+
+## Step 3: Report
+Generate structured report with:
+- Report both quality verdict and verification completeness:
+  - PASS: required checks completed; no CRITICAL, HIGH, or MEDIUM issues
+  - WARNING: required checks completed; no CRITICAL or HIGH issues, but MEDIUM issues exist
+  - FAIL: a reproducible CRITICAL or HIGH issue exists, even if other checks remain unavailable
+  - NOT_ASSESSED: required evidence is missing and no confirmed defect warrants FAIL; list any confirmed lower-severity findings separately
+  - Completeness: `completed` when required verification is finished, `partial` when evidence remains missing, or `blocked` when independent work cannot proceed under the shared execution policy and host rules
+- Verification gaps: missing check, cause, completed alternative checks, and concrete next action; keep these separate from defect findings
+- Findings grouped by severity (CRITICAL > HIGH > MEDIUM > LOW)
+- Each finding: file:line, description, remediation code
+- Performance metrics vs. targets
+- Standards suggestions when relevant:
+  - quality characteristics under-covered
+  - missing test design / traceability / exit criteria
+
+## Step 4: Verify
+- Use applicable sections of `../../_shared/core/common-checklist.md` when the review crosses domains
+
+## On Error
+See `resources/error-playbook.md` for recovery steps.

package/skills/oma-qa/resources/iso-quality.md

@@ -0,0 +1,82 @@
+# QA Agent - ISO Quality Guide
+
+Use this file when the user asks for standards-based QA suggestions, enterprise audit readiness, or process-oriented quality improvements.
+
+## Positioning
+
+- Use **ISO/IEC 25010** as the practical software quality model.
+- Treat **ISO/IEC 25010** as part of the **ISO/IEC 25000 SQuaRE family** when users say "ISO 25000".
+- Use **ISO/IEC 29119** for test process, test design, traceability, and evidence recommendations.
+- Do not force standards language into every QA review. Add it when it improves decision quality, auditability, or delivery discipline.
+
+## 1. ISO/IEC 25010 Mapping
+
+Map findings to these quality characteristics when relevant:
+
+- functional suitability
+- performance efficiency
+- compatibility
+- usability
+- reliability
+- security
+- maintainability
+- portability
+
+Use this mapping to answer:
+
+- Which quality areas are under-covered?
+- Which areas are blocking release confidence?
+- Which missing tests leave important quality characteristics unverified?
+
+## 2. ISO/IEC 29119 Suggestions
+
+Recommend these when test discipline is weak:
+
+- test strategy or test plan
+- test levels and scope definition
+- requirement / risk to test traceability
+- explicit test conditions and expected results
+- risk-based prioritization
+- entry / exit criteria
+- evidence retention for review or audit
+
+## 3. When to Mention Standards
+
+Mention ISO alignment when:
+
+- the user asks for audit readiness
+- the work is enterprise or regulated
+- release governance is unclear
+- testing exists but lacks structure or traceability
+- quality discussion is too vague and needs a common model
+
+Avoid overusing standards language when:
+
+- the task is a quick bug fix
+- the user wants only concrete defects
+- standards language would add ceremony without action
+
+## 4. Review Output Pattern
+
+If standards are relevant, add a short section:
+
+```md
+## Standards Alignment
+
+### ISO/IEC 25010
+- Quality characteristic:
+- Gap:
+- Recommendation:
+
+### ISO/IEC 29119
+- Test governance gap:
+- Traceability / evidence gap:
+- Recommendation:
+```
+
+## 5. Guardrails
+
+- Prefer practical suggestions over compliance theater
+- Do not claim formal compliance unless evidence exists
+- Tie every standards suggestion to a delivery, test, or risk outcome
+- Keep standards comments secondary to concrete findings

package/skills/oma-qa/resources/verify-ship-protocol.md

@@ -0,0 +1,116 @@
+# VERIFY/SHIP Phase Protocol
+
+Execution guide for VERIFY Phase (Steps 6-8) and SHIP Phase (Steps 14-17) in ultrawork workflow.
+
+---
+
+## VERIFY Phase (Steps 6-8)
+
+### Step 6: Alignment Review
+
+**Review Question**: "Did we build what was requested?"
+
+- [ ] Plan vs implementation 1:1 comparison
+- [ ] Misalignments documented
+- [ ] No missing features
+
+---
+
+### Step 7: Security/Bug Review
+
+**Review Question**: "Is there anything dangerous?"
+
+**Automated Tools:**
+- `npm audit` (Node.js)
+- `bandit` (Python)
+- `lighthouse` (web performance)
+
+**OWASP Top 10 Check:**
+- [ ] No injection vulnerabilities
+- [ ] No authentication flaws
+- [ ] No sensitive data exposure
+- [ ] No XXE vulnerabilities
+- [ ] No access control flaws
+
+**Finding Format:**
+- File:line
+- Description
+- Severity (CRITICAL/HIGH/MEDIUM/LOW)
+- Fix suggestion
+
+---
+
+### Step 8: Improvement Review
+
+**Review Question**: "Did improvements break anything?"
+
+- [ ] Affected regression checks pass; broaden only for identified impact
+- [ ] Existing features work normally
+- [ ] New code matches existing patterns
+
+---
+
+### VERIFY_GATE Checklist
+
+- [ ] Implementation = Requirements
+- [ ] CRITICAL issues: 0
+- [ ] HIGH issues: 0
+- [ ] No regressions
+
+**Gate failure → Return to Step 5 (fix implementation)**
+
+---
+
+## SHIP Phase (Steps 14-17)
+
+### Step 14: Code Quality Review
+
+**Review Question**: "Does it meet quality standards?"
+
+- [ ] lint passes
+- [ ] type check passes
+- [ ] applicable project or task-defined coverage target met, or alternative verification recorded
+- [ ] Applicable cross-domain checks from `_shared/core/common-checklist.md` pass
+
+---
+
+### Step 15: UX Flow Verification
+
+- [ ] End-to-end user journey test
+- [ ] Error states verified
+- [ ] Loading states verified
+- [ ] Accessibility compliance (WCAG 2.2 AA)
+
+---
+
+### Step 16: Related Issues Review
+
+**Review Question**: "Did we break anything elsewhere?"
+
+- [ ] Issues discovered during review checked
+- [ ] Related areas not broken
+- [ ] Deferred items documented (next sprint)
+
+---
+
+### Step 17: Deployment Readiness Review
+
+**Review Question**: "Is this ready to deploy?"
+
+- [ ] No hardcoded secrets
+- [ ] Environment variables documented
+- [ ] Migrations safe
+- [ ] Rollback possible
+- [ ] Monitoring ready
+
+---
+
+### SHIP_GATE Checklist
+
+- [ ] All quality checks pass
+- [ ] UX verified
+- [ ] Related issues resolved
+- [ ] Deployment checklist complete
+- [ ] Scope and any external action are authorized under the shared execution policy; reuse existing authorization
+
+**Gate failure → Return to appropriate phase based on failure type**

package/skills/oma-recap/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: oma-recap
+description: Summarize AI conversation histories for a specified date or period.
+  Use for daily work recaps and cross-tool activity summaries.
+---
+
+# AI Tool Conversation History Summary
+
+Analyze AI tool conversation histories for a given period and generate themed work summaries.
+
+## Scheduling
+
+### Goal
+Collect AI tool conversation history for a date or window and synthesize it into a themed, project-oriented recap with saved Markdown output.
+
+### Intent signature
+- User asks for daily recap, weekly/monthly summary, standup notes, work log, tool usage pattern, or AI conversation history analysis.
+- User wants conversation histories grouped by work content rather than raw chronological logs.
+
+### When to use
+- Summarizing a day or period of work activity
+- Understanding the overall flow of work across multiple AI tools
+- Analyzing tool-switching patterns between sessions
+- Preparing daily standups, weekly retros, or work logs
+
+### When NOT to use
+- Git commit-based code change retrospective -> use `oma retro`
+- Real-time agent monitoring -> use `oma dashboard terminal`
+- Productivity metrics -> use `oma stats get`
+
+### Expected inputs
+- Date, relative date, time window, or tool filter
+- Conversation history available through `oma recap --json` or fallback sources
+- Desired daily or multi-day recap scope
+
+### Expected outputs
+- Markdown recap saved to `.agents/results/recap/{date}.md` or range filename
+- TL;DR, overview, themes/projects, miscellaneous or side projects, and tool usage patterns
+- User-facing summary in configured response language
+
+### Dependencies
+- `oma recap --json`
+- Optional Claude fallback history at `~/.claude/history.jsonl`
+- `.agents/oma-config.yaml` for language behavior
+
+### Control-flow features
+- Branches by date resolution, window length, available tool history, and daily vs multi-day output shape
+- Reads local history data and writes Markdown recap files
+- Groups by content, not by tool
+
+## Structural Flow
+
+### Entry
+1. Resolve requested date or window.
+2. Collect normalized conversation history.
+3. Decide daily versus multi-day output structure.
+
+### Scenes
+1. **PREPARE**: Resolve time range and tool filters.
+2. **ACQUIRE**: Collect history through CLI or fallback; retain completion evidence where available.
+3. **REASON**: Group by content and classify each item as requested, in progress, or completed from its evidence.
+4. **ACT**: Write recap Markdown in the required format.
+5. **VERIFY**: Check that every completion claim has direct evidence, then check grouping, language, and output path.
+6. **FINALIZE**: Save and display summary.
+
+### Transitions
+- If no date is specified, use today via `--date` (bare `--window` is a rolling window ending now, not calendar-aligned).
+- If window is 3 days or longer, group by project instead of day chronology.
+- If CLI is unavailable, use Claude fallback only and report scope limits.
+- If tasks are under threshold, group them into Miscellaneous or Side Projects.
+
+### Failure and recovery
+- If history is unavailable, report missing source and requested range.
+- If timestamps are ambiguous, use configured timezone and state assumption.
+- If extracted data is sparse, produce a concise recap and note limited coverage.
+
+### Exit
+- Success: recap file exists and summary is displayed.
+- Partial success: missing tools/history or fallback-only coverage is explicit.
+
+## Logical Operations
+
+### Actions
+| Action | SSL primitive | Evidence |
+|--------|---------------|----------|
+| Resolve date/window | `INFER` | Natural-language date rules |
+| Collect history | `CALL_TOOL` | `oma recap --json` or `jq` fallback |
+| Read extracted records | `READ` | Conversation history |
+| Group and classify themes/projects | `INFER` | Time/content rules plus prompt, progress, completion, receipt, or artifact evidence |
+| Validate output shape | `VALIDATE` | Daily or multi-day template |
+| Write recap | `WRITE` | `.agents/results/recap/` |
+| Report summary | `NOTIFY` | Displayed recap |
+
+### Tools and instruments
+- `oma recap --json`
+- `jq` fallback for Claude history
+- Markdown output templates
+
+### Canonical command path
+```bash
+oma recap --date YYYY-MM-DD --json
+oma recap --window 7d --json
+oma recap --json  # rolling last 24h, not "today"
+```
+
+### Resource scope
+| Scope | Resource target |
+|-------|-----------------|
+| `LOCAL_FS` | Conversation history and recap output files |
+| `PROCESS` | `oma recap`, `jq`, date commands |
+| `USER_DATA` | Conversation prompts and project activity |
+| `MEMORY` | Theme grouping and summary notes |
+
+### Preconditions
+- Requested time range can be resolved.
+- At least one history source is available.
+
+### Effects and side effects
+- Writes recap Markdown under `.agents/results/recap/`.
+- Reads local conversation history data.
+
+### Guardrails
+
+1. **Evidence status**: A prompt alone proves a request, not a result. Mark work **completed** only with an explicit completion/result message, a receipt, or an artifact that supports the stated outcome. Mark it **in progress** with progress evidence; otherwise call it **requested**. Do not infer completion from a tool invocation or elapsed time.
+2. **TL;DR required**: Top 3 supported outcomes. Use "completed" only when the evidence-status rule permits it; otherwise summarize requested or in-progress work plainly. Project name + status/outcome. No tool names or unnecessary detail.
+3. **Overview**: After TL;DR, describe the flow. Start with "I" as subject and preserve evidence status.
+4. **Daily**: themes by time block (15+ min). Rest goes to "Miscellaneous".
+5. **Multi-day (3d+)**: sections by project, ordered by activity. Read like a sprint report, not a daily log.
+6. **2-4 bullets per theme/project**: Concise essentials only. Don't enumerate every step.
+7. **Themes by content**: Group by actual work, not by tool.
+8. **Time range (daily only)**: `(AM/PM/Evening HH:MM~HH:MM)`. AM: ~12:00, PM: 12:00~18:00, Evening: 18:00~.
+9. **Save results**: Write markdown to `.agents/results/recap/`.
+10. **Response language**: the user's prompt language first, then `language` in `.agents/oma-config.yaml`, then English.
+11. **No em dashes**: Use commas, periods, or parentheses instead of `—` (em dash).
+
+### Process
+
+### 1. Resolve Date
+
+Determine the target date or window from the user's natural language input. Default is today.
+
+**Resolution rules:**
+- Relative day references (today, yesterday, day before yesterday, etc.) → calculate `--date YYYY-MM-DD`
+- Specific date mentions (month + day, or full date) → convert to `--date YYYY-MM-DD`
+- Relative weekday references (last Monday, this Friday, etc.) → calculate the date
+- Period references (this week, last 3 days, past 2 weeks, etc.) → convert to `--window Nd`
+- No date specified → today, resolved to `--date YYYY-MM-DD` (bare `--window 1d` is a rolling 24-hour window ending now, not the calendar day)
+- The CLI caps windows at 30 days (longer values are trimmed with a warning) — when a requested period gets capped, say so in the recap
+
+### 2. Collect Data
+
+Extract normalized conversation history via CLI.
+
+```bash
+# Today (calendar day, all tools)
+oma recap --date $(date +%F) --json
+
+# Last 24 hours (rolling window ending now)
+oma recap --json
+
+# Time window (rolling, ends now; capped at 30d)
+oma recap --window 7d --json
+
+# Specific date
+oma recap --date 2026-04-10 --json
+
+# Tool filter (supported: grok, claude, codex, gemini, qwen, cursor, antigravity)
+oma recap --tool claude,codex --json
+```
+
+**Fallback when CLI is not installed**: process Claude history only via inline jq:
+
+```bash
+# Uses the system timezone; export TZ=<zone> first to override, and state the
+# timezone assumption in the recap (per the Failure and recovery rules).
+TARGET_DATE=$(date +%Y-%m-%d)
+# macOS/BSD date: advance the calendar date, then parse both local midnights.
+next_date=$(date -j -v+1d -f "%Y-%m-%d %H:%M:%S" "${TARGET_DATE} 12:00:00" +%Y-%m-%d)
+start_ts=$(date -j -f "%Y-%m-%d %H:%M:%S" "${TARGET_DATE} 00:00:00" +%s)000
+end_ts=$(date -j -f "%Y-%m-%d %H:%M:%S" "${next_date} 00:00:00" +%s)000
+# Linux/GNU date alternatives (replace all three lines above):
+# next_date=$(date -d "${TARGET_DATE} 12:00:00 tomorrow" +%Y-%m-%d)
+# start_ts=$(date -d "${TARGET_DATE} 00:00:00" +%s)000
+# end_ts=$(date -d "${next_date} 00:00:00" +%s)000
+# Do not add a fixed 24 hours: DST calendar days can have 23 or 25 hours.
+
+jq -r --argjson start "$start_ts" --argjson end "$end_ts" '
+  select(.timestamp >= $start and .timestamp < $end and .display != null and .display != "") |
+  {
+    time: (.timestamp / 1000 | localtime | strftime("%H:%M")),
+    project: (.project | split("/") | .[-1]),
+    prompt: (.display | gsub("\n"; " ") | if length > 150 then .[0:150] + "..." else . end)
+  }
+' ~/.claude/history.jsonl
+```
+
+### 3. Theme Analysis and Grouping
+
+Read **all** extracted data and analyze with the following criteria:
+
+**Grouping rules:**
+- Only classify as a separate theme if the work spans **15+ minutes** (based on timestamp gaps and prompt count)
+- Merge consecutive prompts on the same topic into one theme
+- Collect sub-15-minute tasks into a "Miscellaneous" section
+- Group by **work content**, not by tool
+
+**Cross-tool analysis:**
+- Track workflow when multiple tools are used in the same time window
+- Example: "Designed in Antigravity -> Implemented in Claude -> Reviewed in Codex"
+- Derive insights from tool-switching patterns
+
+**Extract from each theme:**
+- Core work performed
+- Key decisions made
+- Tool combinations used
+- Artifacts produced (docs, code, config, etc.)
+
+### 4. Output Format
+
+Save results to `.agents/results/recap/{date}.md` and display simultaneously.
+
+Use the markdown templates in `resources/output-formats.md`:
+- **Daily format** (1d or specific date): TL;DR → Overview → time-blocked themes → Miscellaneous → Tool Usage Patterns.
+- **Multi-day format** (3d+): project-driven sprint-report structure with Side Projects for small (<30 prompts) work; follow the multi-day grouping rules in the same file.
+
+**Response language: the user's prompt language first, then `language` in `.agents/oma-config.yaml`, then English.**
+
+### 5. Save Results
+
+Save to `.agents/results/recap/{date}.md`.
+For window ranges, use `{start-date}~{end-date}.md` format.
+
+```bash
+# Example paths
+.agents/results/recap/2026-04-12.md
+.agents/results/recap/2026-04-06~2026-04-12.md
+```
+
+## References
+
+- Output format templates: `resources/output-formats.md`
+- Recap CLI: `oma recap --json`
+- Output directory: `.agents/results/recap/`
+- Language config: `.agents/oma-config.yaml`
+- Claude fallback history: `~/.claude/history.jsonl`