Capablio

Handbook

Prompt 01 — Bootstrap and populate the dual wiki

Run in Cursor Plan/Agent mode. Do not change product runtime behavior. You may create documentation tooling and validation scripts that do not affect production execution.

Updated

Required context

  • Outputs from prompt 00
  • 02-dual-wiki-operating-model.md from the uplift pack
  • Existing project instructions and documentation conventions

Prompt

Create the Capablio dual-wiki system before feature implementation.

1. Install the repository instructions

Create or reconcile:

AGENTS.md
.cursor/rules/*.mdc

Use flat .mdc files in .cursor/rules. Preserve valid existing project rules; merge rather than overwrite. Resolve conflicts explicitly in wiki/shared/decision-log.md.

The rules must cover:

  • Product constitution
  • Dual-wiki update contract
  • Layout and design system
  • Accessibility/responsive/localization
  • Multi-tenancy/security/privacy
  • Content and marketing truth
  • Testing/observability/release
  • Feedback analytics and data visualization

2. Create the wiki structure

Create:

wiki/shared/
wiki/external/product/
wiki/external/solutions/
wiki/external/pricing/
wiki/external/security/
wiki/external/help/
wiki/external/api/
wiki/external/release-notes/
wiki/external/_templates/
wiki/internal/product/
wiki/internal/architecture/
wiki/internal/data/
wiki/internal/security/
wiki/internal/operations/
wiki/internal/analytics/
wiki/internal/integrations/
wiki/internal/adr/
wiki/internal/runbooks/
wiki/internal/_templates/

Create README files defining audience, publication boundary, ownership, review frequency, and link conventions.

3. Establish shared catalogs

Populate:

  • feature-index.md
  • traceability-matrix.md
  • glossary.md
  • role-permission-matrix.md
  • route-map.md
  • decision-log.md
  • entitlement-matrix.md
  • data-classification.md
  • analytics-event-catalog.md

Create stable feature IDs for the current and target capabilities. Use at least these domains where relevant:

FOUND, AUTH, TEN, DIR, AFF, QLIB, PACK, PROG, CAMP, RATER,
RESP, RSLT, PDP, IMP, MGR, HR, ADM, OPS, INT, BILL, SEC,
AUDIT, DOCS, MKT, NOTIFY, AI

Do not create duplicate IDs for the same capability. Do not encode route names or vendor names in IDs.

4. Seed core external and internal pages

Create paired pages for at least:

  • Adaptive feedback programs
  • Question cooldowns
  • Coverage-aware rotation
  • Question packs and bundles
  • 360 campaigns and relationship groups
  • Anonymity and minimum thresholds
  • Results and imported evidence
  • Personal development plans
  • Tenant-specific content
  • Active subject seats and guest raters
  • Roles and data visibility
  • Authentication and account security
  • Thomas import

External pages explain benefits, steps, visibility, plans, limitations, and help. Internal pages explain invariants, permissions, data classes, APIs/events if known, states, tests, and open decisions.

Mark unknown behavior as proposed or decision-required; do not describe it as released.

5. Add validation

Use the repository's existing scripting language where practical. Add a documentation validation command that checks:

  • Unique feature IDs
  • Every indexed external/internal link exists
  • Paired page frontmatter agrees on feature ID
  • No public page links to an internal-only path
  • No obvious secret patterns in the external wiki
  • Required frontmatter fields
  • Broken local links
  • Duplicate glossary terms

Add the command to local and CI documentation. Do not block the main build until the validator is stable; first run it in report-only mode if necessary.

6. Record governance

Document:

  • Status lifecycle: proposed → approved → building → beta → released → retired
  • Review owner and review date
  • ADR trigger conditions
  • Release-note trigger conditions
  • How marketing and docs consume the external wiki
  • How code/tests link back through traceability

Acceptance gates

  • At least 20 material capabilities exist in the feature index.
  • Every indexed capability has an internal spec or an explicit reason why not.
  • Every released/beta user-facing capability has an external page.
  • The glossary distinguishes program/campaign, family/variant, cooldown/retention, pack/bundle, subject/rater, and private/shared PDP.
  • Validation runs and reports actionable errors.
  • No production code behavior changes.

At completion, list feature IDs created, unresolved decisions, and validation results.