# How To Build An Ignition Perspective AI Skill With A Goal Loop

Canonical URL: https://www.ignitionaiskills.com/blog/build-ignition-perspective-ai-skill-goal-loop

Last updated: 2026-06-29

## Summary

An Ignition Perspective AI skill should not start as a generic prompt pack. Start with a goal loop: connect an AI agent to a controlled Ignition Web Dev runner API, make it test real Perspective page-building on a development or staging Gateway, record evidence, and promote only tested reusable lessons into `SKILL.md`.

The short workflow is:

AI agent -> Web Dev runner API -> real Ignition Gateway -> evidence -> concise SKILL.md rule

## Minimum Setup

1. Create or install a Web Dev runner endpoint in an Ignition 8.1 development or staging Gateway.
2. Give the AI agent an endpoint, token, target project, and allowed write prefixes.
3. Create a working vault or repo folder for the skill, tests, evidence, handoff notes, references, scripts, and runner docs.
4. Pick one realistic Perspective workflow: tank overview, pump/valve faceplate, alarm panel, history trend, equipment route, reusable embedded view, navigation shell, or status dashboard.
5. Require discovery before writes.
6. Require dry-run before apply.
7. Require exact confirmation before any write.
8. Validate with route/view readback, tags, Named Queries, history, alarms, logs, and browser/runtime proof when needed.
9. Put raw evidence outside `SKILL.md`.
10. Promote only durable tested rules into `SKILL.md`.

## Copy-Paste Goal Prompt

Replace `<YOUR_CODEX_SKILL_CREATOR_SKILL_MD_PATH>` and `<YOUR_VAULT_PATH>` with your own local paths.

```text
/goal Build an Ignition 8.1 Perspective skill from scratch by repeatedly testing real Perspective page-building through the Web Dev runner API, learning what works, documenting the evidence, and promoting only tested rules into the skill.

Use skill-creator before creating or editing the skill:
<YOUR_CODEX_SKILL_CREATOR_SKILL_MD_PATH>

Working vault:
<YOUR_VAULT_PATH>

Create this schema:
skills\ignition-perspective-builder\
  SKILL.md
  TESTING.md
  EVIDENCE.md
  HANDOFF.md
  CLAIM_COVERAGE.md
  references\
  scripts\
  agents\

webdev-runner\
  RUNNER.md
  docs\CAPABILITIES.md
  docs\API_CHANGE_WORKFLOW.md
  evidence\EVIDENCE.md
  handoff\HANDOFF.md
  notes\NOTES.md

Core loop:
1. Pick one realistic Perspective visualization or workflow: tank overview, pump/valve faceplate, process line overview, alarm panel, history trend, equipment detail route, reusable template, parameterized embedded view, navigation shell, or status dashboard.
2. Research Ignition 8.1 official docs and high-value Inductive Automation forum examples only as background.
3. Write or update a focused test case in TESTING.md before building.
4. Call runner health first and inspect runnerVersion, supportedActions, features, and mutationLockedActions.
5. Use discovery before writes: projectsList, routesList, viewsList, viewRead, styleResourcesList, seedViewsList, seedViewRead, componentSeedRead, tagProviders, tagBrowse, tagRead, namedQueriesList, namedQueryRead, namedQueryPreview, historyProbe, alarmStatusQuery, alarmJournalQuery, auditQuery, and logQuery as useful.
6. Build the Perspective package or resource using existing project patterns and discovered seeds instead of guessing component JSON.
7. Use dryRun before every write. Apply only with the exact confirmation string. Do not delete live resources unless explicitly asked.
8. Validate with pageValidate, routesList, viewsList, viewRead, dependency checks, tag/Named Query/history/alarm readback, Gateway logs, and browser/runtime proof when needed.
9. Save raw request/response evidence under test-runs\..., then summarize it in EVIDENCE.md.
10. Try to invalidate the rule: test at least one bad input, missing dependency, wrong binding, route conflict, bad component shape, or unsupported API path when practical.
11. Update CLAIM_COVERAGE.md with each SKILL.md claim and whether it is live-tested, locally tested, docs-only, or unproven.
12. Promote only reusable, tested lessons into SKILL.md. Put raw logs, failed attempts, screenshots, and long notes in EVIDENCE.md, TESTING.md, HANDOFF.md, or references\, not in SKILL.md.
13. Update HANDOFF.md after each batch with current versions, tested patterns, open gaps, and next recommended tests.

API evolution rule:
If the current runner API cannot inspect, apply, validate, or debug something needed for the Perspective workflow, add the smallest useful API feature instead of working around it manually. For every API change:
- update both active runner variants;
- add or update focused runner tests;
- update webdev-runner\RUNNER.md;
- update webdev-runner\docs\CAPABILITIES.md;
- update the public API reference/setup docs if the request or response contract changed;
- update any SKILL.md or reference docs that teach the changed API name, field, behavior, confirmation, or validation rule;
- bump runnerVersion for API behavior/contract changes;
- bump stackVersion for shipped skill/docs/product changes;
- run validation and record evidence.

Agent roles to use when helpful:
- Researcher: finds official Ignition 8.1 docs and relevant forum patterns.
- Builder: creates the Perspective package/view/resource.
- API Implementer: adds runner features only when the loop proves they are needed.
- Test Runner: executes dryRun/apply/validation and captures raw evidence.
- Skill Reviewer: compares tested evidence against SKILL.md and removes or labels untested claims.
- Doc Reflector: searches docs and skills for API naming/contract drift after runner changes.

Do not treat research as proof. A rule belongs in SKILL.md only when it is verified through live Gateway/API testing or clearly labeled as docs-only guidance awaiting validation.

Do not mark the overall project complete. Keep iterating: test, invalidate, learn, update evidence, improve the API if needed, and refine the Perspective skill so another LLM can reliably build the same kinds of pages.
```

