Install
$ agentstack add skill-anthonyalcaraz-agentic-graph-rag-skills-eight-pillar-readiness-map ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
Eight-Pillar Readiness Map
Overview
The dual-graph architecture is the structural framework; the eight pillars are the implementation roadmap — the specific capabilities that turn the framework into a working system. Each pillar emerged from a recurring production failure pattern, and the pillars are layered, not independent: knowledge representation (Ch3) must come first because every other pillar depends on the knowledge graph; memory (Ch4) builds on it; reasoning and planning (Ch5) require both; tool orchestration (Ch6) requires all of those; and the final two, self-evolution (Ch7) and optimization (Ch8), depend on the complete architecture being in place.
This skill takes a system's declared capability per pillar (present / partial / missing) and produces a readiness map:
- a readiness score (weighted across the eight pillars),
- dependency violations — a higher pillar claimed present while a lower one
it requires is missing (the chapter says this is structurally unsound),
- unresolved Chapter-1 flaws — mapping remaining gaps back to the five flaws
per Table 2-1 (relationship blindness, context amnesia, temporal ignorance, reasoning paralysis, tool chaos),
- the next pillar to build (always the earliest incomplete layer, because
building higher first creates a violation).
The DevOps agent's Chapter-2 initial state is the worked example: knowledge representation only partial (the data exists in logs and configs but is not a graph), everything else missing, all five flaws open. It is a "representation problem, not a technology problem."
When to Use
- Auditing an agentic-graph system's production readiness
- Planning the build order for a new agent (which pillar next?)
- Checking that a claimed capability is not resting on a missing foundation
- Tracking progress across the book's parts (each part adds a pillar-layer)
Phrases that should invoke this skill: "map the eight pillars", "which pillar should we build next", "is this agent production-ready", "pillar readiness", "what flaws are still unsolved", "eight-pillar audit".
When NOT to Use
- Building a single pillar. Each pillar has its own chapter and skills
(knowledge-representation/, memory/, reasoning-planning/, tool-orchestration/, self-evolution/). This skill maps; it does not build.
- Routing a request. Vertical-vs-horizontal routing is
dual-graph-router. - A generic org/AI maturity model. The eight pillars are specific to the
dual-graph architecture; do not repurpose this for unrelated capability grids.
- Scoring the QUALITY of a pillar. This tracks presence/partial/missing, not
how good a present pillar is — use the pillar's own evaluation skills for that.
Process
| Step | Input | Action | Output | Verification | |------|-------|--------|--------|--------------| | 1 | capability dict {pillar: present\|partial\|missing} | lib.assess(caps) | ReadinessReport | unstated pillars default to missing; invalid status raises ValueError | | 2 | statuses | lib.dependency_violations(statuses) | list of violations | a present/partial pillar with a missing required lower pillar is flagged | | 3 | statuses | lib.unresolved_flaws(statuses) | list of open flaws | a flaw is solved only if a solving pillar is fully present | | 4 | statuses | lib.next_pillar(statuses) | pillar key or None | the earliest not-present pillar in layer order | | 5 | — | lib.initial_state() | the DevOps Chapter-2 starting capabilities | KR partial; all others missing |
Rationalizations
| Agent rationalization | Documented rebuttal | |------------------------|--------------------| | "We built reasoning first because it is the interesting part — skip the graph for now." | The chapter is explicit: "Knowledge representation must come first because every other pillar depends on the knowledge graph." Reasoning present while KR missing is a dependency violation — the reasoning has nothing grounded to reason over. | | "Self-evolution is the goal, let's jump to Chapter 7." | Self-evolution "depends on the complete architecture being in place." It reads the observation record produced by the harness that the earlier pillars build. Claimed present on an incomplete stack, it is a violation, not a capability. | | "Tool orchestration solves tool chaos, so once we have it we are done with flaws." | toolchaos also needs structuredoutput at the tool/node boundaries (the impedance-mismatch pillar). A present toolorchestration with missing structuredoutput leaves toolchaos only partially addressed. | | "Partial on a pillar is basically present." | Partial means the flaw it targets is only partially addressed. The initial DevOps state has partial KR (data exists, unstructured) and still leaves relationshipblindness open — partial is not solved. | | "We can build the pillars in any order our team prefers." | The pillars are layered by dependency, not preference. Building out of order produces the dependency violations this skill exists to catch; the recommended next pillar is always the earliest incomplete layer. |
Red Flags
- A high readiness score with dependency violations. The weighted score can
look healthy while the layering is broken — always read the violations list, not just the percentage.
- Every flaw shows unsolved but pillars are marked present. The
status-to-flaw mapping drifted, or pillars were marked present without their dependencies — cross-check with the violations list.
- next_pillar skips ahead of a missing lower pillar. Impossible by
construction; if you see it, PILLAR_ORDER or depends_on was edited incorrectly.
- self_evolution or optimization shown as solving a flaw. They map to
production viability, not to any of the five flaws; a flaw mapping to them is a corruption of Table 2-1.
- CLI
--helpexits non-zero. SKILL.md / CLI mismatch; the multi-harness
invariant is broken.
Non-Negotiable Verification
- Run the benchmark battery.
`` python cli.py benchmark `` Confirm eight layered pillars, five mapped flaws, the initial state recommending knowledgerepresentation, the mid state solving the first four flaws while leaving toolchaos open, and the violation state flagging reasoning + self_evolution as resting on a missing foundation.
- Inspect the initial state visually.
`` python cli.py assess --system initial `` Confirm KR is partial, all others missing, all five flaws unsolved, and the roadmap starts at knowledge_representation.
- Confirm the layering catches a violation.
`` python cli.py assess --system violation `` Confirm reasoning and self_evolution are flagged as claimed-present-but- foundation-missing.
- JSON output round-trips.
`` python cli.py assess --system mid --json | python -c "import json,sys; json.load(sys.stdin)" `` No exception means the CLI is harness-portable.
Security Posture
- Prompt injection. Capability statuses are a small closed vocabulary
(present/partial/missing) validated on input; any other value raises ValueError rather than being interpreted. Pillar keys are validated against the fixed eight; unknown keys raise. There is no free-text execution surface.
- Data exfiltration. No network calls, no file writes outside the read-only
bundled sample-systems.json. The --json report goes to stdout; the caller owns downstream piping.
- Advisory only. This skill emits a report; it never edits the audited
system, installs a pillar, or grants a capability. A readiness score is not an authorization — the dependency-violation output is the safety signal (do not ship a system whose claimed pillars rest on missing foundations).
Source Attribution
Distilled from Agentic GraphRAG (O'Reilly, by Anthony Alcaraz and Sam Julien), Chapter 2 — Agentic Graph Architecture Foundations:
- "The Eight Pillars of Agentic Graph Architecture" — the eight pillars, their
layering, and why each exists (a recurring production failure pattern).
- Table 2-1 "Mapping the five flaws to the eight pillars" — relationship
blindness → knowledge representation; context amnesia + temporal ignorance → memory; reasoning paralysis → reasoning + planning; tool chaos → tool orchestration + structured output.
- "The Initial State" and "The Transformation Arc" — the DevOps agent's
fragmented starting point and the pillar-per-part progression.
This Reviewer-pattern skill audits the whole architecture; the per-pillar skills in the sibling chapter folders build the capabilities it maps.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: AnthonyAlcaraz
- Source: AnthonyAlcaraz/agentic-graph-rag-skills
- License: MIT
- Homepage: https://www.oreilly.com/library/view/agentic-graphrag/9798341623163/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.