forge-app-review

Name: forge-app-review
Author: atlassian

211installs8forks

How to install forge-app-review?

atlassian/forge-skills/forge-app-review

$npx -y skills add atlassian/forge-skills --skill forge-app-review

Installs into the current project.

Summary

Performs a lightweight pre-release readiness review of Atlassian Forge apps across manifest/module wiring, architecture, runtime compatibility, dependency posture, tests, deploy readiness, and obvious security, cost, or reliability smells. Use when the user asks "review my Forge

Files · 1

View on GitHub

SKILL.md

1	# Forge App Review
2
3	Run a general Forge release-readiness review. This skill is the front door for broad app review, not a replacement for specialist security, cost, or debugging skills.
4
5	## Boundaries
6
7	Use this skill for:
8
9	- Pre-deploy and release-readiness checks.
10	- General architecture and maintainability review.
11	- Manifest/module/resource/function wiring.
12	- Runtime, dependency, package, and script sanity checks.
13	- Basic tests/deploy readiness and operational hygiene.
14	- Obvious security, cost, or reliability smells that should trigger a deeper specialist pass.
15
16	Use another skill instead when the user's primary intent is:
17
18	- Deep security audit, SAST, authz, secrets, tenant isolation, exploitability, or CVSS reporting -> `forge-security-review`.
19	- Cost optimization, invocations, GB-seconds, storage/log volume, trigger frequency, or memory tuning -> `forge-cost-optimizer`.
20	- A known failure, error message, blank UI, failed deploy/install, broken resolver, missing app, or logs/tunnel diagnosis -> `forge-debugger`.
21
22	If a broad review finds a deep security/cost/debug concern, include it as a handoff recommendation rather than duplicating the specialist workflow.
23
24	## Review Rules
25
26	- Audit first. Do not modify app files unless the user explicitly asks to apply fixes.
27	- Read the codebase before making claims.
28	- Prefer concrete file/line evidence.
29	- Keep findings focused on bugs, release blockers, meaningful risks, and missing validation.
30	- Do not run full SAST or cost tooling from this skill. Recommend the specialist skill when warranted.
31	- Do not report speculative security or cost observations as confirmed vulnerabilities or savings.
32
33	## Workflow
34
35	1. Read `manifest.yml` or `manifest.yaml`.
36	- Identify modules, resources, functions, resolver bindings, triggers, web triggers, remotes, permissions, runtime, and memory settings.
37	- Verify referenced handlers/resources exist.
38	2. Read `package.json`.
39	- Check Forge package fit, scripts, runtime assumptions, direct dependencies, and obvious unused/missing packages.
40	3. Inspect source files.
41	- Backend/resolvers: `resolver.define`, handler exports, product API calls, storage usage, external fetches, logging, error handling.
42	- Frontend: UI Kit or Custom UI resource entry points, `invoke()` patterns, bridge usage, loading/error states.
43	4. Inspect tests and project docs when present.
44	- Note missing tests only when behavior risk justifies it.
45	5. Produce a prioritized readiness report.
46
47	## What To Check
48
49	### Release Blockers
50
51	- Manifest references a missing handler, resource path, or module key.
52	- Resolver names called by the frontend do not match `resolver.define()` names.
53	- Required scopes or egress permissions are missing for actual API/fetch usage.
54	- Runtime, package versions, or module syntax likely fail `forge lint`, build, deploy, or install.
55	- App has no clear way to exercise its primary user flow.
56
57	### Architecture And Maintainability
58
59	- Module type matches the intended UX surface.
60	- Resolver boundaries are coherent and not overly monolithic for the app size.
61	- Sensitive or privileged logic stays backend-side.
62	- UI-only formatting/transforms are not unnecessarily forced through backend functions.
63	- Error handling is sufficient for user-facing workflows.
64	- Code organization matches existing project style.
65
66	### Lightweight Security Signals
67
68	Only flag obvious signals and recommend `forge-security-review` for deep validation:
69
70	- Broad/write/admin scopes without visible usage.
71	- `api.asApp()` in user-triggered resolvers without obvious authorization checks.
72	- Hardcoded credentials or token-like literals.
73	- External fetches without manifest egress entries.
74	- Web triggers without visible authentication strategy.
75	- Full payload/request logging that may expose user, tenant, or secret data.
76
77	### Lightweight Cost Signals
78
79	Only flag obvious signals and recommend `forge-cost-optimizer` for deep analysis:
80
81	- Resolver invoked only to return static data or product context.
82	- Multiple independent `invoke()` calls on page load.
83	- Scheduled triggers that look like broad polling.
84	- Product triggers without filters or `ignoreSelf` where applicable.
85	- Full payload/API response logging in hot paths.
86	- Storage writes on every invocation.
87
88	### Lightweight Debuggability Signals
89
90	Only flag

