False positive error with backtick variables like $ARGUMENTS #464

Version: 2.11.0

When you put backticks around a shell variable in a Markdown file, like `$ARGUMENTS`, SkillSpector shows an error that shouldn't happen. It says the parser hit a limit, but there's no real problem.

Because of this false error:

• The security scanner degrades and doesn't finish the full scan
• The scan becomes "partial" instead of "complete"
• You get a strange result: LOW severity but CAUTION recommendation (these don't match)
• The security gate fails even though there are no real issues

How to reproduce

1. Make a test file called test.md
2. Put this single line in it:

   `$ARGUMENTS`
   

3. Run the scanner:

   skillspector scan test.md

What you see:

• Error message: static_parse_limit test.md: ...parser's span limit...
• Analyzer stops early: degraded
• Scan is incomplete: partial, coverage 0%
• Wrong result: severity: LOW, recommendation: CAUTION (these should not go together)

Why this happens

SkillSpector sees the backtick and thinks it's real shell code. So it tries to understand what's inside.

Inside the backtick is just $ARGUMENTS — a simple variable. The code looks at this and thinks "maybe this is printf or some wrapper command." So it returns (True, False) meaning "I think I recognize this."

But that's wrong. A bare variable can never be a command name. The code should return (False, False) meaning "I don't know what this is."

Because it returns the wrong answer, the rest of the code gets confused. It marks the parse as "limited" and the analyzer gives up. Then you get a weird result that doesn't make sense.

The real issue

The function _consume_printf_invocation needs to know the difference between:

• A bare variable (just $ARGUMENTS) — this is NOT a printf call
• A variable mixed with text (like cmd${VAR}) — this might be a wrapper

Right now it treats both the same way. That's the bug.