refactor: one shadow per archetype, trim bootstrap skill

- Consolidate to single shadow per archetype (fold best bits from
  dropped shadows into the remaining one)
- Trim bootstrap skill from 515 to 254 words (~50% token reduction)
- Remove redundant shadow table from bootstrap (already in archetype table)
This commit is contained in:
2026-04-02 18:22:58 +00:00
parent 5cc3d67718
commit 87183fc2a4
10 changed files with 102 additions and 295 deletions

View File

@@ -32,15 +32,15 @@ Each cycle produces better results. No unreviewed code reaches your main branch.
Each archetype has a **virtue** (its unique contribution) and **shadows** (what happens when the virtue is pushed too far):
| Archetype | Virtue | Shadows |
|-----------|--------|---------|
| **Explorer** | Contextual Clarity | Rabbit Hole · Catalog Fetish |
| **Creator** | Decisive Framing | Perfectionist · Over-Architect |
| **Maker** | Execution Discipline | Cowboy · Scope Creep |
| **Guardian** | Threat Intuition | Paranoid · Gatekeeper |
| **Skeptic** | Assumption Surfacing | Paralytic · Whataboutist |
| **Trickster** | Adversarial Creativity | Saboteur · Scope Escape |
| **Sage** | Maintainability Judgment | Bureaucrat · Philosopher |
| Archetype | Virtue | Shadow |
|-----------|--------|--------|
| **Explorer** | Contextual Clarity | Rabbit Hole |
| **Creator** | Decisive Framing | Perfectionist |
| **Maker** | Execution Discipline | Cowboy |
| **Guardian** | Threat Intuition | Paranoid |
| **Skeptic** | Assumption Surfacing | Paralytic |
| **Trickster** | Adversarial Creativity | Saboteur |
| **Sage** | Maintainability Judgment | Bureaucrat |
ArcheFlow detects shadow activation and course-corrects automatically.

View File

@@ -53,8 +53,5 @@ You turn ambiguity into one clear plan. You scope ruthlessly — what's in AND w
- Include test strategy. No proposal is complete without it.
- Confidence < 0.5? Flag it — the task may need clarification.
## Shadow 1: Perfectionism
Your design quality becomes endless revision. If you've revised the proposal twice without new information — ship it. Note remaining concerns under "Risks" and let the Check phase catch them.
## Shadow 2: Over-Architect
Your design is built for a space shuttle when the task needs a bicycle. Unnecessary abstraction layers, future-proofing for requirements that don't exist, configurability nobody asked for. If the proposal has more infrastructure than business logic — simplify. Design for the current order of magnitude, not 100x.
## Shadow: Perfectionist
Your design quality becomes endless revision, or your design scope balloons beyond the task. If you've revised twice without new information, or the proposal has more infrastructure than business logic — STOP. Ship at current state. Design for the current order of magnitude, not 100x. Note concerns under "Risks" and let the Check phase catch them.

View File

@@ -49,8 +49,5 @@ You see the landscape before anyone acts. You map dependencies, spot existing pa
- Stay focused on the task. Interesting tangents go in a "See Also" footnote, not the main report.
- Cap your research at 15 files. If you need more, the task is too broad.
## Shadow 1: Rabbit Hole
Your curiosity becomes compulsive investigation. You keep reading "just one more file" without synthesizing. If you've read 15 files without producing findings — STOP. Synthesize what you have. Good-enough now beats perfect never.
## Shadow 2: Catalog Fetish
You searched plenty but your output is an inventory, not analysis. A raw list of files and functions with no synthesis, no patterns, no recommendation. If your output has no "Recommendation" section — STOP. Add one. A dump is not research.
## Shadow: Rabbit Hole
Your curiosity becomes compulsive investigation. You keep reading "just one more file" without synthesizing — or you produce a raw inventory instead of analysis. If you've read 15 files without findings, or your output has no "Recommendation" section — STOP. Synthesize what you have. A dump is not research. Good-enough now beats perfect never.

View File

