dev-ones-app

Name: dev-ones-app
Author: ONES-com

18stars3forks

How to install dev-ones-app?

ones-com/agent-skills/dev-ones-app

$npx -y skills add ONES-com/agent-skills --skill dev-ones-app

Installs into the current project.

Summary

Evaluate, design, implement, and deliver ONES Apps (ONES Plugin / .opkx) against local ONES App specs. Use for feasibility assessment, capability mapping, implementation planning, and delivery across OpenAPI, Hosted API, Events, Extensions, Web SDK, and manifest/runtime configu

Files · 1

View on GitHub

SKILL.md

1	## Goal
2	Convert ONES App requirements into spec-backed `.opkx` solutions that can be evaluated, built, and delivered.
3
4	## App Model And Runtime Defaults
5
6	- In this skill, a ONES App means a ONES Hosted App unless the user explicitly says they need an externally hosted app.
7	- Backend code runs in the ONES runtime container.
8	- Default backend language is Node.js.
9	- Default backend framework is NestJS.
10	- Frontend code runs in the ONES frontend sandbox.
11	- Default frontend framework is React.
12	- Open Platform ability families include OpenAPI, Events, Extensions, Web SDK, and lifecycle callbacks.
13	- Hosted ability families include structured data storage and file storage.
14
15	## Scope
16	- Clarify requirements, assess feasibility, map capabilities, design solutions, implement features, and deliver ONES Apps (`.opkx`).
17	- Validate OpenAPI, Hosted API, Events, Extensions, Web SDK, and manifest/runtime capabilities against `.ones/ones-app-specs`.
18	- Provide a minimum viable demo path when the user needs a starting point.
19
20	## Spec Source And Selection Rules
21
22	- Prefer project-level specs: `<project>/.ones/ones-app-specs`
23	- If project-level specs do not exist, use global specs: `~/.ones/ones-app-specs`
24	- Install the `ones` CLI with `npm install -g @ones-open/cli`
25	- When working inside a project, run `ones specs fetch --dir "$(pwd)"` first to ensure the specs match the current project version
26	- Requirement evaluation, capability mapping, and implementation decisions must all be traceable to local spec files. Do not answer from memory.
27	- Follow [references/ones-app-specs-playbook.md](references/ones-app-specs-playbook.md) to search `.ones/ones-app-specs`.
28	- Use these lightweight references only when needed:
29	- `references/ones-cli-playbook.md`
30	- `references/ones-app-dev-playbook.md`
31
32	## Default Flow For Requirement Evaluation
33
34	Use this default flow when the user asks "can this be done", "how do I do this", or "what scopes / events / extensions / manifest fields are required":
35
36	1. Load `references/ones-app-specs-playbook.md` first
37	2. Normalize the capability terms and business object terms in the requirement
38	3. Inspect `capability-tree.json` and `guide/guide-index.json` first to narrow the search scope
39	4. Then use `rg` to search `openapi-spec.yaml`, `hosted-api/.yaml`, `schemas//.json`, and `guide/*/.mdx`
40	5. Output a capability evidence table. If there is no local evidence, classify it as `REQUIRES CLARIFICATION` or `unsupported` according to the playbook rules
41
42	## First Response Requirements
43
44	After receiving a requirement, the first reply should include these three sections by default:
45
46	1. Requirement understanding checklist
47	- List the requirement points in numbered form
48	- Mark high-risk assumptions as `Pending confirmation`
49
50	2. Capability mapping draft
51	- List items in the format "requirement point -> ONES capability type -> initial evidence entry point"
52	- List temporarily unmapped items separately
53
54	3. Next actions
55	- State which spec files will be searched next
56	- If critical information is missing, ask only the minimum questions that affect capability judgment
57
58	## Standard Flow From Requirement To Implementation
59
60	1. Requirement collection and clarification
61	- When the user requirement is incomplete, fill in the key details that affect capability judgment first: runtime mode, OAuth / scope, event source, extension entry point, storage, and delivery form
62	- When the user has no clear requirement, provide a minimum viable demo path
63
64	2. Requirement confirmation
65	- Repeat back the understanding in a numbered list
66	- Clearly distinguish what the user has confirmed from what is still an assumption
67
68	3. Feasibility evaluation
69	- Every requirement point must map to local spec evidence
70	- Mark it as `supported` when clear evidence exists
71	- Mark it as `REQUIRES CLARIFICATION` when the user's wording is too unclear to decide
72	- After targeted search, if there is still no matching capability evidence, mark it directly as `unsupported`
73
74	4. Solution design (complex requirements)
75	- Complex requirements must cover: manifest changes, backend endpoints / services, frontend pages / Web SDK, storage model, authentication / scope, and verification path
76	- Backend callback path:
77	- Use this path when the feature is mainly triggered by an event callback or lifecycle callback, and may also call OpenAPI or persist business data or files.
78	- Inspect the current project's event, lifecycle, OpenAPI, hosted API, and schema files.
79	- If there is no clear match, tell the user which capability is unsupported or still requires clarification.
80	- If there is a clear match, implement the callback flow according to the project specs.
81	- Front

