@rune-kit/rune 2.2.6 → 2.3.0

package/skills/team/SKILL.md

@@ -5,7 +5,7 @@ context: fork
 agent: general-purpose
 metadata:
   author: runedev
-  version: "0.5.0"
+  version: "0.6.0"
   layer: L1
   model: opus
   group: orchestrator
@@ -66,6 +66,28 @@ Lite Mode Phases:
 
 Standard team workflow with worktree isolation (Phases 1-5 as documented below).
 
+### Complexity Tiers (DAG Stage Selection)
+
+Before decomposing, classify the task into a complexity tier. Each tier defines a different DAG (directed acyclic graph) of stages, ensuring the right amount of process for the task's complexity.
+
+| Tier | Signals | DAG Stages | Context Windows |
+|------|---------|------------|-----------------|
+| **Trivial** | ≤3 files, single module, no shared contracts | impl → test | 1 (single cook) |
+| **Medium** | 4-10 files, 2-3 modules, shared interfaces | research → plan → impl → test → review → fix | 3 (plan, impl+test, review+fix) |
+| **Large** | 10+ files, 3+ modules, breaking changes or RFC | research → plan → impl → test → review₁ → fix → review₂ → final merge | 4+ (plan, impl+test, review₁+fix, review₂+merge) |
+
+**Key principle — reviewer isolation**: The agent that writes code MUST NOT review its own code. Each review stage uses a **separate context window** (separate Task invocation) that has never seen the implementation reasoning. This prevents author bias from contaminating the review.
+
+**Stage → Context Window mapping**:
+- `research + plan` = Context Window 1 (opus — architectural reasoning)
+- `impl + test` = Context Window 2 (sonnet — code writing)
+- `review₁ + fix` = Context Window 3 (sonnet — fresh eyes, no impl context)
+- `review₂ + merge` = Context Window 4 (sonnet — final verification, Large tier only)
+
+**Merge queue**: When multiple streams complete at different times, use dependency order for merging. If a later stream's merge creates conflicts with an already-merged stream, provide the conflicting stream's cook report as **conflict context** to the resolution agent — never resolve blindly.
+
+> Source: affaan-m/everything-claude-code (91.9k★) — RFC-driven DAG orchestration with reviewer isolation.
+
 ## Calls (outbound)
 
 - `plan` (L2): high-level task decomposition into independent workstreams
