From orchestrator-supaconductor
Evaluates core product logic tracks for rules compliance, feature correctness, edge cases, state transitions, data flow, and user journey completeness.
npx claudepluginhub ibrahim-3d/orchestrator-supaconductor --plugin orchestrator-supaconductorThis skill uses the workspace's default tool permissions.
Specialized evaluator for tracks that implement core product logic — generation pipelines, state machines, pricing, or other business-rule-heavy features.
Dispatches specialized evaluators for UI/UX, code quality, integrations, or business logic tracks by analyzing spec and metadata. Runs structural checks on plan.md and build status.
Evaluates TandemKit Generator output against specs using Codex as second opinion. Autonomous verification loops via bash state watchers and signals until pass or user intervention.
Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.
Share bugs, ideas, or general feedback.
Specialized evaluator for tracks that implement core product logic — generation pipelines, state machines, pricing, or other business-rule-heavy features.
Dispatched by loop-execution-evaluator when the track involves:
spec.md and plan.mdconductor/product.md — product rules (deliverables, tiers, dependencies)Check against rules defined in conductor/product.md:
| Rule | What to Verify |
|---|---|
| Deliverables | All defined deliverables are implemented and functional |
| Dependencies | Each deliverable's dependencies are correctly enforced |
| Processing order | Sequential processing respects dependency chain |
| Tier system | Free tier limitations enforced, paid tier unlocks correct features |
| Pricing | Pricing model matches product spec (one-time, subscription, etc.) |
| State rules | State transitions (e.g., lock/unlock, draft/publish) propagate correctly |
### Product Rules: PASS / FAIL
- Rules checked: [count]
- Violations: [list rule: actual behavior]
- Deliverables functional: [X]/[total]
For each feature in the spec, verify it works correctly:
| Check | Method |
|---|---|
| Happy path | Primary user flow produces expected result |
| Input validation | Invalid inputs rejected with clear messaging |
| Output correctness | Generated data matches expected format/structure |
| State mutations | State changes are correct and complete |
| Side effects | Downstream effects trigger correctly (e.g., dependency propagation) |
### Feature Correctness: PASS / FAIL
- Features tested: [count]
- Correct: [count]
- Failures: [describe each]
| Scenario | What to Verify |
|---|---|
| Empty state | First-time user with no data |
| Boundary values | Max input length, empty inputs, special characters |
| Concurrent operations | What happens if user triggers 2 operations at once |
| Network failure mid-operation | Partial state handled correctly |
| Re-processing | Re-running an operation on existing data prompts confirmation if needed |
| All items locked/finalized | UI reflects that no further changes are possible |
| Tier limits | Exceeding free tier limit shows upgrade prompt |
### Edge Cases: PASS / FAIL
- Scenarios checked: [count]
- Unhandled: [list]
- User impact: [describe]
Verify state machine correctness for your project's state model. Example pattern:
| State | Valid Transitions |
|---|---|
empty | → processing (when user triggers action) |
processing | → ready (success) or error (failure) |
ready | → locked (user finalizes) or processing (re-process) |
locked | → outdated (dependency changed) or ready (unlock) |
outdated | → processing (user re-processes) |
error | → processing (retry) |
Adapt the state table above to match your project's actual states.
### State Transitions: PASS / FAIL
- States implemented: [list]
- Invalid transitions possible: [list]
- Missing transitions: [list]
| Check | What to Verify |
|---|---|
| Input → Processing | User form data correctly feeds into processing pipeline |
| Processing → Output | Results stored/displayed correctly |
| Output → Persistence | Results saved to store/database |
| Cross-component | Data shared correctly between components |
| Stale data | No stale renders after state changes |
### Data Flow: PASS / FAIL
- Flow verified: [input → output]
- Stale data issues: [describe]
- Data loss points: [list]
Walk through the complete user journey for the feature under evaluation. Example structure:
1. User provides input (form, selection, etc.)
2. System processes input
3. User reviews output
4. User can lock/finalize results
5. System handles dependencies between outputs
6. User views all deliverables
7. User can export/download results
8. User can re-process any unlocked item
9. Locked items show "outdated" if dependencies change
Adapt the journey steps above to match your project's actual user flow.
### User Journey: PASS / FAIL
- Steps completed: [X]/[total]
- Broken at step: [which]
- User experience: [smooth / friction at: describe]
## Business Logic Evaluation Report
**Track**: [track-id]
**Evaluator**: eval-business-logic
**Date**: [YYYY-MM-DD]
### Results
| Pass | Status | Issues |
|------|--------|--------|
| 1. Product Rules | PASS/FAIL | [details] |
| 2. Feature Correctness | PASS/FAIL | [details] |
| 3. Edge Cases | PASS/FAIL | [details] |
| 4. State Transitions | PASS/FAIL | [details] |
| 5. Data Flow | PASS/FAIL | [details] |
| 6. User Journey | PASS/FAIL | [details] |
### Verdict: PASS / FAIL
[If FAIL, list specific fix actions for loop-fixer]
loop-execution-evaluator → Conductor marks completeloop-execution-evaluator → Conductor dispatches loop-fixer