mirror of
https://github.com/SHOGGOTH-SECTOR/sica-fondt.git
synced 2026-08-01 16:40:24 +00:00
Place useful parts of the surrounding repos into sica-fondt by layer, per the
body model (Ada = membrane; brain/endocrine/capabilities/knowledge non-Ada):
- brain/ LLM reasoning + providers (dapr, hermes, MoMoA)
- capabilities/ REPRAG sidecars: hermes tools/skills, dapr tools, parallel
dispatch, A51 channels, and the OSINT cluster
- knowledge/ LORAG corpus: 754 cyber-skills, agency personas, secure-coding,
MITRE ATT&CK data
- reference/ defensive threat-reference (C3, shhbruh doc) + AdaYaml parser
License handling: AGPL sources (worldosint, advanced_evolution, mercury,
Reticulum) and GPL DeTTECT are SPEC-only clean-room/port descriptions — no
copyleft code copied. MIT/Apache/data parts copied as working trees.
Safety: shhbruh escape/persistence material and C3 covert-C2 kept as reference
only, not wired into the running organism. See CONSOLIDATION.md.
https://claude.ai/code/session_01UehUqEXXJJCsHoA4voCU5c
58 lines
1.9 KiB
Markdown
58 lines
1.9 KiB
Markdown
---
|
|
name: plan
|
|
description: "Plan mode: write markdown plan to .hermes/plans/, no exec."
|
|
version: 1.0.0
|
|
author: Hermes Agent
|
|
license: MIT
|
|
metadata:
|
|
hermes:
|
|
tags: [planning, plan-mode, implementation, workflow]
|
|
related_skills: [writing-plans, subagent-driven-development]
|
|
---
|
|
|
|
# Plan Mode
|
|
|
|
Use this skill when the user wants a plan instead of execution.
|
|
|
|
## Core behavior
|
|
|
|
For this turn, you are planning only.
|
|
|
|
- Do not implement code.
|
|
- Do not edit project files except the plan markdown file.
|
|
- Do not run mutating terminal commands, commit, push, or perform external actions.
|
|
- You may inspect the repo or other context with read-only commands/tools when needed.
|
|
- Your deliverable is a markdown plan saved inside the active workspace under `.hermes/plans/`.
|
|
|
|
## Output requirements
|
|
|
|
Write a markdown plan that is concrete and actionable.
|
|
|
|
Include, when relevant:
|
|
- Goal
|
|
- Current context / assumptions
|
|
- Proposed approach
|
|
- Step-by-step plan
|
|
- Files likely to change
|
|
- Tests / validation
|
|
- Risks, tradeoffs, and open questions
|
|
|
|
If the task is code-related, include exact file paths, likely test targets, and verification steps.
|
|
|
|
## Save location
|
|
|
|
Save the plan with `write_file` under:
|
|
- `.hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md`
|
|
|
|
Treat that as relative to the active working directory / backend workspace. Hermes file tools are backend-aware, so using this relative path keeps the plan with the workspace on local, docker, ssh, modal, and daytona backends.
|
|
|
|
If the runtime provides a specific target path, use that exact path.
|
|
If not, create a sensible timestamped filename yourself under `.hermes/plans/`.
|
|
|
|
## Interaction style
|
|
|
|
- If the request is clear enough, write the plan directly.
|
|
- If no explicit instruction accompanies `/plan`, infer the task from the current conversation context.
|
|
- If it is genuinely underspecified, ask a brief clarifying question instead of guessing.
|
|
- After saving the plan, reply briefly with what you planned and the saved path.
|