메뉴
Synthesizes raw learnings and codebase analysis into an interlinked Markdown Knowledge Base (KB). Use at the beginning of a loop to build or update architecture.md, entities, and vulnerabilities. Don't use for generating threat models or formulating execution plans.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | mantis_architecture |
| description | Synthesizes raw learnings and codebase analysis into an interlinked Markdown Knowledge Base (KB). Use at the beginning of a loop to build or update architecture.md, entities, and vulnerabilities. Don't use for generating threat models or formulating execution plans. |
Knowledge Base Synthesizer. Translates ephemeral insights from the learnings
queue (learnings.jsonl) and structural analysis of the codebase into a
canonical, interlinked Markdown Knowledge Base (workspace/kb/).
/mantis_architectureAnalyze the codebase and pending learnings to construct a permanent, Markdown-based memory for future agents.
Execute the architecture stage as follows:
Read the Inbox (learnings.jsonl and historical_learnings.jsonl):
learnings.jsonl (and
historical_learnings.jsonl if it exists). Extract all trajectory
insights, discovered vulnerabilities, viable crash paths, and verified
patches.Analyze Source Code Boundaries:
Build or Update the Knowledge Base (KB):
Create or update files in the workspace/kb/ directory using standard
Markdown. Follow these strict paths:
workspace/kb/architecture.md: High-level data flows, zone
definitions, system design, and overall availability/uptime
requirements (if documented or inferable from configuration like
systemd, kubernetes, or load balancers).workspace/kb/entities/[component_name].md: Specific definitions
for components (e.g., auth_module.md). Must include links to
associated vulnerability classes and document known constraints
(e.g., "This module sanitizes input X"). Document the component's
criticality and availability requirements (classify as CRITICAL,
STANDARD, or LOW_CRITICALITY if applicable). Incorporate trajectory
insights here.workspace/kb/vulnerabilities/[CWE-ID_or_BugClass].md: Descriptions
of bug classes (e.g., CWE-79.md or Memory-Corruption.md) that
have been historically relevant to this codebase, including examples
of what not to do.workspace/kb/index.md: A root catalog containing links and 1-line
summaries to every file created above. This is the map the Planner
will read.Important Formatting Rules: Use relative links to cross-reference
entities and vulnerabilities (e.g., [Auth Module](entities/auth_module.md)). Ensure all markdown files are
concise and focused on actionable security context.
Validate and Decay Knowledge (Drift Prevention):
workspace/kb/entities/ against the live source code.Clear the Inbox (State Management):
learnings.jsonl have been
successfully synthesized into the Markdown KB, programmatically
empty the learnings.jsonl file. The KB is now the single source of
truth.When complete, notify the user.
Calculates the final risk score based on empirical evidence and architectural impact. Use when findings have been fully processed by previous stages and you need to append final risk scores to the finding files. Don't use for discovering new vulnerabilities or writing patches.
Synthesizes trust boundaries, attack surfaces, and attacker profiles into a living threat model. Use as Stage B of the Knowledge Base generation process, reading architecture and entity definitions from the KB. Don't use for analyzing source code or extracting raw learnings from JSONL files.
Analyzes individual security findings to identify and construct complex exploit chains. Use after validation stages to see if multiple low-severity bugs can be combined into a higher impact vulnerability. Don't use for initial codebase auditing or writing patch code.
Consolidates raw security findings to eliminate redundant reports. Use when raw findings have been generated by the researcher and need consolidation before review. Don't use for initial code auditing or patch generation.
Audits production source code files based on the strategy in plan.json. Use when a review plan exists and you need to perform static analysis and deep-dive reviews of targeted files. Don't use for planning, deduplicating, or writing patches.
Assesses the production viability of findings, filtering out debug-only features and assertion traps. Use when findings have been validated and you need to confirm they are triggerable in production release builds (with assertions disabled). Don't use for writing reproduction scripts or patches.