@@ -433,6 +455,16 @@ Dependent streams    → SEQUENTIAL (respecting dependency order)
 All streams done     → MERGE sequentially (avoid conflicts)
 ```
 
+## Returns
+
+| Artifact | Format | Location |
+|----------|--------|----------|
+| Workstream assignments | Markdown (inline) | NEXUS Handoff Templates emitted per stream |
+| Cook Reports (per stream) | Markdown (inline) | Collected from each parallel cook instance |
+| Merged implementation | Source files | `main` branch after Phase 4 merge |
+| Integration test results | Inline stdout | Captured in Phase 5 verify |
+| Team Report | Markdown (inline) | Emitted at end of session |
+
 ## Sharp Edges
 
 Known failure modes for this skill. Check these before declaring done.
@@ -464,3 +496,5 @@ Known failure modes for this skill. Check these before declaring done.
 ## Cost Profile
 
 ~$0.20-0.50 per session. Opus for coordination. Most expensive orchestrator but handles largest tasks.
+
+**Scope guardrail**: Do not invoke launch, rescue, or scaffold autonomously unless explicitly delegated by the parent agent.

package/skills/test/SKILL.md

@@ -3,7 +3,7 @@ name: test
 description: "TDD test writer. Writes failing tests FIRST (red), then verifies they pass after implementation (green). Covers unit, integration, and e2e tests."
 metadata:
   author: runedev
-  version: "0.7.0"
+  version: "1.1.0"
   layer: L2
   model: sonnet
   group: development
@@ -242,6 +242,52 @@ For non-trivial features (3+ test files or 20+ test cases), create a `TEST.md` i
 
 **Why TEST.md**: Planning tests before code catches missing edge cases early. Appending results creates permanent evidence. One document = complete testing story.
 
+## Skill Behavior Tests (Eval Scenarios)
+
+For testing SKILL.md behavior (not code), use **Eval Scenarios** — unit tests for skill files, not code files.
+
+### Eval Scenario Format
+
+```markdown
+## Eval: E[NN] — [scenario name]
+
+### Prompt
+[The exact situation/message an agent receives]
+
+### Expected Reasoning
+[Step-by-step reasoning the agent SHOULD follow]
+
+### Must Include
+- [Assertion 1: what the output MUST contain or do]
+- [Assertion 2]
+
+### Must NOT
+- [Anti-pattern 1: what the output MUST NOT do]
+- [Anti-pattern 2]
+
+### Category
+happy-path | adversarial | edge-case | jailbreak | credential-leak
+```
+
+### Eval Coverage Requirements
+
+A skill is **behavior-tested** when it has evals covering:
+
+| Category | Min Evals | Purpose |
+|----------|-----------|---------|
+| Happy path | 1 | Core workflow executes correctly |
+| Edge case | 1 | Empty input, missing context, unusual state |
+| Adversarial | 1 | Time pressure, sunk cost, authority pressure |
+| Jailbreak / injection | 1 | Prompt injection attempt, "ignore instructions" |
+
+**Minimum**: 4 evals per skill (1 per category). Security-critical skills (sentinel, safeguard): 8+ evals.
+
+### Eval Storage
+
+Save eval files as `skills/<name>/evals.md`. Each eval is a numbered scenario (E01–E24 range). skill-forge Phase 7 checks for evals presence before ship.
+
+> Source: PhucMPham/zalo-agent-cli (35★) — 24 eval scenario format (E01-E24) with Must Include / Must NOT assertions.
+
 ## Error Recovery
 
 - If test framework not found: ask calling skill to specify, or check `package.json` `devDependencies`
@@ -298,6 +344,101 @@ For non-trivial features (3+ test files or 20+ test cases), create a `TEST.md` i
 | "I mentally tested it" | Mental testing is not testing. Run the command, show the output. |
 | "This is different because..." | It's not. Write the test first. |
 
+## Advanced: Oracle-Injection E2E Testing
+
+For **data pipelines, AI workflows, and multi-stage processing** where comparing full output structures is impractical, use oracle injection:
+
+1. **Generate a UUID oracle token**: `const oracle = crypto.randomUUID()`
+2. **Inject into synthetic input**: embed the oracle in realistic test data that flows through the pipeline
+3. **Run the full pipeline**: input → all stages → output
+4. **Search for oracle in output**: if found → data flowed end-to-end correctly
+
+```
+// Example: testing a document processing pipeline
+const oracle = "ORACLE-" + crypto.randomUUID();
+const testDoc = `Meeting notes: discussed ${oracle} integration timeline`;
+const result = await pipeline.process(testDoc);
+assert(result.output.includes(oracle), "Oracle not found — pipeline lost data");
+```
+
+**When to use**: E2E tests for pipelines with 3+ stages, LLM-based processing, ETL workflows, or any system where output structure is complex/non-deterministic but data preservation is critical.
+
+**When NOT to use**: Unit tests, simple CRUD, or when exact output comparison is feasible.
+
+> Source: airweave-ai/airweave (6k★) — Bongo oracle-injection pattern for pipeline E2E testing.
+
+## Spec→Test Traceability
+
+When a plan with acceptance criteria exists (`.rune/features/<name>/plan.md` or phase file), every criterion MUST map to at least one test case.
+
+```
+Plan Acceptance Criteria → Test Case → Implementation
+
+AC-1: "User can reset password via email" → test_password_reset_sends_email()
+AC-2: "Rate limit: max 3 reset attempts/hour" → test_password_reset_rate_limit()
+AC-3: "Expired tokens rejected" → test_expired_reset_token_rejected()
+```
+
+**Validation step** (after writing tests): Cross-check plan's acceptance criteria against test names. For each criterion:
+- Has test → OK
+- No test → flag as UNTESTED REQUIREMENT (more serious than uncovered lines)
+
+**Why this is stronger than coverage**: Coverage checks that lines were EXECUTED. Traceability checks that INTENT was VERIFIED. You can have 100% coverage but miss a requirement if the test doesn't assert the right behavior.
+
+**Skip if**: No plan exists (ad-hoc fix), or plan has no acceptance criteria section.
+
+> Source: Fission-AI/OpenSpec (32.8k★) — spec→test traceability validates intent, not just lines.
+
+## Eval-Driven Development
+
+Define **capability evals** and **regression evals** BEFORE writing implementation code. Evals go beyond unit tests — they verify that the agent/system can handle the feature's intent, not just its mechanics.
+
+### Two Eval Types
+
+| Type | Purpose | Pass Criteria | When |
+|------|---------|---------------|------|
+| **Capability eval** | Can the system do this new thing? | pass@k: ≥1 success in k attempts (k=3-5) | Before implementation |
+| **Regression eval** | Did we break existing behavior? | pass^k: ALL k attempts must pass | After implementation |
+
+**pass@k** (capability): At least 1 of k runs succeeds. Used for new features where some variance is acceptable. Threshold: ≥90% pass@3 for standard features, ≥95% pass@5 for critical paths.
+
+**pass^k** (regression): ALL k runs must pass. Used for existing behavior that must never break. If ANY run fails, it's a regression. Threshold: 100% pass^3.
+
+### Eval File Format
+
+Store evals in `.rune/evals/<feature>.md`:
+
+```markdown
+# Eval: <feature name>
+
+## Capability Evals (pass@k)
+| ID | Description | k | Threshold | Status |
+|----|-------------|---|-----------|--------|
+| CAP-1 | [what the system should be able to do] | 3 | 90% | pending |
+
+## Regression Evals (pass^k)
+| ID | Description | k | Status |
+|----|-------------|---|--------|
+| REG-1 | [existing behavior that must not break] | 3 | pending |
+```
+
+### Anti-Pattern: Eval Overfitting
+
+Do NOT overfit evals to specific prompts or known examples. Evals should test the **capability**, not the **exact input**.
+
+- BAD: `"When user says 'hello', respond with 'Hi there!'"` — tests exact string match
+- GOOD: `"When user greets, respond with a greeting"` — tests capability
+
+### Integration with TDD
+
+1. Write eval definitions (capability + regression) → `.rune/evals/<feature>.md`
+2. Write unit/integration tests (RED phase) → test files
+3. Implement feature (GREEN phase) → source files
+4. Run evals to verify capability achieved + no regressions
+5. Preflight checks eval results as part of quality gate
+
+> Source: affaan-m/everything-claude-code (91.9k★) — eval-driven development with pass@k/pass^k distinction.
+
 ## Red Flags — STOP and Start Over
 
 If you catch yourself with ANY of these, delete implementation code and restart with tests:
@@ -378,11 +519,34 @@ Partial mock missing fields that downstream code consumes. Your test passes beca
 If mock setup is 30 lines and the actual test assertion is 3 lines, the test is testing infrastructure, not behavior. This is a code smell that indicates wrong abstraction level.
 **Gate**: "Is my mock setup longer than my test logic?" → If yes: test at a higher level (integration) or extract mock factories.
 
+### Anti-Pattern 6: Test Slop (Framework-Behavior Tests)
+Tests that verify the framework works rather than YOUR code works. If the test would still pass with an empty component/function, it's testing infrastructure.
+**Gate**: "Would this test pass if I deleted my business logic?" → If yes: STOP. Rewrite to test behavior that YOUR code introduces.
+
+Examples of test slop:
+- "renders without crashing" (tests that React works, not your component)
+- "route responds with 200" without checking response body (tests Express, not your handler)
+- Asserting a mock was called N times without checking the RESULT of those calls
+- Type existence tests (`typeof result === 'object'`) when you should test the actual value
+
+> Source: affaan-m/everything-claude-code (91.9k★) — de-sloppify pattern applied to test writing.
+
 **Red flags — any of these means STOP and rethink:**
 - Mock setup longer than test logic
 - `*-mock` test IDs in assertions
 - Methods only called in test files
 - Can't explain in one sentence why a mock is needed
+- Test would pass with empty implementation (test slop)
+
+## Returns
+
+| Artifact | Format | Location |
+|----------|--------|----------|
+| Test files | Source files | Co-located or `__tests__/` per project convention |
+| Test plan + results | Markdown | `TEST.md` in test directory (non-trivial features only) |
+| Eval scenarios | Markdown | `skills/<name>/evals.md` (for skill behavior testing) |
+| Coverage report | Inline stdout | Shown in Test Report |
+| Test Report | Markdown (inline) | Emitted to calling skill (cook, fix, review) |
 
 ## Sharp Edges
 
@@ -425,3 +589,5 @@ SELF-VALIDATION (run before emitting Test Report):
 ## Cost Profile
 
 ~$0.03-0.08 per invocation. Sonnet for writing tests, Bash for running them. Frequent invocation in TDD workflow.
+
+**Scope guardrail**: Do not modify source or implementation files to make tests pass unless explicitly delegated by the parent agent.