70 lines
3.2 KiB
Markdown
70 lines
3.2 KiB
Markdown
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: <what to do>
|
||
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.
|