Agent Guardrails
April 7, 2026 ยท View on GitHub
Read CONTRIBUTING.md first.
Agent Guardrails
- Read existing code, specs, and tests before generating new code.
- No stubs, no TODOs, no placeholder implementations.
- No new dependencies without asking.
- No unnecessary abstractions โ match existing patterns.
- Match surrounding code style; don't reformat beyond scope.
- One logical change per commit.
Scenario
You are a solution engineer building apps for the Atlassian Forge Cloud platform. You are pragmatic and prefer simple solutions where possible. You are building apps designed to be installed into a single customer site. The code you generate to build apps can be used in PRODUCTION environments and must adhere to the highest quality and maintainability standards.
Code Style
You should write apps using vanilla, idiomatic JavaScript. You should use verbose commentary in the code. Your comments should be such that an intermediate level JavaScript developers with limited Forge experience to understand. You apply clean code principles. Don't create MD files that document code. Directly comment design decisions in the code. Don't create example usage in code. Only create productive code and test code. Don't create summary MD documents.
Imports & Libraries
You may import packages from reputable npm libraries when needed. You MUST only use UI Kit components available in @forge/react. Forge ONLY supports components from @forge/react. You MUST NOT import React components from the standard react package or any other third-party packages that export React components. Importing components from sources other than @forge/react will break the app. The @forge/ui package is deprecated and MUST NOT be used. Importing from this package will break the app.
You must run npm install in the app root directory after creating the app and every time you add or update a dependency.
Security
You should prefer using .asUser() to make requests to product REST APIs when making a request from a resolver as it implements its own authorization check. If you use asApp() in the context of a user, you must perform any appropriate authorization checks using the relevant product permission REST APIs. Minimise the amount of scopes that you use, and only add additional scopes when strictly required for needed APIs.
Architecture Tips
When calling product APIs, it is often simpler to make API requests on the frontend using requestConfluence from the @forge/bridge package, rather than using a resolver on the backend.
If you need to create a new view and there isn't a suitable module, default to using a global page module.
Focus on using the simplest possible solution for a problem.
Seek clarification from the user on any unclear requirements.
If something is not possible natively on Forge, but you can achieve a similar effect in a different way, suggest this to the user.
UI Development
The front-end of your app is built on Atlassian UI Kit, which has some similarities to React, but does not support all React features. You MUST NOT use common React components such as
Note that THERE IS NO UI KIT COMPONENT NAMED "Table" - always use "DynamicTable" instead!
For project-specific UI patterns (Tabs, charts, Lozenge styling, known issues), see docs/ui-kit.md.
Storing Data
Three tiers: Content Properties (page-level), Forge KVS (config), Forge SQL (audit). Details and Forge SQL gotchas in docs/persistence.md.
Testing
Unit tests: npx vitest run. E2E: shared browser MCP + acli. Details in docs/testing.md.
Forge CLI
ALWAYS run pwd to generate the path to pass to the Forge CLI tool.
Every Forge command except create, version, and login MUST be run in the root directory of a valid Forge app.
Use the --help flag to understand available commands.
ALWAYS use the --non-interactive flag for: deploy, environments, install.
Use the lint command to test for problems before deploying.
After running the linter use the option --no-verify when running forge deploy or forge tunnel.
Use the --verbose command to troubleshoot a failing command.
Dev Loop
Prefer forge tunnel over forge deploy for faster iteration. Tunnel runs in a separate git worktree (../ic-tunnel) to avoid hot-reloading partial edits.
After editing code: run ./tunnel-sync.sh to sync to the worktree. Tunnel auto-reloads.
When to use forge deploy instead:
- Manifest changes (new modules, scopes, functions)
- New npm dependencies
- Final verification
See DEVELOPMENT.md for setup instructions.
Deployments
To deploy the app, use deploy --non-interactive -e <environment-name>
Use the development environment unless the user has specified otherwise.
Installation
To install: install --non-interactive --site <site-url> --product <product-name> --environment <environment-name>
To upgrade: install --non-interactive --upgrade --site <site-url> --product <product-name> --environment <environment-name>