Memory and reusable GIS knowledge
Keep reusable procedures in skills, stable profile facts in memory, and project evidence in sessions or notes.
Hermes can use skills, durable memory, and session history, but they serve different purposes. Keeping those layers separate prevents stale project data or sensitive information from becoming permanent agent context.
What belongs in a skill versus memory
Use a skill for reusable GIS procedures: service validation, CRS checks, pagination, cartographic QA, or approval workflows. Use memory only for stable profile facts such as an approved public catalog URL or a project convention.
Do not save credentials, client data, task logs, one-off layer IDs, temporary query results, or private service metadata in memory or skills.
Cross-session recall
Session search can recover prior project conversations and evidence without turning every result into durable memory. Project notes or a controlled knowledge base are better places for completed decisions, data dictionaries, source assessments, and delivery records.
Keep memory lean
Memory should contain compact, stable facts that reduce future setup. Put reusable procedures in skills and completed project history in sessions or notes.
Curating improvements upstream
A personal profile may refine a skill while solving real work. Treat that copy as private working context until it has been reviewed.
The public repository is maintained through reviewed Git changes. Before contributing a learning-loop improvement upstream:
- remove private URLs, local paths, credentials, and client details;
- generalize organization-specific wording;
- verify referenced files and commands;
- run the package validator;
- review the Git diff and submit the change through a pull request.
This keeps the shared package useful without publishing private operational context.