## What Each File Is For

- `SKILL.md`: concise instructions another LLM should actually use.
- `TESTING.md`: planned tests, bad-input tests, current test status, and next tests.
- `EVIDENCE.md`: summarized proof with links to raw request/response evidence.
- `HANDOFF.md`: current versions, open gaps, tested patterns, and next steps.
- `CLAIM_COVERAGE.md`: every skill claim mapped to live-tested, locally tested, docs-only, or unproven.
- `references\`: supporting notes that are too long for `SKILL.md`.
- `scripts\`: repeatable harnesses and helper checks.
- `webdev-runner\docs\CAPABILITIES.md`: current runner action and feature map.
- `webdev-runner\docs\API_CHANGE_WORKFLOW.md`: what must change when the API contract changes.

## Promotion Rule

Research is background, not proof. Official Ignition documentation and strong Inductive Automation forum examples help choose tests, but a rule belongs in `SKILL.md` only when it has been verified through live Gateway/API testing or clearly labeled as docs-only guidance awaiting validation.

## Why This Works

Generic AI agents can produce plausible Ignition content, but Ignition has real constraints: Perspective resource structure, Jython 2.7.3, tag quality, route configuration, Named Queries, historian data, alarms, Gateway logs, project scans, and browser runtime behavior.

The goal loop gives the agent a way to learn those constraints from the Gateway instead of hallucinating around them.

## Product Context

Ignition AI Skills packages this method into the Ignition AI Toolkit. The Toolkit includes the Web Dev API runner plus focused skills for Perspective pages, importable Perspective zips, UDTs, Jython 2.7.3 scripts, SQL and Named Queries, expression language, button/action logging, HMI/SCADA visual standards, historian troubleshooting, performance profiling, and AI log diagnostics.

Main site: https://www.ignitionaiskills.com/

Blog article: https://www.ignitionaiskills.com/blog/build-ignition-perspective-ai-skill-goal-loop

Web Dev API Runner: https://www.ignitionaiskills.com/api-runner

Related article: https://www.ignitionaiskills.com/blog/ignition-web-dev-api-ai-agent