Skip to main content

ecorp-operations

Inspect ECorp mission, run, runner, approval and verification state through its native MCP gateway, or diagnose a blocked operation using authoritative evidence. Use for ECorp operational questions, not ordinary code review or unrelated repository edits.

설치로 이동

소스 정보

저장소
All-The-Vibes/ecorp
최근 소스 활동
2026년 9월 18일 21:50
감지된 SKILL.md 언어
영어
스타
6
포크
4

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
ecorp-operations
description
Inspect ECorp mission, run, runner, approval and verification state through its native MCP gateway, or diagnose a blocked operation using authoritative evidence. Use for ECorp operational questions, not ordinary code review or unrelated repository edits.
# Inspect ECorp operations Use the configured `ecorp` MCP server and its `crony_snapshot` tool. For a selected Factory work item, use `crony_factory_recovery_context` with its exact `work_item_id` UUID. The repository configuration starts the native gateway with `--read-only`: it exposes these inspection tools and rejects write tools before making a server request. If the installed gateway lacks this mode, build the current gateway; do not silently remove the flag. The operator must select the server, Corp and actor through trusted host configuration. Do not substitute demo identities, another Corp, a localhost default or another signed-in account when the requested identity is unavailable. The server remains responsible for membership and role authorization. A native tool permission is not tenant authorization. For setup and the non-mutating stdio probe, read [the MCP operations guide](../../../docs/MCP_OPERATIONS.md). The probe emits connection metadata and counts; the snapshot itself can contain private operational content and should stay within the requesting user's authorized context. Do not copy full snapshots into public issues or logs. ## Trace an outcome Find the exact mission/run requested by the user and correlate its task status, runner presence, verification result, outstanding approval and budget state. Prefer persisted IDs and source or artifact digests over display names. A missing object may be outside the actor's scope; it is not proof that no such object exists. Distinguish these states in the answer: - planned or held work versus launched work; - a provider's completion claim versus accepted verifier completion; - a retained checkpoint versus a verified deliverable; - a published review PR versus an integrated or deployed result. When source or artifact evidence is needed, use the existing authorized download/verification path documented in [Architecture](../../../docs/ARCHITECTURE.md). Do not infer successful tests from an artifact name or substitute a historical receipt for the current run's verifier policy. For a run-specific observation, follow [operation observations](../../../docs/OPERATION_OBSERVATIONS.md). Recheck a received observation against fresh native state before using its outcome. An input-file hash is not a signature, and an accepted run with incomplete check history is not full check evidence. ## When the user requests a change Read the relevant contract and current routing in [the contributor guide](../../../CONTRIBUTING.md) and [the Factory guide](../../../docs/DARK_FACTORY_CONTRIBUTOR_GUIDE.md). Reuse the native mission, recovery, budget-revision or publication operation appropriate to the persisted state. The read-only MCP connection does not grant those effects. Do not turn a room message into a task, auto-submit a human review decision, reopen a terminal budget stop, or execute in a configured source checkout. Report the observed state, its supporting IDs, the specific unresolved condition and the next supported operation. Keep unavailable hosted, production, provider and end-to-end evidence explicit. Never present an inspection or a configuration file as proof that an operating loop ran. ## Inspect recovery eligibility Prefer the selected item's native recovery context over inferring eligibility from a broad snapshot. Correlate its work-item version, source run, remaining attempts and budget, retained recovery records and checkpoint capabilities. Missing flags remain unknown. A permission error or hidden item does not authorize another identity, broader scope or a fallback write operation. The server's existing `Operate` permission and human-role/room checks still apply to this GET. Do not send recovery modes, actor IDs or authority claims as tool arguments. The inspection does not create a checkpoint, resume a provider, clear a breaker, reset spending or approve a recovery. Revalidate current native authority through the existing action path before any separately requested change. Keep private context fields within the requesting user's authorized scope; use the probe's metadata report when full policy/source/failure data is unnecessary.
GitHub에서 보기