People who liked this also viewed

6 picks

Type

dev-ones-app

18stars3forks

View on GitHub

How to install dev-ones-app?

ones-com/agent-skills/dev-ones-app

$npx -y skills add ONES-com/agent-skills --skill dev-ones-app

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	## Goal
2	Convert ONES App requirements into spec-backed `.opkx` solutions that can be evaluated, built, and delivered.
3
4	## App Model And Runtime Defaults
5
6	- In this skill, a ONES App means a ONES Hosted App unless the user explicitly says they need an externally hosted app.
7	- Backend code runs in the ONES runtime container.
8	- Default backend language is Node.js.
9	- Default backend framework is NestJS.
10	- Frontend code runs in the ONES frontend sandbox.
11	- Default frontend framework is React.
12	- Open Platform ability families include OpenAPI, Events, Extensions, Web SDK, and lifecycle callbacks.
13	- Hosted ability families include structured data storage and file storage.
14
15	## Scope
16	- Clarify requirements, assess feasibility, map capabilities, design solutions, implement features, and deliver ONES Apps (`.opkx`).
17	- Validate OpenAPI, Hosted API, Events, Extensions, Web SDK, and manifest/runtime capabilities against `.ones/ones-app-specs`.
18	- Provide a minimum viable demo path when the user needs a starting point.
19
20	## Spec Source And Selection Rules
21
22	- Prefer project-level specs: `<project>/.ones/ones-app-specs`
23	- If project-level specs do not exist, use global specs: `~/.ones/ones-app-specs`
24	- Install the `ones` CLI with `npm install -g @ones-open/cli`
25	- When working inside a project, run `ones specs fetch --dir "$(pwd)"` first to ensure the specs match the current project version
26	- Requirement evaluation, capability mapping, and implementation decisions must all be traceable to local spec files. Do not answer from memory.
27	- Follow [references/ones-app-specs-playbook.md](references/ones-app-specs-playbook.md) to search `.ones/ones-app-specs`.
28	- Use these lightweight references only when needed:
29	- `references/ones-cli-playbook.md`
30	- `references/ones-app-dev-playbook.md`
31
32	## Default Flow For Requirement Evaluation
33
34	Use this default flow when the user asks "can this be done", "how do I do this", or "what scopes / events / extensions / manifest fields are required":
35
36	1. Load `references/ones-app-specs-playbook.md` first
37	2. Normalize the capability terms and business object terms in the requirement
38	3. Inspect `capability-tree.json` and `guide/guide-index.json` first to narrow the search scope
39	4. Then use `rg` to search `openapi-spec.yaml`, `hosted-api/.yaml`, `schemas//.json`, and `guide/*/.mdx`
40	5. Output a capability evidence table. If there is no local evidence, classify it as `REQUIRES CLARIFICATION` or `unsupported` according to the playbook rules
41
42	## First Response Requirements
43
44	After receiving a requirement, the first reply should include these three sections by default:
45
46	1. Requirement understanding checklist
47	- List the requirement points in numbered form
48	- Mark high-risk assumptions as `Pending confirmation`
49
50	2. Capability mapping draft
51	- List items in the format "requirement point -> ONES capability type -> initial evidence entry point"
52	- List temporarily unmapped items separately
53
54	3. Next actions
55	- State which spec files will be searched next
56	- If critical information is missing, ask only the minimum questions that affect capability judgment
57
58	## Standard Flow From Requirement To Implementation
59
60	1. Requirement collection and clarification
61	- When the user requirement is incomplete, fill in the key details that affect capability judgment first: runtime mode, OAuth / scope, event source, extension entry point, storage, and delivery form
62	- When the user has no clear requirement, provide a minimum viable demo path
63
64	2. Requirement confirmation
65	- Repeat back the understanding in a numbered list
66	- Clearly distinguish what the user has confirmed from what is still an assumption
67
68	3. Feasibility evaluation
69	- Every requirement point must map to local spec evidence
70	- Mark it as `supported` when clear evidence exists
71	- Mark it as `REQUIRES CLARIFICATION` when the user's wording is too unclear to decide
72	- After targeted search, if there is still no matching capability evidence, mark it directly as `unsupported`
73
74	4. Solution design (complex requirements)
75	- Complex requirements must cover: manifest changes, backend endpoints / services, frontend pages / Web SDK, storage model, authentication / scope, and verification path
76	- Backend callback path:
77	- Use this path when the feature is mainly triggered by an event callback or lifecycle callback, and may also call OpenAPI or persist business data or files.
78	- Inspect the current project's event, lifecycle, OpenAPI, hosted API, and schema files.
79	- If there is no clear match, tell the user which capability is unsupported or still requires clarification.
80	- If there is a clear match, implement the callback flow according to the project specs.
81	- Front

People who liked this also viewed

6 picks

Type