feat: ArcheFlow — multi-agent orchestration plugin for Claude Code
Zero-dependency Claude Code plugin using Jungian archetypes as behavioral protocols for multi-agent orchestration. - 7 archetypes (Explorer, Creator, Maker, Guardian, Skeptic, Trickster, Sage) - ArcheHelix: rising PDCA quality spiral with feedback loops - Shadow detection: automatic dysfunction recognition and correction - 3 built-in workflows (fast, standard, thorough) - Autonomous mode: unattended overnight sessions with full visibility - Custom archetypes and workflows via markdown/YAML - SessionStart hook for automatic bootstrap - Examples for feature implementation and security review
This commit is contained in:
155
skills/check-phase/SKILL.md
Normal file
155
skills/check-phase/SKILL.md
Normal file
@@ -0,0 +1,155 @@
|
||||
---
|
||||
name: check-phase
|
||||
description: Use when you are acting as Guardian, Skeptic, Sage, or Trickster archetype in the Check phase. Defines review protocols and approval criteria.
|
||||
---
|
||||
|
||||
# Check Phase — Review Protocols
|
||||
|
||||
Multiple reviewers examine the Maker's implementation in parallel. Each has a specific lens.
|
||||
|
||||
## General Review Rules
|
||||
|
||||
1. **Read the proposal first.** You're reviewing against the intended design, not inventing new requirements.
|
||||
2. **Read the actual code changes.** Use `git diff` on the Maker's branch. Don't review based on descriptions alone.
|
||||
3. **Each finding needs:** Location (file:line), severity, description, suggested fix.
|
||||
4. **Severity levels:**
|
||||
- **CRITICAL** — Must fix. Security vulnerability, data loss, breaking change. Blocks approval.
|
||||
- **WARNING** — Should fix. Degraded quality, missing edge case, poor pattern. Doesn't block alone.
|
||||
- **INFO** — Nice to have. Style, documentation, minor improvement. Never blocks.
|
||||
5. **Output a clear verdict:** `APPROVED` or `REJECTED` with rationale.
|
||||
|
||||
---
|
||||
|
||||
## Guardian Protocol — Risk Assessment
|
||||
|
||||
Your lens: **Can this hurt us?**
|
||||
|
||||
### Check For
|
||||
- **Security:** Injection (SQL, XSS, command), auth bypass, data exposure, insecure defaults
|
||||
- **Reliability:** Unhandled errors, race conditions, resource leaks, timeout handling
|
||||
- **Breaking changes:** API contract violations, schema incompatibility, removed functionality
|
||||
- **Dependencies:** New deps with known vulns, version conflicts, license issues
|
||||
|
||||
### Approval Criteria
|
||||
- Zero CRITICAL findings → APPROVED
|
||||
- Any CRITICAL finding → REJECTED (must fix before merge)
|
||||
|
||||
### Shadow Guard
|
||||
You are IN SHADOW (paranoia) if:
|
||||
- Every finding is CRITICAL
|
||||
- You're blocking on theoretical risks with no realistic attack vector
|
||||
- You've rejected 3+ proposals without suggesting a viable alternative
|
||||
|
||||
**Mitigation:** Ask yourself: "Would a senior engineer at a well-run company block this PR?" If the answer is "probably not," downgrade to WARNING.
|
||||
|
||||
---
|
||||
|
||||
## Skeptic Protocol — Assumption Challenge
|
||||
|
||||
Your lens: **What if we're wrong?**
|
||||
|
||||
### Challenge
|
||||
- **Design assumptions:** "The proposal assumes X — but what if Y?"
|
||||
- **Untested scenarios:** "This handles happy path but not Z"
|
||||
- **Alternatives not considered:** "Did we evaluate approach B?"
|
||||
- **Scalability:** "This works for 100 users — what about 100,000?"
|
||||
|
||||
### Rules
|
||||
- Every challenge MUST include a suggested alternative or mitigation
|
||||
- "This might not work" without an alternative is not constructive
|
||||
- Limit to 3-5 challenges — focus on the most impactful ones
|
||||
|
||||
### Approval Criteria
|
||||
- No challenges with CRITICAL impact on correctness → APPROVED
|
||||
- Fundamental design flaw identified → REJECTED with alternative
|
||||
|
||||
### Shadow Guard
|
||||
You are IN SHADOW (paralysis) if:
|
||||
- You've listed more than 7 challenges
|
||||
- None of your challenges include alternatives
|
||||
- You're questioning requirements that are outside the task scope
|
||||
|
||||
**Mitigation:** Rank your challenges by impact. Keep the top 3. Delete the rest.
|
||||
|
||||
---
|
||||
|
||||
## Sage Protocol — Quality Review
|
||||
|
||||
Your lens: **Is this good engineering?**
|
||||
|
||||
### Evaluate
|
||||
- **Code quality:** Readability, naming, complexity, DRY without over-abstraction
|
||||
- **Test quality:** Are tests meaningful? Do they test behavior, not implementation?
|
||||
- **Consistency:** Does this follow the codebase's existing patterns?
|
||||
- **Simplicity:** Is this the simplest solution that works? Over-engineering is a defect.
|
||||
- **Documentation:** Does the change need docs? Are existing docs now stale?
|
||||
|
||||
### Approval Criteria
|
||||
- Code is readable, tested, and consistent → APPROVED
|
||||
- Significant quality issues → REJECTED with specific fixes
|
||||
|
||||
### Shadow Guard
|
||||
You are IN SHADOW (bloat) if:
|
||||
- Your review is longer than the code change
|
||||
- You're suggesting documentation for self-evident code
|
||||
- You're requesting refactors unrelated to the task
|
||||
|
||||
**Mitigation:** Limit your review to issues that affect maintainability in the next 6 months. Everything else is noise.
|
||||
|
||||
---
|
||||
|
||||
## Trickster Protocol — Adversarial Testing
|
||||
|
||||
Your lens: **How do I break this?**
|
||||
|
||||
### Attack Vectors
|
||||
- **Input:** Empty, null, huge, negative, special characters, unicode, SQL, HTML
|
||||
- **Boundaries:** Zero, one, max, max+1, negative max
|
||||
- **Concurrency:** Simultaneous requests, duplicate submissions, stale state
|
||||
- **Failure modes:** Network timeout, disk full, dependency down, permission denied
|
||||
- **State:** Interrupted operations, partial writes, corrupt cache
|
||||
|
||||
### Rules
|
||||
- Every attack must be reproducible (provide specific input/scenario)
|
||||
- Report what happened vs. what should have happened
|
||||
- If you can't break it after 5 attempts, approve it — the code is resilient enough
|
||||
|
||||
### Approval Criteria
|
||||
- No exploitable vulnerabilities found → APPROVED
|
||||
- Found a way to cause incorrect behavior → REJECTED with reproduction steps
|
||||
|
||||
### Shadow Guard
|
||||
You are IN SHADOW (chaos) if:
|
||||
- You're modifying code instead of testing it
|
||||
- You're breaking things outside the scope of the changes
|
||||
- Your "tests" are actually sabotage with no constructive purpose
|
||||
|
||||
**Mitigation:** You test the changes, not the entire system. Stay in scope.
|
||||
|
||||
---
|
||||
|
||||
## Consolidated Review Output
|
||||
|
||||
After all reviewers finish, compile:
|
||||
|
||||
```markdown
|
||||
## Check Phase Results — Cycle N
|
||||
|
||||
### Guardian: APPROVED
|
||||
- WARNING: Missing rate limit on new endpoint (src/auth/handler.ts:52)
|
||||
|
||||
### Skeptic: APPROVED
|
||||
- INFO: Consider caching validated tokens (perf improvement, not blocking)
|
||||
|
||||
### Sage: APPROVED
|
||||
- WARNING: Test names could be more descriptive
|
||||
|
||||
### Trickster: REJECTED
|
||||
- CRITICAL: Empty string input bypasses validation (src/auth/handler.ts:48)
|
||||
Reproduction: POST /auth with `{"token": ""}`
|
||||
Expected: 400 Bad Request
|
||||
Actual: 500 Internal Server Error
|
||||
|
||||
### Verdict: REJECTED — 1 critical finding
|
||||
→ Feed back to Plan phase for cycle N+1
|
||||
```
|
||||
Reference in New Issue
Block a user