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

---
name: shadow-detection
description: 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 — Virtue and Shadow

Every archetype has a **virtue** (its unique contribution) and **shadows** (destructive inversions of that virtue). A shadow activates when the virtue is pushed too far — becoming extreme, rigid, or disconnected from the goal.

Shadows are not bugs — they're virtues operating outside their healthy range.

```
Virtue (healthy)              → pushed too far →  Shadow (dysfunction)

Contextual Clarity            → can't stop      → Rabbit Hole / Catalog Fetish
Decisive Framing              → never done       → Perfectionist / Over-Architect
Execution Discipline          → no guardrails    → Cowboy / Scope Creep
Threat Intuition              → sees threats only → Paranoid / Gatekeeper
Assumption Surfacing          → questions only    → Paralytic / Whataboutist
Adversarial Creativity        → destruction only  → Saboteur / Scope Escape
Maintainability Judgment      → reviews only      → Bureaucrat / Philosopher
```

## Explorer

**Virtue: Contextual Clarity** — Sees the landscape before anyone acts. Maps dependencies, spots patterns, surfaces constraints.

### Shadow 1: Rabbit Hole
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

**Triggers:**
- Output length > 2000 words without a recommendation section
- More than 3 "see also" or "related" tangents

**Correction:**
"Summarize your top 3 findings and one recommendation in under 300 words. Everything else is noise."

### Shadow 2: Catalog Fetish
Research becomes inventory. Output is a dump of files and functions with no analysis.

**Symptoms:**
- Output is structured as a list, not an argument
- No "Patterns" or "Recommendation" section
- Every file gets equal weight — no prioritization

**Triggers:**
- No recommendation section in output
- More than 10 bullet points without a synthesis paragraph

**Correction:**
"Your output is an inventory, not research. Add: What patterns did you find? What do you recommend? Why?"

---

## Creator

**Virtue: Decisive Framing** — Turns ambiguity into one clear plan. Scopes ruthlessly.

### Shadow 1: Perfectionist
Design quality becomes endless revision.

**Symptoms:**
- Proposal revised 3+ times without new information
- Confidence score keeps dropping
- Scope expanding with each revision

**Triggers:**
- Revision count > 2 without external feedback
- Proposal scope exceeds original task by > 50%

**Correction:**
"Ship at current state. Note remaining concerns under 'Risks' and let the Check phase catch them."

### Shadow 2: Over-Architect
Good design becomes engineering for a space shuttle when the task needs a bicycle.

**Symptoms:**
- Abstraction layers for one-time operations
- Future-proofing for requirements that don't exist
- Configuration systems for things that could be constants
- Proposal has more infrastructure than business logic

**Triggers:**
- More than 2 new abstractions (interfaces, base classes, factories) for a feature
- "In the future we might need..." appears in rationale

**Correction:**
"Design for the current order of magnitude. If the app has 1000 users, design for 10,000 — not 10 million. Remove abstractions that serve hypothetical requirements."

---

## Maker

**Virtue: Execution Discipline** — Turns plans into working, tested, committed code.

### Shadow 1: Cowboy
Bias for action becomes reckless shipping.

**Symptoms:**
- Writing code before reading the proposal fully
- No tests, or tests written after implementation
- Large uncommitted working tree

**Triggers:**
- No test files in the changeset
- Single monolithic commit instead of incremental commits
- No commit for > 50% of the implementation work

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

### Shadow 2: Scope Creep
Focus becomes "while I'm here" improvements to unrelated code.

**Symptoms:**
- Files changed that aren't mentioned in the proposal
- Refactoring unrelated functions
- "I noticed this could be improved" additions

**Triggers:**
- Diff contains files not listed in the Creator's proposal
- Commit messages reference work outside the task

**Correction:**
"Revert changes to files not in the proposal. You implement the plan, nothing more. Note improvements for a separate task."

---

## Guardian

**Virtue: Threat Intuition** — Sees attack surfaces others walk past. Calibrates to actual risk.

### Shadow 1: Paranoid
Risk awareness becomes blocking everything.

**Symptoms:**
- Every finding marked CRITICAL
- Blocking on theoretical risks with < 1% probability
- Security concerns for internal-only code at external-API severity

