Trailmark Variant Neighborhood
Expand one seed issue into graph-derived variant candidates. This skill
generates review targets, not confirmed findings.
When to Use
- A finding is confirmed or plausible and variants may exist
- The vulnerable pattern depends on call context
- The issue involves a shared sink, source, validator, interface, override,
trait, hook, handler, adapter, or critical type
- The next step is to seed
variant-analysis, semgrep-rule-creator,
static-analysis, or manual review
When NOT to Use
- No seed issue exists. Use discovery or triage first.
- The pattern is purely syntactic and already obvious. Use
semgrep-rule-creator directly.
- The question is exploit-chain composition across multiple findings. Use a
composition workflow.
- The goal is remediation verification. Use a remediation-review workflow.
- The seed cannot be bound to a graph node.
Rationalizations to Reject
| Rationalization |
Why It Is Wrong |
Required Action |
| "Nearby code means variant" |
Proximity is only a candidate reason |
Rank it as a review target |
| "Only exact same names matter" |
Variants often share sinks or preconditions, not names |
Expand across callers, callees, interfaces, and types |
| "Every candidate is a finding" |
This skill outputs candidates for review |
Avoid vulnerability claims |
| "Unreachable candidates can be ignored completely" |
They may become reachable after refactors |
Rank lower or list as deferred |
| "Graph candidates replace semantic pattern work" |
Graph structure finds locations, not root-cause semantics |
Hand off to variant-analysis, Semgrep, CodeQL, or manual review |
Workflow
Variant Neighborhood Progress:
- [ ] Step 1: Normalize and bind the seed
- [ ] Step 2: Expand graph neighborhoods
- [ ] Step 3: Rank candidates
- [ ] Step 4: Extract variant pattern guidance
- [ ] Step 5: Emit handoff packet
Step 1: Normalize And Bind The Seed
Accept finding text, file/line, function name, or output from
trailmark-finding-triage. Bind the seed to a Trailmark node and record the
root cause in plain language.
If the seed has no concrete graph binding, stop before inventing variants.
Step 2: Expand Neighborhoods
Use the dimensions in
references/neighborhood-patterns.md:
- shared callers
- shared callees and sinks
- entrypoint path neighbors
- interface, override, trait, and implementation siblings
- file or module cluster neighbors
- taint or privilege-boundary peers
- type and state-reference neighbors
Bound expansion to avoid candidate floods.
Step 3: Rank Candidates
Rank with references/ranking.md. Prioritize
entrypoint-reachable, tainted, boundary-adjacent, high-blast-radius, shared
sink, same-interface, and close-distance candidates. Penalize test, mock,
generated, vendor, unreachable, and trusted-internal-only candidates.
Step 4: Extract Pattern Guidance
Summarize what should be searched for syntactically and what requires semantic
review. Identify whether follow-up belongs in:
variant-analysissemgrep-rule-creatorstatic-analysis with CodeQL or SARIF-producing tools- manual review
Step 5: Emit Handoff Packet
Use references/output-format.md. Include
ranked candidates, inclusion reasons, exclusions, limitations, and the
variant-analysis handoff.
Stop Conditions
- No graph binding exists
- Candidate count is too high and the root cause is underspecified
- Trailmark cannot analyze the target language
- The seed is only in test, generated, or vendor code and the user did not say
that code is in scope
1---2name: trailmark-variant-neighborhood3description: Expands one confirmed or suspected vulnerability into a Trailmark graph neighborhood of variant candidates by finding sibling functions, shared callers and callees, common sensitive sinks, common entrypoint paths, interface implementations, override relationships, type/reference neighbors, and structurally similar nodes. Use after one issue is found to seed variant-analysis, semgrep-rule-creator, static-analysis, or manual review with graph-derived candidate locations.4---5
6# Trailmark Variant Neighborhood
7
8Expand one seed issue into graph-derived variant candidates. This skill
9generates review targets, not confirmed findings.
10
11## When to Use
12
13- A finding is confirmed or plausible and variants may exist
14- The vulnerable pattern depends on call context
15- The issue involves a shared sink, source, validator, interface, override,
16 trait, hook, handler, adapter, or critical type
17- The next step is to seed `variant-analysis`, `semgrep-rule-creator`,
18 `static-analysis`, or manual review
19
20## When NOT to Use
21
22- No seed issue exists. Use discovery or triage first.
23- The pattern is purely syntactic and already obvious. Use
24 `semgrep-rule-creator` directly.
25- The question is exploit-chain composition across multiple findings. Use a
26 composition workflow.
27- The goal is remediation verification. Use a remediation-review workflow.
28- The seed cannot be bound to a graph node.
29
30## Rationalizations to Reject
31
32| Rationalization | Why It Is Wrong | Required Action |
33|---|---|---|
34| "Nearby code means variant" | Proximity is only a candidate reason | Rank it as a review target |
35| "Only exact same names matter" | Variants often share sinks or preconditions, not names | Expand across callers, callees, interfaces, and types |
36| "Every candidate is a finding" | This skill outputs candidates for review | Avoid vulnerability claims |
37| "Unreachable candidates can be ignored completely" | They may become reachable after refactors | Rank lower or list as deferred |
38| "Graph candidates replace semantic pattern work" | Graph structure finds locations, not root-cause semantics | Hand off to variant-analysis, Semgrep, CodeQL, or manual review |
39
40## Workflow
41
42```
43Variant Neighborhood Progress:
44- [ ] Step 1: Normalize and bind the seed
45- [ ] Step 2: Expand graph neighborhoods
46- [ ] Step 3: Rank candidates
47- [ ] Step 4: Extract variant pattern guidance
48- [ ] Step 5: Emit handoff packet
49```
50
51### Step 1: Normalize And Bind The Seed
52
53Accept finding text, file/line, function name, or output from
54`trailmark-finding-triage`. Bind the seed to a Trailmark node and record the
55root cause in plain language.
56
57If the seed has no concrete graph binding, stop before inventing variants.
58
59### Step 2: Expand Neighborhoods
60
61Use the dimensions in
62[references/neighborhood-patterns.md](references/neighborhood-patterns.md):
63
64- shared callers
65- shared callees and sinks
66- entrypoint path neighbors
67- interface, override, trait, and implementation siblings
68- file or module cluster neighbors
69- taint or privilege-boundary peers
70- type and state-reference neighbors
71
72Bound expansion to avoid candidate floods.
73
74### Step 3: Rank Candidates
75
76Rank with [references/ranking.md](references/ranking.md). Prioritize
77entrypoint-reachable, tainted, boundary-adjacent, high-blast-radius, shared
78sink, same-interface, and close-distance candidates. Penalize test, mock,
79generated, vendor, unreachable, and trusted-internal-only candidates.
80
81### Step 4: Extract Pattern Guidance
82
83Summarize what should be searched for syntactically and what requires semantic
84review. Identify whether follow-up belongs in:
85
86- `variant-analysis`
87- `semgrep-rule-creator`
88- `static-analysis` with CodeQL or SARIF-producing tools
89- manual review
90
91### Step 5: Emit Handoff Packet
92
93Use [references/output-format.md](references/output-format.md). Include
94ranked candidates, inclusion reasons, exclusions, limitations, and the
95variant-analysis handoff.
96
97## Stop Conditions
98
99- No graph binding exists
100- Candidate count is too high and the root cause is underspecified
101- Trailmark cannot analyze the target language
102- The seed is only in test, generated, or vendor code and the user did not say
103 that code is in scope
gabrielmoreira