Expand create-an-edge-app skill with integrations and pre-PR steps

[renatgalimov]

User description

The skill covered scaffolding and Figma but said nothing about integrations, so agents invent their own auth flows and produce nonsense. It also omitted the testing, screenshot, and QC steps every app needs before a PR.

Adds an Integrations and Authentication section that steers toward declaring integration-backed settings and reading credentials via getCredentials(), with two simple local options (a CLI-set secret, or a tiny OAuth companion app). Adds testing, screenshots, and QC steps, a boot-verification step after scaffolding, and Google Calendar and Salesforce as integration reference apps.

🤖 Generated with Claude Code

---

PR Type

Documentation

---

Description

• Expands Edge App scaffolding guidance

• Adds integrations and authentication instructions

• Adds testing and pre-PR checklist

• Adds integration reference app examples

---

Diagram Walkthrough

flowchart LR
  skill["Edge App skill"] 
  scaffold["Boot verification"]
  auth["Integrations and auth"]
  testing["Testing guidance"]
  pr["Pre-PR checklist"]
  refs["Reference apps"]
  skill -- "adds" --> scaffold
  skill -- "adds" --> auth
  skill -- "adds" --> testing
  skill -- "adds" --> pr
  skill -- "extends" --> refs

Loading

File Walkthrough

Relevant files

Documentation

SKILL.md Expanded Edge App creation guidance                                            .claude/skills/create-an-edge-app/SKILL.md Updates the skill description to cover integrations, tests, and pre-PR checks. Adds boot verification after scaffolding with bun run dev, bun run lint, and tests. Documents integration-backed settings, getCredentials(), and local credential strategies. Adds testing, screenshot, QC checklist, and Google Calendar/Salesforce references. +33/-1

---

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪

🧪 No relevant tests

🔒 Security concerns Sensitive information exposure: The documentation suggests supplying an access_token via mock-data.yml. If that file is source-controlled or shared and a real token is used, this can leak OAuth credentials.

⚡ Recommended focus areas for review Secret Exposure The local development guidance suggests putting an access_token in mock-data.yml. If a developer follows this with a real OAuth token and the file is committed or shared, credentials can be exposed. Consider explicitly limiting this to dummy tokens or an untracked local file/env-based setup. - **Read a secret (CLI is fine).** Declare an `access_token` secret marked "for testing only", set it with `screenly edge-app setting set access_token=...` (or in `mock-data.yml`), and read it with `getSettingWithDefault('access_token', '')`. See `edge-apps/google-calendar/` (`src/main.ts`).

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Security	Prevent committed secret leaks Avoid recommending real OAuth tokens in mock-data.yml, since that file is commonly committed and can leak credentials. Make the local-token path explicitly require non-committed local storage for real secrets, with mock-data.yml limited to dummy values. .claude/skills/create-an-edge-app/SKILL.md [36] -- **Read a secret (CLI is fine).** Declare an `access_token` secret marked "for testing only", set it with `screenly edge-app setting set access_token=...` (or in `mock-data.yml`), and read it with `getSettingWithDefault('access_token', '')`. See `edge-apps/google-calendar/` (`src/main.ts`). +- **Read a local test secret (CLI is fine).** Declare an `access_token` secret marked "for testing only", set real local values with `screenly edge-app setting set access_token=...`, and read it with `getSettingWithDefault('access_token', '')`. Use `mock-data.yml` only for dummy/example values that are safe to commit. See `edge-apps/google-calendar/` (`src/main.ts`). Suggestion importance[1-10]: 7 __ Why: This is a valid security improvement because the current guidance allows putting an access_token in mock-data.yml, which may be committed accidentally. The impact is meaningful, though it is documentation guidance rather than an application code vulnerability.	Medium
	Restrict local token endpoint The companion authenticator guidance exposes bearer tokens over HTTP but does not require localhost-only binding. Add an explicit restriction so developers do not accidentally publish a token endpoint on a network-accessible interface. .claude/skills/create-an-edge-app/SKILL.md [37] -- **Handle the OAuth flow with a tiny companion app.** A small Express + Bun server that runs the flow, stores the tokens, refreshes them, and exposes `GET /access_token/` returning `{ token, metadata }` — mimicking the Screenly OAuth service. Wire it in via `mock-data.yml`'s `screenly_oauth_tokens_url`. See the `mock-authenticator/` in [Screenly/salesforce-app](https://github.com/Screenly/salesforce-app) for a complete, minimal example. +- **Handle the OAuth flow with a tiny companion app.** A small Express + Bun server that runs the flow, stores the tokens, refreshes them, and exposes `GET /access_token/` returning `{ token, metadata }` — mimicking the Screenly OAuth service. Bind it to `127.0.0.1` only, never expose it publicly, and keep stored tokens out of the repository. Wire it in via `mock-data.yml`'s `screenly_oauth_tokens_url`. See the `mock-authenticator/` in [Screenly/salesforce-app](https://github.com/Screenly/salesforce-app) for a complete, minimal example. Suggestion importance[1-10]: 7 __ Why: This accurately targets the new companion authenticator guidance and reduces the risk of exposing bearer tokens via a network-accessible GET /access_token/ endpoint. It is a worthwhile security clarification, but its effect is limited to developer documentation.	Medium