janus-analyzer-skill

# Janus Analyzer Skill ## Overview Use this skill when the user wants Janus to answer a measurement question, design a new metric, extend an analyzer, or explain why a result differs between Mythic and Ghostwriter. Start from the existing Janus execution path instead of inventing new analysis flows. Read only the source-specific reference that matches the request. ## Workflow 1. Pin down the question to answer in one sentence. 2. Determine the source: `mythic`, `ghostwriter`, or compare both. If the source is omitted, infer it from the task or config only when low-risk. 3. Read these core files first: - `janus.py` - `Core/analyzer_registry.py` - `Core/analyzer_behavior_registry.py` - `Config/analyzers.yml` - `Config/analyzer_registry.yml` 4. Route by source: - Mythic: read `Parsers/Mythic/mythic_pull.py` - Ghostwriter: read `Parsers/Ghostwriter/main.py` - Cobalt Strike REST: read `Parsers/CobaltStrike/cobalt_strike_rest.py` - CobaltStrike TSV: read `Parsers/CobaltStrike/cobalt_strike_tsv.py` - Partial Mythic: read `Parsers/Mythic/partial_data_adapter.py` - Cross-source comparison: read `docs/architecture.md` then parser files above 5. Classify the request before editing code: - Existing analyzer usage or report interpretation - Behavior-registry tweak - Parser normalization gap - New analyzer 6. Prefer the smallest change that answers the question cleanly. ## Implementation Rules - Keep analyzer names in kebab-case and register outputs in `Core/analyzer_registry.py`. - For a new analyzer, update all runtime registration points: - `Core/analyzer_registry.py` - `Config/analyzers.yml` - `janus.py` `ANALYZER_FUNCTIONS` - `janus.py` `run_analyze()`'s explicit analyzer dispatch branch - Preserve the canonical task/result event model Janus already uses. - Treat Ghostwriter result state as unreliable unless the source schema actually adds trustworthy status fields. - Do not “equalize” Mythic downward; source-aware behavior should degrade weaker sources safely, not discard stronger Mythic fidelity. - If a metric depends on success/error truth, say explicitly whether Ghostwriter can support it today. - If only heuristics need adjustment for known commands, prefer `Config/analyzer_registry.yml` over hard-coding special cases. - **Always update `Core/html_output.py` when an analyzer's output schema changes.** Find the `_render_<analyzer_name>` function and update any `.get(“key”)` references that no longer match. Silently empty tables are the failure mode. - After adding a new analyzer, run it once through the real CLI/container path, not just direct Python imports, to catch missing `run_analyze()` registration. - Parser robustness guardrails now exist and should be preserved: - `normalize_timestamp()` accepts ISO and epoch values; malformed timestamps should be handled intentionally (skip with counters or raise early). - `load_events()` can validate schema and warns on unknown event types. - `run_merge()` remaps missing/duplicate `operation_id` values to deterministic unique IDs to avoid cross-operation key collisions. ## What Good Output Looks Like When answering the user, produce: - The metric or question being answered - The source scope and any fidelity limits - Whether Janus already supports it or needs code changes - If code changes are needed, the minimal files to touch ## References - `docs/architecture.md`