Prompt 05 — Customer documentation and contextual help

Required context

• Documentation shell from prompt 03
• External Experience Wiki
• Shared glossary, feature index, route map, and release statuses

Prompt

Build a searchable, role-aware Capablio documentation site whose content is sourced from or synchronized with the external wiki.

1. Define the publishing model

Use the existing repository stack where possible. Document whether:

• The docs app renders wiki Markdown/MDX directly
• A build step transforms wiki files
• Navigation is generated from frontmatter/manifests
• API docs are generated from OpenAPI/schema sources

Avoid duplicating full documents into a second content tree unless generation is deterministic.

2. Build documentation navigation

Support entry by:

• Role: User, Manager, HR, Tenant admin, Global admin
• Task: create a program, run a campaign, complete feedback, review results, create a PDP, configure SSO, etc.
• Concept: pack, bundle, cadence, cooldown, threshold, coverage, imported evidence, active subject seat

Include global search, breadcrumbs where useful, right-page TOC, previous/next, related pages, version or product-status labels, last reviewed, and page feedback.

3. Publish the minimum guide set

• Getting started and invitation onboarding
• My workspace
• Manager workspace
• HR workspace
• Organization settings
• Platform operations
• Programs and scheduling
• Question library, packs, and bundles
• 360 campaigns and raters
• Completion, reminders, and exceptions
• Results and interpretation
• PDP and sharing
• Thomas/PDF imports
• Roles, visibility, anonymity, and privacy
• Authentication and account security
• Integrations
• Billing/plans/usage
• Troubleshooting
• Release notes
• API/webhooks where released

4. Contextual help

Create a mapping from application route/feature ID to a documentation page. Add a consistent help action in the product shell and page-level “Learn more” links for complex settings.

Do not send users to generic docs home when a specific page exists.

5. Documentation quality

Each task page should include:

• Applicable role and plan
• Prerequisites
• Steps
• What happens next
• Who can see the result
• Limitations
• Troubleshooting
• Related pages

Use the shared glossary. Do not expose internal security procedures, raw schema details, or unsupported roadmap promises.

6. Search and accessibility

• Search indexes only publishable content.
• Results show title, section, role/status, and relevant snippet.
• Keyboard navigation and screen-reader semantics work.
• Code blocks and tables are responsive.
• Diagrams include text descriptions.
• External links are labeled and checked.

7. Validation

Add CI checks for:

• Broken links and anchors
• Missing required frontmatter
• Orphan docs
• Duplicate titles/slugs
• Internal-only links in public docs
• Feature-status mismatches
• Stale release-note references
• Search index build

Acceptance gates

• Every released application feature has a contextual help target.
• Every pricing/security claim links to supporting docs.
• Docs build without manual copy steps.
• Search works with keyboard and returns role-relevant results.
• Documentation validation is part of CI or has an approved rollout plan.