Notis Apps
Build apps that feel native to Notis: compact, readable, responsive, and useful.
Use Vite + React, @notis/sdk, and the existing scaffold components. Use the Notis
CLI for app operations: npx --package @notis_ai/cli@latest -- notis ....
Read existing apps and resources
Use ordinary data tools for straightforward reads. When the task needs a live
render, chart, filter, or visual inspection, follow Read Notis web content.
It covers apps, views, reports, HTML and file documents without requiring the
user to open Portal or Desktop. Use the agent's available browser capability;
this is not an app build, deployment, or Portal editing-context workflow.
Build → inspect → fix → deliver
For every app UI create/edit task, read both Design and
Delivery. Then:
- Understand the result. Identify the main user action and the requested
change. For a reported visual bug, describe what is wrong in the actual
screen before editing. Preserve what already works.
- Start from native patterns. Pull the existing app or choose the closest
Store scaffold. Use the appropriate page layout instead of inventing a new
visual system. Make routine choices yourself; ask only for missing decisions
that materially change the result.
- Build, look, improve. Run build and verification, then actually inspect
the rendered app. Follow the short visual check in the design guide. Fix what
is wrong and recheck the affected screen; a passing build is not visual approval.
- Deliver the checked result. Follow the delivery guide and existing user
authorization. Confirm the released result inside Notis before calling it
verified. Say plainly what is local, deployed, or still unverified.
Keep these boundaries
- User and repository instructions take precedence, including preview-only,
no-deploy, and explicit-consent requirements. Store publication is separate.
- Preserve the exact app identity, account/team scope, permissions, and user data.
Reconcile an uncertain release instead of blindly retrying it.
- Use SDK hooks and declared tools. Let Notis own its sidebar, search, runtime,
and rendering boundary; do not query host DOM or recreate that chrome in the app.
References — only as needed
- SDK hooks: reads, edits, selection, and navigation.
- App contracts: configuration, packaging, and data ownership.
- Troubleshooting: a specific failure or mismatch.
The CLI distributes this skill and its references from the canonical product
source. Do not maintain competing copies.
Shared views, independent reports and feedback
Use a shared app view when many records should share one implementation. Use
notis-reports when an app-owned record needs its own independently authored
SDK presentation. A report is not a new app, and changing it must not deploy or
replace shared app routes. The agent chooses live data versus captured results.
Share selected text, comments, loaded resources or app-defined annotations through
generic context pills. Apps own annotation storage and
presentation; the chat owns unsent context drafts. Passive context is not execution approval.
1---2name: notis-apps3description: Design and package Notis apps, or inspect their live views and resources. Use when users want an installable Notis app or need rendered content, charts, or filters that ordinary data tools do not provide.4---56# Notis Apps78Build apps that feel native to Notis: compact, readable, responsive, and useful.9Use Vite + React, `@notis/sdk`, and the existing scaffold components. Use the Notis10CLI for app operations: `npx --package @notis_ai/cli@latest -- notis ...`.1112## Read existing apps and resources1314Use ordinary data tools for straightforward reads. When the task needs a live15render, chart, filter, or visual inspection, follow [Read Notis web content](references/reading.md).16It covers apps, views, reports, HTML and file documents without requiring the17user to open Portal or Desktop. Use the agent's available browser capability;18this is not an app build, deployment, or Portal editing-context workflow.1920## Build → inspect → fix → deliver2122For every app UI create/edit task, read both [Design](references/design.md) and23[Delivery](references/release.md). Then:24251. **Understand the result.** Identify the main user action and the requested26 change. For a reported visual bug, describe what is wrong in the actual27 screen before editing. Preserve what already works.282. **Start from native patterns.** Pull the existing app or choose the closest29 Store scaffold. Use the appropriate page layout instead of inventing a new30 visual system. Make routine choices yourself; ask only for missing decisions31 that materially change the result.323. **Build, look, improve.** Run build and verification, then actually inspect33 the rendered app. Follow the short visual check in the design guide. Fix what34 is wrong and recheck the affected screen; a passing build is not visual approval.354. **Deliver the checked result.** Follow the delivery guide and existing user36 authorization. Confirm the released result inside Notis before calling it37 verified. Say plainly what is local, deployed, or still unverified.3839## Keep these boundaries4041- User and repository instructions take precedence, including preview-only,42 no-deploy, and explicit-consent requirements. Store publication is separate.43- Preserve the exact app identity, account/team scope, permissions, and user data.44 Reconcile an uncertain release instead of blindly retrying it.45- Use SDK hooks and declared tools. Let Notis own its sidebar, search, runtime,46 and rendering boundary; do not query host DOM or recreate that chrome in the app.4748## References — only as needed4950- [SDK hooks](references/sdk.md): reads, edits, selection, and navigation.51- [App contracts](references/architecture.md): configuration, packaging, and data ownership.52- [Troubleshooting](references/troubleshooting.md): a specific failure or mismatch.5354The CLI distributes this skill and its references from the canonical product55source. Do not maintain competing copies.5657## Shared views, independent reports and feedback5859Use a shared app view when many records should share one implementation. Use60`notis-reports` when an app-owned record needs its own independently authored61SDK presentation. A report is not a new app, and changing it must not deploy or62replace shared app routes. The agent chooses live data versus captured results.6364Share selected text, comments, loaded resources or app-defined annotations through65[generic context pills](references/context.md). Apps own annotation storage and66presentation; the chat owns unsent context drafts. Passive context is not execution approval.
mindtheflo