lesser-body

Drive an adversarial, security-first review of a pull request on your governed github_* surface: ground on the real diff at a pinned head SHA, threat-model the change, sweep it through named security lenses, then attempt to refute every candidate finding before reporting — post the survivors as a COMMENT-only PR review with inline threads. NOT for approving, requesting changes, merging, or gating a PR; NOT a replacement for repo CI, SAST/CodeQL, or human security review; NOT for repositories outside your github_list_repos scope; NOT a whole-repo security audit.

Apply this repository's resolved governance profile and verify it: checksum the parent-staged gov-infra genome, run the repo-local verifier to fresh gov_rubric_report.v1 evidence, and confirm branch/profile consistency — for a software_repo_gov_infra steward at milestone boundaries, before a PR, or when governance evidence is stale. NOT for editing the namespace governance profile (that is operator-level setup-governance-profile) and NOT for a parent verifying a submodule (verify-governance-in-submodule).

Use after plan-roadmap is approved, if the roadmap warrants a tracked GitHub Project at the equaltoai org level. Translates a roadmap document into a Projects v2 kanban board with issues across the affected repos. Follows equaltoai's established project pattern.

Use to walk a merged change through per-stage CDK deploy — `lab`/`dev` → `staging` → `live` — with SSM parameter-export publication, three-step first-deploy coordination with lesser when applicable, and never-timeout on CDK commands.

Use after scope-need and relevant specialist skills approve work. Takes the scoped-need document and produces a flat, ordered list of discrete changes required. Each change is scoped to be a single commit.

Use for any GitHub operation on equaltoai/lesser-body — branches, commits, pull requests, reviews, issues, comments, checks, orchestrated closeout. Prefer the governed TheoryMCP github_* tools (agent-scoped, attributable as body-theorymcp[bot], policy-gated) over the gh CLI; fall back to gh only for operations TheoryMCP does not expose (PR body read, Projects v2, delete-branch, resolve-thread, releases, workflow dispatch, secrets, gists, gh api, other repos) and say so explicitly.

Use to execute a single milestone (or GitHub Project phase) of work — feature branch off staging, commits per enumerated task, PR review with existing ci / verify, merge to staging. Runs one milestone at a time. Deploys themselves go through deploy-body.

Use after enumerate-changes. Takes a flat enumerated change list and sequences it with dependencies, risks, and a per-stage rollout plan. Produces a roadmap document, not code or project state.

Use when building or maintaining body surfaces framework awkwardness — an AppTheory MCP runtime limitation, a TableTheory query-builder friction, a CDK construct gap. Produces a cleanly-shaped signal for the relevant Theory Cloud framework steward rather than a local patch. body's role as flagship consumer of AppTheory's MCP runtime means framework-consumption awkwardness here is scope-evidence for framework evolution.

Use when a change touches the body↔lesser integration surface — JWT secret handling, DynamoDB data-table reads, lesser REST API consumption, SSM parameter exports, `soulEnabled` CDK context, or the three-step first-deploy order. Walks the integration impact and produces a coordination plan with the `lesser` steward before the change proceeds. body extends lesser; the integration is architecture, not plumbing.

Use when a change touches the 27-tool surface — adding a tool, modifying a tool's behavior, removing a tool, adjusting a tool's declared scope (`read`/`write`/`admin`) or declared profile (`drone`/`souled`), or touching the static registration mechanism in `internal/mcpserver/`. Walks the tool-surface impact with scope / profile correctness, communication-tool delegation discipline, per-actor session handling, and static-registration integrity.

Use when a user reports a bug, regression, or unexpected behavior in body — MCP client failing to connect, tool invocation returning wrong result, scope / profile rejection when it shouldn't, JWT validation failure, OAuth metadata shape issue, communication-tool delivery failure, lesser-integration failure, SSM export drift, session persistence bug, CDK deploy issue. Runs before any fix is proposed. Produces an investigation note, not a patch.

Use when a change affects the MCP contract surface — `.well-known/mcp.json` discovery, `.well-known/oauth-protected-resource/mcp/<actor>` OAuth metadata, or JSON-RPC request/response shape for `tools/call` / `resources/read` / `prompts/get`. Walks contract impact across every MCP client class and produces a coordination plan.

Use when the user pastes or describes an inbound advisor-agent email dispatched to this steward. Advisor emails end with `@lessersoul.ai` and carry a provenance signature. This skill verifies the brief's origin, extracts the request cleanly, and surfaces it to the principal for explicit review before any action is taken. Advisor-dispatched work never executes autonomously.

Use when a user brings a new capability, feature request, or enhancement need for body in vague terms. Interviews conversationally and produces a scoped-need document. Applies Gate 1 (MCP-mission alignment), Gate 2 (narrowest scope), and Gate 3 (specialist routing) before producing output.