Make product direction, decisions, and context travel at the same speed as creation. AI-native knowledge ops for roadmaps, journeys, decisions, and cross-role handoffs. Vendor-neutral. No database. Lives in your repo.
The repository-backed operating model: governance layers, process loops, policies, and templates. Humans decide, agents execute, Git governs.
Pillar 02 — The Knowledge LayerThe layered, vendor-neutral knowledge-ops spec with the /kb command — keeps humans and agents on the same page.
The production-ready engineering loop that schedules tasks, resolves rebase conflicts, and verifies code via tests.
The quickest credible adoption story is not a bigger architecture pitch. It is one short path a team can run and inspect.
Wire one harness into its documented native command or skill surface.
Create one anchor layer plus one adjacent shared layer with the same file contract.
Turn one source into a finding/topic update that another human can review.
Exercise the shared loop once so the governance story is visible, not implied.
Regenerate reports and run the repo-owned fixtures that prove the same path in CI.
If a team already runs on GitHub Issues, Projects, and pull requests, /kb setup can generate a generic governance profile instead of leaving adopters to invent the issue/project/PR rules themselves.
Feedback, ideas, decisions, tasks, bugs, features, roadmap items, content updates, and governance changes get typed intake.
The PR template ties changes back to tracker items, KB artifacts, validation, changelog impact, and safe review.
A workflow checks template syntax, unresolved placeholders, linked issues or explicit exceptions, version-impact policy, and skill presence.
A repo-local tracker workflow skill teaches agents the same issue/project/PR rules that CI and reviewers enforce.
Setup also stages a path labeler and a manual checklist for native issue types, project/status fields, labels, milestones, branch protection, CODEOWNERS, parent/sub-issues, and required checks. The profile stays generic: no organization names, product-specific labels, or hardcoded project IDs.
Your agents made you 10× faster at creating. Nothing made you faster at deciding. The bottleneck didn't move to design, quality, or testing.
It moved to convergence.
Creation at agent speed. Decisions at human speed. That gap is where budgets burn, alignment erodes, and smart teams end up running in three directions at once.
Product direction is where the gap becomes painfully visible: roadmaps drift from delivery reality, journeys live in slides instead of source control, and stakeholder alignment depends on who saw the latest deck.
agentic-kb is the piece of the fix that puts roadmaps, journeys, decisions, ideas, goals, and context on the same rails as the output — so a human at any level can stay in the loop with a swarm of agents and a team of other humans, without becoming the bottleneck.
An architecture constructed for long-term ownership, simplicity, and zero friction.
Plain Markdown in a git repo. Your KB versions like code, reviews like code, diffs like code. If a folder can read it, this works.
No SaaS. No auth. No infra. Your knowledge stays on your disk. If the vendor disappears tomorrow, your KB is still there.
Claude Code and VS Code have marketplace/native plugin paths. OpenCode, Gemini, and Kiro get installer-backed native entrypoints. Codex uses the same repo contract via AGENTS.md plus a reusable kb skill.
One spec. One plugin with four reference skills. One reference agent. One installer. Install in about a minute. Rip it out in five if it's not for you.
You don't have to be "fully agentic" for agentic-kb to pay off. Same contract at every stage — the agent just does more of the filing work the higher you go.
Human-only baseline. Just git + markdown + the agentic-kb directory contract. No agents required. You get audit trail, decision lifecycle, and cross-role handoffs for free, just by writing into the right files.
The /kb evaluation gate fires on capture; agent proposes where things belong; humans approve before anything persists. The handoff surfaces stay yours.
Scheduled rituals, guarded auto-promote on confidence, exception escalation. Humans review only flagged items, not every line.
agentic-kb is the knowledge-ops layer of an agentic enterprise — it owns Strategy, Product Direction, Design, Delivery, Operations, and Learning artifacts (foundation, roadmaps, journeys, briefs, specs, decisions, findings, topics, reports, releases, incidents) and pairs cleanly with any repo-as-OS framework that owns the work-flow side (signals, missions, PRs, releases) — for example agentic-enterprise with its execution loop agentic-dev. Standalone is also a valid stop — capture-discipline-only is not a half-installed product.
Right move for most teams: Start at Stage 1, graduate when steady, never skip ahead.
A workspace is a layer graph, not a fixed ladder. Each layer has a name, a scope, a role, and a parent edge. Knowledge flows up via promote; context flows down via digest. Here is the most common shape — your graph can have fewer or more layers, and your anchor (the layer that holds .kb-config/) does not have to be personal.
alice-personal
contributor
team-observability
contributor
engineering-org
contributor
company-guidance
consumer · read-down only
At least one contributor-capable layer is required. A personal anchor is recommended but not mandatory. promote and publish into a consumer layer are refused with a clear message.
Marketplaces are cross-cutting, not a slot in the chain. Any layer can attach its own marketplace repo for skills it wants to share with that audience.
Applied at every persistence boundary. This is the system's immune system — nothing persists without earning its place.
Every primitive is a file with a contract. Layers opt in to the ones they need.
Dated, immutable snapshots. The evidence base.
Living positions. Updated in place with changelog.
Open or resolved choices with evidence trail and stakeholders.
Incubation objects. Seed → growing → ready → shipped.
Meeting and working notes — first-class, not chat noise.
Focus and backlog with explicit creation and closure.
Identity: who you are, your context, sources, stakeholders.
Parallel tracks with their own themes and active decisions.
Phase/lane plans that reconcile customer value, plan truth, and delivery reality.
User, customer, operator, or product flows that ground roadmap scope in lived experience.
Briefs and specs that make direction executable without losing intent.
Release and incident records that feed learning back into the KB.
/kbThe agent infers the layer and action from context. No subcommand memorization needed.
/kb [text]
Capture + evaluate input
/kb review
Process inbox items
/kb promote [file] [layer]
Promote upward to parent layers
/kb digest [layer]
Pull parent-layer changes
/kb digest connections
Pull repo / tracker deltas
/kb note meeting [topic]
Start a meeting note
/kb note retro [topic]
Start a retrospective
/kb idea [text]
Create new incubation idea
/kb develop [idea]
Sparring session on idea
/kb decide [desc]
Open decision tracking
/kb brief [title]
Frame delivery intent
/kb spec [title]
Open design contract
/kb release [title]
Record rollout and rollback logs
/kb incident [title]
Capture impact and follow-ups
/kb task
Show focus items list
/kb start-day
Morning briefing summary
/kb end-week
Weekly summary builder
/kb present [topic]
Generate HTML slides
/kb report progress [scope]
Generate cross-source reports
/kb migrate layer-model
Migrate legacy ladder → graph config
/kb setup
Onboarding setup wizard
Two product-management subcommands ship with the same plugin and activate only after setup derives or you confirm their owning layer:
/kb roadmap
Customer-value phase/lane roadmap (MD + HTML + JSON)
/kb journeys
Author + render user/customer/operator journeys with extractable mocks
The same marketplace install ships roadmap and journey skills next to the core. Setup proposes them when your role, goals, sources, or desired outputs imply roadmap or journey work; expert users can also add the config blocks manually. Same `/kb` surface, no second install.
/kb roadmap · kb-roadmapTurns dense planning and delivery inputs into a customer-value roadmap: lanes, phases, confidence state, and traceability in one artifact. Emits Markdown, HTML, and JSON, with value-first headlines and explicit proposed/agreed/shipped status.
/kb journeys · kb-journeysAuthors hierarchical journeys (journey → phase → sub-journey → step) with entry/exit conditions, interfaces, and per-step readiness. Journeys become the product-management ground truth that roadmap items cite, review, and move forward.
Both skills share an authoring arc — ideate · discuss · review · refine — and treat the journey as the third party in every roadmap critique when both are enabled.
Moving beyond plain text to structured planning primitives.
Tracked with evidence trails, stakeholders, RACI, and due dates. Not buried in prose.
Observations with novelty value get incubated. The agent plays devil's advocate via /kb develop.
One source of skills and commands feeds every documented harness tier. The workflow stays the same even when the invocation surface changes.
.claude/skills/
.github/skills/
.opencode/skills/
.gemini/commands/
.kiro/skills/
.agents/skills/ + AGENTS.md
Claude Code exposes a stable native /kb install path. VS Code Copilot Chat exposes a Preview path (chat.plugins.marketplaces) plus a stable installer fallback.
OpenCode, Gemini CLI, and Kiro IDE get their documented command or skill entrypoint from scripts/install.
Codex CLI uses the same workspace contract through AGENTS.md plus the installed kb skill.
Pick the installation flow that matches your developer setup.
/plugin marketplace add https://github.com/wlfghdr/agentic-kb
/plugin install kb@agentic-kb
/kb setup// user-level settings.json
"chat.plugins.marketplaces": [
"wlfghdr/agentic-kb"
]
// install from Extensions view, then:
/kb setup
// Stable alternative:
// scripts/install --target vscodegit clone https://github.com/wlfghdr/agentic-kb
cd agentic-kb
scripts/install --target <harness> --global
# then: /kb setup
/kb setup walks you through name, role, workstreams, layer graph, branding, and optional integrations. See the README for the full per-harness install matrix.