agentic-praxis-grimoire

Synthesizing Repository Guidance

Core principle

Classify and disposition; do not rewrite or migrate. Split mixed content into coherent guidance units, then prefer the smallest existing owner that fully covers each unit. Source authority, repetition, file boundaries, and private skill boundaries are evidence to inspect; none establishes public adoption or a new capability by itself.

Do not use

Do not use this skill to author a technically valid skill after its owner, trigger, scenario contract, and destination are accepted; use native Codex skill-authoring guidance and the repository’s authoring lifecycle. Do not use it for a simple documentation edit, direct implementation or debugging, or one already coherent project-local policy change.

It does not own automatic root reduction, one-to-one private-skill migration, personal or machine integration management, or immediate cutover, deletion, publication, or decommissioning. It is not a standards generator, migration engine, or implementation authority.

Procedure

Establish the human authority, source scope, applicable instructions, and desired decision boundary. Classification cannot broaden them.
Snapshot or otherwise identify the bounded source corpus without changing it. Record coverage and intentional exclusions.
Classify source ownership, publication eligibility, reuse rights, privacy, and any required notices. Keep authority and reuse permission distinct.
Split mixed content into coherent guidance units. Give each unit a stable local identifier; use split-required until a misleading combined unit is separated.
State the concrete problem and applicability scope of each coherent unit. Do not infer a reusable problem solely from sensitive or personal context.
Inspect the smallest plausible current owners: existing APG skills, native capabilities, root policy, core documentation, deterministic tooling, language-profile candidates, project policy, and private overlays.
Resolve governing authority, precedence, conflict, and material overlap before selecting an owner. Preserve the higher authority rather than synthesizing a weakening compromise.

Assign one proposed owner and one bounded disposition to each coherent unit. Use only the vocabulary below unless the project has accepted a narrower equivalent:

retain-root
route-existing-owner
synthesize-existing-owner-correction
candidate-new-skill
candidate-language-profile
core-documentation
deterministic-tool-candidate
project-owned
keep-private
evidence-only
defer
reject
split-required
blocked-source-or-rights

Record source class, source and rights status, current and proposed owners, authority result, conflict or overlap, acceptance evidence, migration dependencies, rollback or restoration boundary, and public/private treatment for every unit.
Identify units that require a future skill, profile, architecture, or roadmap decision without accepting or authorizing that decision. Prefer an existing owner; apply the repository’s new-capability threshold before proposing another skill.
Produce a public-safe aggregate summary and, only when required, a bounded private exact ledger. Do not copy private, sensitive, or externally protected expression into either result.
Leave all source instructions unchanged until a separate accepted migration defines shadow behavior, discovery, overrides, cutover evidence, rollback, and restoration.

Project-owned parameters

The task and repository own migration and implementation authority, instruction precedence, source scope, public/private boundaries, licensing interpretation, the accepted skill catalog, language-profile status, exact commands, versions, frameworks, test gates, cutover timing, release policy, destructive actions, and private-overlay ownership.

This skill proposes destinations; the project model owns the destinations, provenance policy owns source and rights facts, the accepted authoring lifecycle owns skill creation and behavior-bearing correction, and native skill-writing guidance owns technical file construction after acceptance.

Evidence and completion

A completed result records inventory coverage and exclusions, a disposition map, source-rights and privacy classification, conflicts and precedence, current and proposed owners, acceptance evidence, implementation or migration prerequisites, rollback or restoration boundaries, and unresolved blockers. For each coherent unit, retain one stable identifier and one disposition.

State explicitly that a disposition grants no implementation authority and that no source rewrite, removal, migration, or cutover occurred. A table plus short detail sections is sufficient; JSON, a database, or a universal registry is not required.

Stop or escalate

Stop copied or adapted work when source identity or reuse rights are incomplete. Stop, defer, or keep the unit private when source authority is unclear; sensitive personal detail is material; the public/private boundary cannot be preserved; governing instructions conflict; project policy cannot be distinguished from reusable procedure; a new skill or architecture decision is required but unauthorized; a cutover would remove the only current owner; or the requested output crosses from classification into implementation.

Bounded independently written analysis from observable facts may continue when rights permit it, but do not invent provenance, permission, or notices.

Common mistakes

Mirroring source files or private skills one to one.
Treating repeated prose as a capability requirement.
Using a native skill writer before ownership is decided.
Assigning one owner to mixed content.
Copying private or external wording.
Publishing personal, sensitive, or machine guidance.
Rewriting before disposition review.
Treating a candidate or disposition as accepted authority.
Creating a broad coding-standards encyclopedia.
Hiding exact project parameters in public procedure.
Deleting source instructions without shadow, rollback, and restoration evidence.

This site is open source. Improve this page.