Milens eval
Evaluation & Quality Gate — plan, implement, verify scope, review risk, run tests, check coverage, and pass/failFrom its SKILL.md
npx -y skills add fuze210699/milens --skill milens-evalAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 8 stars8 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
7.0 KB, as published. Nobody here has run it
milens-eval — Evaluation & Quality Gate
A structured quality gate for feature development: plan tests, implement changes, verify scope, review risks, run impacted tests, check coverage gaps, and produce a pass/fail verdict.
Tools Required
| Tool | Purpose |
|---|---|
mcp_milens_test_plan | Generate test strategy before implementation |
mcp_milens_detect_changes | Verify only expected files changed after implementation |
mcp_milens_review_pr | Risk assessment of the changes |
mcp_milens_test_impact | Identify and run affected test files |
mcp_milens_test_coverage_gaps | Verify no new untested critical symbols introduced |
CRITICAL: All milens MCP tool calls MUST include the
repoparameter set to the absolute path of the workspace root.
Workflow
Step 1: Plan Tests (Before Implementation)
Before writing code, plan the test strategy.
mcp_milens_test_plan({name: "<symbolName>", repo: "<workspaceRoot>"})
This provides:
- Mock strategy — what dependencies to isolate
- Test scenarios — happy path, error states, edge cases
- Affected test files — existing test files that may need updates
Review the plan to ensure it covers:
- Core functionality (happy path)
- Input validation (error handling)
- Integration points (service boundaries)
- Edge cases (null, empty, boundary values)
Step 2: Implement Changes
Write the actual code changes. This is the implementation phase:
- Write or update the target symbol(s)
- Implement tests following the plan from Step 1
- Follow existing code conventions and patterns
- No
console.log, no commented-out code, no debug artifacts
Step 3: Detect Changes
Verify the scope of changes matches expectations.
mcp_milens_detect_changes({repo: "<workspaceRoot>"})
Check:
- Expected files present — all intended modifications are listed
- No unexpected files — no config drift, accidental staging, or side effects
- No missing files — if a file you expected to change is absent, investigate
Step 4: Review Risk
Assess the quality and risk of the changes.
mcp_milens_review_pr({repo: "<workspaceRoot>"})
Focus on:
- CRITICAL symbols — any symbol rated CRITICAL needs thorough review
- Risk distribution — how many HIGH/MEDIUM/LOW symbols changed
- Review suggestions — automated findings to address
Step 5: Run Tests
Identify and run all affected tests.
mcp_milens_test_impact({repo: "<workspaceRoot>"})
This returns the list of test files impacted by the changes. Run them all:
- If any test fails: fix before proceeding
- If a test you didn't expect is affected: investigate why
- If a test you expected is missing: your test files may not be indexed
Step 6: Check Coverage Gaps
Verify no new untested critical symbols were introduced.
mcp_milens_test_coverage_gaps({repo: "<workspaceRoot>", limit: 20})
Review the output:
- Newly introduced symbols — should have test coverage
- Pre-existing gaps — note them but don't fail the gate (they're not new)
- HIGH risk + no tests — if any HIGH-risk symbol in the change has no tests, this is a failure
Step 7: Quality Gate Verdict
Apply the pass/fail criteria (see Quality Gate section below) and produce a verdict:
PASSED:
- All test files pass
- No CRITICAL review_pr findings
- No unexpected files in detect_changes
- No new HIGH-risk uncovered symbols
CONDITIONAL PASS:
- All tests pass
- CRITICAL review_pr findings are acknowledged and documented with remediation plan
- Minor unexpected files that are harmless (lockfile updates)
FAILED:
- Any test fails
- Hardcoded secrets found
- Blast radius exceeds safe threshold without justification
- New HIGH-risk symbols with zero test coverage
Example Session
Input
"evaluate the feature branch for the new rate limiter"
Tool Calls
Step 1 — Test plan:
mcp_milens_test_plan({name: "RateLimiter", repo: "/home/user/project"})
Output:
Test Plan for RateLimiter:
Mock strategy: stub Redis client, stub clock
Tests:
1. allows requests within limit
2. blocks requests exceeding limit
3. resets counter after window expires
4. handles Redis connection failure gracefully
Affected: src/__tests__/middleware.test.ts (new)
Step 2 — Implement rate limiter class and tests.
Step 3 — Detect changes:
mcp_milens_detect_changes({repo: "/home/user/project"})
Output:
Changed files:
src/middleware/rateLimiter.ts [new]
src/__tests__/middleware.test.ts [new]
src/middleware/index.ts [modified] — barrel export
3 files — all expected.
Step 4 — Review risk:
mcp_milens_review_pr({repo: "/home/user/project"})
Output:
Affected symbols:
RateLimiter [class] MEDIUM — 2 callers, 4 tests
applyRateLimit [function] LOW — 0 callers (internal helper)
No CRITICAL findings. 1 LOW suggestion: add JSDoc to RateLimiter class.
Step 5 — Test impact:
mcp_milens_test_impact({repo: "/home/user/project"})
Output:
Affected test files:
src/__tests__/middleware.test.ts (new)
Run tests: npm test -- middleware.test.ts — all 4 pass.
Step 6 — Coverage gaps:
mcp_milens_test_coverage_gaps({repo: "/home/user/project", limit: 20})
Output: No new HIGH-risk symbols introduced. 3 pre-existing LOW/medium gaps unrelated to this change.
Step 7 — Verdict: PASSED.
Best Practices
- Test plan before code, not after. Step 1 exists to prevent "I'll test it later." Write the plan, review it, then implement.
- detect_changes is your safety net. If it shows a
package-lock.jsonchange you didn't intend, something went wrong. Investigate every unexpected file. - Treat CRITICAL review findings as blockers. Don't rationalize them away. A CRITICAL finding means the change introduces significant risk.
- Coverage gaps are relative to the change. Don't fail the gate because of pre-existing gaps. Fail only if the change itself introduces new uncovered critical symbols.
- Conditional passes need a deadline. If you issue a "Conditional Pass," document exactly what must be fixed and by when. An open-ended conditional is a failed gate in disguise.
Quality Gate
| Criteria | Pass | Fail |
|---|---|---|
| Test plan exists | Test plan generated with ≥3 scenarios | No test plan or < 3 scenarios |
| Change scope | detect_changes shows only expected files | Unexpected files in diff (unless harmless) |
| Review risk | No CRITICAL findings | Unresolved CRITICAL findings |
| Test execution | All test_impact files pass | Any test file fails |
| Coverage gaps | No new HIGH-risk symbols without tests | New HIGH-risk symbol has 0 test coverage |
| Gate verdict | PASSED or CONDITIONAL PASS (with documented remediation) | FAILED — must fix and re-run evaluation |