@elevasis/sdk 0.4.6 → 0.4.7
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/dist/cli.cjs +814 -451
- package/dist/index.d.ts +79 -14
- package/dist/index.js +17 -12
- package/dist/templates.js +747 -0
- package/dist/types/templates.d.ts +1 -0
- package/dist/types/worker/index.d.ts +6 -0
- package/dist/types/worker/platform.d.ts +32 -0
- package/dist/worker/index.js +4701 -9
- package/package.json +16 -10
- package/reference/_index.md +48 -6
- package/reference/_navigation.md +104 -0
- package/reference/cli/index.mdx +2 -1
- package/reference/concepts/index.mdx +203 -0
- package/reference/deployment/api.mdx +1 -0
- package/reference/deployment/index.mdx +1 -0
- package/reference/developer/interaction-guidance.mdx +213 -0
- package/reference/framework/agent.mdx +175 -0
- package/reference/{documentation/index.mdx → framework/documentation.mdx} +1 -0
- package/reference/framework/index.mdx +95 -0
- package/reference/framework/memory.mdx +337 -0
- package/reference/framework/project-structure.mdx +294 -0
- package/reference/getting-started/index.mdx +39 -15
- package/reference/index.mdx +10 -2
- package/reference/platform-tools/examples.mdx +1 -0
- package/reference/platform-tools/index.mdx +43 -2
- package/reference/resources/index.mdx +1 -0
- package/reference/resources/patterns.mdx +2 -1
- package/reference/resources/types.mdx +1 -0
- package/reference/roadmap/index.mdx +1 -0
- package/reference/runtime/index.mdx +1 -0
- package/reference/runtime/limits.mdx +1 -0
- package/reference/security/credentials.mdx +141 -0
- package/reference/templates/data-enrichment.mdx +162 -0
- package/reference/templates/email-sender.mdx +135 -0
- package/reference/templates/lead-scorer.mdx +175 -0
- package/reference/templates/pdf-generator.mdx +151 -0
- package/reference/templates/recurring-job.mdx +189 -0
- package/reference/templates/text-classifier.mdx +147 -0
- package/reference/templates/web-scraper.mdx +135 -0
- package/reference/troubleshooting/common-errors.mdx +210 -0
- package/reference/getting-started/project-structure.mdx +0 -148
|
@@ -0,0 +1,213 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Interaction Guidance"
|
|
3
|
+
description: "Full dimensional adaptation rules per skill axis -- programming, TypeScript, API integration, automation concepts, domain expertise -- with growth tracking protocol"
|
|
4
|
+
loadWhen: "Unsure how to adapt for a skill combination"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
This reference defines how to adapt every interaction based on the dimensions in `.claude/memory/profile/skills.md`. Read it when the compact directive in CLAUDE.md is not enough to decide how to handle an unusual skill combination.
|
|
8
|
+
|
|
9
|
+
---
|
|
10
|
+
|
|
11
|
+
## Skill Dimensions
|
|
12
|
+
|
|
13
|
+
The user profile stores five independent skill dimensions. Each dimension has its own adaptation rules. Do not collapse them into a single beginner/intermediate/advanced rating.
|
|
14
|
+
|
|
15
|
+
### Programming Fundamentals (none / minimal / comfortable / advanced)
|
|
16
|
+
|
|
17
|
+
**none** -- Has not written code. May have used no-code tools.
|
|
18
|
+
|
|
19
|
+
- Explain what functions, variables, and objects are when they appear in code
|
|
20
|
+
- Use analogies for every technical concept (see Analogies section below)
|
|
21
|
+
- Show complete, working files with every import included
|
|
22
|
+
- Never show code fragments they cannot place
|
|
23
|
+
- Walk through each line in plain English before showing code
|
|
24
|
+
- Do not assume they can read code independently
|
|
25
|
+
|
|
26
|
+
**minimal** -- Has written HTML, CSS, Excel formulas, or simple scripts.
|
|
27
|
+
|
|
28
|
+
- Briefly explain language constructs that differ from what they know
|
|
29
|
+
- Show complete files with inline comments on non-obvious parts
|
|
30
|
+
- Avoid assuming they know what async/await, imports, or type annotations do
|
|
31
|
+
- Skip explanations of basic web/formula concepts they likely know
|
|
32
|
+
|
|
33
|
+
**comfortable** -- Has written programs in at least one general-purpose language.
|
|
34
|
+
|
|
35
|
+
- Brief inline comments for non-obvious SDK-specific parts
|
|
36
|
+
- Skip explanations of variables, functions, loops, and basic data structures
|
|
37
|
+
- Focus on what is different about TypeScript and the SDK API
|
|
38
|
+
|
|
39
|
+
**advanced** -- Writes production software professionally.
|
|
40
|
+
|
|
41
|
+
- Concise code, no commentary on language features
|
|
42
|
+
- Focus only on SDK-specific patterns and constraints
|
|
43
|
+
- Trust them to infer context from types and naming
|
|
44
|
+
|
|
45
|
+
---
|
|
46
|
+
|
|
47
|
+
### TypeScript (none / exposure / proficient)
|
|
48
|
+
|
|
49
|
+
**none** -- Has not used TypeScript or any statically typed language.
|
|
50
|
+
|
|
51
|
+
- Show complete files with every import
|
|
52
|
+
- Explain type annotations as "labels that describe what kind of data this is"
|
|
53
|
+
- Never use generics without a plain-English explanation
|
|
54
|
+
- Explain `z.infer` every time it appears: "This creates a TypeScript type from the schema so you get autocomplete and error checking"
|
|
55
|
+
- Explain the difference between runtime validation (Zod) and compile-time checking (TypeScript)
|
|
56
|
+
|
|
57
|
+
**exposure** -- Has read TypeScript or used a typed language (Java, C#, Go).
|
|
58
|
+
|
|
59
|
+
- Show code with brief type annotation comments for SDK-specific types
|
|
60
|
+
- Explain `WorkflowDefinition`, `StepType`, and `OrganizationResources` on first use
|
|
61
|
+
- Trust them to understand basic type syntax
|
|
62
|
+
|
|
63
|
+
**proficient** -- Has written TypeScript projects.
|
|
64
|
+
|
|
65
|
+
- Types without explanation
|
|
66
|
+
- Focus on SDK API surface, not language features
|
|
67
|
+
- Trust them to read type definitions
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
### API and Integration (none / basic / proficient)
|
|
72
|
+
|
|
73
|
+
**none** -- Has not called an API directly. Uses tools with built-in integrations.
|
|
74
|
+
|
|
75
|
+
- Explain what credentials are and why they exist before any integration code
|
|
76
|
+
- Walk through credential creation in the platform command center step by step
|
|
77
|
+
- Explain what "calling an API" means in plain English
|
|
78
|
+
- Explain why `.env` exists and what `ELEVASIS_API_KEY` is for
|
|
79
|
+
- Do not assume they understand HTTP methods, JSON, or authentication headers
|
|
80
|
+
|
|
81
|
+
**basic** -- Has used APIs with documentation or built simple integrations.
|
|
82
|
+
|
|
83
|
+
- Show `platform.call()` patterns with brief notes on credential names
|
|
84
|
+
- Reference the platform credential system for setup without full walkthrough
|
|
85
|
+
- Explain SDK-specific credential patterns (how the platform injects secrets server-side)
|
|
86
|
+
|
|
87
|
+
**proficient** -- Has built production integrations, understands REST and auth patterns.
|
|
88
|
+
|
|
89
|
+
- Just the code and credential name
|
|
90
|
+
- Trust them to set up credentials in the command center without guidance
|
|
91
|
+
- Focus on SDK-specific behavior (timeout, error types, server-side injection)
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
### Automation Concepts (none / low-code / custom)
|
|
96
|
+
|
|
97
|
+
**none** -- Has not used automation tools. Thinks in manual processes.
|
|
98
|
+
|
|
99
|
+
- Use analogies before any technical explanation (see Analogies section)
|
|
100
|
+
- Explain the execution model early: "Your code runs on Elevasis servers, not your computer"
|
|
101
|
+
- Define Workflow, Step, Trigger, Schema, Credential on first use
|
|
102
|
+
- Explain why automation is valuable for their specific use case before building anything
|
|
103
|
+
- Explain deploy: "After deploy, your workflow is live and can be triggered"
|
|
104
|
+
|
|
105
|
+
**low-code** -- Has used Zapier, Make, or similar tools.
|
|
106
|
+
|
|
107
|
+
- Map Elevasis concepts to tools they know: "Steps are like Zapier actions. The workflow is the Zap."
|
|
108
|
+
- Focus on what is different: code is more flexible but requires TypeScript
|
|
109
|
+
- Explain schema validation: "Zapier has field mapping; Elevasis has schemas that validate the shape of data"
|
|
110
|
+
|
|
111
|
+
**custom** -- Has written custom automation scripts or integrations.
|
|
112
|
+
|
|
113
|
+
- Skip analogies
|
|
114
|
+
- Focus on the SDK execution model: worker threads, postMessage, ephemeral processes
|
|
115
|
+
- Explain the credential security model (server-side injection, no env vars in workers)
|
|
116
|
+
- Discuss error handling patterns and retry behavior
|
|
117
|
+
|
|
118
|
+
---
|
|
119
|
+
|
|
120
|
+
### Domain Expertise
|
|
121
|
+
|
|
122
|
+
Domain expertise is not a code skill. It is the user's depth of knowledge in their industry or business function (sales, finance, operations, marketing, etc.).
|
|
123
|
+
|
|
124
|
+
When domain expertise is high:
|
|
125
|
+
|
|
126
|
+
- Ask for business process descriptions before designing schemas
|
|
127
|
+
- Let them drive the "what" (business logic); you handle the "how" (implementation)
|
|
128
|
+
- Translate their process description into workflow steps, schemas, and tool choices
|
|
129
|
+
- Validate your understanding: "So the workflow should: receive a new lead from the CRM, score it based on these criteria, and send a Slack alert if the score is above 80?"
|
|
130
|
+
- Trust their judgment on what the workflow should do; never second-guess business logic
|
|
131
|
+
|
|
132
|
+
When domain expertise is low:
|
|
133
|
+
|
|
134
|
+
- Ask clarifying questions about the business process before designing anything
|
|
135
|
+
- Do not assume what "a lead" or "a deal" or "an invoice" means in their context
|
|
136
|
+
- Confirm edge cases explicitly: "What should happen if the lead has no email address?"
|
|
137
|
+
|
|
138
|
+
---
|
|
139
|
+
|
|
140
|
+
## Analogies for Non-Technical Users
|
|
141
|
+
|
|
142
|
+
Use these when programming level is none or minimal, or when automation level is none.
|
|
143
|
+
|
|
144
|
+
| Concept | Analogy |
|
|
145
|
+
| --- | --- |
|
|
146
|
+
| Workflow | A recipe: ingredients go in (input), steps are instructions, finished dish comes out (output) |
|
|
147
|
+
| Step | One instruction in a recipe: "add salt," "stir for 2 minutes" |
|
|
148
|
+
| Schema | A form template: it defines what fields exist and what type of data each field accepts |
|
|
149
|
+
| Deployment | Publishing: like publishing a document so others can access it |
|
|
150
|
+
| Execution | One run: like baking the recipe once |
|
|
151
|
+
| Platform tool | A kitchen appliance: you use the mixer (tool) without knowing how it works inside |
|
|
152
|
+
| Credential | A key: you give Elevasis the key to your Gmail account; it unlocks the door when needed |
|
|
153
|
+
| Assembly line | Raw material goes in one end (input), each station does one job (step), finished product comes out (output) |
|
|
154
|
+
|
|
155
|
+
Choose the analogy that fits the user's domain. A sales operations person will relate more to "a form template" than a developer would.
|
|
156
|
+
|
|
157
|
+
---
|
|
158
|
+
|
|
159
|
+
## Growth Tracking Protocol
|
|
160
|
+
|
|
161
|
+
### Observations
|
|
162
|
+
|
|
163
|
+
During each session, note behaviors that reveal skill level changes. Examples:
|
|
164
|
+
|
|
165
|
+
- User wrote a handler without asking for help
|
|
166
|
+
- User independently caught a type error before you pointed it out
|
|
167
|
+
- User suggested using StepType.CONDITIONAL without prompting
|
|
168
|
+
- User asked a question that shows they now understand the execution model
|
|
169
|
+
|
|
170
|
+
### Promotion Rules
|
|
171
|
+
|
|
172
|
+
Do not automatically update the skill profile for every observation. Update when:
|
|
173
|
+
|
|
174
|
+
- The user independently performs a task they previously needed explicit help with
|
|
175
|
+
- The behavior is consistent across at least two instances (not a one-off)
|
|
176
|
+
- The observation demonstrates understanding, not just copying a pattern
|
|
177
|
+
|
|
178
|
+
### Update Format
|
|
179
|
+
|
|
180
|
+
When updating `.claude/memory/profile/skills.md` Growth Log:
|
|
181
|
+
|
|
182
|
+
```
|
|
183
|
+
| Date | Observation | Skill Updated |
|
|
184
|
+
| 2026-03-01 | Wrote complete handler with correct types independently | TypeScript: none -> exposure |
|
|
185
|
+
```
|
|
186
|
+
|
|
187
|
+
Also update the dimension's Level field and Evidence field to reflect the new assessment.
|
|
188
|
+
|
|
189
|
+
### Celebration
|
|
190
|
+
|
|
191
|
+
When growth is observed, acknowledge it briefly:
|
|
192
|
+
|
|
193
|
+
- "You just wrote that handler without any help -- your TypeScript is definitely improving."
|
|
194
|
+
- "Good catch on the optional field -- that is exactly the kind of thing that trips people up."
|
|
195
|
+
|
|
196
|
+
Keep it natural. One sentence is enough. Do not over-celebrate.
|
|
197
|
+
|
|
198
|
+
---
|
|
199
|
+
|
|
200
|
+
## When This Reference is Needed
|
|
201
|
+
|
|
202
|
+
Load this file when:
|
|
203
|
+
|
|
204
|
+
- Starting `/meta init` to understand how to phrase the competency assessment questions
|
|
205
|
+
- The user's skill combination is unusual and the compact CLAUDE.md directive is not enough to decide how to respond
|
|
206
|
+
- Reassessing skill levels after several sessions
|
|
207
|
+
- Writing the initial profile during onboarding
|
|
208
|
+
|
|
209
|
+
For routine sessions, the compact directive in CLAUDE.md plus the user's stored `skills.md` is sufficient.
|
|
210
|
+
|
|
211
|
+
---
|
|
212
|
+
|
|
213
|
+
**Last Updated:** 2026-02-26
|
|
@@ -0,0 +1,175 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Agent System
|
|
3
|
+
description: CLAUDE.md drives all agent behavior -- project instructions, slash commands, memory-based developer profile, and three-tier adaptive guidance
|
|
4
|
+
loadWhen: "Configuring agent behavior or capabilities"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
The agent system is the set of files that shape how Claude Code behaves in your SDK project. It consists of four parts: `CLAUDE.md` (the instruction file), slash commands (structured task entry points), the developer profile stored in `memory/profile/`, and the adaptive guidance rules that translate profile data into concrete agent behavior.
|
|
8
|
+
|
|
9
|
+
Nothing here requires configuration. The agent reads these files at session start and adapts automatically.
|
|
10
|
+
|
|
11
|
+
## CLAUDE.md
|
|
12
|
+
|
|
13
|
+
`CLAUDE.md` is the project instruction file for Claude Code. It is read at the start of every session and governs all agent behavior. In an Elevasis SDK project, it is generated by `elevasis init` and lives at the project root.
|
|
14
|
+
|
|
15
|
+
The file is instruction-driven by design. Non-technical developers should never need to edit it. When the agent learns a new rule worth preserving -- such as an error pattern that recurs three times -- it promotes that rule into `CLAUDE.md` automatically.
|
|
16
|
+
|
|
17
|
+
### Sections
|
|
18
|
+
|
|
19
|
+
The generated `CLAUDE.md` contains these sections:
|
|
20
|
+
|
|
21
|
+
- **Session Initialization** -- Instructs the agent to read `memory/index.md` silently at session start, drill into `memory/profile/skills.md` for adaptive behavior, suggest `/meta init` if memory does not exist, and notify the user if the template version is outdated.
|
|
22
|
+
- **What This Is** -- Project orientation: what an Elevasis SDK project is and how it deploys to the platform.
|
|
23
|
+
- **Project Structure** -- Which files contain resources, documentation, and configuration.
|
|
24
|
+
- **CLI Reference** -- All `elevasis` commands with flags, including deploy, exec, env, and execution inspection.
|
|
25
|
+
- **SDK Patterns** -- Working code examples for resource definitions, Zod schemas, multi-step workflows, platform tools, and execution context.
|
|
26
|
+
- **Rules** -- Project-specific constraints. Starts empty; grows as the agent promotes recurring error patterns.
|
|
27
|
+
- **Maintaining Memory** -- Hierarchical scaling pattern, pruning rules, and promotion criteria for the `memory/` directory.
|
|
28
|
+
- **SDK Reference Documentation** -- Paths to bundled SDK reference docs in `node_modules/@elevasis/sdk/reference/`.
|
|
29
|
+
- **Adaptive Guidance** -- Behavior rules for Beginner, Intermediate, and Advanced tiers based on skill levels read from `memory/profile/skills.md`.
|
|
30
|
+
|
|
31
|
+
### Session Initialization
|
|
32
|
+
|
|
33
|
+
At the start of every session the agent runs these steps silently before responding:
|
|
34
|
+
|
|
35
|
+
1. Read `.claude/memory/index.md` if it exists -- scan what project context has been recorded, including profile, error patterns, deployment state, and decisions. Drill into `memory/profile/skills.md` to personalize responses based on experience level.
|
|
36
|
+
2. If `.claude/memory/` does not exist, suggest running `/meta init` to set up the project.
|
|
37
|
+
3. Check the installed `@elevasis/sdk` template version against `templateVersion` in `elevasis.config.ts`. If the SDK has a newer version, notify the user and suggest running `/meta update`.
|
|
38
|
+
|
|
39
|
+
## Slash Commands
|
|
40
|
+
|
|
41
|
+
Slash commands are short Markdown instruction files in `.claude/commands/`. When you type `/command-name` in a Claude Code session, the agent reads the corresponding file and follows its instructions.
|
|
42
|
+
|
|
43
|
+
All nine commands are scaffolded by `elevasis init` and committed to version control so collaborators get the same experience:
|
|
44
|
+
|
|
45
|
+
| Command | File | Purpose |
|
|
46
|
+
| --- | --- | --- |
|
|
47
|
+
| `/meta` | `meta.md` | Project lifecycle management -- init, status, update, fix, deploy, health, develop |
|
|
48
|
+
| `/docs` | `docs.md` | Documentation lifecycle -- create, checkpoint, cleanup, resume, verify |
|
|
49
|
+
| `/database` | `database.md` | Database operations -- init, status, add, browse, schema, import |
|
|
50
|
+
| `/resource` | `resource.md` | Scaffolds a new workflow or agent resource in `src/` |
|
|
51
|
+
| `/templates` | `templates.md` | Workflow template discovery and scaffolding |
|
|
52
|
+
| `/agent` | `agent.md` | Agent development (placeholder for future agent runtime) |
|
|
53
|
+
| `/tutorial` | `tutorial.md` | Progressive learning path for new developers |
|
|
54
|
+
| `/help` | `help.md` | Displays the full command tree and navigation map |
|
|
55
|
+
| `/profile` | `profile.md` | Views and updates the developer profile in `memory/profile/` |
|
|
56
|
+
|
|
57
|
+
### `/meta` Command
|
|
58
|
+
|
|
59
|
+
The `/meta` command namespace manages the full project lifecycle. It has seven operations:
|
|
60
|
+
|
|
61
|
+
- **`/meta init`** -- First-run guided setup. Runs after `elevasis init` to install dependencies, configure `.env`, run the 6-question onboarding flow, seed `memory/profile/`, verify the project, and optionally do a first deploy.
|
|
62
|
+
- **`/meta`** (no arguments) -- Project health status. Shows current template version, SDK version, profile summary, and a quick drift check.
|
|
63
|
+
- **`/meta update`** -- Upgrade the SDK and merge template changes. Runs `pnpm update @elevasis/sdk`, then `elevasis update`, then intelligently merges flagged files and reports what changed.
|
|
64
|
+
- **`/meta fix`** -- Repair drift without a version upgrade. Checks for missing commands, missing gitignore entries, missing CLAUDE.md sections, broken memory links, and broken doc cross-references.
|
|
65
|
+
- **`/meta deploy`** -- Full 9-step deploy pipeline: validate, type-check, verify docs, commit, deploy, bump version, verify platform, update deployment state, and optionally push.
|
|
66
|
+
- **`/meta health`** -- Execution debugging and resource status; shows recent executions, analyzes failures, and checks environment connectivity.
|
|
67
|
+
- **`/meta develop`** -- Development navigation hub that loads the resource map, SDK reference, and project state; replaces the old standalone `/workflow`, `/tools`, and `/examples` commands.
|
|
68
|
+
|
|
69
|
+
### `/docs` Command
|
|
70
|
+
|
|
71
|
+
The `/docs` command manages the full documentation lifecycle. It has six operations:
|
|
72
|
+
|
|
73
|
+
- **`/docs`** (no arguments) -- Show current documentation status: pages in progress, recent changes, and any stale entries flagged for review.
|
|
74
|
+
- **`/docs create`** -- Create a new documentation page. Prompts for title, description, and location, then scaffolds an MDX file with proper frontmatter.
|
|
75
|
+
- **`/docs checkpoint`** -- Save current work progress for session resume. Creates or updates `docs/in-progress/<topic>.mdx` with current state, decisions made, remaining work, and blockers. Also updates `docs/priorities.mdx`.
|
|
76
|
+
- **`/docs cleanup`** -- Move completed documents from `docs/in-progress/` to their final location. Reviews each in-progress doc, relocates complete ones, and rebuilds `docs/navigation.mdx`.
|
|
77
|
+
- **`/docs resume`** -- Start-of-session review of in-progress docs, priorities, and recent deployment state. Offers to continue work on the highest-priority item.
|
|
78
|
+
- **`/docs verify`** -- Cross-reference documentation with the codebase. Reads the specified doc (or all docs if no path provided) and reports discrepancies against actual resource IDs, schema fields, and platform tools.
|
|
79
|
+
|
|
80
|
+
### `/database` Command
|
|
81
|
+
|
|
82
|
+
The `/database` command handles all database operations for projects that connect a Supabase project. It has six operations:
|
|
83
|
+
|
|
84
|
+
- **`/database init`** -- Connect a Supabase project. Prompts for project URL and anon key, writes connection config, and verifies connectivity.
|
|
85
|
+
- **`/database`** (no arguments) -- Show database status: connection health, migration count, and a summary of tables.
|
|
86
|
+
- **`/database add`** -- Create a migration script for a new table. Prompts for table name and columns, generates a typed migration, and updates schema documentation.
|
|
87
|
+
- **`/database browse`** -- Query and display table contents in a readable format for quick inspection during development.
|
|
88
|
+
- **`/database schema`** -- View or compare schema documentation against the live database. Highlights drift between documented schema and actual columns.
|
|
89
|
+
- **`/database import`** -- Import CSV or JSON data into a table. Validates column mapping before writing.
|
|
90
|
+
|
|
91
|
+
### `/help` Command
|
|
92
|
+
|
|
93
|
+
The `/help` command displays the complete command tree with one-line descriptions for every command and subcommand, plus navigation pointers to key project files (`docs/navigation.mdx`, `docs/priorities.mdx`, `memory/index.md`). It is the "I'm lost, what can I do?" entry point for command discovery and navigation.
|
|
94
|
+
|
|
95
|
+
### `/profile` Command
|
|
96
|
+
|
|
97
|
+
The profile command reads from and writes to `memory/profile/`. It has three modes:
|
|
98
|
+
|
|
99
|
+
- **No arguments** -- Displays the current profile in readable format (organization, industry, experience levels, goals, known integrations, preferences) and asks if anything needs updating.
|
|
100
|
+
- **`/profile update`** -- Walks through each profile section, shows current values, and updates only the fields the user wants to change. Writes changes to the appropriate `memory/profile/` file.
|
|
101
|
+
- **`/profile level`** -- Assesses the user's current skill level based on project history (resources created, successful deploys, error handling patterns) and suggests updating `memory/profile/skills.md` if the assessment differs from the stored level.
|
|
102
|
+
|
|
103
|
+
## Developer Profile
|
|
104
|
+
|
|
105
|
+
The developer profile is stored in `.claude/memory/profile/` as a set of markdown files. It is gitignored -- personal to each developer, not shared with collaborators. Profile data lives in the memory system alongside error patterns, deployment state, and decisions.
|
|
106
|
+
|
|
107
|
+
### Onboarding Flow
|
|
108
|
+
|
|
109
|
+
Profile data is created during `/meta init`. The command runs a 6-question onboarding conversation and writes the responses to `memory/profile/`:
|
|
110
|
+
|
|
111
|
+
1. What kind of business or team is this for? (industry, size)
|
|
112
|
+
2. What are the main goals for this project? (automation goals)
|
|
113
|
+
3. Which external tools or services will workflows integrate with? (integrations)
|
|
114
|
+
4. How would you describe your experience with TypeScript? (beginner / intermediate / advanced)
|
|
115
|
+
5. How familiar are you with AI automation and workflow concepts? (new / some experience / experienced)
|
|
116
|
+
6. Do you prefer detailed explanations or concise responses? (detailed / concise)
|
|
117
|
+
|
|
118
|
+
### Profile Structure
|
|
119
|
+
|
|
120
|
+
```
|
|
121
|
+
.claude/memory/profile/
|
|
122
|
+
├── index.md # Profile summary with links to sub-files
|
|
123
|
+
├── identity.md # Organization, industry, goals, integrations
|
|
124
|
+
├── skills.md # TypeScript level, automation experience, growth history
|
|
125
|
+
└── preferences.md # Verbosity, guidance style, interaction patterns
|
|
126
|
+
```
|
|
127
|
+
|
|
128
|
+
`identity.md` records the organization name, industry, size, project goals, and known tool integrations. `skills.md` stores the TypeScript and automation skill levels as structured values (`beginner / intermediate / advanced`, `new / some-experience / experienced`) along with a growth history table. `preferences.md` stores verbosity (`detailed / concise`) and proactive guidance preference.
|
|
129
|
+
|
|
130
|
+
### Auto-Update Triggers
|
|
131
|
+
|
|
132
|
+
The agent updates `memory/profile/` files when it observes:
|
|
133
|
+
|
|
134
|
+
- The user successfully completes an advanced task (level upgrade candidate in `skills.md`)
|
|
135
|
+
- The user mentions new tools or integrations not in `identity.md`
|
|
136
|
+
- The user explicitly asks to change preferences
|
|
137
|
+
|
|
138
|
+
The agent does not prompt for confirmation on minor updates. Major changes (level upgrades) are surfaced to the user before writing.
|
|
139
|
+
|
|
140
|
+
## Adaptive Guidance
|
|
141
|
+
|
|
142
|
+
The `CLAUDE.md` Adaptive Guidance section translates the skill levels from `memory/profile/skills.md` into concrete behavior rules. The agent checks the TypeScript level and automation level and applies the matching tier.
|
|
143
|
+
|
|
144
|
+
### Beginner
|
|
145
|
+
|
|
146
|
+
Applies when TypeScript level is `beginner` or automation level is `new`:
|
|
147
|
+
|
|
148
|
+
- Always show complete, working code -- never fragments
|
|
149
|
+
- Explain every new concept the first time it appears (TypeScript types, Zod schemas, async/await)
|
|
150
|
+
- After creating a resource, walk through deployment step by step
|
|
151
|
+
- Proactively suggest next steps ("Now let's deploy this" or "Want to test it?")
|
|
152
|
+
- When errors occur, explain both the fix and why it happened
|
|
153
|
+
- Use `/help` to navigate to the relevant SDK reference before suggesting platform tools
|
|
154
|
+
|
|
155
|
+
### Intermediate
|
|
156
|
+
|
|
157
|
+
Applies when TypeScript level is `intermediate` and automation level is `some-experience`:
|
|
158
|
+
|
|
159
|
+
- Show code with brief inline comments for non-obvious parts
|
|
160
|
+
- Explain new concepts but not basics (Zod, async/await, TypeScript types)
|
|
161
|
+
- Suggest deployment after resource creation but do not walk through it
|
|
162
|
+
- When errors occur, provide the fix with a one-line explanation
|
|
163
|
+
|
|
164
|
+
### Advanced
|
|
165
|
+
|
|
166
|
+
Applies when TypeScript level is `advanced` and automation level is `experienced`:
|
|
167
|
+
|
|
168
|
+
- Concise code, minimal explanation
|
|
169
|
+
- Focus on edge cases and performance
|
|
170
|
+
- Trust the user to deploy and test independently
|
|
171
|
+
- When errors occur, provide the fix
|
|
172
|
+
|
|
173
|
+
---
|
|
174
|
+
|
|
175
|
+
**Last Updated:** 2026-02-26
|
|
@@ -1,6 +1,7 @@
|
|
|
1
1
|
---
|
|
2
2
|
title: Resource Documentation
|
|
3
3
|
description: Write and deploy MDX documentation alongside your Elevasis resources
|
|
4
|
+
loadWhen: "Writing or updating project documentation"
|
|
4
5
|
---
|
|
5
6
|
|
|
6
7
|
`elevasis deploy` ships your code and your documentation atomically -- one command, no version drift. Documentation files live in a `docs/` directory at your project root and render in the Elevasis platform UI for operators using your resources.
|
|
@@ -0,0 +1,95 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: Development Framework
|
|
3
|
+
description: The SDK scaffolds a complete development environment for Claude Code -- project instructions, slash commands, cross-session memory, and template versioning
|
|
4
|
+
loadWhen: "Understanding the agent framework structure"
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
`elevasis init` scaffolds more than code. It builds a development environment designed around Claude Code as the primary interface. Most external SDK developers are non-technical -- they write workflows through conversation, not by reading API docs. The framework gives the agent everything it needs to guide those users effectively from the first session onward.
|
|
8
|
+
|
|
9
|
+
The framework lives entirely in `.claude/`. It is never deployed and never touches the `docs/` directory, which ships to the platform.
|
|
10
|
+
|
|
11
|
+
## What Gets Scaffolded
|
|
12
|
+
|
|
13
|
+
Running `elevasis init my-project` produces the following agent infrastructure alongside your source files:
|
|
14
|
+
|
|
15
|
+
```
|
|
16
|
+
.claude/
|
|
17
|
+
├── CLAUDE.md # Project instructions for Claude Code
|
|
18
|
+
├── settings.json # autoCompact: false
|
|
19
|
+
└── commands/
|
|
20
|
+
├── docs.md # Documentation assistant
|
|
21
|
+
├── resource.md # Resource scaffolding assistant
|
|
22
|
+
├── profile.md # View and update developer profile
|
|
23
|
+
├── meta.md # Project lifecycle (init, status, update, fix)
|
|
24
|
+
├── help.md # Contextual help and concept explanations
|
|
25
|
+
├── database.md # Database schema and query assistant
|
|
26
|
+
├── agent.md # Agent scaffolding and configuration
|
|
27
|
+
├── templates.md # Template browsing and generation
|
|
28
|
+
└── tutorial.md # Progressive 7-lesson learning path
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
The `memory/` directory is gitignored -- it is personal to each developer and not shared with collaborators. Everything else in `.claude/` is committed.
|
|
32
|
+
|
|
33
|
+
CLAUDE.md is scaffolded with an `<!-- initialized: false -->` HTML comment at the very top. When the agent reads this flag on session start and finds it false, it automatically runs the `/meta init` flow -- no slash command knowledge required from the user. After initialization completes the agent changes the flag to `<!-- initialized: true -->`, so subsequent sessions proceed normally.
|
|
34
|
+
|
|
35
|
+
## Why It Works This Way
|
|
36
|
+
|
|
37
|
+
The agent needs three things to guide a non-technical developer well:
|
|
38
|
+
|
|
39
|
+
- **Who the user is** -- their TypeScript experience, automation background, and project goals, stored in `.claude/memory/profile/` as markdown files and created during `/meta init`
|
|
40
|
+
- **What has happened in this project** -- deployment state, credentials, errors encountered, and architectural decisions, stored in `.claude/memory/` and loaded on demand
|
|
41
|
+
- **How to behave** -- adaptive guidance rules in `CLAUDE.md` that translate experience levels into concrete behaviors: complete code examples for beginners, concise fixes for advanced users
|
|
42
|
+
|
|
43
|
+
The agent reads `memory/index.md` at session start and drills into `memory/profile/skills.md` for adaptive behavior. It adjusts its tone, explanation depth, and proactivity based on what it finds. This happens silently -- the developer sees a helpful response, not a loading message.
|
|
44
|
+
|
|
45
|
+
## The Framework Components
|
|
46
|
+
|
|
47
|
+
### Agent System
|
|
48
|
+
|
|
49
|
+
The `CLAUDE.md` file drives all agent behavior. It contains the session initialization instructions, adaptive guidance tiers, memory maintenance rules, and slash command definitions. No hooks, no code enforcement -- everything is instruction-driven so non-technical users never need to configure anything.
|
|
50
|
+
|
|
51
|
+
The `/profile` slash command lets developers view and update their profile in `memory/profile/`. The `/meta` command manages the project lifecycle: `/meta init` for guided setup, `/meta update` for SDK upgrades, `/meta fix` for drift repair. Other commands give the agent structured entry points for common tasks: `/meta deploy` for deployments, `/resource` for scaffolding new resources, `/meta health` for debugging executions.
|
|
52
|
+
|
|
53
|
+
See [Agent System](agent.mdx) for CLAUDE.md sections, slash command reference, developer profile, and adaptive guidance tiers.
|
|
54
|
+
|
|
55
|
+
### Memory System
|
|
56
|
+
|
|
57
|
+
The `memory/` directory follows a hierarchical index tree pattern: a root `index.md` maps to topic files and subdirectories, each subdirectory has its own index. The agent reads only the root index at session start and drills into detail files on demand. The `memory/profile/` subdirectory is seeded by `/meta init` during guided setup; other topics are created by the agent as needed.
|
|
58
|
+
|
|
59
|
+
Topics include developer profile (identity, skills, preferences), deployment state, environment credentials, architectural decisions, and error patterns. Error tracking starts as a subdirectory because it naturally spans multiple categories. Other topics start as flat files and split when they outgrow a single document.
|
|
60
|
+
|
|
61
|
+
See [Memory System](memory.mdx) for architecture, error tracking format, scaling rules, and maintenance guidelines.
|
|
62
|
+
|
|
63
|
+
### Project Structure
|
|
64
|
+
|
|
65
|
+
The scaffolded project separates concerns clearly: `src/` for resources, `docs/` for platform documentation, `.claude/` for agent infrastructure, and config files at the root. Understanding which files are gitignored, which are committed, and why matters for collaborating on projects.
|
|
66
|
+
|
|
67
|
+
See [Project Structure](project-structure.mdx) for a file-by-file walkthrough of the scaffolded project.
|
|
68
|
+
|
|
69
|
+
### Documentation
|
|
70
|
+
|
|
71
|
+
Every SDK project ships its own MDX documentation alongside its resources. The `docs/` directory is bundled into each deployment and served from the platform. This is where you document what your resources do, how to use them, and what inputs they expect.
|
|
72
|
+
|
|
73
|
+
See [Documentation](documentation.mdx) for writing MDX docs, file limits, and the deploy pipeline.
|
|
74
|
+
|
|
75
|
+
## Adaptive Guidance
|
|
76
|
+
|
|
77
|
+
The agent adapts its communication based on five independent skill dimensions stored in `memory/profile/skills.md`:
|
|
78
|
+
|
|
79
|
+
- **Programming Fundamentals** -- none / minimal / comfortable / advanced
|
|
80
|
+
- **TypeScript** -- none / exposure / proficient
|
|
81
|
+
- **API & Integration** -- none / basic / proficient
|
|
82
|
+
- **Automation Concepts** -- none / low-code / custom
|
|
83
|
+
- **Data Management** -- none / spreadsheets / databases
|
|
84
|
+
|
|
85
|
+
Each dimension is assessed separately during `/meta init` via 5-6 conditional questions. A user who has deep Zapier experience but no TypeScript knowledge will receive Zod explanations every time while getting automation concepts treated as familiar ground. The questions use conditional skipping to minimize friction: beginners answer 5 questions, developers answer 6.
|
|
86
|
+
|
|
87
|
+
See [Agent System](agent.mdx) for the full assessment question set, dimensional interaction rules, and communication principles.
|
|
88
|
+
|
|
89
|
+
### Skills Auto-Update
|
|
90
|
+
|
|
91
|
+
The Growth Log in `memory/profile/skills.md` keeps approximately 20 recent entries. The agent adds an entry whenever it observes the user performing something they previously needed help with. When a consistent pattern of growth is observed -- typically after several independent successes -- the agent promotes the observation to a level change in the relevant dimension. The `/profile` command lets developers view their current levels and trigger a fresh assessment at any time.
|
|
92
|
+
|
|
93
|
+
---
|
|
94
|
+
|
|
95
|
+
**Last Updated:** 2026-02-25
|