feat: add SiftRank skill helper

[noperator]

Used GPT 5.5 to draft an initial implementation of a SiftRank integration into Raptor. I haven't used Raptor yet so I'm not very familiar with its architecture, but it seems like the best way is putting a SiftRank wrapper into libexec/ that can be called by a Claude skill. That's the approach I took here, but feel free to suggest something different @danielcuthbert :) I also followed other examples in the codebase that fetched OpenAI API creds from the Raptor models config file. I tested this out with a few basic examples and it seems to work well. The code and tests can likely be tightened up.

Coding agent summary here:

• Add a Claude Code skill for using SiftRank to prioritize candidate security items before deeper RAPTOR review.
• Add libexec/raptor-siftrank as a trusted helper that reads RAPTOR model configuration, ensures the external siftrank CLI is available, invokes it with an OpenAI-compatible analysis model, and writes ranked JSON while preserving original candidate items.
• The skill documents when SiftRank is useful, how to prepare candidate JSON, how to use named or literal prompts, and how to interpret ranked output as a review queue rather than a validation result.
• Add focused tests for deterministic helper behavior, model selection, SiftRank output mapping, and Go-based SiftRank installation paths.

[grokjc]

Hey - thanks for putting this together. The core idea here is genuinely interesting: pairwise comparison as a triage primitive is a smart approach to the "too many findings" problem.

RAPTOR already has LLM-driven triage in its analysis pipeline, so one option worth exploring is implementing the pairwise-ranking primitive natively which would give us tighter control over prompts, cost tracking, and finding-schema integration. But the siftrank approach has the advantage of being battle-tested in your own workflows.

A few thoughts on how to take this forward and potentially cement an approach:

Dependency management: the auto-install via go install is clever for local experimentation, but for the shipped tool we'd want the operator to bring siftrank themselves (like we do other dependencies) with a clean probe, actionable error message, no runtime fetching. We're also a big fan of pinning versioned dependencies to avoid nasty surprises.
That said, the right shape might not be an external binary at all.

Model selection: the model config functions you're reaching into are internal/private, and the OpenAI filter means operators running Anthropic or via Bedrock would be locked out. RAPTOR is model-agnostic by design - so worth wiring through the public model-selection surface so any configured provider works 'for free'.

Integration point: this is the big one, and also the most intriguing question: where in the pipeline does this fire? After /scan? Before /validate? As a step inside /agentic? Once there's a concrete caller with a defined input/output contract, everything else (schema, test placement, prompts) falls into place naturally. This is where we'd love your ideas.

Test location: Small thing, but tests for libexec/ scripts should live closer to the owning module rather than in packages/llm_analysis/tests/. Easy to move.

If you want to keep going with this, I'd suggest starting from the integration point question - as once we know where it plugs in, we can figure out the ideal shape together.

[danielcuthbert]

This is cool @noperator thanks for pushing this. I'm with @grokjc here, if you could help us with the wiring, that would be epic