v1.0.0 to v1.1.0

46 added, 106 removed. Audit A to A.

---

name: primr-qa

- version: "1.0.0"

- description: "Quality assessment and system diagnostics for Primr"

+ version: "1.1.0"

+ description: "Review Primr outputs and diagnose integration issues. Use when the user wants report quality assessment, output review, or system health checks."

metadata:

openclaw:

requires:

bins:

- primr-mcp

env:

+ - XAI_API_KEY

- GEMINI_API_KEY

- - SEARCH_API_KEY

- - SEARCH_ENGINE_ID

os:

- linux

- darwin

- win32

mcp_server: primr

tools:

- run_qa

- doctor

resources:

- primr://output/latest

- primr://config

---

# Primr QA Skill

- You are a quality assurance specialist with access to Primr's QA and diagnostic capabilities. You help ensure research reports meet quality standards and troubleshoot system issues.

## Conceptual Framework

- Primr's QA system evaluates reports against research quality criteria:

- - **Factual accuracy**: Claims supported by sources

- - **Completeness**: Key sections adequately covered

- - **Actionability**: Insights that help you make informed decisions

- - **Citation quality**: Sources properly attributed

- **Key Principle**: QA scores reflect usefulness as research, not report mechanics. An 85+ means the brief gives you a solid understanding of the company.

- ### Score Interpretation

+ Use QA to judge research usefulness and trustworthiness, not just formatting. Use diagnostics when the failure is operational rather than editorial.

- | Score Range | Meaning |

- |-------------|---------|

- | 85+ | Excellent - ready for use |

- | 70-84 | Acceptable - may need refinement |

- | Below 70 | Needs work - review weak sections |

+ This skill should stay close to MCP outputs. Avoid embedding fixed provider assumptions in the skill body.

## Operational Capabilities

- ### 1. Run Quality Assessment

- **Trigger**: User asks to check report quality

- **Tool**: `run_qa`

- **Parameters**:

- - `report_path`: Path to report file (optional - defaults to latest)

- - `company_name`: Company name to find most recent report (optional)

+ ### 1. Run quality assessment

- ```

- Example: "Run QA on the Acme Corp report"

- → Call run_qa with company_name="Acme Corp"

- Example: "Check quality of output/acme_corp/report.md"

- → Call run_qa with report_path="output/acme_corp/report.md"

- ```

- **Output Includes**:

- - Overall score (0-100)

- - Section-by-section breakdown

- - Specific improvement suggestions

- - Weak areas flagged for attention

+ Read `primr://output/latest` when no path is specified, then call `run_qa` on the concrete report file.

- ### 2. System Diagnostics

- **Trigger**: User reports issues or wants to check system health

- **Tool**: `doctor`

- ```

- Example: "Is Primr working correctly?"

- → Call doctor to run diagnostics

- ```

+ ```text

- **Checks Performed**:

- - API key validity (Gemini, Search)

- - Network connectivity

- - Orphaned Gemini resources

- - Disk space for output

- - Python environment

+ run_qa(report_path="output/exampleco/report.md")

- ### 3. Interpret QA Results

+ ```

- When presenting QA results:

- **For scores 85+**:

- - "Report is ready for use. Quality score: {score}"

- - Highlight any standout sections

- **For scores 70-84**:

- - "Report is usable but could be improved. Score: {score}"

- - List specific weak sections

- - Offer to help refine

+ ### 2. Run diagnostics

- **For scores <70**:

- - "Report needs attention before use. Score: {score}"

- - Prioritize the weakest sections

- - Suggest re-running research or manual review

- ## Error Handling

- ### Common Issues

+ Call `doctor` when the issue looks like environment, API, or runtime configuration rather than report quality.

- | Issue | Diagnosis | Resolution |

- |-------|-----------|------------|

- | QA fails to run | API key issue | Run `doctor` to check keys |

- | Low scores consistently | Source quality | Try `deep` mode for better sources |

- | Doctor shows orphaned resources | Interrupted runs | Suggest cleanup script |

- ### Recovery Patterns

- 1. **QA timeout**: Large reports may take longer; retry with patience

- 2. **Missing report**: Check output directory, may need to run research first

- 3. **API errors**: Run `doctor`, check rate limits, wait and retry

+ ### 3. Interpret results

- ## Memory Subsystem Integration

- When you solve a Primr-related issue, record the solution in MEMORY.md for future reference:

- ```markdown

- ## Primr Solutions

+ Focus on factual gaps, weak evidence, and thin strategic interpretation before cosmetic issues.

- ### [Error Signature]

- - **Encountered**: [date]

- - **Symptoms**: [what the user saw]

- - **Solution**: [what fixed it]

- - **Expires**: [30 days from now]

- ```

- **Guardrails for Memory Entries**:

- - NEVER record API keys, tokens, or credentials

- - NEVER record internal URLs or file paths with sensitive data

- - Keep entries to "error signature → fix" format

- - Include expiration date (30 days) for revalidation

- - Flag entries for optional human review

- ### Example Memory Entry

+ ## Error Handling

- ```markdown

- ### gemini_rate_limit_exceeded

- - **Encountered**: 2026-02-15

- - **Symptoms**: Research fails with "429 Too Many Requests"

- - **Solution**: Wait 60 seconds between research runs; use --mode scrape for quick checks

- - **Expires**: 2026-03-17

- ```

- ## Workflow Integration

- ### Post-Research QA Flow

+ - QA failures: run `doctor` and confirm the report path.

- After research completes:

- 1. Automatically suggest running QA

- 2. If score <85, offer specific improvements

- 3. If score 85+, proceed to strategy generation

+ - Low scores: identify the weakest sections and recommend one next action.

- ### Troubleshooting Flow

+ - Config issues: use `primr://config` and `doctor` to explain what is missing.

- When user reports issues:

- 1. Run `doctor` first

- 2. Check for common patterns in MEMORY.md

- 3. If new issue, diagnose and record solution