enterprise

Files (12)

• SKILL.md
• evals.json · evals/
• agent-session-model.md · references/
• agent-stage-gates.md · references/
• workflow-routing.md · references/
• agent_session.py · scripts/
• codex_worker_dispatch.py · scripts/
• enterprise_required_gates.py · scripts/
• validate_architecture_contract.py · scripts/
• validate_enterprise_containment.py · scripts/
• validate_evals.py · scripts/
• validate_worker_artifacts.py · scripts/

SKILL.md (first lines)

# Enterprise

Portable enterprise workflow wrapper. This suite is repo-agnostic, publishable, and intended to generate repo-local overlays that travel with the repository.

## Core Rules

- Use a GPT-5.5 fresh baseline: state the outcome, success criteria, constraints, output shape, and stop rules; load detailed stage procedure only when it changes behavior.
- Planning and contract quality may consume most of the lane. Do not rush to build while schema, tenant, identity, current-code, file-boundary, E2E, or evidence questions remain open.
- Keep proof scope explicit: `function-level`, `slice-level`, `domain-level`, or `full-system`.
- `/goal` may be used as the enterprise intent front door for vague or product-shaped work, but it is only an intake adapter and never replaces `$enterprise`; it must hand off to path selection, source-read targets, build-packet seed, refusal conditions, and required gates before build.
- No production code before a locked contract, except a documented inline contract on `QUICK` path work.
- No completion claim before fresh verification evidence.
- `$enterprise` owns the mechanical gate runner. Do not ask the user to run `npm`, `node`, or harness commands to prove enterprise compliance; invoke `enterprise-required-gates --repo-root "$PWD" ...` yourself and report its result.
- Use stable enterprise wrappers as the primary command surface in every worktree: `enterprise-agent-session`, `enterprise-required-gates`, and `enterprise-containment`. They prefer repo-local tooling when present and fall back to reviewed global tooling when old promotion worktrees lack repo-local gate files. Do not hardcode `python3 tools/enterprise-skills/...` as the primary command.
- Source edits must be contained by the current agent session's locked contract and mechanical build packet. `QUICK` may skip the full plan/audit/contract-manager chain, but it must still record `path_classification=QUICK`, a locked quick contract, and a mechanical build packet before source edits. Non-`QUICK` also requires plan, plan-360-audit, contract-manager, and contract history.
- Schema/query/data claims require current code reads plus real database proof. Migrations, diffs, and mocks are not enough.
- UI, PDF upload, file upload, preview/download, modal, navigation, and rendered-output claims require headless browser proof when verified.
- Repo-portable facts belong in committed `.codex/enterprise-state/` files.
- Machine-specific facts belong in gitignored local-machine state, not committed profiles.
- In-flight workflow state belongs in gitignored `.codex/enterprise-state/agent-sessions/<agent-id>.json`, not repo-global status files.
- For high-risk domains, fail closed if required docs, return legs, or downstream consumers remain untraced.

## Path Selection

Use the routing matrix in [workflow-routing.md](references/workflow-routing.md).

- `DISCOVER_ONLY`: initial repo uplift, environment setup, or portability refresh
- `QUICK`: tiny, bounded changes with no meaningful architecture ambiguity
- `STANDARD`: clear feature or fix with moderate blast radius
- `FULL`: multi-stage work needing discovery, design, contract, adversarial review, and evidence pack
- `DEBUG`: bug or regression path when the problem is not yet understood

## Required Workflow

1. Decide the path up front and say it plainly.
2. Resolve or mint the current agent id with `enterprise-agent-session ensure --repo-root "$PWD" --agent-id <agent-id> ...` and keep using that same agent session for the whole lane.
3. Immediately run `enterprise-required-gates --repo-root "$PWD" --stage start --agent-id <agent-id>` to prove the required gate machinery is healthy.
4. If the repo profile is missing, stale, or contradicted by reality, run `enterprise-discover`.
5. Keep `.codex/repo-skills/<repo-family>-enterprise*` in sync with the committed repo profile.
6. Produce the upstream artifact for each downstream stage and record it in the current agent session.
7. Before entering any gated stage, run `enterprise-required-gates --repo-root "$PWD" --stage <stage> --agent-id <agent-id>` instead of hand-picking individual checks.
8. Stop if a required upstream artifact or required domain standard is missing.
9. State the final proof scope explicitly. If it is not truly `full-system`, say what remains unproven.

## Execution Discipline

- Reuse only the minimal skill subset required by the chosen path. Do not open every related skill just because it exists.
- If the task brief is already specific, approved, and bounded, do not invoke `brainstorming` just to restate the brief.
- For `QUICK`, `STANDARD`, or other bounded slice work, keep plan, contract, review, and verification artifacts concise and task-specific.
- Preserve time and attention for downstream completion. Do not spend the whole lane polishing upstream prose while review or verification is still unwritten.
- If the user asked for end-to-end completion, continue through downstream stages in the same lane until the verification artifact exists or a real blocker stops you.

## Agent-Bound Enforcement

- Use [agent-session-model.md](references/agent-session-model.md) for the state split.
- Use [agent-stage-gates.md](references/agent-stage-gates.md) for stage-entry enforcement.
- Never use another agent's session file as the source of truth for your stage entry.

If the prompt explicitly states that the committed repo profile and repo-local overlay are already current, do not restart bootstrap work unless the prompt also describes new drift.

## Existing Codex Skills To Reuse

- `brainstorming` for feature design
- `writing-plans` for implementation plans
- `test-driven-development` for implementation
- `systematic-debugging` for root-cause work
- `code-reviewer` and `requesting-code-review` for review
- `verification-before-completion` for completion claims

## High-Risk Domain Rule

If the task touches money movement, orders, auth, privacy, regulated data, external integrations, user safety, or any end-to-end hardening claim:

- locate the repo's source-of-truth docs first
- trace downstream and return-leg consumers explicitly
- keep the proof label below `full-system` until every required leg is evidenced

If the repo has no clear source-of-truth docs for that domain, record the gap and fail closed on the enterprise claim.

From anotherben/agentic-governance, MIT.

More from anotherben/agentic-governance