workspace-topology

Inspect, declare, and migrate code-to-docs workspace layouts across inline, shell, and linked modes.

Updated Jan 12, 2026
One-click install
npx skills add https://github.com/ab300819/keel-workflow --skill workspace-topology-ab300819
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: workspace-topology
Source: https://github.com/ab300819/keel-workflow/tree/main/skills/workspace-topology
Command: npx skills add https://github.com/ab300819/keel-workflow --skill workspace-topology-ab300819

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Teams that keep documentation and code in separate repositories (open-source maintenance, multi-repo development, pre-publication projects) lack a consistent way to declare where code lives relative to docs. This Skill manages that workspace layout declaration so downstream workflows always know which directories are code roots. ## Core Features & Use Cases - Topology inspection: Returns a structured workspace context (mode, resolved absolute code-root paths, missing roots) that orchestration layers pass to other skills. - Interactive declaration maintenance: The reconcile entry asks the user for mode (inline/shell/linked) and code roots, writes the workspace: block into AGENTS.md frontmatter, and self-validates with rollback on failure. - Repository migration: Converts a single-repo project into a shell layout with git submodules, including detached-HEAD guards, pointer-drift repair, and fail-closed validation. - Use Case: You maintain a fork of an open-source project and want your private docs in a separate shell repo. Run the skill to declare the submodule as a code root, then migrate the repo layout without polluting the upstream repository. ## Quick Start Ask the assistant to inspect the current workspace topology and declare whether code lives inline, in submodules, or in linked external directories.

Frequently Asked Questions about workspace-topology

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I separate documentation and code into different git repositories?

Declare a shell or linked workspace mode in the AGENTS.md workspace frontmatter block. Shell mode tracks code as git submodules owned by the repo, while linked mode references external directories the repo does not own. The reconcile flow asks for the mode and code roots interactively.

How to migrate a single repo into a git submodule shell layout?

Use the migrate entry with the target mode shell, choosing manual or auto mode. The process creates the shell repo, moves the code repo in, registers it via git submodule add, copies docs, validates the copy, then deletes originals, with rollback on validation failure.

What is the difference between shell and linked workspace modes?

Shell mode means the repository owns the code through git submodules with gitlink pointer tracking. Linked mode only records path references to directories the repo does not own, so there is no pointer bumping and no cross-repo traceability guarantee.

Why does committing inside a git submodule fail or lose work?

Submodules default to detached HEAD, where commits become orphaned and can be garbage-collected. The skill blocks commits in this state and instructs you to run git checkout <branch> inside the submodule first.

Can the tool automatically detect my repository layout?

No. Repository shape is treated as a product decision, so the skill asks the user instead of guessing. Filesystem scans only order the suggested options, such as preferring shell when .gitmodules entries exist.

What are the limitations of linked mode for traceability?

Linked mode performs no pointer bumps because there are no gitlinks, so the documentation repo cannot record which code commits correspond to a docs change. Projects needing that traceability chain should use shell mode instead.