A place for each kind of knowledge
Instructions that matter in every session belong in a short entry file. Current work belongs on a board. Tool details stay behind pointers until the task needs them. Repeatable work becomes a skill, then a script when its steps can be made deterministic.
The structure is a starting point. Your stack, conventions and recurring work determine what belongs inside it.
What is inside the release candidate
- A four-layer structure for standing instructions, current state, reference material and execution.
- Local onboarding that writes an operator profile, records the declared stack and selects the relevant conventions and connector notes after review.
- Seven declarative, one-way PM mappings for Linear, Jira, Asana, Notion, Monday, ClickUp and GitHub Issues, with dry runs and mock-tested transports.
- Local document intake and structure advice for plain text, Markdown, HTML, Confluence, Notion exports and Google Docs HTML exports.
- Snapshot-based marketing operations tools for a dependency graph, declared-versus-snapshot drift and evidence-based wrap.
- Eight GTM pattern skills plus local recipes for field audits, company deduplication and UTM checks.
- Checks for artifact conformance, malformed work items, missing completion evidence and stale sourced references.
This is a local first-release candidate. Onboarding does not connect to a platform. PM mappings are one-way projections tested with mocked responses; they still need tenant configuration and live verification before use. The operations graph, drift report and wrap read declared snapshots rather than live systems. Document advice evaluates structure and writes local review files; it does not publish or decide whether the content is correct or current.
| Knowledge | How to handle it |
|---|---|
| Shared practice | Start with the loading discipline, file shapes and working checks. |
| Your context | Record your stack, owners and conventions. These answers come from your team. |
| External facts | Keep a source and verification date. Refresh vendor information instead of treating an old copy as current. |
Make the failure visible
| What can go wrong | What catches it |
|---|---|
| The entry file grows with every task | A context-budget check using a stated character-count estimate |
| Skills acquire different shapes | Required fields and sections checked for conformance |
| A completed item has no evidence | A board validator that refuses missing evidence |
| A task starts without a prerequisite | A local access preflight with an actionable refusal |
| A document conversion drops content or activates an unsafe reference | Preservation and output-safety tests across the supported local intake formats |
Some checks remain a human responsibility. A credential variable being present does not prove its permissions. Mock tests do not establish a vendor tenant's behavior. A passing test does not prove the test covers the right behavior. Review the evidence at the end of a session and archive material that no longer describes the work.
What one hygiene pass changed
In one internal ax1om repo audit, eager context fell from 14,787 to 4,726 tokens. Session-start reads fell from 26,560 to 6,914 tokens.
Where ax1om fits
The repo organizes agent-assisted work. When that work calls for models trained on your outcome history, ax1om is a modeling engine for AI agents. An ax1om account is not required to use the repo.
Get the repo
Request free, read-only GitHub access. Tell us your GitHub username, company and what you plan to work on. Personal email addresses are welcome.
We will email about this access request even if you do not opt in to news. You decide whether to accept the GitHub invitation. We do not track invitation acceptance.