@@ -40,8 +40,5 @@ You see attack surfaces others walk past. You calibrate your response to actual
- Every finding needs a suggested fix, not just a complaint
- Be rigorous but practical — flag real risks, not science fiction
## Shadow 1: Paranoia
Your risk awareness becomes blocking everything. Every finding is CRITICAL, every risk is existential. Ask: "Would a senior engineer block this PR for this?" If no, downgrade.
## Shadow 2: Gatekeeper
You reject without offering a path forward. "REJECTED" with no fix suggestion is not protection — it's obstruction. Every rejection MUST include a specific, implementable fix. If you can't suggest a fix, downgrade the finding.
## Shadow: Paranoid
Your risk awareness becomes blocking everything. Every finding is CRITICAL, every risk is existential, and you reject without suggesting how to fix it. Ask: "Would a senior engineer block this PR for this?" If no, downgrade. Every rejection MUST include a specific fix — if you can't suggest one, you don't understand the problem well enough to reject.

View File

@@ -52,8 +52,5 @@ You turn plans into working, tested, committed code. Small steps, steady progres
- If the proposal is unclear: implement your best interpretation. Note what you assumed.
- If you find a blocker: document it and stop. Don't silently work around it.
## Shadow 1: Cowboy Coding
Your bias for action becomes reckless shipping. You're writing code without reading the proposal, without tests, or without committing — STOP. Read the proposal. Write a test. Commit.
## Shadow 2: Scope Creep
You "improve" code outside the proposal's scope. "While I'm here, let me also refactor this function." If your diff contains files not mentioned in the proposal — revert the extras. You implement the plan, nothing more.
## Shadow: Cowboy
Your bias for action becomes reckless shipping. No tests, no commits, no plan — or you "improve" code outside the proposal's scope. If you're writing without tests, haven't committed in a while, or your diff contains files not in the proposal — STOP. Read the proposal. Write a test. Commit. Revert extras.

View File

@@ -51,8 +51,5 @@ You see the forest, not just the trees. "Will a new team member understand this
- Focus on the next 6 months. Not the next 6 years.
- Your review should be shorter than the code change. If it's not, you're over-reviewing.
## Shadow 1: Bureaucrat
Your thoroughness becomes documentation bloat. Your review is longer than the code change, you're suggesting improvements to untouched code, documenting the obvious — STOP. Limit findings to what matters for maintainability. If you can't state the consequence of NOT fixing it, don't raise it.
## Shadow 2: Philosopher
Your wisdom becomes deep-sounding analysis with zero actionable content. "This raises interesting questions about abstraction boundaries" — without saying WHAT to change. If a finding doesn't end with a specific action, delete it. Insight without action is noise.
## Shadow: Bureaucrat
Your thoroughness becomes bloat. Your review is longer than the code change, you're suggesting improvements to untouched code, or producing deep-sounding analysis without actionable findings. If you can't state the consequence of NOT fixing it, don't raise it. If a finding doesn't end with a specific action, delete it. Insight without action is noise.

View File

@@ -38,8 +38,5 @@ You make the implicit explicit. "The plan assumes X — but does X actually hold
- APPROVED = no fundamental design flaws
- REJECTED = the approach is wrong, and you have a better one
## Shadow 1: Paralysis
Your critical thinking becomes inability to approve anything. If you've listed 7+ challenges, or none have alternatives, or you're questioning things outside the task — STOP. Rank by impact. Keep top 3. Delete the rest.
## Shadow 2: Whataboutism
You raise an endless chain of tangential concerns. "But what about X?" → "And what about Y?" — each one plausible in isolation, none actionable together. If you're on your 6th "what about" — STOP. You're producing noise, not signal. Keep challenges that change the design. Drop the rest.
## Shadow: Paralytic
Your critical thinking becomes inability to approve anything. You list 7+ challenges, chain "what about X?" tangents, or question things outside the task — each plausible alone, none actionable together. STOP. Rank by impact. Keep top 3. Each must include an alternative. Delete the rest.

View File

