SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillslaohan-chushicodex

laohan-chushicodex

Agents & models

View repository

Updated 10-15 22:12

About this skill

Codex Lightweight Initialization

Establish only the minimal baseline that improves security, executability, and acceptance quality; do not disguise personal model preferences, plugin lists, keys, absolute paths, or complex workflows as general initialization.

Select Mode

GLOBAL_SETUP: execute only once when newly installing or reorganizing Codex

  • Used for scenarios where a baseline needs to be established for global config.toml、global AGENTS.md, profile, or client health.
  • Execute scripts/audit-codex-init.shto first obtain a read-only snapshot. The script will call codex doctoras-is (runtime permission/health information) and separately list configuration text; it does not connect to the network, write, read key fields in the configuration, or dump the full environment. The output contains local paths, the Doctor summary, and Git status; review before sharing.
  • Before making changes, explain the files to be modified and the reasons; when it involves updating the CLI, installing plugins/MCP, authentication, networking, committing, publishing, or relaxing permissions, wait for explicit user confirmation.
  • Preserve the user's existing valid configuration; do not delete MCP, plugins,AGENTS.md, project trust, or historical preferences because of initialization.

PROJECT_ONBOARDING: perform a lightweight check once when each project is first integrated

  • Do not redo the global configuration, and do not copy the global AGENTS.md。
  • Only confirm the project's runtime, package manager/lockfile, minimal verification commands, directory boundaries, and acceptance conditions; test first, then write the real results into the project AGENTS.md。
  • When a new project AGENTS.md needs to be created, write only project facts, do not copy global template。

General global AGENTS.md

  • GLOBAL_SETUP , if the user requests creating or replacing a general global AGENTS.md, read global-agents-template.md。
  • The template is only suitable for users without existing global rules; it does not contain names, models, MCP, plugins, paths, project commands, or personal ways of working.
  • When the target file already exists, compare first and provide a minimal diff; do not overwrite the original file unless the user explicitly requests it.

Six Minimal Baselines

1. Check up first, then decide whether to upgrade

  • Run codex --version、codex doctor and codex --strict-config --help; record what versions the CLI and Desktop App are respectively, and do not conflate them.
  • If the version is behind, only report the version and the official update path codex update; do not upgrade automatically. First confirm the installation source, update impact, and rollback conditions.
  • Use codex doctor 's runtime output to confirm approval/sandbox; the configuration file text is only a supplementary snapshot and cannot replace runtime evidence.
  • If doctor or the strict configuration check fails, fix that issue first, then add any optimization.

2. Default to least privilege, not "fully automatic" by default

  • The recommended baseline for interactive development is approval_policy = "on-request" and sandbox_mode = "workspace-write"; for review use read-only profile。
  • Optionally establish review、dev、deep three profiles: serving only permission boundaries and reasoning effort, without changing models or stuffing in environment variables.
  • Do not treat never、danger-full-access、--dangerously-bypass-approvals-and-sandbox, automatic plugin installation, or MCP as initialization defaults.
  • Set trust_level = "trusted"only for projects the user has inspected and trusts; keep unknown repositories untrusted for now.

3. Make AGENTS.md layered and short

  • Global ~/.codex/AGENTS.md stores only cross-project, long-lived collaboration preferences, safety boundaries, and tool routing.
  • Project root AGENTS.md stores only project facts: startup/test/format commands, directory boundaries, acceptance criteria, and non-negotiable constraints.
  • Move long tutorials, history, and occasional troubleshooting to project docs;AGENTS.md keep only what is needed at execution time. Do not copy-paste the same rule into both global and project locations.
  • If the user also uses Claude Code, first confirm its existing synchronization conventions; do not write only Codex-private records.

4. Make the project start reproducibly

  • Discover the project language, package manager, lockfile, version declarations, and existing CI; read first, then run installation.
  • Record a minimal verification command that has already run successfully on this machine (for example test、lint、typecheck or the project's own contract check), and state the required runtime version.
  • Do not replace the package manager, rewrite the lockfile, or install a "kitchen sink" of dependencies during initialization; when dependencies are missing, report the exact command and run it after authorization.

5. Write requests as executable task contracts

  • For every non-trivial task, write clearly: goal, scope/what not to change, acceptance command or manual acceptance point, deliverables.
  • For high-risk, cross-module, or ambiguous goals, investigate first and give a plan; for single-file, low-risk tasks, implement directly.
  • Templates are prompts, not process tools. It is forbidden to create an issue, branch, worktree, or complex document for every small change.
  • Reusable prompt:目标：…；范围：…；不改：…；验收：…；交付：…。

6. Fix "implement—verify—hand off"; do not treat verbal conclusions as completion

  • First establish a baseline or restate the goal and verification method; after implementation, run targeted verification and necessary manual checks.
  • Report actual changes, verification evidence, unverified items, and external actions requiring user decision.
  • For code changes, at least review the diff; failures must not be silently ignored. Do at most three low-risk targeted fixes, then stop and report with evidence.

Delivery format

Output the following four sections, keeping them short:

  1. Health check conclusion: pass, warning, blocking items.
  2. Proposed changes: files, minimal diff, rationale; list unauthorized operations as pending confirmation.
  3. Verification evidence: commands actually run and results; do not substitute speculation.
  4. Usage: recommended profile, prompt for the project's first task, and next manual decision.

Anti-patterns

❌ Copy one machine's model, MCP, plugins,trust_level and absolute paths to everyone.

✅ Do a health check first; establish only the four foundations: safe permissions, layered instructions, runnable verification, and traceable handoff.

❌ Enable no-approval, full-disk writes, or automatic upgrades under the pretext of "improving efficiency."

✅ Use the review profile for investigation and review; use devonly when truly needed. deep。

References

  • When you need to view the basis or update this Skill, read references/sources.md。
  • When conflicts arise, safety and configuration semantics are governed by the current official documentation and this machine's codex --help .