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.

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.

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.

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.

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

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'.

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.

BLOCKING. Use ONLY from bes-fleet-policy. Issues structured fleet directives to one or more child repos, then applies them via fleet-enforce.sh, commits, and pushes. This is the cross-repo enforcement channel — when fleet rules change in bes-fleet-policy, this skill drives compliance across every fleet location named in the roster manifests rather than waiting for manual per-repo sync. Owner alone authorises new directives; the skill executes them.

Use when capturing an IDEA (/idea-capture) or authoring a SPEC.md (/author-spec) under the BES spec-first model. Owns templates, type selection (fastpath / task / contract / decision), shared schema, citation discipline, IDEA-conversation tactics. Hands off to spec-review for the BLOCKING gate. Do not use to review existing specs (spec-review) or implement approved specs (implementation-execution).

Routes BES non-trivial work through the IDEA -> SPEC lifecycle and selects the next phase skill. Use when planning architecture, behavior, guardrails, workflow, data model, CI, public-doc, multi-file, or unclear-scope work in a BES repo.

Use as the BLOCKING per-type quality gate after authoring or revising an IDEA.md or SPEC.md. Selects Task/Contract/Decision bar from front-matter, runs lint-spec.sh (REQUIRED for Contract), emits a Quality Gate Result, transitions status to needs-revision or approved-pending-owner. Never sets status: approved (owner-only). Do not use to author specs — use spec-authoring.

Use when implementing a behavior change (feature, bug fix) where a runnable test can describe the expected behavior. Write the check first (red), implement (green), refactor. Do not use for refactors that preserve behavior — use implementation-execution alone.

Use before reporting done. Runs the narrowest relevant checks first, then the repo gate when warranted, and records fresh evidence plus residual risk.

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.

Use when implementing an approved BES SPEC.md or a TASK.md slice (after decomposition). Keeps edits scoped to approved scope, preserves user work, updates directly coupled tests/docs, surfaces (does not silently swallow) scope drift. Requires SPEC at status: approved (owner-set) or later. Do not implement against draft / needs-revision / approved-pending-owner specs.

Use to convert durable lessons from a completed task into spec evidence candidates — claims with scope, evidence citation, confidence, and a suggested route. Fires after a SPEC reaches status: verified, after a substantial review, or after incident resolution. Do not write trusted shared memory directly; emit candidates for owner triage only.