Instructions
- Classify the task as document parsing/extraction, index/search, configuration, template management, or MCP. Check the pin and installed CLI help before using exact flags.
he parse <input> -t <template> -o <output>is a documented command shape; preview the source files and output directory first. Extraction may send document data to a configured model provider. Obtain explicit approval for uploads, provider calls, cost, and output writes.- Inspect provider/config location and permissions before recommending changes. The pinned implementation stores config under
~/.he/config.tomland restricts access where supported. Never print or request API key values; use provider environment settings or secure local entry only after approval. - Do not infer MCP safety from CLI use. Review transport, tool scope, credentials and client config; obtain approval before server start or registration.
Examples
- “Extract this local Markdown file using a template, but do not call a provider yet.”
- “Explain the difference between
he parseandhe search.” - “Troubleshoot an
he configissue without exposing API keys.”
Best practices
- Start with
he --help,he config --help, andhe list template; use a small non-sensitive fixture before production documents. - Keep raw inputs, generated knowledge artifacts, and indexes in distinct destinations with explicit retention and access rules.
- Read
references/upstream.mdfor current provider and MCP boundaries. The offline helper verifies only selected file hashes and PATH tool presence, never provider/runtime readiness.
References
references/upstream.md- install/CLI, provider config, MCP scope, limits, license and approvals.references/source.json- selected pinned file SHA256s; not a whole-revision attestation.evals/evals.json- authored routing and boundary scenarios, not executed model-quality tests.