@cira-app/cli 0.1.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/SKILL.md +78 -0
- package/bin/cira.js +1348 -0
- package/package.json +32 -0
package/SKILL.md
ADDED
|
@@ -0,0 +1,78 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: cira
|
|
3
|
+
description: Build and deploy internal company software to Cira. Use when a project is being deployed to Cira or the user asks to work with Cira.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Cira
|
|
7
|
+
|
|
8
|
+
Cira is where companies deploy and use internal software.
|
|
9
|
+
|
|
10
|
+
## Core rule
|
|
11
|
+
|
|
12
|
+
Build normal software using the project's existing framework and conventions. Do not redesign an app around Cira.
|
|
13
|
+
|
|
14
|
+
Cira automatically analyzes deployed code for reusable business capabilities.
|
|
15
|
+
|
|
16
|
+
## While building
|
|
17
|
+
|
|
18
|
+
Make the app easy for Cira to understand without adding Cira-specific architecture:
|
|
19
|
+
|
|
20
|
+
- Keep meaningful server-side business operations explicit.
|
|
21
|
+
- Use descriptive names for business functions and routes.
|
|
22
|
+
- Prefer typed inputs and outputs.
|
|
23
|
+
- Keep business logic separate from purely presentational UI when practical.
|
|
24
|
+
- Keep sensitive or destructive operations clearly separated.
|
|
25
|
+
- Preserve the existing architecture unless a real problem requires a change.
|
|
26
|
+
|
|
27
|
+
Do not create an MCP server for the app.
|
|
28
|
+
Do not create manual capability manifests unless Cira explicitly asks for an override.
|
|
29
|
+
Do not weaken security or restructure working code only to influence capability detection.
|
|
30
|
+
|
|
31
|
+
## Cira CLI
|
|
32
|
+
|
|
33
|
+
Check the current project:
|
|
34
|
+
|
|
35
|
+
cira status
|
|
36
|
+
|
|
37
|
+
Authenticate if needed:
|
|
38
|
+
|
|
39
|
+
cira login
|
|
40
|
+
|
|
41
|
+
Deploy:
|
|
42
|
+
|
|
43
|
+
cira deploy
|
|
44
|
+
|
|
45
|
+
If the user belongs to multiple Spaces and the target Space is known:
|
|
46
|
+
|
|
47
|
+
cira deploy --space <slug>
|
|
48
|
+
|
|
49
|
+
Use only CLI commands and flags that actually exist.
|
|
50
|
+
|
|
51
|
+
## After deployment
|
|
52
|
+
|
|
53
|
+
Read Cira's deployment output.
|
|
54
|
+
|
|
55
|
+
Cira may automatically:
|
|
56
|
+
|
|
57
|
+
- deploy and link the app
|
|
58
|
+
- analyze the codebase
|
|
59
|
+
- discover business capabilities
|
|
60
|
+
- classify capability risk
|
|
61
|
+
- enable safe capabilities
|
|
62
|
+
|
|
63
|
+
If deployment succeeds, stop unless the user asked for more work.
|
|
64
|
+
|
|
65
|
+
If Cira reports a capability problem, make the smallest sensible code change that improves clarity or reachability, then redeploy. Never disguise destructive behavior as a safe capability.
|
|
66
|
+
|
|
67
|
+
## Safety
|
|
68
|
+
|
|
69
|
+
Never bypass Cira access controls or risk classifications.
|
|
70
|
+
Never expose secrets, raw database access, privileged infrastructure operations, or destructive admin functions as ordinary capabilities.
|
|
71
|
+
|
|
72
|
+
## Goal
|
|
73
|
+
|
|
74
|
+
The ideal workflow is:
|
|
75
|
+
|
|
76
|
+
build normal software
|
|
77
|
+
-> cira deploy
|
|
78
|
+
-> done
|