Run any Skill in Manus with one click

evidence-cluster

Stars1

Forks0

UpdatedJuly 10, 2026 at 22:59

Use during code authoring + spec-review. Four practices bundled: (1) impact-aware test selection — run tests the changed files transitively reach, not just the ones you wrote; (2) anti-over-mock cue — no mocks outside test files; (3) complexity-delta gate during review — measure lines vs behaviour; (4) dual-reader ambiguity probe at SPEC review — second reviewer asks 'what does this permit/forbid that disagrees'.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

buildepicshit

buildepicshit/agentic-installation-methodology

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	evidence-cluster
description	Use during code authoring + spec-review. Four practices bundled: (1) impact-aware test selection — run tests the changed files transitively reach, not just the ones you wrote; (2) anti-over-mock cue — no mocks outside test files; (3) complexity-delta gate during review — measure lines vs behaviour; (4) dual-reader ambiguity probe at SPEC review — second reviewer asks 'what does this permit/forbid that disagrees'.
license	internal-only
compatibility	["copilot","claude","bes-fleet"]
allowed-tools	[]
metadata	{"bes_provenance":{"origin":"internal","source_urls":[],"borrowed_from":[],"upstream_status":"not-applicable","last_audited":"2026-06-05T00:00:00.000Z","audit_cadence":"annual","adoption_status":"bes-native","security_review":"not-required","notes":"BES fleet-native skill."},"bes_tool_surface":{"scripts":"none","network":false,"dependencies":[],"secrets":[],"allowed_tools":[],"risk_notes":"No skill-local executable helper scripts."}}

Evidence Cluster

Four practices bundle here because they share one root: the artefact has to do the right thing, not just exist.

Use Cases

Invoke this skill when implementing a behaviour change (impact-aware tests + anti-over-mock), when reviewing a diff (complexity-delta gate), when reviewing a SPEC (dual-reader ambiguity probe).

The Four Practices

1. Impact-Aware Test Selection

Before declaring a behaviour change done:

