@notionhq/apps 0.0.48 → 0.0.49

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@notionhq/apps",
-	"version": "0.0.48",
+	"version": "0.0.49",
 	"description": "An SDK for building workflow apps for Notion",
 	"license": "MIT",
 	"bin": {

package/skills/workflow/SKILL.md

@@ -156,7 +156,10 @@ configuration, and do not log secrets or private payloads.
 
 ## Manual workflow inputs
 
-Provide up to one `events.manual` to allow triggering the workflow manually from the UI or CLI for testing purposes.
+Provide up to one `events.manual()` to allow triggering the workflow from the UI
+or CLI on demand. For scheduled workflows, include it alongside
+`events.scheduled()` so users can run the workflow without waiting for the next
+scheduled time.
 
 Specify the inputs accepted using `@notionhq/apps/schema-builder`.
 
@@ -247,7 +250,7 @@ import { guide } from "./sayHello/lib/notion.js";
 export default workflow({
 	name: "Read guide",
 	description: "Reads the App's guide on a recurring schedule.",
-	triggers: [events.scheduled()],
+	triggers: [events.scheduled(), events.manual()],
 	access: { guide: access.view(guide) },
 	handler: async (_event, context) => {
 		await context.step("Read guide", () =>
@@ -262,11 +265,6 @@ declarations in `access` work too. Importing a declaration alone provisions the
 resource but does not create a `context.access` alias. An `access` entry declares
 the needed permission level and a named binding for that NaC resource.
 
-For a workflow that uses `events.scheduled()`, also declare a "triggers"
-database with a page-added trigger bound to it. This lets the user manually
-trigger a run at any time by adding a page to that database, without waiting
-for the schedule.
-
 `access.view()`, `access.comment()`, `access.edit()`, and `access.fullAccess()`
 accept page, database, and data-source handles. `access.call()` accepts custom-agent
 handles. Keys are workflow-local aliases. The handler's