People who liked this also viewed

6 picks

Type

forge-app-review

211installs8forks

View on GitHub

How to install forge-app-review?

atlassian/forge-skills/forge-app-review

$npx -y skills add atlassian/forge-skills --skill forge-app-review

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Forge App Review
2
3	Run a general Forge release-readiness review. This skill is the front door for broad app review, not a replacement for specialist security, cost, or debugging skills.
4
5	## Boundaries
6
7	Use this skill for:
8
9	- Pre-deploy and release-readiness checks.
10	- General architecture and maintainability review.
11	- Manifest/module/resource/function wiring.
12	- Runtime, dependency, package, and script sanity checks.
13	- Basic tests/deploy readiness and operational hygiene.
14	- Obvious security, cost, or reliability smells that should trigger a deeper specialist pass.
15
16	Use another skill instead when the user's primary intent is:
17
18	- Deep security audit, SAST, authz, secrets, tenant isolation, exploitability, or CVSS reporting -> `forge-security-review`.
19	- Cost optimization, invocations, GB-seconds, storage/log volume, trigger frequency, or memory tuning -> `forge-cost-optimizer`.
20	- A known failure, error message, blank UI, failed deploy/install, broken resolver, missing app, or logs/tunnel diagnosis -> `forge-debugger`.
21
22	If a broad review finds a deep security/cost/debug concern, include it as a handoff recommendation rather than duplicating the specialist workflow.
23
24	## Review Rules
25
26	- Audit first. Do not modify app files unless the user explicitly asks to apply fixes.
27	- Read the codebase before making claims.
28	- Prefer concrete file/line evidence.
29	- Keep findings focused on bugs, release blockers, meaningful risks, and missing validation.
30	- Do not run full SAST or cost tooling from this skill. Recommend the specialist skill when warranted.
31	- Do not report speculative security or cost observations as confirmed vulnerabilities or savings.
32
33	## Workflow
34
35	1. Read `manifest.yml` or `manifest.yaml`.
36	- Identify modules, resources, functions, resolver bindings, triggers, web triggers, remotes, permissions, runtime, and memory settings.
37	- Verify referenced handlers/resources exist.
38	2. Read `package.json`.
39	- Check Forge package fit, scripts, runtime assumptions, direct dependencies, and obvious unused/missing packages.
40	3. Inspect source files.
41	- Backend/resolvers: `resolver.define`, handler exports, product API calls, storage usage, external fetches, logging, error handling.
42	- Frontend: UI Kit or Custom UI resource entry points, `invoke()` patterns, bridge usage, loading/error states.
43	4. Inspect tests and project docs when present.
44	- Note missing tests only when behavior risk justifies it.
45	5. Produce a prioritized readiness report.
46
47	## What To Check
48
49	### Release Blockers
50
51	- Manifest references a missing handler, resource path, or module key.
52	- Resolver names called by the frontend do not match `resolver.define()` names.
53	- Required scopes or egress permissions are missing for actual API/fetch usage.
54	- Runtime, package versions, or module syntax likely fail `forge lint`, build, deploy, or install.
55	- App has no clear way to exercise its primary user flow.
56
57	### Architecture And Maintainability
58
59	- Module type matches the intended UX surface.
60	- Resolver boundaries are coherent and not overly monolithic for the app size.
61	- Sensitive or privileged logic stays backend-side.
62	- UI-only formatting/transforms are not unnecessarily forced through backend functions.
63	- Error handling is sufficient for user-facing workflows.
64	- Code organization matches existing project style.
65
66	### Lightweight Security Signals
67
68	Only flag obvious signals and recommend `forge-security-review` for deep validation:
69
70	- Broad/write/admin scopes without visible usage.
71	- `api.asApp()` in user-triggered resolvers without obvious authorization checks.
72	- Hardcoded credentials or token-like literals.
73	- External fetches without manifest egress entries.
74	- Web triggers without visible authentication strategy.
75	- Full payload/request logging that may expose user, tenant, or secret data.
76
77	### Lightweight Cost Signals
78
79	Only flag obvious signals and recommend `forge-cost-optimizer` for deep analysis:
80
81	- Resolver invoked only to return static data or product context.
82	- Multiple independent `invoke()` calls on page load.
83	- Scheduled triggers that look like broad polling.
84	- Product triggers without filters or `ignoreSelf` where applicable.
85	- Full payload/API response logging in hot paths.
86	- Storage writes on every invocation.
87
88	### Lightweight Debuggability Signals
89
90	Only flag

People who liked this also viewed

6 picks

Type