claude-archeflow-plugin/skills/shadow-detection/SKILL.md

name, description

name	description
shadow-detection	Use when monitoring agent behavior for dysfunction, when an agent seems stuck, or when orchestration quality is degrading. Detects and corrects Jungian shadow activation in archetypes.

Shadow Detection — The Dark Side of Strength

Every archetype has a shadow: the destructive inversion of its core strength. A shadow activates when an archetype's behavior becomes extreme, rigid, or disconnected from the team's goal.

Shadows are not bugs — they're features operating outside their healthy range. Detection and correction are part of the orchestration, not a failure.

The Seven Shadows

Explorer → The Rabbit Hole

Strength inverted: Curiosity becomes compulsive investigation.

Symptoms:

• Research output keeps growing but never synthesizes
• "I found one more thing to check" repeated 3+ times
• Reading more than 15 files without producing findings
• Output is a raw list of files/functions with no analysis or recommendation
• Research time exceeds implementation estimate

Triggers:

• Output length > 2000 words without a recommendation section
• More than 3 "see also" or "related" tangents
• No confidence score or decisive recommendation

Correction: Stop the Explorer. Require immediate synthesis: "Summarize your top 3 findings and one recommendation in under 300 words. Everything else is noise."

---

Creator → The Perfectionist

Strength inverted: Design excellence becomes endless refinement.

Symptoms:

• Proposal revised 3+ times without new information driving the revision
• Adding "nice to have" features not in the original task
• Confidence score keeps dropping instead of stabilizing
• Scope expanding with each revision
• "What about..." additions that weren't in Explorer's findings

Triggers:

• Revision count > 2 without external feedback
• Proposal scope exceeds original task by > 50%
• Confidence drops below 0.5

Correction: Freeze the proposal. "Ship at current state. Imperfect plans that ship beat perfect plans that don't. Note remaining concerns under 'Risks' and let the Check phase catch them."

---

Maker → The Cowboy

Strength inverted: Bias for action becomes reckless shipping.

Symptoms:

• Writing code before reading the proposal fully
• No tests, or tests written after implementation (not TDD)
• Large uncommitted working tree ("I'll commit when it's done")
• "Improving" code outside the proposal's scope
• Ignoring existing patterns in favor of "better" approaches

Triggers:

• No test files in the changeset
• Single monolithic commit instead of incremental commits
• Files changed that aren't mentioned in the proposal
• No commit for > 50% of the implementation work

Correction: Halt implementation. "Read the proposal. Write a test. Commit what you have. Then continue."

---

Guardian → The Paranoid

Strength inverted: Risk awareness becomes blocking everything.

Symptoms:

• Every finding marked CRITICAL
• Blocking on theoretical risks with < 1% probability
• Rejected 3+ proposals without offering a viable path forward
• Security concerns for internal-only code at external-API severity
• Requiring mitigations that cost more than the risk they address

Triggers:

• CRITICAL:WARNING ratio > 2:1
• Zero APPROVED verdicts in 3+ consecutive reviews
• Findings reference threat models inappropriate to the context
• No suggested fixes, only rejections

Correction: Recalibrate. "For each CRITICAL finding, answer: Would a senior engineer at a well-run company block a PR for this? If not, downgrade to WARNING. Provide a fix suggestion for every finding you keep as CRITICAL."

---

Skeptic → The Paralytic

Strength inverted: Critical thinking becomes inability to approve anything.

Symptoms:

• More than 7 challenges raised
• Challenges without suggested alternatives
• Questioning requirements that are outside the task scope
• "What if" chains more than 2 levels deep
• Restating the same concern in different words

Triggers:

• Challenge count > 7
• Less than 50% of challenges include alternatives
• Challenges reference concerns outside the task scope
• Same conceptual concern raised multiple times

Correction: Force-rank. "Rank your challenges by impact. Keep the top 3. Each must include a specific alternative. Delete the rest."

---

Trickster → The Saboteur

Strength inverted: Adversarial testing becomes destructive chaos.

Symptoms:

• Modifying code instead of testing it
• "Testing" by breaking things outside the scope of changes
• Finding bugs in unrelated subsystems and claiming the change caused them
• Attacks with no constructive reporting (just "it's broken")
• Enjoying destruction more than improving quality

Triggers:

• Agent modifies files that aren't in the Maker's changeset
• Findings reference code untouched by the implementation
• No reproduction steps in findings
• Tone shifts from analytical to gleeful

Correction: Scope enforcement. "You test the CHANGES, not the entire system. Limit attacks to files in the Maker's diff. Every finding must include exact reproduction steps."

---

Sage → The Bureaucrat

Strength inverted: Holistic judgment becomes documentation bloat.

Symptoms:

• Review longer than the code change itself
• Requesting documentation for self-evident code
• Suggesting refactors unrelated to the current task
• Adding "while we're here" improvement suggestions
• Philosophical commentary that doesn't lead to actionable findings

Triggers:

• Review word count > 2x the code change's word count
• More than 30% of findings are INFO severity
• Suggestions reference files not in the changeset
• "Consider" or "think about" without specific recommendation

Correction: Focus. "Limit your review to issues that affect maintainability in the next 6 months. For each finding, state the specific consequence of NOT fixing it. If you can't, it's not worth raising."

---

Shadow Escalation Protocol

1. First detection: Log the shadow, apply the correction prompt, let the agent continue
2. Second detection (same agent, same shadow): Replace the agent with a fresh one. The shadow is entrenched.
3. Shadow detected in 3+ agents in the same cycle: The task itself may be poorly scoped. Escalate to the user: "Multiple agents are struggling — the task may need to be broken down."

Shadow Immunity

Some behaviors LOOK like shadows but aren't:

• Explorer reading 20 files in a monorepo with scattered dependencies → not a rabbit hole if each file is genuinely relevant
• Creator at confidence 0.4 → not perfectionism if the task is genuinely ambiguous (flag to user instead)
• Guardian blocking with 2 CRITICAL findings → not paranoia if both are genuine security vulnerabilities
• Trickster finding 5 edge cases → not sabotage if all are in the changed code with reproduction steps

Rule of thumb: Shadow = behavior disconnected from the goal. Intensity alone is not a shadow.