submanager/AGENTS.md

Codex Agent Guide for SubManager

Scope

• Applies to the entire repository unless a more specific rule exists deeper in the tree.
• Precedence: project AGENTS.md > project .claude/agents > user ~/.claude > default Codex CLI rules. Direct system/developer instructions always win.

Goals

• Accelerate small, safe changes with consistent quality.
• Keep diffs minimal, focused, and aligned with Flutter best practices.

Guardrails

• Workspace only: modify files within this repo. Ask before adding dependencies or using network.
• Safety: avoid destructive actions (file deletions, rewrites, config changes) unless explicitly requested.
• Responses: be concise; code first, short rationale after. If uncertain, prefix with "Uncertain:". If multiple viable solutions, show the top 2 briefly.
• Planning: for multi‑step tasks, maintain an update_plan with exactly one in_progress step.
• Language: 기본적으로 한국어로 응답합니다. (필요 시 코드/로그/명령어는 원문 유지)

Coding Standards

• Language: Dart/Flutter (SDK >= 3.0). Respect analysis_options.yaml (flutter_lints baseline).
• Style/format: use dart format . and keep changes minimal. Avoid one‑letter variable names; avoid inline comments unless requested.
• Structure: follow existing file/module patterns and naming. Do not introduce new frameworks or architectural shifts without approval.
• Tests: add or update tests when behavior changes or bugs are fixed (if feasible). Keep tests scoped to the change.

Validation

• Always run local checks via scripts/check.sh before proposing completion:
  • formatting check: dart format --set-exit-if-changed .
  • static analysis: flutter analyze
  • unit/widget tests: flutter test (ok if none exist)
• UI changes: include brief description of visual impact; screenshots if readily available by the user.

Sensitive Areas (require explicit approval)

• Android/iOS/macOS build configs, signing, bundle identifiers, Gradle/Kotlin/Swift project settings.
• Dependency graph changes (pubspec.yaml add/remove/upgrade).
• Network access, calling external APIs, or adding secrets.

Operational Conventions

• Branch naming: codex/<type>-<slug> (e.g., codex/fix-url-matcher).
• Commits: Conventional Commits preferred (e.g., fix: correct url matching for X).
• PR description template:
  • Summary: what/why
  • Changes: key files and decisions
  • Validation: how verified (analyze/tests/manual)
  • Risk & Rollback: potential impact and quick rollback steps

Task Template (author-provided)

Next: Complexity: simple | medium | complex

Context

• Problem / goal:
• Constraints / non‑goals:
• Repro or commands:

Done When

• Behavior verified (scripts/check.sh passes)
• Tests/docs updated if applicable

---

Commands

• Lint/analyze/tests: scripts/check.sh
• Auto‑format: scripts/fix.sh

References & External Facts

• Prefer official docs and code‑local references. If citing sources, include plain URLs or file paths in PR descriptions (avoid footnote citation syntaxes).

Notes from ~/.claude (adapted)

• Few‑shot examples improve accuracy; include small before/after or sample input→output when helpful.
• Use structured thinking internally; present only concise, actionable outputs here.