upload current sources
This commit is contained in:
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: openspec-apply-change
|
||||
description: Implement the tasks from a change. Use when the user wants to start implementing, continue implementation, or work through the tasks of an existing change.
|
||||
license: MIT
|
||||
compatibility: Claude Code — no external CLI required.
|
||||
metadata:
|
||||
author: openspec (adapted for Claude Code)
|
||||
version: "1.0-claude"
|
||||
source: SAP-samples/cap-agentic-engineered
|
||||
---
|
||||
|
||||
Implement the tasks from a change.
|
||||
|
||||
> **Adapted for Claude Code.** No `openspec` CLI. A change is a folder under
|
||||
> `openspec/changes/<name>/`; tasks live in `tasks.md` as a Markdown checklist. Read the
|
||||
> artifacts directly, implement, and flip `- [ ]` → `- [x]` with the Edit tool.
|
||||
|
||||
**Input**: Optionally specify a change name. If omitted, infer from conversation context; if ambiguous, prompt.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **Select the change**
|
||||
|
||||
If a name is provided, use it. Otherwise list active changes:
|
||||
|
||||
```bash
|
||||
ls -1 openspec/changes 2>/dev/null | grep -v '^archive$'
|
||||
```
|
||||
|
||||
- Infer from conversation context if the user mentioned a change
|
||||
- Auto-select if only one active change exists
|
||||
- If ambiguous, use the **AskUserQuestion tool** to let the user choose
|
||||
|
||||
Always announce: "Using change: <name>".
|
||||
|
||||
2. **Read the change artifacts**
|
||||
|
||||
Read every artifact that exists in `openspec/changes/<name>/`:
|
||||
- `proposal.md` (what & why)
|
||||
- `design.md` (how)
|
||||
- `tasks.md` (the checklist you will execute)
|
||||
|
||||
If `tasks.md` is missing, the change is not ready to implement — suggest the
|
||||
`openspec-propose` skill (or creating `tasks.md`) and stop.
|
||||
|
||||
3. **Assess progress**
|
||||
|
||||
Count tasks in `tasks.md`:
|
||||
- Incomplete = lines matching `- [ ]`
|
||||
- Complete = lines matching `- [x]`
|
||||
|
||||
Display: change name, "N/M tasks complete", and a short overview of what remains.
|
||||
If all tasks are already complete, congratulate and suggest archiving
|
||||
(the `openspec-archive-change` skill).
|
||||
|
||||
4. **Implement tasks (loop until done or blocked)**
|
||||
|
||||
Mirror `tasks.md` into your task-tracking tool (`TaskCreate` / `TaskUpdate`) so progress
|
||||
is visible. For each pending task:
|
||||
- Show which task is being worked on
|
||||
- Make the code changes required — keep them minimal and focused on that task
|
||||
- **For SAP code, consult the relevant MCP server first** (`sap-cap`, `sap-fiori`,
|
||||
`sap-ui5` skills) — never guess CDS/Fiori/UI5 behavior
|
||||
- For non-trivial implementation, dispatch to the appropriate specialist sub-agent via
|
||||
the **Agent tool** rather than writing large code blocks inline
|
||||
- Mark the task complete by editing `tasks.md`: `- [ ]` → `- [x]`
|
||||
- Continue to the next task
|
||||
|
||||
**Pause if:**
|
||||
- A task is unclear → ask for clarification
|
||||
- Implementation reveals a design issue → suggest updating `design.md`/`proposal.md`
|
||||
- An error or blocker is encountered → report and wait for guidance
|
||||
- The user interrupts
|
||||
|
||||
5. **On completion or pause, show status**
|
||||
|
||||
- Tasks completed this session
|
||||
- Overall progress: "N/M tasks complete"
|
||||
- If all done: suggest archiving (`openspec-archive-change`)
|
||||
- If paused: explain why and wait
|
||||
|
||||
**Output During Implementation**
|
||||
```
|
||||
## Implementing: <change-name>
|
||||
|
||||
Working on task 3/7: <task description>
|
||||
[...implementation happening...]
|
||||
✓ Task complete
|
||||
```
|
||||
|
||||
**Output On Completion**
|
||||
```
|
||||
## Implementation Complete
|
||||
|
||||
**Change:** <change-name>
|
||||
**Progress:** 7/7 tasks complete ✓
|
||||
|
||||
All tasks complete! Ready to archive this change (openspec-archive-change).
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Keep going through tasks until done or blocked
|
||||
- Always read the artifacts before starting
|
||||
- If a task is ambiguous, pause and ask before implementing
|
||||
- If implementation reveals issues, pause and suggest artifact updates
|
||||
- Keep code changes minimal and scoped to each task
|
||||
- Update the `tasks.md` checkbox immediately after completing each task
|
||||
- Pause on errors, blockers, or unclear requirements — don't guess
|
||||
- Consult MCP/skills for SAP code; orchestrate via sub-agents for substantial work
|
||||
@@ -0,0 +1,82 @@
|
||||
---
|
||||
name: openspec-archive-change
|
||||
description: Archive a completed change after implementation. Use when the user wants to finalize and archive a change once its tasks are done.
|
||||
license: MIT
|
||||
compatibility: Claude Code — no external CLI required.
|
||||
metadata:
|
||||
author: openspec (adapted for Claude Code)
|
||||
version: "1.0-claude"
|
||||
source: SAP-samples/cap-agentic-engineered
|
||||
---
|
||||
|
||||
Archive a completed change.
|
||||
|
||||
> **Adapted for Claude Code.** No `openspec` CLI. Archiving is a plain directory move:
|
||||
> `openspec/changes/<name>/` → `openspec/changes/archive/YYYY-MM-DD-<name>/`.
|
||||
|
||||
**Input**: Optionally specify a change name. If omitted, prompt for selection.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **Select the change**
|
||||
|
||||
List active changes and let the user choose with the **AskUserQuestion tool**:
|
||||
|
||||
```bash
|
||||
ls -1 openspec/changes 2>/dev/null | grep -v '^archive$'
|
||||
```
|
||||
|
||||
**IMPORTANT**: Do NOT guess or auto-select. Always let the user choose (unless they
|
||||
already named the change in their request).
|
||||
|
||||
2. **Check task completion**
|
||||
|
||||
Read `openspec/changes/<name>/tasks.md` and count incomplete tasks (`- [ ]`) vs
|
||||
complete (`- [x]`).
|
||||
|
||||
- **If incomplete tasks exist:** show the count and use the **AskUserQuestion tool** to
|
||||
confirm the user still wants to archive. Proceed only if confirmed.
|
||||
- **If no `tasks.md` exists:** proceed without a task warning.
|
||||
|
||||
3. **Sync any delta specs (optional)**
|
||||
|
||||
If the change captured spec deltas under `openspec/changes/<name>/specs/`, compare each
|
||||
with its main spec at `openspec/specs/<capability>/spec.md` and offer to apply the
|
||||
changes (read both, then Edit the main spec). Options to present:
|
||||
- "Sync now (recommended)" / "Archive without syncing"
|
||||
|
||||
If there are no delta specs, skip this step.
|
||||
|
||||
4. **Perform the archive**
|
||||
|
||||
```bash
|
||||
mkdir -p openspec/changes/archive
|
||||
```
|
||||
|
||||
Determine today's date (`date +%F` → `YYYY-MM-DD`) and build the target name
|
||||
`YYYY-MM-DD-<name>`.
|
||||
|
||||
- **If the target already exists:** stop with an error; suggest a different date suffix
|
||||
or renaming the existing archive.
|
||||
- **Otherwise:** move the change folder:
|
||||
|
||||
```bash
|
||||
mv openspec/changes/<name> openspec/changes/archive/<YYYY-MM-DD>-<name>
|
||||
```
|
||||
|
||||
5. **Display summary**
|
||||
|
||||
```
|
||||
## Archive Complete
|
||||
|
||||
**Change:** <change-name>
|
||||
**Archived to:** openspec/changes/archive/YYYY-MM-DD-<name>/
|
||||
**Specs:** ✓ Synced to main specs (or "No delta specs" / "Sync skipped")
|
||||
```
|
||||
|
||||
**Guardrails**
|
||||
- Always prompt for change selection if not provided
|
||||
- Don't block archive on warnings — inform, confirm, then proceed
|
||||
- Never overwrite an existing archive target
|
||||
- Show a clear summary of what happened
|
||||
- If delta specs exist, run the sync assessment and show the summary before prompting
|
||||
@@ -0,0 +1,174 @@
|
||||
---
|
||||
name: openspec-explore
|
||||
description: Enter explore mode — a thinking partner for exploring ideas, investigating problems, and clarifying requirements before or during a change. Read-only; never implements code. Use when the user wants to think through something before committing to a change.
|
||||
license: MIT
|
||||
compatibility: Claude Code — no external CLI required.
|
||||
metadata:
|
||||
author: openspec (adapted for Claude Code)
|
||||
version: "1.0-claude"
|
||||
source: SAP-samples/cap-agentic-engineered
|
||||
---
|
||||
|
||||
Enter explore mode. Think deeply. Visualize freely. Follow the conversation wherever it goes.
|
||||
|
||||
> **Adapted for Claude Code.** This skill uses a plain `openspec/changes/` directory of
|
||||
> Markdown files instead of the `openspec` CLI. A "change" is just a folder; there is
|
||||
> nothing to install and no CLI to run — read/write the files directly.
|
||||
|
||||
**IMPORTANT: Explore mode is for thinking, not implementing.** You may read files, search code, and investigate the codebase, but you must NEVER write code or implement features. If the user asks you to implement something, remind them to exit explore mode first and create a change proposal (use the `openspec-propose` skill). You MAY create change artifacts (proposal/design/specs) if the user asks — that's capturing thinking, not implementing.
|
||||
|
||||
**This is a stance, not a workflow.** There are no fixed steps, no required sequence, no mandatory outputs. You're a thinking partner helping the user explore.
|
||||
|
||||
---
|
||||
|
||||
## The Stance
|
||||
|
||||
- **Curious, not prescriptive** - Ask questions that emerge naturally, don't follow a script
|
||||
- **Open threads, not interrogations** - Surface multiple interesting directions and let the user follow what resonates. Don't funnel them through a single path of questions.
|
||||
- **Visual** - Use ASCII diagrams liberally when they'd help clarify thinking
|
||||
- **Adaptive** - Follow interesting threads, pivot when new information emerges
|
||||
- **Patient** - Don't rush to conclusions, let the shape of the problem emerge
|
||||
- **Grounded** - Explore the actual codebase when relevant, don't just theorize
|
||||
|
||||
---
|
||||
|
||||
## What You Might Do
|
||||
|
||||
Depending on what the user brings, you might:
|
||||
|
||||
**Explore the problem space**
|
||||
- Ask clarifying questions that emerge from what they said
|
||||
- Challenge assumptions
|
||||
- Reframe the problem
|
||||
- Find analogies
|
||||
|
||||
**Investigate the codebase**
|
||||
- Map existing architecture relevant to the discussion
|
||||
- Find integration points
|
||||
- Identify patterns already in use
|
||||
- Surface hidden complexity
|
||||
|
||||
**Compare options**
|
||||
- Brainstorm multiple approaches
|
||||
- Build comparison tables
|
||||
- Sketch tradeoffs
|
||||
- Recommend a path (if asked)
|
||||
|
||||
**Visualize**
|
||||
```
|
||||
┌─────────────────────────────────────────┐
|
||||
│ Use ASCII diagrams liberally │
|
||||
├─────────────────────────────────────────┤
|
||||
│ ┌────────┐ ┌────────┐ │
|
||||
│ │ State │────────▶│ State │ │
|
||||
│ │ A │ │ B │ │
|
||||
│ └────────┘ └────────┘ │
|
||||
│ System diagrams, state machines, │
|
||||
│ data flows, architecture sketches, │
|
||||
│ dependency graphs, comparison tables │
|
||||
└─────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**Surface risks and unknowns**
|
||||
- Identify what could go wrong
|
||||
- Find gaps in understanding
|
||||
- Suggest spikes or investigations
|
||||
|
||||
---
|
||||
|
||||
## Change Awareness (CLI-free)
|
||||
|
||||
Use the `openspec/changes/` directory naturally, don't force it.
|
||||
|
||||
### Check for context
|
||||
|
||||
At the start, quickly see what already exists by listing the change folders:
|
||||
|
||||
```bash
|
||||
ls -1 openspec/changes 2>/dev/null | grep -v '^archive$'
|
||||
```
|
||||
|
||||
Each subfolder (excluding `archive/`) is an active change. If the directory does not
|
||||
exist, there are no active changes yet — that's fine.
|
||||
|
||||
### When no change exists
|
||||
|
||||
Think freely. When insights crystallize, you might offer:
|
||||
|
||||
- "This feels solid enough to start a change. Want me to create a proposal?" (the `openspec-propose` skill)
|
||||
- Or keep exploring — no pressure to formalize
|
||||
|
||||
### When a change exists
|
||||
|
||||
If the user mentions a change or you detect one is relevant:
|
||||
|
||||
1. **Read existing artifacts for context**
|
||||
- `openspec/changes/<name>/proposal.md`
|
||||
- `openspec/changes/<name>/design.md`
|
||||
- `openspec/changes/<name>/tasks.md`
|
||||
|
||||
2. **Reference them naturally in conversation**
|
||||
- "Your design mentions using HANA, but we just realized SQLite fits better..."
|
||||
- "The proposal scopes this to the RiskAnalyst role, but we're now thinking everyone..."
|
||||
|
||||
3. **Offer to capture when decisions are made**
|
||||
|
||||
| Insight Type | Where to Capture |
|
||||
|----------------------------|----------------------------------------|
|
||||
| New requirement discovered | `openspec/specs/<capability>/spec.md` |
|
||||
| Requirement changed | `openspec/specs/<capability>/spec.md` |
|
||||
| Design decision made | `design.md` |
|
||||
| Scope changed | `proposal.md` |
|
||||
| New work identified | `tasks.md` |
|
||||
| Assumption invalidated | Relevant artifact |
|
||||
|
||||
4. **The user decides** - Offer and move on. Don't pressure. Don't auto-capture.
|
||||
|
||||
---
|
||||
|
||||
## What You Don't Have To Do
|
||||
|
||||
- Follow a script
|
||||
- Ask the same questions every time
|
||||
- Produce a specific artifact
|
||||
- Reach a conclusion
|
||||
- Stay on topic if a tangent is valuable
|
||||
- Be brief (this is thinking time)
|
||||
|
||||
---
|
||||
|
||||
## Ending Discovery
|
||||
|
||||
There's no required ending. Discovery might:
|
||||
|
||||
- **Flow into a proposal**: "Ready to start? I can create a change proposal." (`openspec-propose`)
|
||||
- **Result in artifact updates**: "Updated design.md with these decisions"
|
||||
- **Just provide clarity**: User has what they need, moves on
|
||||
- **Continue later**: "We can pick this up anytime"
|
||||
|
||||
When it feels like things are crystallizing, you might summarize:
|
||||
|
||||
```
|
||||
## What We Figured Out
|
||||
|
||||
**The problem**: [crystallized understanding]
|
||||
**The approach**: [if one emerged]
|
||||
**Open questions**: [if any remain]
|
||||
**Next steps** (if ready): create a change proposal, or keep exploring
|
||||
```
|
||||
|
||||
But this summary is optional. Sometimes the thinking IS the value.
|
||||
|
||||
---
|
||||
|
||||
## Guardrails
|
||||
|
||||
- **Don't implement** - Never write code or implement features. Creating change artifacts is fine, writing application code is not.
|
||||
- **Don't fake understanding** - If something is unclear, dig deeper
|
||||
- **Don't rush** - Discovery is thinking time, not task time
|
||||
- **Don't force structure** - Let patterns emerge naturally
|
||||
- **Don't auto-capture** - Offer to save insights, don't just do it
|
||||
- **Do visualize** - A good diagram is worth many paragraphs
|
||||
- **Do explore the codebase** - Ground discussions in reality
|
||||
- **Do question assumptions** - Including the user's and your own
|
||||
- **For SAP work** - When exploring CDS, Fiori, or UI5, still consult the relevant MCP server (`sap-cap`, `sap-fiori`, `sap-ui5` skills) rather than relying on training knowledge.
|
||||
@@ -0,0 +1,132 @@
|
||||
---
|
||||
name: openspec-propose
|
||||
description: Propose a new change and generate all artifacts (proposal, design, tasks) in one step, ready for implementation. Use when the user wants to describe what they want to build and get a complete change proposal.
|
||||
license: MIT
|
||||
compatibility: Claude Code — no external CLI required.
|
||||
metadata:
|
||||
author: openspec (adapted for Claude Code)
|
||||
version: "1.0-claude"
|
||||
source: SAP-samples/cap-agentic-engineered
|
||||
---
|
||||
|
||||
Propose a new change — create the change folder and generate all artifacts in one step.
|
||||
|
||||
> **Adapted for Claude Code.** No `openspec` CLI. A change is a folder under
|
||||
> `openspec/changes/<name>/` containing three Markdown files you create directly with
|
||||
> the Write tool. Templates are embedded below.
|
||||
|
||||
I'll create a change with artifacts:
|
||||
- `proposal.md` (what & why)
|
||||
- `design.md` (how)
|
||||
- `tasks.md` (implementation steps)
|
||||
|
||||
When ready to implement, use the `openspec-apply-change` skill.
|
||||
|
||||
---
|
||||
|
||||
**Input**: The user's request should include a change name (kebab-case) OR a description of what they want to build.
|
||||
|
||||
**Steps**
|
||||
|
||||
1. **If no clear input provided, ask what they want to build**
|
||||
|
||||
Use the **AskUserQuestion tool** (open-ended) to ask:
|
||||
> "What change do you want to work on? Describe what you want to build or fix."
|
||||
|
||||
From their description, derive a kebab-case name (e.g., "add user authentication" → `add-user-auth`).
|
||||
|
||||
**IMPORTANT**: Do NOT proceed without understanding what the user wants to build.
|
||||
|
||||
2. **Create the change directory**
|
||||
|
||||
```bash
|
||||
mkdir -p openspec/changes/<name>
|
||||
```
|
||||
|
||||
If a folder with that name already exists, ask whether to continue the existing change
|
||||
(use `openspec-apply-change`) or pick a new name.
|
||||
|
||||
3. **Track progress**
|
||||
|
||||
Use your task-tracking tool (`TaskCreate` / `TaskUpdate`) to track the three artifacts.
|
||||
|
||||
4. **Create the artifacts in order: proposal → design → tasks**
|
||||
|
||||
For each artifact, read the previously created artifact(s) for context, then Write the
|
||||
file using the templates below. Apply project context and conventions as constraints —
|
||||
do NOT paste meta-instructions into the files.
|
||||
|
||||
For SAP artifacts, **consult the relevant MCP server before writing design or tasks**
|
||||
that touch CDS, Fiori, or UI5 (see the `sap-cap`, `sap-fiori`, `sap-ui5` skills). Don't
|
||||
guess SAP behavior into a design.
|
||||
|
||||
**`proposal.md` template**
|
||||
```markdown
|
||||
# <Change Title>
|
||||
|
||||
## Why
|
||||
<the problem or motivation — what's broken or missing, and why now>
|
||||
|
||||
## What Changes
|
||||
<high-level summary of the change in 2–5 bullets>
|
||||
|
||||
## Scope
|
||||
- In scope: <...>
|
||||
- Out of scope: <...>
|
||||
|
||||
## Impact
|
||||
<affected capabilities, entities, services, UIs, integrations>
|
||||
```
|
||||
|
||||
**`design.md` template**
|
||||
```markdown
|
||||
# Design: <Change Title>
|
||||
|
||||
## Approach
|
||||
<how it will be built>
|
||||
|
||||
## Architecture / Data Flow
|
||||
<entities, service handlers, annotations, UI; ASCII diagram if helpful>
|
||||
|
||||
## Decisions
|
||||
- <decision> — <rationale>
|
||||
|
||||
## Alternatives Considered
|
||||
- <alternative> — <why not>
|
||||
|
||||
## Risks & Open Questions
|
||||
- <...>
|
||||
```
|
||||
|
||||
**`tasks.md` template**
|
||||
```markdown
|
||||
# Tasks: <Change Title>
|
||||
|
||||
- [ ] 1. <task>
|
||||
- [ ] 2. <task>
|
||||
- [ ] 3. <task>
|
||||
```
|
||||
|
||||
5. **Verify and show final status**
|
||||
|
||||
Confirm all three files exist, then list them.
|
||||
|
||||
```bash
|
||||
ls -1 openspec/changes/<name>
|
||||
```
|
||||
|
||||
**Output**
|
||||
|
||||
After completing all artifacts, summarize:
|
||||
- Change name and location (`openspec/changes/<name>/`)
|
||||
- The artifacts created with brief descriptions
|
||||
- "All artifacts created! Ready for implementation."
|
||||
- "Use the `openspec-apply-change` skill (or ask me to implement) to start working on the tasks."
|
||||
|
||||
**Guardrails**
|
||||
- Create ALL three artifacts (proposal, design, tasks) before declaring the change apply-ready
|
||||
- Always read dependency artifacts before creating the next one
|
||||
- If context is critically unclear, ask the user — but prefer reasonable decisions to keep momentum
|
||||
- If a change with that name already exists, ask whether to continue it or create a new one
|
||||
- Verify each file exists after writing before proceeding to the next
|
||||
- `context`/`rules` are constraints for YOU — never copy them into the artifact files
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
name: sap-cap
|
||||
description: >
|
||||
Query the CAP MCP server before writing CDS entities, types, aspects, services,
|
||||
or CAP service handlers. Triggers on schema and service files in db/ and srv/.
|
||||
paths:
|
||||
- "**/db/**/*.cds"
|
||||
- "**/srv/**/*.cds"
|
||||
- "**/srv/**/*.js"
|
||||
metadata:
|
||||
source: SAP-samples/cap-agentic-engineered
|
||||
adapted: MCP tool names mapped to this environment (mcp__cap-mcp-server__*)
|
||||
---
|
||||
|
||||
# CAP MCP-First Development
|
||||
|
||||
Before writing, modifying, debugging, or fixing CDS entities, service definitions,
|
||||
or CAP service handlers, you MUST query the CAP MCP server and apply its guidance.
|
||||
|
||||
## Tools
|
||||
|
||||
Use `mcp__cap-mcp-server__*` tools — primarily `mcp__cap-mcp-server__search_docs` and `mcp__cap-mcp-server__search_model`.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Query before coding** — call `mcp__cap-mcp-server__search_docs` for syntax, patterns, or conventions
|
||||
2. **Trust MCP over training knowledge** — if guidance conflicts with what you know, follow MCP
|
||||
3. **Prefer the simplest pattern** when MCP returns multiple valid approaches
|
||||
|
||||
## Scope
|
||||
|
||||
This skill covers:
|
||||
- CDS entity definitions, types, aspects (`db/schema.cds`)
|
||||
- Service definitions and projections (`srv/*.cds`)
|
||||
- Service handlers, actions, functions, events (`srv/*.js`)
|
||||
- CDS built-in types, key patterns, virtual fields
|
||||
|
||||
This skill does **not** cover CDS annotations (`@UI`, `@Common`, `@Capabilities`) or
|
||||
Fiori Elements configuration — those belong to the `sap-fiori` skill.
|
||||
@@ -0,0 +1,51 @@
|
||||
---
|
||||
name: sap-fiori
|
||||
description: >
|
||||
Query the Fiori MCP server before writing CDS annotations, Fiori Elements
|
||||
config, or manifest.json. Triggers on annotation files in app/ and manifests.
|
||||
paths:
|
||||
- "**/app/**/*.cds"
|
||||
- "**/app/**/manifest.json"
|
||||
metadata:
|
||||
source: SAP-samples/cap-agentic-engineered
|
||||
adapted: MCP tool names mapped to this environment (mcp__fiori-mcp-server__*)
|
||||
---
|
||||
|
||||
# Fiori MCP-First Development
|
||||
|
||||
Before writing, modifying, debugging, or fixing CDS annotations, Fiori Elements
|
||||
page configuration, or manifest.json, you MUST query the Fiori MCP server and apply its guidance.
|
||||
|
||||
## Tools
|
||||
|
||||
Use `mcp__fiori-mcp-server__*` tools — primarily `mcp__fiori-mcp-server__search_docs`,
|
||||
`mcp__fiori-mcp-server__list_functionality`, `mcp__fiori-mcp-server__get_functionality_details`,
|
||||
and `mcp__fiori-mcp-server__execute_functionality`.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Query before coding** — call `mcp__fiori-mcp-server__search_docs` for annotation patterns, floorplan config, or manifest structure
|
||||
2. **Trust MCP over training knowledge** — if guidance conflicts with what you know, follow MCP
|
||||
3. **Use Fiori MCP tooling for modifications** — before manually editing manifest.json or annotations, check if `mcp__fiori-mcp-server__list_functionality` provides an automated function
|
||||
4. **Prefer the simplest pattern** when MCP returns multiple valid approaches
|
||||
|
||||
## Scope
|
||||
|
||||
This skill covers:
|
||||
- CDS annotations: `@UI`, `@Common`, `@Capabilities`, `@Communication`
|
||||
- Fiori Elements floorplans: List Report, Object Page, Analytical List Page
|
||||
- `manifest.json` configuration: routing, data sources, control configuration
|
||||
- Custom actions in manifest (`controlConfiguration.actions`)
|
||||
|
||||
## Fiori Elements App Rules
|
||||
|
||||
When creating or modifying SAP Fiori Elements applications:
|
||||
|
||||
- The application typically starts with a **List Report** page showing the base entity in a table. Row details are shown in an **ObjectPage** based on the same entity.
|
||||
- An ObjectPage can contain table sections based on to-many associations. Row details in a table section can open another ObjectPage based on the association's target entity.
|
||||
- The data model must have one main entity with navigation properties to related entities.
|
||||
- Each property must have a proper datatype.
|
||||
- For all entities, provide primary keys of type **UUID**.
|
||||
- When creating sample data in CSV files, all primary keys and foreign keys **MUST** be in UUID format (e.g., `550e8400-e29b-41d4-a716-446655440001`).
|
||||
- When modifying the application (e.g., adding columns), do **not** use screen personalization — modify the project code. Always check whether `mcp__fiori-mcp-server__list_functionality` provides a suitable function first.
|
||||
- When previewing, use the most specific `npm run watch-*` script for the app in `package.json`.
|
||||
@@ -0,0 +1,53 @@
|
||||
---
|
||||
name: sap-ui5
|
||||
description: >
|
||||
Query the UI5 MCP server before writing SAPUI5 controllers, XML views, control
|
||||
APIs, or model bindings. Triggers on views and controller extensions in app/.
|
||||
paths:
|
||||
- "**/app/**/*.xml"
|
||||
- "**/app/**/ext/**/*.js"
|
||||
- "**/app/**/ext/**/*.ts"
|
||||
- "**/webapp/**/*.xml"
|
||||
- "**/webapp/**/controller/**/*.js"
|
||||
metadata:
|
||||
source: SAP-samples/cap-agentic-engineered
|
||||
adapted: MCP tool names mapped to this environment (mcp__ui5-mcp-server__*)
|
||||
---
|
||||
|
||||
# UI5 MCP-First Development
|
||||
|
||||
Before writing, modifying, debugging, or fixing SAPUI5 controllers, XML views,
|
||||
or control bindings, you MUST query the UI5 MCP server and apply its guidance.
|
||||
|
||||
## Tools
|
||||
|
||||
Use `mcp__ui5-mcp-server__*` tools — primarily `mcp__ui5-mcp-server__get_api_reference`,
|
||||
`mcp__ui5-mcp-server__get_guidelines`, `mcp__ui5-mcp-server__run_ui5_linter`, and
|
||||
`mcp__ui5-mcp-server__get_project_info`.
|
||||
|
||||
> Note: in this environment the same UI5 tooling is also exposed under the
|
||||
> `mcp__plugin_sapui5_ui5-tooling__*` namespace — either prefix works.
|
||||
|
||||
## Workflow
|
||||
|
||||
1. **Query before coding** — call `mcp__ui5-mcp-server__get_api_reference` for control APIs, or `mcp__ui5-mcp-server__get_guidelines` for project-level patterns
|
||||
2. **Trust MCP over training knowledge** — if guidance conflicts with what you know, follow MCP
|
||||
3. **Run the linter after changes** — call `mcp__ui5-mcp-server__run_ui5_linter` to catch deprecated APIs
|
||||
4. **Prefer the simplest pattern** when MCP returns multiple valid approaches
|
||||
|
||||
## Scope
|
||||
|
||||
This skill covers:
|
||||
- XML views with `sap.m`, `sap.f`, `sap.uxap` namespaces
|
||||
- Controller extensions (`app/**/ext/controller/*.js`) and freestyle controllers (`webapp/**/controller/*.js`)
|
||||
- Model bindings, formatters, event handlers
|
||||
- Control APIs and property configuration
|
||||
|
||||
## UI5 Code Standards
|
||||
|
||||
- XML views only — no JavaScript views
|
||||
- `sap.ui.define` for all modules — no globals
|
||||
- Async loading: `data-sap-ui-async="true"`
|
||||
- i18n for all user-facing text
|
||||
- No deprecated APIs (`jQuery.sap.*`, sync loading, `sap.ui.getCore()`)
|
||||
- Fiori Elements controller extensions must be plain objects (not ES6 classes) — `this` refers to the `ExtensionAPI` instance
|
||||
Reference in New Issue
Block a user