Prompt hierarchy and execution protocol

Why prompts are hierarchical

A single “redesign the product” prompt will produce inconsistent routes, duplicate components, incorrect permissions, and documentation drift. The hierarchy separates permanent rules, architecture decisions, experience foundations, persona workspaces, domain workflows, and final quality gates.

Levels

L0 — Product constitution

Always active. Defines product purpose, privacy, tenancy, development-not-judgment, imported-data lineage, and prohibition on fabricated marketing claims.

Files:

• AGENTS.md
• .cursor/rules/000-capablio-product-constitution.mdc

L1 — Cross-cutting rules

Applied by relevance or always where critical:

• Dual-wiki change contract
• Layout and design system
• Accessibility, responsive, and localization
• Security, privacy, and multi-tenancy
• Content and marketing truth
• Testing, observability, and release
• Feedback analytics and data visualization

L2 — Discovery and architecture prompts

No production code until exit criteria are met:

• 00-repository-discovery-and-baseline.md
• 01-bootstrap-and-populate-dual-wiki.md
• 02-product-ia-rbac-and-technical-plan.md

L3 — Foundations

Create shared implementation primitives:

• 03-design-system-and-application-shells.md
• 04-public-marketing-site.md
• 05-customer-documentation-site.md
• 06-auth-invite-onboarding-and-account-security.md

L4 — Persona workspaces

• 07-individual-user-workspace.md
• 08-manager-workspace.md
• 09-hr-workspace.md
• 10-tenant-admin-workspace.md
• 11-global-admin-control-plane.md

L5 — Domain workflows

• 12-question-library-packs-and-program-builder.md
• 13-survey-campaign-and-rater-lifecycle.md
• 14-results-analytics-and-reporting.md
• 15-pdp-development-and-follow-up.md

L6 — Quality and release

• 16-integrations-billing-entitlements-and-governance.md
• 17-accessibility-security-observability-and-test-hardening.md
• 18-migration-content-seo-demo-and-release-readiness.md

L7 — Micro-prompts

Use after the main architecture is stable:

• Page implementation template
• Feature slice template
• UX review template
• Migration template

Prompt execution rules

1. Attach AGENTS.md, relevant .cursor/rules, the shared feature row, both wiki pages, and the specific prompt.
2. Ask Cursor to inspect before editing. It must name the files and assumptions.
3. For prompts 00–02, explicitly prohibit code changes.
4. For implementation prompts, require a small plan and a test plan before edits.
5. Do not mix unrelated personas in one commit.
6. Do not create a new component when a design-system primitive already fits.
7. Do not add a permission merely to make a page render.
8. Do not use mock values in production code paths without a fixture boundary.
9. Update both wikis and traceability before declaring completion.
10. Run focused tests during the slice and the required full gates before merge.

Required response format from Cursor

At the beginning:

Relevant feature IDs:
Wiki pages read:
Assumptions:
Files likely to change:
Authorization/data-class impact:
ADR required: yes/no and why
Test plan:

At the end:

Implemented:
Files changed:
Tests run:
Accessibility checks:
Security/privacy checks:
External wiki updated:
Internal wiki updated:
Traceability updated:
Migration/release notes:
Known limitations:

Stop conditions

Cursor must stop and request a decision when:

• The repository has two competing authentication or tenancy models.
• A requested view would expose plaintext feedback to a role not authorized by the wiki.
• Encryption or recovery promises conflict with implemented architecture.
• A destructive migration lacks rollback or backup.
• A marketing claim has no source.
• The desired feature requires a plan entitlement or contract not defined.
• A question-score transformation would blend incomparable instruments.
• A change would make anonymity thresholds ineffective.
• The codebase cannot pass the baseline tests before modifications.

Definition of done for any feature

• Acceptance criteria are mapped to tests.
• Authorization is server-enforced and negatively tested.
• All UI states exist.
• Responsive and keyboard behavior are tested.
• Sensitive data is absent from logs and analytics payloads.
• External documentation matches observable behavior.
• Internal spec matches domain behavior.
• Feature index and traceability matrix are current.
• Release note or migration note exists when user-visible.