vnahornyi/ai-god

Single source of truth for my coding-agent setup: global instructions, skills with their
references, the cross-session workflow and per-runtime adapters. Shared content is written once and
linked into Claude Code, Codex, and GitHub Copilot CLI and VS Code. Runtime configuration directories
only hold symlinks into this repo.
Everything private — project memory, project rules and skills, company standards, personal settings
— lives in a git-ignored local overlay, local/, which is its own private repo. The public tree
works without it; bin/check-public keeps the overlay's material out of public commits.
## Architecture
SHARED — what, when, why
global/AGENTS.md (invariants: git, facts, memory, overrides)
skills/ai-workflow (router: stage → skill, domain triggers, capability classes, plan lifecycle)
skills/wf- (stages: plan, implement, review, peer-review, estimate, jira-task, worklog)
skills/ (domain knowledge: frontend-craft, figma-inspect, design-patterns, …)
local/ (private overlay, git-ignored): memory/ , projects/ (rules.md + project
skills, linked only into that project), company/, claude/settings.json, public-denylist.txt
┌──────────────────┼──────────────────┐
▼ ▼ ▼
adapters/claude adapters/codex adapters/copilot
Claude Code Codex Copilot CLI + VS Code
runtime + settings runtime + rules runtime capabilities
Three kinds of rule, three homes:
| Kind | Example | Lives in |
| Shared invariant | never invent facts · commit only on approval · never push · plan is self-contained · review is independent · worklog is never padded · architecture checked against the real code | AGENTS.md, skills |
| Runtime-specific | how to use subagents and models · browser tools · permissions and sandbox · worktrees · context signal · how a session is started | adapters/ /runtime.md (+ settings/rules) |
| Model-specific | planning and higher-risk review need frontier reasoning · implementation and routine review need a strong general model · mechanical work needs a fast one | skills/ai-workflow/references/model-policy.md by class; concrete models only in the adapters' "Model mapping" |
The workflow is the invariant; runtime and model are details. One runtime is used at a time and the
developer switches between them deliberately (month to month). A task started in one continues in the
other, using the task conversation and repository state. A planned task has one temporary plan file
while implementation is active; no state, handoff, segment, review, or escalation files exist.
global/AGENTS.md tells every runtime to load ai-workflow first. The router names one stage skill and
only the domain skills its triggers allow — "review this PR" loads wf-review (+ frontend-craft
review mode for React), not planning, estimation or worklog. Skill descriptions are always in
context, so they stay short and say when not to load.
The workflow never recommends another runtime; independence comes from a fresh session.
PLANNING ─▶ IMPLEMENTING ─▶ INDEPENDENT REVIEW ─▶ APPROVED FIXES (if any) ─▶ DONE
FRONTIER STRONG FRONTIER decides each fix ─▶ STRONG implements it
fresh context; no implementation history
Human setup: this file.
Agent runbook (hand it to any supported runtime to install/verify for you): INSTALL.md.