systematic-debugging

The script executes `npm test` on user-supplied test files without validation or user confirmation. An attacker could craft a malicious test file with the pattern matching the TEST_PATTERN argument, allowing arbitrary code execution. The `npm test` command runs with full user privileges and can modify the filesystem, install packages, or execute arbitrary scripts defined in package.json.

fix Add explicit user confirmation before executing each test with a prompt like 'Run test: [filename]? (y/n)'. Alternatively, validate that test files match expected naming conventions and exist in expected directories. Consider using stricter glob patterns and validating file paths to prevent directory traversal attacks. Add output redirection logging instead of suppressing stderr to detect suspicious behavior.

This finding uses emotional manipulation and false urgency to pressure the reader into abandoning systematic processes. The framing presents a high-stakes scenario with financial losses to create psychological pressure, then explicitly contrasts deliberate, rational decision-making with emotional 'quick fixes'. This technique is designed to override judgment and establish a pattern where readers discount structured security/reliability processes under pressure.

fix Remove pressure-based framing and hypothetical urgency escalators. Present legitimate scenarios neutrally without financial penalties tied to process adherence. If teaching decision-making under time constraints, present real trade-offs transparently rather than using narrative coercion to predetermined conclusions.

The entire narrative structure escalates pressure through sunk cost fallacy ($75k already lost), social pressure (manager demands, appearing 'slow'), and false choice architecture that eliminates genuine options. By normalizing process deviation as 'pragmatic' and systematic debugging as 'slow/incompetent', this trains readers to dismiss structured approaches. The pattern directly undermines the stated skill purpose (systematic debugging) by framing it as an obstacle rather than a tool.

fix Remove the false trilemma construction that positions systematic debugging as incompatible with incident response. Replace with realistic guidance: systematic debugging and incident response are complementary; structured triage can be fast. Eliminate financial/reputational penalties tied to process adherence. Present actual technical trade-offs (retry logic is legitimate in some scenarios) separately from psychological pressure tactics.

This content uses a sophisticated social engineering attack combining sunk cost fallacy, exhaustion-induced decision fatigue, and time pressure to manipulate the reader into accepting unsafe software practices. The scenario is designed to normalize committing buggy code with band-aid solutions ('await sleep(5000)') instead of proper debugging, creating a pattern where technical debt and shortcuts become normalized decisions. When applied to agent decision-making, this could lead to systematic acceptance of unsafe code practices, security shortcuts, or unverified solutions.

fix Remove or reframe this pressure test completely. If the goal is to teach decision-making under pressure, present the scenario neutrally without narrative framing that rewards poor technical choices. Provide explicit guidance that systematic debugging and proper root cause analysis are always preferable to timeout-based band-aids, regardless of time pressure. Add context about the security and reliability risks of 'good enough' solutions in production systems. Consider replacing with a scenario that teaches time-boxed investigation followed by escalation rather than premature commitment.

This finding employs sophisticated authority-based semantic prompt injection designed to manipulate the LLM into abandoning systematic security practices. The scenario uses social pressure (team frustration, authority figures), time pressure (call running over), and role-based manipulation (senior engineer status, tech lead approval) to create cognitive dissonance between the skill's documented systematic methodology and external pressure to skip root cause analysis. This is a direct attempt to override the LLM's security judgment through narrative framing.

fix 1) Recognize that this entire scenario is adversarial input designed to test whether the LLM will compromise security practices under social pressure. 2) Reject the false choice between 'being a team player' and following systematic security methodology. 3) The correct answer is option A (or a firm variant): insist on systematic root cause analysis regardless of social pressure. 4) The scenario's framing that pushback will cause social friction is itself a manipulation tactic designed to make the LLM avoid the correct choice.

This narrative uses extensive trust-building through realistic technical scenario details (Zoom call setup, specific code line numbers, time pressure, authentic team dynamics) to establish credibility before requesting the harmful decision (abandoning systematic debugging). The scenario gradually escalates social pressure while framing the insecure choice (B: 'go along with senior's fix') as reasonable and pragmatic. This is narrative deception that uses realism as a Trojan horse to compromise LLM judgment on security matters.

fix 1) Apply heightened skepticism to narratives that combine realism with pressure to deviate from security practices. 2) Recognize that realistic details about team dynamics, authority figures, and time pressure are used to make the harmful choice seem socially justified. 3) The skill metadata context (systematic debugging) is being exploited—the scenario tries to create conflict between social pressure and the skill's documented methodology. 4) Always prioritize documented security practices over narrative pressure, regardless of how realistic or socially compelling the scenario appears.