mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-06-22 16:51:13 +00:00
Oleksandr Bezdieniezhnykh
1f634c2604
ci/woodpecker/push/02-build-push Pipeline failed
- Modified the autodev state to reflect the current testing phase and details of the new `jetson-e2e` tests. - Enhanced the "How to Test" documentation to provide clearer instructions on the demo replay validation process, including video and tlog alignment steps. - Updated architectural documentation to include the new demo replay operator flow and its dependencies. - Documented the removal of deprecated auto-sync features and clarified the operator-facing UI for replay validation. - Added new entries in the dependencies table for upcoming tasks related to the demo replay flow. These changes improve clarity and usability for operators and developers working with the demo replay system.
39 lines
2.2 KiB
Plaintext
39 lines
2.2 KiB
Plaintext
---
|
|
description: "Standards for creating and maintaining Cursor skills"
|
|
globs: [".cursor/skills/**"]
|
|
---
|
|
|
|
# Skill Building
|
|
|
|
## When To Create A Skill
|
|
- Create a skill for repeatable, bounded workflows that benefit from a reusable process.
|
|
- Do not create a skill for a one-off task, vague goal, or workflow that still needs product decisions.
|
|
- Start small; evolve the skill when repeated use reveals clearer steps, constraints, or checks.
|
|
|
|
## Skill Contract
|
|
- `SKILL.md` must define a clear `name` and a proactive `description` that explains when the skill should be used.
|
|
- State expected inputs, constraints, workflow steps, and final output shape.
|
|
- Make trigger conditions explicit enough that the agent can recognize intent without an exact command.
|
|
- Base instructions on observable project evidence; do not invite fabrication or unsupported assumptions.
|
|
|
|
## Keep The Core Lean
|
|
- Keep `SKILL.md` concise and under the repo's `.cursor/` size guidance.
|
|
- Move detailed standards, examples, and background knowledge into `references/`.
|
|
- Put reusable output shapes in `templates/` or other skill-local assets instead of embedding them in the main instructions.
|
|
- Keep one primary responsibility per skill; use an orchestrator skill only when multiple existing skills must run in a defined order.
|
|
|
|
## Deterministic Work
|
|
- Use scripts for mechanical steps that are repeatable, parameterized, and safer outside the model's reasoning.
|
|
- Scripts must expose explicit inputs, avoid hidden side effects, and fail loudly on errors.
|
|
- Do not use scripts to bypass review, hide destructive behavior, or hardcode secrets.
|
|
|
|
## Quality Proof
|
|
- Include realistic examples, checklists, or eval-style scenarios that define what good output looks like.
|
|
- Cover common failure cases such as missing sections, leftover placeholders, hallucinated facts, unsafe actions, or malformed output.
|
|
- Review skill changes against those checks before treating the skill as ready.
|
|
|
|
## Security Review
|
|
- Treat third-party skills like untrusted code until reviewed.
|
|
- Inspect scripts, dependencies, references, secret handling, network calls, and destructive commands before use.
|
|
- Prefer local, project-scoped assets and dependencies; document any external dependency the skill requires.
|