Identify the files you modified.
Identify tests that transitively reach those files (import graph, not just sibling tests).
Run THAT set, not just the tests you wrote.
Cite the test run as a tool-receipt (execution-discipline-cluster cross-ref).
If a predicate or contract gates behavior, execute it against the live filesystem/runtime before sign-off (file://specs/2026-06-22-fleet-sync-self-reconcile/SPEC_EVIDENCE.md SE-1).

For the BES fleet today the helpers are:

bash .claude/hooks/tests/run-tests.sh — fleet hook impact.
bash agents/scripts/<helper>.sh --self-test — per-helper impact.

2. Anti-Over-Mock Cue

Rules:

NEVER add mock, jest.mock, vi.mock, MagicMock, etc. outside test files. Production code that needs a mockable seam should use dependency injection at module boundaries (per standards §U15 boundary validation).
One mock per test, not many. Over-mocked tests test the mock, not the behaviour.
If you find yourself mocking the database in more than half your tests the architecture is test-hostile. Surface it.

3. Complexity-Delta Gate (during review)

When reviewing a diff:

Measure lines added vs behaviour added.
If the code added is roughly an order of magnitude more than the behaviour warrants, flag as complexity-bloat. (Calibration: a ~200-line PR that adds one new public-API function is fine; ~2000 lines for that same one function is suspect — ~10x too much. Advisory cue, not a lint-enforced ratio.)
Check imports added — every new dep is a long-lived liability; new deps without deps_added SPEC declaration are blocked by block-undeclared-deps.sh but advisory deps inside a node_modules churn warrant review.

4. Dual-Reader Ambiguity Probe (at SPEC review)

When cross-family reviewing a SPEC:

Pick one normative claim per major section.
Ask: "What behaviour does this permit / forbid that another reader might disagree on?"
If the answer is "nothing" you've read it tightly; if the answer reveals interpretive surface, surface the ambiguity as a finding.

This is distinct from existing diff-review — the ambiguity probe targets the SPEC TEXT's interpretive surface, not the implementation.

Hard Rules

Do not declare a behaviour change done without running impact-aware tests.
Do not add mocks to non-test files.
Do not let a PR whose size dwarfs its behaviour by ~an order of magnitude land unchallenged (see the complexity-delta cue above).
Do not skip the ambiguity probe on Contract SPECs — Contract is the most-binding artefact type.

Cross-references

Host skills per practice: tdd (impact-aware selection), code-review (complexity-delta), spec-review (ambiguity probe), execution-discipline-cluster (tool receipts).

More from this repository

same repository

repo-orientation

buildepicshit/agentic-installation-methodology

Use at the start of work in any BES repo to build a current, cited map of instructions, repo state, verification gates, active plans, and likely risk before editing.

2026-07-121

approved-spec-decomposition

buildepicshit/agentic-installation-methodology

BLOCKING. Use after a SPEC.md is approved and before in-execution to emit one TASK.md per executable slice into specs/<id>/tasks/. Each TASK.md carries primary/cross-validation/verification model lanes and gates the parent SPEC's transition approved -> decomposed -> in-execution. Tasks are the source-of-truth dispatchable units that agents execute directly; no external tracker (Linear) or dispatcher (Symphony) is required.

2026-07-101

code-review

buildepicshit/agentic-installation-methodology

Use for reviewing local diffs, branches, or PRs. Prioritises bugs, regressions, missing tests, unsafe assumptions, and broken repo contracts over surface polish. Do not use to author or review SPEC.md / IDEA.md artefacts — use spec-review for that BLOCKING gate.

2026-07-101

cross-agent-cli-invocation

buildepicshit/agentic-installation-methodology

Use when you (an agent) intend to invoke another agent's CLI from Bash — claude calling copilot, copilot calling claude, or any equivalent cross-agent pattern. Read at session start whenever you might fire `claude` or `copilot` from a Bash tool call. The skill documents the gotchas, points at the validator helper, and explains where the mechanical block fires.

2026-07-101

diagnosis

buildepicshit/agentic-installation-methodology

Use when debugging a failure, flaky behavior, regression, broken command, or unclear root cause. Builds a fast deterministic feedback loop before fixing.

2026-07-101

execution-discipline-cluster

buildepicshit/agentic-installation-methodology

Use during every execution-phase task AND whenever answering any question with a knowledge gap. Six practices bundled: (1) tool receipts; (2) in-flight failure disclosure; (3) receiving-code-review; (4) ground before you answer; (5) confidence-band declarations on completion-report claims; (6) escalation rubric — stop and surface or reset rather than grind. Inherits the canonical exit-code mapping from the CLI invocation contract.

2026-07-101

name	evidence-cluster
description	Use during code authoring + spec-review. Four practices bundled: (1) impact-aware test selection — run tests the changed files transitively reach, not just the ones you wrote; (2) anti-over-mock cue — no mocks outside test files; (3) complexity-delta gate during review — measure lines vs behaviour; (4) dual-reader ambiguity probe at SPEC review — second reviewer asks 'what does this permit/forbid that disagrees'.
license	internal-only
compatibility	["copilot","claude","bes-fleet"]
allowed-tools	[]
metadata	{"bes_provenance":{"origin":"internal","source_urls":[],"borrowed_from":[],"upstream_status":"not-applicable","last_audited":"2026-06-05T00:00:00.000Z","audit_cadence":"annual","adoption_status":"bes-native","security_review":"not-required","notes":"BES fleet-native skill."},"bes_tool_surface":{"scripts":"none","network":false,"dependencies":[],"secrets":[],"allowed_tools":[],"risk_notes":"No skill-local executable helper scripts."}}

Evidence Cluster

Four practices bundle here because they share one root: the artefact has to do the right thing, not just exist.

Use Cases

Invoke this skill when implementing a behaviour change (impact-aware tests + anti-over-mock), when reviewing a diff (complexity-delta gate), when reviewing a SPEC (dual-reader ambiguity probe).

The Four Practices

1. Impact-Aware Test Selection

Before declaring a behaviour change done:

Identify the files you modified.
Identify tests that transitively reach those files (import graph, not just sibling tests).
Run THAT set, not just the tests you wrote.
Cite the test run as a tool-receipt (execution-discipline-cluster cross-ref).
If a predicate or contract gates behavior, execute it against the live filesystem/runtime before sign-off (file://specs/2026-06-22-fleet-sync-self-reconcile/SPEC_EVIDENCE.md SE-1).

For the BES fleet today the helpers are:

bash .claude/hooks/tests/run-tests.sh — fleet hook impact.
bash agents/scripts/<helper>.sh --self-test — per-helper impact.

2. Anti-Over-Mock Cue

Rules:

NEVER add mock, jest.mock, vi.mock, MagicMock, etc. outside test files. Production code that needs a mockable seam should use dependency injection at module boundaries (per standards §U15 boundary validation).
One mock per test, not many. Over-mocked tests test the mock, not the behaviour.
If you find yourself mocking the database in more than half your tests the architecture is test-hostile. Surface it.

3. Complexity-Delta Gate (during review)

When reviewing a diff:

Measure lines added vs behaviour added.
If the code added is roughly an order of magnitude more than the behaviour warrants, flag as complexity-bloat. (Calibration: a ~200-line PR that adds one new public-API function is fine; ~2000 lines for that same one function is suspect — ~10x too much. Advisory cue, not a lint-enforced ratio.)
Check imports added — every new dep is a long-lived liability; new deps without deps_added SPEC declaration are blocked by block-undeclared-deps.sh but advisory deps inside a node_modules churn warrant review.

4. Dual-Reader Ambiguity Probe (at SPEC review)

When cross-family reviewing a SPEC:

Pick one normative claim per major section.
Ask: "What behaviour does this permit / forbid that another reader might disagree on?"
If the answer is "nothing" you've read it tightly; if the answer reveals interpretive surface, surface the ambiguity as a finding.

This is distinct from existing diff-review — the ambiguity probe targets the SPEC TEXT's interpretive surface, not the implementation.

Hard Rules

Do not declare a behaviour change done without running impact-aware tests.
Do not add mocks to non-test files.
Do not let a PR whose size dwarfs its behaviour by ~an order of magnitude land unchallenged (see the complexity-delta cue above).
Do not skip the ambiguity probe on Contract SPECs — Contract is the most-binding artefact type.

Cross-references

Host skills per practice: tdd (impact-aware selection), code-review (complexity-delta), spec-review (ambiguity probe), execution-discipline-cluster (tool receipts).