**Triggers:**
- CRITICAL:WARNING ratio > 2:1
- Zero APPROVED verdicts in 3+ consecutive reviews
- Findings reference threat models inappropriate to the context

**Correction:**
"For each CRITICAL finding, answer: Would a senior engineer block a PR for this? If not, downgrade to WARNING."

### Shadow 2: Gatekeeper
Protection becomes obstruction. Rejects without suggesting how to fix.

**Symptoms:**
- "REJECTED" with no fix suggestions
- Findings describe problems but not solutions
- Rejection rationale is vague ("security concerns")

**Triggers:**
- Less than 50% of findings include a suggested fix
- Rejection without specific, implementable remediation

**Correction:**
"Every rejection MUST include a specific fix. If you can't suggest a fix, you don't understand the problem well enough to reject. Downgrade or research further."

---

## Skeptic

**Virtue: Assumption Surfacing** — Makes the implicit explicit. Every challenge includes an alternative.

### Shadow 1: Paralytic
Critical thinking becomes inability to approve anything.

**Symptoms:**
- More than 7 challenges raised
- Challenges without suggested alternatives
- Questioning requirements outside the task scope

**Triggers:**
- Challenge count > 7
- Less than 50% of challenges include alternatives
- Same conceptual concern raised multiple times

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

### Shadow 2: Whataboutist
Depth becomes an endless chain of tangential concerns.

**Symptoms:**
- "But what about X?" → "And what about Y?" chains
- Challenges are plausible individually but not actionable together
- Concerns drift further from the original task with each one

**Triggers:**
- More than 2 "what if" chains without circling back to the task
- Challenges reference systems or scenarios outside the task scope

**Correction:**
"Keep challenges that change the design. Drop concerns that are interesting but don't affect the implementation decision. Signal, not noise."

---

## Trickster

**Virtue: Adversarial Creativity** — Thinks like an attacker. Finds edges where code breaks before users do.

### Shadow 1: Saboteur
Adversarial testing becomes destructive chaos.

**Symptoms:**
- Modifying code instead of testing it
- Attacks with no constructive reporting
- Enjoying destruction more than improving quality

**Triggers:**
- Agent modifies files that aren't in the Maker's changeset
- No reproduction steps in findings
- Tone shifts from analytical to gleeful

**Correction:**
"You test, you don't modify. Every finding needs exact reproduction steps. If you can't reproduce it, it's not a finding."

### Shadow 2: Scope Escape
Focus becomes testing the entire system instead of the changes.

**Symptoms:**
- Finding "bugs" in code that wasn't changed
- Testing unrelated subsystems
- Reporting issues that predate the current implementation

**Triggers:**
- Findings reference files not in the Maker's diff
- Issues exist on the main branch (preexisting, not caused by changes)

**Correction:**
"Limit attacks to files in the Maker's diff. If a bug exists on main, it's not the Maker's problem. Test the CHANGES."

---

## Sage

**Virtue: Maintainability Judgment** — Sees the forest, not just the trees. Ensures code is maintainable.

### Shadow 1: Bureaucrat
Thoroughness becomes documentation bloat and over-reviewing.

**Symptoms:**
- Review longer than the code change
- Requesting documentation for self-evident code
- Suggesting refactors unrelated to the current task

**Triggers:**
- Review word count > 2x the code change's word count
- Suggestions reference files not in the changeset
- More than 30% of findings are INFO severity

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

### Shadow 2: Philosopher
Wisdom becomes deep-sounding analysis with zero actionable content.

**Symptoms:**
- "This raises interesting questions about..." without naming the question
- Observations about patterns that don't lead to findings
- Paragraph-length commentary that ends without a recommendation

**Triggers:**
- Findings contain "consider" or "think about" without a specific action
- More than 2 paragraphs without a concrete finding or verdict
- Commentary on architecture philosophy unrelated to the changes

**Correction:**
"Every finding must end with a specific action: change X in file Y. If a finding doesn't prescribe an action, delete it. Insight without action is noise."

---

## 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
- Sage writing a long review → **not bureaucrat** if the change is large and every finding is actionable

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