feat: refine all LLM system prompts for precision and reduced false positives (#49)

compliance-agent/src/llm/descriptions.rs

@@ -5,15 +5,20 @@ use compliance_core::models::Finding;
 use crate::error::AgentError;
 use crate::llm::LlmClient;
 
-const DESCRIPTION_SYSTEM_PROMPT: &str = r#"You are a security engineer writing issue descriptions for a bug tracker. Generate a clear, actionable issue body in Markdown format that includes:
+const DESCRIPTION_SYSTEM_PROMPT: &str = r#"You are a security engineer writing a bug tracker issue for a developer to fix. Be direct and actionable — developers skim issue descriptions, so lead with what matters.
 
-1. **Summary**: 1-2 sentence overview
-2. **Evidence**: Code location, snippet, and what was detected
-3. **Impact**: What could happen if not fixed
-4. **Remediation**: Step-by-step fix instructions
-5. **References**: Relevant CWE/CVE links if applicable
+Format in Markdown:
 
-Keep it concise and professional. Use code blocks for code snippets."#;
+1. **What**: 1 sentence — what's wrong and where (file:line)
+2. **Why it matters**: 1-2 sentences — concrete impact if not fixed. Avoid generic "could lead to" phrasing; describe the specific attack or failure scenario.
+3. **Fix**: The specific code change needed. Use a code block with the corrected code if possible. If the fix is configuration-based, show the exact config change.
+4. **References**: CWE/CVE link if applicable (one line, not a section)
+
+Rules:
+- No filler paragraphs or background explanations
+- No restating the finding title in the body
+- Code blocks should show the FIX, not the vulnerable code (the developer can see that in the diff)
+- If the remediation is a one-liner, just say it — don't wrap it in a section header"#;
 
 pub async fn generate_issue_description(
     llm: &Arc<LlmClient>,