Skip to content
Back to skills

Jtbd Map

ASecurity

Populate JTBD navigation map files with actual include directives from Jira tickets or category/job/topic names. Use when mapping content for a JTBD job, populating nav files, or connecting existing modules to the JTBD structure.

  • 25 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 5, 2026
securitygobashnodegit

Works with

  • cli

Security analysis

A100/100

Pro scans all 3 files and shows the line behind each finding

Scanned September 5, 2026

npx -y skills add redhat-developer/red-hat-developers-documentation-rhdh --skill jtbd-map --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Jtbd Map?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Jtbd Map
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/redhat-developer-jtbd-map/badge)](https://www.skillsdirectory.com/skills/redhat-developer-jtbd-map)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: jtbd-map
description: Populate JTBD navigation map files with actual include directives from Jira tickets or category/job/topic names. Use when mapping content for a JTBD job, populating nav files, or connecting existing modules to the JTBD structure.
argument-hint: "[RHIDP-XXXX or category/job/topic]"
allowed-tools: Bash(git *) Bash(node *) Read Grep Glob Edit Write
---

# JTBD Map: Populate navigation map files

## Purpose

This skill populates the JTBD (Jobs To Be Done) navigation map files under `titles/product_product/category-maps/` with actual `include::` directives pointing to existing modules. It bridges the migration from modular docs (assemblies) to JTBD docs (MAP files).

## Arguments

The skill accepts one or more of:
- **Jira ticket** IDs (e.g., `RHIDP-14636` or `RHIDP-14545 RHIDP-14546 RHIDP-14547`) -- fetches ticket content to identify the category, job, or topic
- A **category name** (e.g., `Secure`, `Install`) -- maps the entire category
- A **job or topic name** (e.g., `Configure authentication providers`) -- maps a specific job

## Workflow

### Step 1: Identify scope and check file state

If the argument is a Jira ticket:
1. Use the `jira-reader` skill to fetch the ticket summary and description
2. Match the ticket to a category, job, or topic in the TOC mapping reference

If the argument is a category/job/topic name:
1. Search the TOC mapping reference file at `.claude/skills/jtbd-map/jtbd-toc-mapping.tsv`
2. Find the matching entry in the hierarchy

Then, for each entry in scope:
3. Check whether the corresponding `nav-*.adoc` and `con-*.adoc` files exist in `titles/product_product/category-maps/<category>/`
4. If any nav or con file is missing, create it using the standard templates (see "MAP file structure" and "Concept file structure" below)
5. For existing nav files, check whether they contain `// TODO:` comments (need population) or actual `include::` directives (already populated). Skip entries that are already fully populated.

### Step 2: Confirm scope with user

Before proceeding, show the user:
- The identified category, job, and topic hierarchy from the TSV
- The nav files that will be populated, indicating which have TODOs vs. which are already done

Ask the user to confirm before making changes.

### Step 3: Find existing assemblies and modules

For each topic in the scope, find the corresponding assembly file first, then derive modules from it:

1. Search `assemblies/<category>_*/` for matching assembly files by title (using `Glob` and `Grep`)
2. If no match, search `assemblies/shared/`
3. If still no match, search all `assemblies/*/` subdirectories (catches content that moved categories, such as reference and troubleshooting content originating in other directories)
4. Read the found assembly's `include::` directives -- these give the module file paths to use in the nav file
5. Read the assembly's body content (abstract, paragraphs, admonitions, snippet includes, additional resources) -- this content goes into the concept file

If no assembly is found for a topic, fall back to searching modules directly:
1. Search `modules/<category>_*/`
2. If no match, search `modules/shared/`
3. If still no match, search all `modules/*/` subdirectories

### Step 4: Populate nav files

For each nav file in scope:
1. Replace `// TODO:` comments with actual `include::` directives
2. Use the format without navtitle (default):
   ```
   include::modules/<subdirectory>/<module>.adoc[leveloffset=+1]
   ```
   Where `<subdirectory>` is the actual directory the module lives in (e.g., `shared`, `configure_configuring-rhdh`, `extend_orchestrator-in-rhdh`), accessed through the `modules` symlink in the category directory.
3. Add `navtitle` only when the TSV's Navtitle column (column 9) has an explicit value, or when the module's internal `= Title` heading does not match the desired navigation title:
   ```
   include::modules/<subdirectory>/<module>.adoc[leveloffset=+1,navtitle="<nav title>"]
   ```
4. Keep any existing includes that are already populated
5. If a nav file would contain only one module include (besides the mandatory concept file), collapse it: delete the nav+con pair and include the module directly in the parent nav file with a `navtitle` override

### Step 5: Populate concept files

The concept file (`con-*.adoc`) in the MAP structure contains the assembly's non-include content. For each `con-*.adoc` concept file paired with a nav file:

1. Read the corresponding assembly file to extract all non-include content
2. Replace the TODO placeholder with the following content, in this order:
   a. The `[role="_abstract"]` paragraph -- always exactly one paragraph (the short description)
   b. Body content after the abstract -- additional paragraphs, admonitions, notes, lists, maintaining the original order from the assembly
   c. Snippet includes -- `include::` directives to `snip-*` files (such as Technology Preview admonitions), placed where they appeared in the assembly body
   d. `[role="_additional-resources"]` section -- always last, if present in the assembly
3. Do NOT include in the concept file:
   - Module includes (`proc-*`, `ref-*`, `con-*`, `assembly-*`) -- these go in the nav file
   - Context save/restore (`ifdef::context[:parent-context:]`, `ifdef::parent-context[:context:]`)
   - `[id="..."]` attributes -- the nav file owns the ID
   - `:context:` declarations -- the nav file owns the context

### Step 6: Resolve xref dependencies

When the content you are migrating (modules or concept body text) contains `xref:` cross-references pointing to IDs that do not yet exist in the MAP structure, you must also migrate the referenced content as a dependency:

1. For each `xref:<target-id>` found in migrated content, check whether `<target-id>` resolves to an existing `[id="..."]` in the `product_product` include tree
2. If the target ID is missing, trace it back to the old assembly or module that defines it
3. Use the TOC mapping reference (`.claude/skills/jtbd-map/jtbd-toc-mapping.tsv`) to determine the correct JTBD category and job for the missing content
4. Create or populate the corresponding nav file and concept file in the correct category directory, adding the module includes that provide the missing ID
5. Use hardcoded IDs (e.g., `[id="permission-policies-reference_authorization-in-rhdh"]`) when the xrefs use hardcoded context values instead of `_{context}`
6. When a module defines `[id="module-id_{context}"]` and existing xrefs use a hardcoded old context value (e.g., `xref:module-id_old-assembly-context[...]`), temporarily set `:context:` to the old value before the module include and restore it after:
   ```asciidoc
   // Temporarily set old context for backward-compatible module IDs
   :context: old-assembly-context
   include::modules/<subdirectory>/<module>.adoc[leveloffset=+1]
   :context: current-nav-context
   ```
7. For assembly-level IDs (e.g., `xref:old-assembly-id_old-context[...]`), add a backward-compatible anchor before the concept include in the nav file:
   ```asciidoc
   // Backward-compatible anchor for xrefs using the old assembly context
   [id="old-assembly-id_old-context"]
   ```
8. Repeat until all xref targets in the migrated scope are resolvable within the `product_product` build

This ensures the ccutil build passes with 0 "Unknown ID" errors.

### Step 7: Ensure required attributes

For each modified nav file, verify:

1. **Mandatory attributes** are present:
   - `:_mod-docs-content-type: MAP` before the ID
   - `[id="<context-value>_{context}"]` before the title
   - `:context: <context-value>` after the title
2. **Cross-reference attributes** are defined where needed:
   - `:secrets-context:` for authentication-related nav files (needed by 9 modules using `{secrets-context}` in xrefs)
   - `:import-context:` for authentication nav files (needed by PingFederate module)
3. **Platform attributes** for non-OCP install nav files. Each hyperscaler section must include the corresponding platform attribute file before its includes and restore OCP defaults after. The platform attribute files are at `titles/product_product/platform-{ocp,eks,gke,aks}.adoc`, each defining 8 attributes (`:platform-id:`, `:platform-long:`, `:platform:`, `:platform-cli:`, `:platform-cli-link:`, `:platform-cli-name:`, `:a-platform-generic:`, `:namespace:`).

   ```asciidoc
   // EKS: override platform attributes
   include::../../platform-eks.adoc[]

   // ... EKS content includes ...

   // Restore platform attributes to OCP defaults
   include::../../platform-ocp.adoc[]

   // GKE: override platform attributes
   include::../../platform-gke.adoc[]

   // ... GKE content includes ...

   // Restore platform attributes to OCP defaults
   include::../../platform-ocp.adoc[]
   ```

### Step 8: Validate

1. Run CQA checks: `node build/scripts/cqa/index.js titles/product_product/master.adoc`
2. Run full build: `build/scripts/build-ccutil.sh`
3. Report any errors and suggest fixes

## Architecture reference

### Old structure (modular docs with assemblies)
```
titles/<category>_<title>/
  master.adoc                              # Title entry point with :context:
  assemblies/<category>_<title>/
    assembly-<topic>.adoc                  # Assembly: includes modules
  modules/<category>_<title>/
    proc-<step>.adoc                       # Procedure module
    con-<concept>.adoc                     # Concept module
    ref-<reference>.adoc                   # Reference module
```

### New structure (JTBD with MAP files)
```
titles/product_product/
  master.adoc                              # Product entry point
  title-attributes.adoc                    # Title, subtitle, abstract, context
  platform-ocp.adoc                        # OCP platform defaults (8 attributes)
  platform-eks.adoc                        # EKS platform overrides
  platform-gke.adoc                        # GKE platform overrides
  platform-aks.adoc                        # AKS platform overrides
  category-maps/
    <category>.adoc                        # Category MAP (includes concept + job navs)
    <category>/
      modules -> ../../../../modules       # Symlink to shared modules
      con-<category>.adoc                  # Category intro concept
      nav-<job>.adoc                       # Job MAP (includes concept + topic modules)
      con-<job>.adoc                       # Job overview concept
```

### MAP file structure
```asciidoc
:_mod-docs-content-type: MAP

[id="<context-value>_{context}"]
= <Title>
:context: <context-value>

include::con-<matching-concept>.adoc[leveloffset=+1]
include::modules/<subdirectory>/<module>.adoc[leveloffset=+1]
include::nav-<sub-job>.adoc[leveloffset=+1]
```

**Mandatory attributes:**
- `:_mod-docs-content-type: MAP`
- `[id="<context-value>_{context}"]`
- `:context: <context-value>`

**Optional attributes:**
- `:secrets-context:`, `:import-context:` (for authentication-related nav files)
- Platform attribute blocks (for non-OCP install nav files)

**Also allowed:**
- Comments (`// ...`) and blank lines
- `// TODO: include <Topic title>` for topics not yet populated

### Concept file structure
```asciidoc
:_mod-docs-content-type: CONCEPT

= <Title>

[role="_abstract"]
<Short description paragraph.>
```

**Rules:**
- No `[id="..."]` anchor -- the ID is inherited from the parent MAP
- No `:context:` declaration -- the MAP file owns the context
- Title matches the corresponding nav file section title

### Key rules
- First include in a MAP must be a `con-` concept file
- MAP files contain only the mandatory attributes listed above, optional attributes, `include::` directives, comments, and blank lines
- `navtitle` is only added when the module's internal title does not match the desired navigation title
- Context values must be unique across all MAP files (IDs derive from context)
- Some nav files share a context value with their parent for xref compatibility

## TOC mapping reference

The complete TOC mapping is available at `.claude/skills/jtbd-map/jtbd-toc-mapping.tsv`. This file maps:
- Categories (L1) to their Jira tickets and assignees
- Jobs (L2) and sub-jobs (L3/L4) to their topics
- Topics to their H2/H3 headings and `.adoc` file paths

Each level in the TSV hierarchy can correspond to either a MAP file (nav + con pair) or a leaf module include. The skill determines which from the actual file structure on disk.

## Categories (16)

Discover, Get started, Plan, Install, Upgrade, Migrate, Administer, Develop, Configure, Secure, Observe, Integrate, Optimize, Extend, Troubleshoot, Reference

Files in this skill

  • RHIDP-14642-validation-report.md9.3 KB
  • SKILL.md12.3 KB
  • jtbd-toc-mapping.tsv38.1 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…