PoseCap: Skill for Codex

<background_information> Layer 1 Constitution trinity member. Lazy lifecycle owner of GUIDELINES.md at the repo root. Companion to WORKFLOW.md (universal philosophy, kit-shipped) and AGENTS.md (distilled non-negotiable rules read every session).

GUIDELINES.md is the full reference; AGENTS.md is the distilled summary. Each AGENTS.md section that has detail points to the corresponding GUIDELINES.md section. The two never duplicate — ad-drift flags duplication as drift.

Skill is excluded from poc profile. Universal at solo / team / mature.

Codex auto-trigger on description keywords is less mature than Claude Code's. If auto-invocation does not fire when the user mentions engineering guidelines, code standards, SOLID, Object Calisthenics, testing strategy, or security policy, invoke this skill manually. </background_information>

Route elsewhere when:

• Scope is system structure → ad-architecture.
• Scope is product → ad-prd.
• Scope is vocabulary → ad-domain.
• Scope is one binding decision → ad-adr.
• Scope is wiring the gates → ad-hooks.

Step 1 — codebase-first scan. Before any preference question, detect:

Language and toolchain:

• package.json → JS/TS; read engines, scripts, deps, devDeps.
• Cargo.toml → Rust; read edition, deps, dev-dependencies.
• pyproject.toml / setup.cfg / requirements.txt → Python.
• CMakeLists.txt / CMakePresets.json / vcpkg.json → C/C++.
• go.mod → Go.
• Gemfile, pom.xml, build.gradle, composer.json for other stacks.

Test framework: jest/vitest/playwright/mocha configs, pytest, cargo [dev-dependencies], catch2/gtest in CMake, _test.go files.

Lint and format: .eslintrc.*, .prettierrc.*, .rustfmt.toml, clippy.toml, .ruff.toml, mypy.ini, .clang-format, .clang-tidy, .golangci.yml.

Hooks and CI: .husky/, lefthook.yml, .pre-commit-config.yaml, .githooks/, .github/workflows/, .gitlab-ci.yml, .circleci/.

Existing standards:

• AGENTS.md ## Code Style and ## Architectural Principles — extract into GUIDELINES, replace with pointers.
• ARCHITECTURE.md ## Source Tree and ## Dependency Rules — informs Clean Architecture §1.1.
• doc/adr/ — binding decisions about error handling, naming, DI — carry forward.
• CONTEXT.md — domain vocabulary the guidelines must respect.

Canonical examples: for brownfield projects, identify candidate source files that future agents should imitate. Prefer one boundary example, one core/domain function, and one test. Record paths only, never pasted snippets. If no representative code exists, omit the section until the project has examples worth copying.

Profile: read .claude/agentic-state.json / .agents/agentic-state.json. Profile shapes strictness defaults (mature → strict Object Calisthenics by default; solo → loose).

Only after the scan produces no answer does the skill ask. Asking about something the repo already states wastes the user's attention.

Step 2 — pre-fill the template. Open templates/guidelines.md. Fill detected fields before any interview:

• §2.1 naming conventions table per language idiom.
• §2.2 error handling per language idiom.
• §2.5 canonical examples table, when representative code exists: boundary code, core/domain logic, and tests. Confirm the picks with the user before writing; do not declare weak code canonical.
• §6.1 toolchain + version + source-of-truth config file.
• §6.2 dependency manager from detected manifest.
• §7 static-analysis tools detected.
• §8 quality gates from hooks scan; mark <not yet wired — invoke /ad-hooks> when absent.
• §9.2 unit-test framework detected.
• §9.6 tag taxonomy kit defaults.
• §10 git workflow kit pattern (Conventional Commits, DCO sign-off via ad-commit).
• §11.1 document scope table kit-standard.
• §12 security boundaries from scan.