Platform Notes
- Optional helper plugins may help in some environments, but they must not be treated as required for this skill.
Doc Architect
Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.
Use When
- Generate Triple-Layer AGENTS.md documentation by scanning a project for its tech stack, data directory, and planning directory. Use when the user asks to standardize project documentation, generate agent files, or create AGENTS.md guides.
- The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.
Do Not Use When
- The task is unrelated to
doc-architect or would be better handled by a more specific companion skill.
- The request only needs a trivial answer and none of this skill's constraints or references materially help.
Documentation Intake Guidance
- Gather relevant project context, constraints, and the concrete problem to solve; load
references, templates, protocols only as needed.
- Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.
Documentation Method Detail
- Read this
SKILL.md first, then load only the referenced deep-dive files that are necessary for the task.
- Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.
- Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.
Quality Standards
- Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.
- Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.
- Prefer deterministic, reviewable steps over vague advice or tool-specific magic.
Legacy Documentation Pitfalls
- Treating examples as copy-paste truth without checking fit, constraints, or failure modes.
- Loading every reference file by default instead of using progressive disclosure.
Documentation Deliverable Detail
- A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.
- Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.
- References used, companion skills, or follow-up actions when they materially improve execution.
Evidence Produced
| Category |
Artifact |
Format |
Example |
| Release evidence |
Triple-Layer AGENTS.md output |
Generated AGENTS.md covering project tech stack, data directory, and planning directory layers |
AGENTS.md |
References
- Use the
references/ directory for deep detail after reading the core workflow below.
- Use the
templates/ directory when the task needs a structured deliverable.
- Use the
protocols/ directory for formal execution order or handoff rules.
Design and generate a portable Triple-Layer AGENTS.md documentation set that reflects the project’s real structure and constraints.
When generated documentation must describe system boundaries, workflows, requirements, data architecture, interfaces, states, business rules, or design-system conventions, load systems-process-requirements and use its artifact router before writing the docs.
Modularize Instructions (Token Economy): Avoid consolidating all AI/dev guidance into a single CLAUDE.md. Prefer smaller, focused docs (e.g., docs/setup.md, docs/api.md, docs/workflows.md) and reference them only when needed.
Documentation Standards (MANDATORY): ALL generated markdown files must follow strict formatting rules:
- 500-line hard limit - no exceptions for any .md file
- Two-tier structure: High-level TOC (Tier 1) + Deep dive docs (Tier 2)
- Smart subdirectory grouping for related documentation
- See
doc-standards.md for complete requirements
Core Outcome
Inputs
| Input |
Source/provider |
If absent |
| Repository structure, manifests, existing instructions |
Workspace inspection |
Mark the technology or directory unknown; do not invent it |
| Authority to create or update AGENTS.md files |
Requester |
Return a plan only |
Capability Contract
Inspection is read-only by default. Creating directories or changing instruction files requires explicit authority; deletion and unrelated documentation changes are out of scope.
Documentation Fallback Notes
Without full workspace access, produce a partial documented map with unknown areas named; do not claim the three layers are complete.
Decision Rules
| Choice |
Action |
Failure/risk avoided |
| Data directory is evidenced |
Place data instructions there |
Arbitrary path |
| No planning directory exists |
Propose location before creation |
Unauthorised structure |
| Rules conflict |
Escalate and preserve both sources |
Silent contradiction |
Documentation Correction Examples
- Inventing a technology stack; inspect manifests.
- Copying generic rules; bind them to evidence.
- Placing files arbitrarily; use discovered boundaries.
- Editing without authority; return a plan.
- Hiding conflicting instructions; escalate them.
Worked Example
If no schema directory exists, the output proposes a data-layer location and records the gap instead of creating one silently.
Core Outcome
Produce three aligned AGENTS.md files:
- Root AGENTS.md: Project identity, tech stack, global standards
- Data AGENTS.md: Data integrity rules and schema governance
- Planning AGENTS.md: Spec-driven development workflow
Trigger Phrases
The skill should activate when the user asks to:
- Standardize project documentation
- Generate agent files
Standard Operating Procedure (SOP)
Scan the workspace
- Inspect the root for identifiers (README, PROJECT_BRIEF, TECH_STACK, ARCHITECTURE, CLAUDE, package.json, composer.json, *.sln, pyproject.toml).
- Locate likely data directories (database/, schema/, migrations/, sql/, db/).
- Locate planning/documentation directories (docs/, docs/plans/, planning/, specs/).
- Identify module/area entry points (menus, docs, feature folders) to group specs.
- Note template conventions (public/ as web root, per-panel includes, API outside public).
Identify the environment
- Determine primary language (PHP/C#/Python or other).
- Determine DB type (MySQL/PostgreSQL/SQLite/SQL Server/other).
- Determine deployment environment (Docker/Kubernetes/shared hosting/cloud).
Set up plan grouping (first-time)
- Create
docs/plans/<module>/ subdirectories for each discovered module/area.
- Update
docs/plans/AGENTS.md with the current module list.
- Create or update
docs/plans/INDEX.md as the master plan status index.
- Ensure the index includes status, urgency, last implementation date, and last modification date.
- Keep
docs/plans/AGENTS.md updated whenever plans are added or their status changes.
- Maintain a folder map at the top of
docs/plans/AGENTS.md and update it when requested.
- Note that developers can add new folders and update the list manually.
Generate Triple-Layer docs
- Use the templates in templates/root-agents.md.template, templates/data-agents.md.template, and templates/plan-agents.md.template.
- Populate with real findings and pull constraints from references/logic-library.md as needed.
- Create files at:
- Root: AGENTS.md at project root
- Data: database/schema/AGENTS.md (or best-fit schema directory)
- Planning: docs/plans/AGENTS.md (or best-fit planning directory)
Bundled Resources
- protocols/workflow.md: 3-step workflow used during generation
- templates/root-agents.md.template: Root AGENTS.md template
- templates/data-agents.md.template: Data AGENTS.md template
- templates/plan-agents.md.template: Planning AGENTS.md template
- references/logic-library.md: Domain constraint library for reuse
Common Pitfalls
- Do not invent tech stacks. Only infer from files found in the workspace.
- Do not place AGENTS.md in arbitrary locations; follow the best-fit paths above.
- Do not include contradictory rules across the three layers.
Quick Example
If a project uses Laravel + MySQL with docs/plans and database/schema:
- Root: AGENTS.md → PHP/Laravel, MySQL, deployment standards
- Data: database/schema/AGENTS.md → referential integrity, no-delete rules
- Plans: docs/plans/AGENTS.md → spec.md format and workflow steps
Cross-References to SDLC Skills
When generating AGENTS.md files, be aware of the complete SDLC documentation ecosystem:
SDLC Documentation Skills
| Skill |
Phase |
Documents Generated |
When to Reference |
sdlc-planning |
Planning |
Vision, SDP, SRS, SCMP, QA Plan, Risk Plan, Feasibility |
When plans directory contains SDLC planning docs |
sdlc-design |
Design |
SDD, Tech Spec, ICD, Database Design, API Docs, Code Standards |
When referencing architecture and design decisions |
sdlc-testing |
Testing |
Test Plan, Test Cases, V&V Plan, Test Report, Peer Reviews |
When referencing testing and quality standards |
sdlc-user-deploy |
Delivery |
User Manual, Ops Guide, Training, Release Notes, Maintenance, README |
When referencing deployment and user documentation |
Related Documentation Skills
| Skill |
Purpose |
Relationship |
project-requirements |
Raw requirements interview |
Input source for SDLC planning docs |
systems-process-requirements |
Systems/process/requirements modeling |
Supplies boundary, workflow, state, interface, data, business-rule, and traceability discipline for documentation |
feature-planning |
Feature-level specs + implementation plans |
Stored in docs/plans/ (planning directory) |
manual-guide |
End-user manuals and guides |
Stored in /manuals/ (separate from AGENTS.md) |
update-claude-documentation |
Keep project docs (README, CLAUDE.md) updated |
Maintains project-level docs after changes |
SDLC Output Directory Structure
When scanning for documentation, expect this structure in projects using SDLC skills:
docs/
├── planning/ # sdlc-planning output (7 docs)
├── design/ # sdlc-design output (6 docs)
├── testing/ # sdlc-testing output (5 docs)
├── user-deploy/ # sdlc-user-deploy output (6 docs)
├── plans/ # feature-planning output
│ ├── AGENTS.md # Plans directory index (doc-architect manages this)
│ ├── INDEX.md # Plan status tracker
│ └── specs/ # Feature specifications
└── project-requirements/ # project-requirements output
Integration Rule: When generating the Planning AGENTS.md (docs/plans/AGENTS.md), include references to any SDLC documentation directories that exist alongside the plans directory.
Workflow
- Inspect manifests, instructions, data paths, planning paths, and boundaries read-only.
- Map evidence to root, data, and planning instruction layers.
- Stop when authority is absent, instructions conflict, or a location lacks evidence.
- Recover with a qualified plan, mark unassessed areas, and request resolution before mutation.
- Generate authorised files and verify consistency, links, placement, and line limits.
Outputs
| Artefact |
Consumer |
Acceptance condition |
| Root, data, and planning AGENTS.md set |
Repository agents and maintainers |
Each rule is evidence-based, scoped, non-conflicting, linked, and within limits |
Degraded Mode
Without full workspace access, return a qualified partial map, preserve unassessed directories, and do not claim the three-layer set is complete.
Anti-Patterns
- Inventing a technology stack. Fix: inspect manifests and source files.
- Copying generic rules. Fix: bind each rule to repository evidence.
- Placing files arbitrarily. Fix: use responsibility boundaries.
- Editing without authority. Fix: return a proposed file plan.
- Hiding conflicting instructions. Fix: stop and request resolution.
1---2name: doc-architect-33description: Use when generating or revising a project's triple-layer AGENTS.md documentation from observed workspace structure, technology, data, and planning evidence; do not use for general technical documentation or a single ad hoc README edit.4---56## Platform Notes78- Optional helper plugins may help in some environments, but they must not be treated as required for this skill.910# Doc Architect11Acknowledgement: Shared by Peter Bamuhigire, techguypeter.com, +256 784 464178.1213<!-- dual-compat-start -->14## Use When1516- Generate Triple-Layer AGENTS.md documentation by scanning a project for its tech stack, data directory, and planning directory. Use when the user asks to standardize project documentation, generate agent files, or create AGENTS.md guides.17- The task needs reusable judgment, domain constraints, or a proven workflow rather than ad hoc advice.1819## Do Not Use When2021- The task is unrelated to `doc-architect` or would be better handled by a more specific companion skill.22- The request only needs a trivial answer and none of this skill's constraints or references materially help.2324## Documentation Intake Guidance2526- Gather relevant project context, constraints, and the concrete problem to solve; load `references, templates, protocols` only as needed.27- Confirm the desired deliverable: design, code, review, migration plan, audit, or documentation.2829## Documentation Method Detail3031- Read this `SKILL.md` first, then load only the referenced deep-dive files that are necessary for the task.32- Apply the ordered guidance, checklists, and decision rules in this skill instead of cherry-picking isolated snippets.33- Produce the deliverable with assumptions, risks, and follow-up work made explicit when they matter.3435## Quality Standards3637- Keep outputs execution-oriented, concise, and aligned with the repository's baseline engineering standards.38- Preserve compatibility with existing project conventions unless the skill explicitly requires a stronger standard.39- Prefer deterministic, reviewable steps over vague advice or tool-specific magic.4041## Legacy Documentation Pitfalls4243- Treating examples as copy-paste truth without checking fit, constraints, or failure modes.44- Loading every reference file by default instead of using progressive disclosure.4546## Documentation Deliverable Detail4748- A concrete result that fits the task: implementation guidance, review findings, architecture decisions, templates, or generated artifacts.49- Clear assumptions, tradeoffs, or unresolved gaps when the task cannot be completed from available context alone.50- References used, companion skills, or follow-up actions when they materially improve execution.5152## Evidence Produced5354| Category | Artifact | Format | Example |55|----------|----------|--------|---------|56| Release evidence | Triple-Layer AGENTS.md output | Generated AGENTS.md covering project tech stack, data directory, and planning directory layers | `AGENTS.md` |5758## References5960- Use the `references/` directory for deep detail after reading the core workflow below.61- Use the `templates/` directory when the task needs a structured deliverable.62- Use the `protocols/` directory for formal execution order or handoff rules.63<!-- dual-compat-end -->64Design and generate a portable Triple-Layer AGENTS.md documentation set that reflects the project’s real structure and constraints.6566When generated documentation must describe system boundaries, workflows, requirements, data architecture, interfaces, states, business rules, or design-system conventions, load `systems-process-requirements` and use its artifact router before writing the docs.6768**Modularize Instructions (Token Economy):** Avoid consolidating all AI/dev guidance into a single CLAUDE.md. Prefer smaller, focused docs (e.g., docs/setup.md, docs/api.md, docs/workflows.md) and reference them only when needed.6970**Documentation Standards (MANDATORY):** ALL generated markdown files must follow strict formatting rules:71- **500-line hard limit** - no exceptions for any .md file72- **Two-tier structure**: High-level TOC (Tier 1) + Deep dive docs (Tier 2)73- **Smart subdirectory grouping** for related documentation74- **See `doc-standards.md` for complete requirements**7576## Core Outcome7778## Inputs7980| Input | Source/provider | If absent |81|---|---|---|82| Repository structure, manifests, existing instructions | Workspace inspection | Mark the technology or directory unknown; do not invent it |83| Authority to create or update AGENTS.md files | Requester | Return a plan only |8485## Capability Contract8687Inspection is read-only by default. Creating directories or changing instruction files requires explicit authority; deletion and unrelated documentation changes are out of scope.8889## Documentation Fallback Notes9091Without full workspace access, produce a partial documented map with unknown areas named; do not claim the three layers are complete.9293## Decision Rules9495| Choice | Action | Failure/risk avoided |96|---|---|---|97| Data directory is evidenced | Place data instructions there | Arbitrary path |98| No planning directory exists | Propose location before creation | Unauthorised structure |99| Rules conflict | Escalate and preserve both sources | Silent contradiction |100101## Documentation Correction Examples102103- Inventing a technology stack; inspect manifests.104- Copying generic rules; bind them to evidence.105- Placing files arbitrarily; use discovered boundaries.106- Editing without authority; return a plan.107- Hiding conflicting instructions; escalate them.108109## Worked Example110111If no schema directory exists, the output proposes a data-layer location and records the gap instead of creating one silently.112113## Core Outcome114115Produce three aligned AGENTS.md files:116117- **Root AGENTS.md**: Project identity, tech stack, global standards118- **Data AGENTS.md**: Data integrity rules and schema governance119- **Planning AGENTS.md**: Spec-driven development workflow120121## Trigger Phrases122123The skill should activate when the user asks to:124125- Standardize project documentation126- Generate agent files127128## Standard Operating Procedure (SOP)1291301. **Scan the workspace**131 - Inspect the root for identifiers (README, PROJECT_BRIEF, TECH_STACK, ARCHITECTURE, CLAUDE, package.json, composer.json, \*.sln, pyproject.toml).132 - Locate likely data directories (database/, schema/, migrations/, sql/, db/).133 - Locate planning/documentation directories (docs/, docs/plans/, planning/, specs/).134 - Identify module/area entry points (menus, docs, feature folders) to group specs.135 - Note template conventions (public/ as web root, per-panel includes, API outside public).1361372. **Identify the environment**138 - Determine primary language (PHP/C#/Python or other).139 - Determine DB type (MySQL/PostgreSQL/SQLite/SQL Server/other).140 - Determine deployment environment (Docker/Kubernetes/shared hosting/cloud).1411423. **Set up plan grouping (first-time)**143 - Create `docs/plans/<module>/` subdirectories for each discovered module/area.144 - Update `docs/plans/AGENTS.md` with the current module list.145 - Create or update `docs/plans/INDEX.md` as the master plan status index.146 - Ensure the index includes status, urgency, last implementation date, and last modification date.147 - Keep `docs/plans/AGENTS.md` updated whenever plans are added or their status changes.148 - Maintain a folder map at the top of `docs/plans/AGENTS.md` and update it when requested.149 - Note that developers can add new folders and update the list manually.1501514. **Generate Triple-Layer docs**152 - Use the templates in [templates/root-agents.md.template](templates/root-agents.md.template), [templates/data-agents.md.template](templates/data-agents.md.template), and [templates/plan-agents.md.template](templates/plan-agents.md.template).153 - Populate with real findings and pull constraints from [references/logic-library.md](references/logic-library.md) as needed.154 - Create files at:155 - **Root**: AGENTS.md at project root156 - **Data**: database/schema/AGENTS.md (or best-fit schema directory)157 - **Planning**: docs/plans/AGENTS.md (or best-fit planning directory)158159## Bundled Resources160161- [protocols/workflow.md](protocols/workflow.md): 3-step workflow used during generation162- [templates/root-agents.md.template](templates/root-agents.md.template): Root AGENTS.md template163- [templates/data-agents.md.template](templates/data-agents.md.template): Data AGENTS.md template164- [templates/plan-agents.md.template](templates/plan-agents.md.template): Planning AGENTS.md template165- [references/logic-library.md](references/logic-library.md): Domain constraint library for reuse166167## Common Pitfalls168169- Do not invent tech stacks. Only infer from files found in the workspace.170- Do not place AGENTS.md in arbitrary locations; follow the best-fit paths above.171- Do not include contradictory rules across the three layers.172173## Quick Example174175If a project uses Laravel + MySQL with docs/plans and database/schema:176177- Root: AGENTS.md → PHP/Laravel, MySQL, deployment standards178- Data: database/schema/AGENTS.md → referential integrity, no-delete rules179- Plans: docs/plans/AGENTS.md → spec.md format and workflow steps180181## Cross-References to SDLC Skills182183When generating AGENTS.md files, be aware of the complete SDLC documentation ecosystem:184185### SDLC Documentation Skills186187| Skill | Phase | Documents Generated | When to Reference |188|-------|-------|--------------------|--------------------|189| `sdlc-planning` | Planning | Vision, SDP, SRS, SCMP, QA Plan, Risk Plan, Feasibility | When plans directory contains SDLC planning docs |190| `sdlc-design` | Design | SDD, Tech Spec, ICD, Database Design, API Docs, Code Standards | When referencing architecture and design decisions |191| `sdlc-testing` | Testing | Test Plan, Test Cases, V&V Plan, Test Report, Peer Reviews | When referencing testing and quality standards |192| `sdlc-user-deploy` | Delivery | User Manual, Ops Guide, Training, Release Notes, Maintenance, README | When referencing deployment and user documentation |193194### Related Documentation Skills195196| Skill | Purpose | Relationship |197|-------|---------|-------------|198| `project-requirements` | Raw requirements interview | Input source for SDLC planning docs |199| `systems-process-requirements` | Systems/process/requirements modeling | Supplies boundary, workflow, state, interface, data, business-rule, and traceability discipline for documentation |200| `feature-planning` | Feature-level specs + implementation plans | Stored in `docs/plans/` (planning directory) |201| `manual-guide` | End-user manuals and guides | Stored in `/manuals/` (separate from AGENTS.md) |202| `update-claude-documentation` | Keep project docs (README, CLAUDE.md) updated | Maintains project-level docs after changes |203204### SDLC Output Directory Structure205206When scanning for documentation, expect this structure in projects using SDLC skills:207208```209docs/210├── planning/ # sdlc-planning output (7 docs)211├── design/ # sdlc-design output (6 docs)212├── testing/ # sdlc-testing output (5 docs)213├── user-deploy/ # sdlc-user-deploy output (6 docs)214├── plans/ # feature-planning output215│ ├── AGENTS.md # Plans directory index (doc-architect manages this)216│ ├── INDEX.md # Plan status tracker217│ └── specs/ # Feature specifications218└── project-requirements/ # project-requirements output219```220221**Integration Rule:** When generating the Planning AGENTS.md (`docs/plans/AGENTS.md`), include references to any SDLC documentation directories that exist alongside the plans directory.222223## Workflow2242251. Inspect manifests, instructions, data paths, planning paths, and boundaries read-only.2262. Map evidence to root, data, and planning instruction layers.2273. Stop when authority is absent, instructions conflict, or a location lacks evidence.2284. Recover with a qualified plan, mark unassessed areas, and request resolution before mutation.2295. Generate authorised files and verify consistency, links, placement, and line limits.230231## Outputs232233| Artefact | Consumer | Acceptance condition |234|---|---|---|235| Root, data, and planning AGENTS.md set | Repository agents and maintainers | Each rule is evidence-based, scoped, non-conflicting, linked, and within limits |236237## Degraded Mode238239Without full workspace access, return a qualified partial map, preserve unassessed directories, and do not claim the three-layer set is complete.240241## Anti-Patterns242243- Inventing a technology stack. **Fix:** inspect manifests and source files.244- Copying generic rules. **Fix:** bind each rule to repository evidence.245- Placing files arbitrarily. **Fix:** use responsibility boundaries.246- Editing without authority. **Fix:** return a proposed file plan.247- Hiding conflicting instructions. **Fix:** stop and request resolution.