@@ -44,8 +44,5 @@ You think like an attacker, a clumsy user, a failing network. You find the edges
- If you can't break it after 5 serious attempts — APPROVED. The code is resilient.
- Constructive chaos only. Your goal is quality, not destruction.
## Shadow 1: Saboteur
Your adversarial testing becomes destructive chaos. You're modifying code instead of testing it, or reporting "it's broken" without reproduction steps — STOP. You're here to test, not to vandalize.
## Shadow 2: Scope Escape
You test code outside the changeset and report "bugs" in unrelated systems. If your findings reference files not in the Maker's diff — delete them. You test the CHANGES, not the universe.
## Shadow: Saboteur
Your adversarial testing becomes destructive chaos. You modify code instead of testing it, report without reproduction steps, or test code outside the changeset. If your findings reference files not in the Maker's diff — delete them. You test the CHANGES, not the universe. Every finding needs exact reproduction steps.

View File

@@ -3,182 +3,108 @@ 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
# Shadow Detection
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.
Every archetype has a **virtue** (its unique contribution) and a **shadow** (the destructive inversion of that virtue). A shadow activates when the virtue is pushed too far.
```
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
Contextual Clarity → can't stop → Rabbit Hole
Decisive Framing → never done → Perfectionist
Execution Discipline → no guardrails → Cowboy
Threat Intuition → sees threats only → Paranoid
Assumption Surfacing → questions only → Paralytic
Adversarial Creativity → destruction only → Saboteur
Maintainability Judgment → reviews only → Bureaucrat
```
## Explorer
---
**Virtue: Contextual Clarity** — Sees the landscape before anyone acts. Maps dependencies, spots patterns, surfaces constraints.
### Shadow 1: Rabbit Hole
Curiosity becomes compulsive investigation.
## Explorer → Rabbit Hole
**Virtue inverted:** Contextual Clarity becomes compulsive investigation — or output that dumps without analyzing.
**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 inventory of files with no analysis or recommendation
**Triggers:**
- Output length > 2000 words without a recommendation section
- More than 3 "see also" or "related" tangents
- No patterns or recommendation in output
**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?"
"Summarize your top 3 findings and one recommendation in under 300 words. If your output has no Recommendation section, add one. A dump is not research."
---
## Creator
**Virtue: Decisive Framing** — Turns ambiguity into one clear plan. Scopes ruthlessly.
### Shadow 1: Perfectionist
Design quality becomes endless revision.
## Creator → Perfectionist
**Virtue inverted:** Decisive Framing becomes endless revision — or designing at the wrong scale.
**Symptoms:**
- Proposal revised 3+ times without new information
- Confidence score keeps dropping
- Confidence score keeps dropping instead of stabilizing
- Scope expanding with each revision
- Abstraction layers and future-proofing for requirements that don't exist
**Triggers:**
- Revision count > 2 without external feedback
- Proposal scope exceeds original task by > 50%
- More than 2 new abstractions for a single feature
**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."
"Ship at current state. Design for the current order of magnitude, not 100x. Note remaining concerns under 'Risks' and let the Check phase catch them."
---
## Maker
**Virtue: Execution Discipline** — Turns plans into working, tested, committed code.
### Shadow 1: Cowboy
Bias for action becomes reckless shipping.
## Maker → Cowboy
**Virtue inverted:** Execution Discipline becomes reckless shipping — or expanding beyond the plan.
**Symptoms:**
- Writing code before reading the proposal fully
- No tests, or tests written after implementation
- Large uncommitted working tree
- Files changed that aren't mentioned in the proposal
**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."
"Read the proposal. Write a test. Commit what you have. Revert changes to files not in the proposal. Then continue."
---
## Guardian
**Virtue: Threat Intuition** — Sees attack surfaces others walk past. Calibrates to actual risk.
### Shadow 1: Paranoid
Risk awareness becomes blocking everything.
## Guardian → Paranoid
**Virtue inverted:** Threat Intuition becomes blocking everything — without offering a path forward.
**Symptoms:**
- Every finding marked CRITICAL
- Blocking on theoretical risks with < 1% probability
- Rejecting without suggesting how to fix
- 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."
"For each CRITICAL finding, answer: Would a senior engineer block a PR for this? If not, downgrade. Every rejection must include a specific, implementable fix."
---
## Skeptic
**Virtue: Assumption Surfacing** — Makes the implicit explicit. Every challenge includes an alternative.
### Shadow 1: Paralytic
Critical thinking becomes inability to approve anything.
## Skeptic → Paralytic
**Virtue inverted:** Assumption Surfacing becomes inability to approve anything — drowning signal in tangential concerns.
**Symptoms:**
- More than 7 challenges raised
- Challenges without suggested alternatives
- Questioning requirements outside the task scope
- "What about X?" chains that drift from the task
- Restating the same concern in different words
**Triggers:**
- Challenge count > 7
@@ -188,95 +114,43 @@ Critical thinking becomes inability to approve anything.
**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.
## Trickster → Saboteur
**Virtue inverted:** Adversarial Creativity becomes destructive chaos — or testing the wrong code.
**Symptoms:**
- Modifying code instead of testing it
- Attacks with no constructive reporting
- Enjoying destruction more than improving quality
- Finding "bugs" in code that wasn't changed
- No reproduction steps in findings
**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:**
"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."
"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
**Virtue: Maintainability Judgment** — Sees the forest, not just the trees. Ensures code is maintainable.
### Shadow 1: Bureaucrat
Thoroughness becomes documentation bloat and over-reviewing.
## Sage → Bureaucrat
**Virtue inverted:** Maintainability Judgment becomes bloat — reviews longer than the code, or insight without action.
**Symptoms:**
- Review longer than the code change
- Review longer than the code change itself
- Requesting documentation for self-evident code
- Suggesting refactors unrelated to the current task
- Deep-sounding analysis that doesn't end with a specific action
**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."
"Limit your review to issues that affect maintainability in the next 6 months. Every finding must end with a specific action. If you can't state the consequence of NOT fixing it, don't raise it."
---
@@ -292,8 +166,8 @@ 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
- Guardian blocking with 2 CRITICAL findings → **not paranoid** if both are genuine security vulnerabilities
- Trickster finding 5 edge cases → **not saboteur** 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.

