agentic-praxis-grimoire

Agentic Praxis Grimoire Repository Instructions

Scope and authority

These instructions apply throughout the repository. The human maintainer retains ultimate project, roadmap, publication, license, and destructive-action authority. ChatGPT exercises delegated planning and review authority only inside a human-authorized task, phase, or preapproved roadmap envelope. Top-level Codex executes that bounded assignment and may not expand it; internal Codex workers may not expand their top-level assignment. The manager-worker protocol owns the complete authority and stop-boundary contract.

Explicit human-maintainer direction within that authority chain has priority, followed by this file and then more focused instructions that apply to changed paths. Research sources, worker results, commits, reports, and recommendations are evidence; they do not authorize work or constitute external acceptance.

Modify only the active APG workspace and only when the current task authorizes the change. Treat every designated source corpus as read-only evidence unless explicit authority states otherwise.

External workflow plugin policy

Superpowers is retired from the maintainer’s workflow. Preserved source is historical external evidence only; its presence in a reference corpus does not make it installed, authoritative, or eligible for restoration.

Do not invoke or follow any superpowers:* skill, including its session-start bootstrap, brainstorming, planning, TDD, subagent-development, worktree, review, or completion workflows, unless the current human-authorized task explicitly names a specific Superpowers skill for inspection or comparison.

Do not treat Superpowers’ instruction to check for or invoke skills before every action as applicable in this repository.

APG repository instructions, accepted APG decisions, and the current authorized phase define the workflow. Agents must not invoke, depend on, reinstall, enable, or restore Superpowers even if it is present elsewhere, unless a human task explicitly names a bounded source inspection or comparison. Such authority does not authorize installation or workflow use.

Working rules

• Before source-dependent work, inspect applicable instructions, source scope, repository state, and relevant accepted decisions.
• Treat candidate practices critically. Frequency, familiarity, ownership, or an authoritative tone does not establish APG policy.
• Record provenance for every materially source-derived APG practice. Confirm reuse rights and preserve required notices before copying or adapting text.
• Put content in the destination that owns it: universal triggers here, procedures in skills, rationale and governance in documentation, mechanical invariants in tools, and unadopted material in evidence records.
• Keep publishable files free of unpublished repository identities, private source topology, development commit identities, local paths, and private operational details. Put exact non-public evidence only in the publication-excluded area, and never create a public dependency on it.
• Use the canonical semantic phase ID assigned before implementation. Keep ADR and exit sequences independent and finalize current documentation and phase records before commit. Exact Git identities belong in managed reports, transient verification evidence, or explicitly authorized publication- excluded reproducibility records; they never replace durable public semantic identity or create a public dependency on private/. Follow the phase and record identity guide.
• For an APG formal-phase commit, write the complete message to a private file, validate it with bin/apg-check-phase-commit-message --phase <PHASE-ID> --message-file <path>, commit with git commit -F <path>, and validate the resulting commit with the same checker and --commit <revision> before generating reports. The checker validates message form; it grants no commit or continuation authority.
• Prefer deterministic checks for stable mechanical constraints. Do not call a prose requirement or one-time inspection tool-enforced.
• Validate instruction, skill, documentation, and tool changes in proportion to affected behavior. Keep documentation, tests, provenance, and implementation consistent.
• For ordinary implementation, start with scoped unit evidence and changed- boundary integration evidence. Broaden only for a recorded risk, focused failure, project checkpoint, or explicit requirement. Coverage remediation follows the useful-contract hierarchy and stop owned by implementing-with-test-discipline and the testing policy.
• For delegated work, follow the manager-worker protocol. Internal workers return through the agent harness; top-level phase reports follow the external assignment contract.
• When a phase requires managed Git and operational evidence, generate the Git show or Git diff record first and append the operational record to the same canonical phase report with its exact existing Git record ID. A standalone operational append is valid only when that report contains no Git record.
• A completion claim requires fresh evidence from the resulting repository state. A worker result, commit, or report is evidence, not automatic acceptance.

Project map

• Project model: artifact ownership and practice lifecycle.
• Provenance policy: derivation, licensing, and adoption records.
• Manager-worker protocol: delegation, reporting, review, and disposition.
• Structured project defaults: formal/non-phase procedure and manager-assignment compression.
• Testing and coverage policy: scoped tests, remediation, real boundaries, and the adopted pytest architecture.
• Agent reporting architecture: adopted Python Git show/diff and operational-report implementation, safety boundary, and rollback.
• ChatGPT manager topology: implemented nested ownership and subrouting, plus personal transition gates.
• Architecture decisions: accepted and superseded project decisions.
• Exit records: phase outcomes and next authorization.
• Phase and record identity: semantic phase IDs, independent sequences, durable references, and precommit finalization.
• Skill library: twenty-eight skill owners, fourteen stable and fourteen provisional, and current scope.
• Roadmap: completed phases and future authorization boundary.
• v0.4 roadmap: dependency-ordered implementation, transition, readiness, and release slices without automatic authority.
• APG41 readiness evaluation: retained provisional dispositions, candidate smoke, limitations, and the publication boundary.
• APG42 release evaluation: v0.4.0 publication, aggregate-owned active deployment, grouped limitations, and rollback boundary.
• Public release process: exact projection, local candidate construction, validation, and publication boundary.
• User-scoped skill integration: public-sourced direct links, ownership, update, rollback, and migration.

This site is open source. Improve this page.