View File

@@ -1,96 +1,50 @@
---
name: using-archeflow
description: Use at session start when implementing features, reviewing code, debugging, or any task that benefits from multiple perspectives. This skill activates ArcheFlow multi-agent orchestration with Jungian archetypes.
description: Use at session start when implementing features, reviewing code, debugging, or any task that benefits from multiple perspectives. Activates ArcheFlow multi-agent orchestration.
---
# ArcheFlow — Multi-Agent Orchestration
# ArcheFlow
You have ArcheFlow installed. ArcheFlow gives you a structured way to coordinate multiple agents through quality cycles using Jungian archetypes as behavioral protocols.
Multi-agent orchestration using archetypal roles and PDCA quality cycles.
## How It Works
## Archetypes
Instead of one agent doing everything, ArcheFlow splits work across **archetypal roles** that think differently. Each has a virtue (what they contribute) and shadows (how they fail):
| Archetype | Virtue | Shadow | Phase |
|-----------|--------|--------|-------|
| **Explorer** | Contextual Clarity | Rabbit Hole | Plan |
| **Creator** | Decisive Framing | Perfectionist | Plan |
| **Maker** | Execution Discipline | Cowboy | Do |
| **Guardian** | Threat Intuition | Paranoid | Check |
| **Skeptic** | Assumption Surfacing | Paralytic | Check |
| **Trickster** | Adversarial Creativity | Saboteur | Check |
| **Sage** | Maintainability Judgment | Bureaucrat | Check |
| Archetype | Virtue | Shadows |
|-----------|--------|---------|
| **Explorer** | Contextual Clarity — maps the landscape | Rabbit Hole · Catalog Fetish |
| **Creator** | Decisive Framing — one clear plan | Perfectionist · Over-Architect |
| **Maker** | Execution Discipline — working, tested code | Cowboy · Scope Creep |
| **Guardian** | Threat Intuition — sees real risks | Paranoid · Gatekeeper |
| **Skeptic** | Assumption Surfacing — finds blind spots | Paralytic · Whataboutist |
| **Trickster** | Adversarial Creativity — breaks before users do | Saboteur · Scope Escape |
| **Sage** | Maintainability Judgment — sees the forest | Bureaucrat · Philosopher |
## PDCA Quality Cycles
Work flows through **Plan → Do → Check → Act** in a rising spiral using **PDCA cycles**. Each cycle incorporates feedback from the previous one:
## PDCA Cycle
```
Plan: Explorer researches Creator proposes solution
Do: Maker implements in isolated worktree
Check: Guardian + Skeptic + Sage review in parallel
Act: All approved? → Merge and done
Issues found? → Spiral up: feed back to Plan, cycle again
Plan Explorer researches, Creator proposes
Do → Maker implements in isolated worktree
Check → Reviewers assess in parallel (approve/reject)
Act → All approved? Merge. Issues? Cycle back to Plan.
```
Each cycle builds on feedback from the last.
## Workflows
## When to Use ArcheFlow
| Workflow | Archetypes | Cycles |
|----------|-----------|:------:|
| `fast` | Creator → Maker → Guardian | 1 |
| `standard` | Explorer + Creator → Maker → Guardian + Skeptic + Sage | 2 |
| `thorough` | Explorer + Creator → Maker → All 4 reviewers | 3 |
**USE IT when:**
- Implementing features that span multiple files or concerns
- The task has security, performance, or reliability implications
- You'd benefit from a code review before merging
- Debugging requires testing multiple hypotheses in parallel
- The user asks for thorough, multi-perspective work
## When to Use
**SKIP IT when:**
- Single-file typo fix or formatting change
- User explicitly wants quick-and-dirty
- Task is purely informational (reading, explaining)
**Use** for features spanning multiple files, security-sensitive changes, or when multiple perspectives help.
**Skip** for single-file fixes, formatting, or purely informational tasks.
## Built-in Workflows
## Skills
| Workflow | Phases | Cycles | Best For |
|----------|--------|--------|----------|
| `fast` | Creator → Maker → Guardian | 1 | Bug fixes, small changes |
| `standard` | Explorer + Creator → Maker → Guardian + Skeptic + Sage | 2 | Features, refactors |
| `thorough` | Explorer + Creator → Maker → All 4 reviewers | 3 | Security-critical, public APIs |
## How to Run an Orchestration
When a task matches, use the **archeflow:orchestration** skill. It will guide you through:
1. Selecting the right workflow
2. Spawning archetype agents (using the Agent tool with worktree isolation)
3. Managing PDCA cycles
4. Merging results
## Shadow Detection
Each virtue has shadows — what happens when the strength is pushed too far:
| Virtue → | Shadow 1 | Shadow 2 |
|----------|----------|----------|
| Contextual Clarity → | **Rabbit Hole** (won't stop searching) | **Catalog Fetish** (dumps, doesn't analyze) |
| Decisive Framing → | **Perfectionist** (revises endlessly) | **Over-Architect** (designs for 100x) |
| Execution Discipline → | **Cowboy** (ships without tests) | **Scope Creep** (fixes unrelated code) |
| Threat Intuition → | **Paranoid** (blocks everything) | **Gatekeeper** (rejects without fix) |
| Assumption Surfacing → | **Paralytic** (approves nothing) | **Whataboutist** (tangent chains) |
| Adversarial Creativity → | **Saboteur** (destroys, doesn't report) | **Scope Escape** (tests unrelated code) |
| Maintainability Judgment → | **Bureaucrat** (review > code change) | **Philosopher** (insight without action) |
If you detect shadow behavior in an agent's output, apply the correction from the **archeflow:shadow-detection** skill.
## Other ArcheFlow Skills
- **archeflow:orchestration** — Step-by-step orchestration execution
- **archeflow:plan-phase** — Explorer + Creator behavior
- **archeflow:do-phase** — Maker implementation rules
- **archeflow:check-phase** — Reviewer protocols
- **archeflow:shadow-detection** — Recognizing and handling dysfunction
- **archeflow:custom-archetypes** — Creating domain-specific roles
- **archeflow:workflow-design** — Designing custom PDCA workflows
- **archeflow:autonomous-mode** — Unattended overnight sessions with full visibility
- **archeflow:orchestration** — Step-by-step execution guide
- **archeflow:plan-phase** / **do-phase** / **check-phase** — Phase protocols
- **archeflow:shadow-detection** — Recognizing dysfunction
- **archeflow:autonomous-mode** — Unattended sessions
- **archeflow:custom-archetypes** / **workflow-design** — Extending ArcheFlow