Skills-System

Instruction file imported from trentnixon/fixtura-remotion-version2 (.cursor/rules/Skills-System.mdc). Copyright stays with the author.

Skills System (Repo Root)

Trigger

• If the user message starts with SKILL: then you MUST follow the workflow below.
• If the user message does NOT start with SKILL:, do not create or modify /.skills/* unless the user explicitly asks.

Core Philosophy

Skills are the repository’s internal “how-to” system.

A skill:

• Defines how to implement a feature or system pattern in THIS repo.
• Documents structure, constraints, and execution flow.
• Links to related skills when dependencies exist.
• Routes clearly to the relevant feature or system area.

Skills are not brainstorming documents. Skills are not memory logs. Skills are deterministic implementation guides.

Authority (User-Defined Only)

• Skills are defined by the user.

• You may propose a draft skill file.

• You MUST NOT save it to /.skills/* unless the user explicitly says:

  • “create that skill”
  • “save it”
  • “write it to /.skills”
  • “commit it”

No autonomous skill creation.

Skill Discovery Inputs

When drafting a skill, you MUST use these repo files as primary context:

• README.md
• Roadmap.md (or ROADMAP.md / DevelopmentRoadMap.md if present)
• Any feature-level README or roadmap files inside relevant feature directories

You must extract:

• Existing terminology
• Structural conventions
• Naming patterns
• Architectural boundaries
• Declared constraints or non-goals

If these files are missing:

• Proceed with a generic draft
• Clearly list assumptions

Do not invent repo conventions.

Skill Workflow (when triggered)

1. Identify the feature or system pattern from the SKILL: message.

2. Determine if this is:

   • A feature implementation guide
   • A reusable pattern
   • A structural architecture rule

3. Read relevant README and roadmap files.

4. Identify related existing skills (if any).

5. Draft ONE skill file.

6. Return:

   • Proposed file path under /.skills/
   • Full .md contents
   • Related skills (if applicable)
   • Assumptions (if any)

Do not write the file unless explicitly instructed.

Skill Structure (Required Format)

Every skill MUST follow this structure:

Skill:

Purpose

Clear description of what this feature or pattern accomplishes.

Scope

• Which feature/module/system this applies to
• What it does NOT apply to (if relevant)

Entry Points

• File paths or directories where this pattern begins
• Feature routes or core modules affected

Dependencies

• Related skills (use relative path links)
• Required systems or layers (API, UI, DB, etc.)

Process

Step-by-step implementation guide specific to this repo.

Output

What must exist after implementation:

• Files
• Structural changes
• Config updates
• Tests
• Memory updates (if required)

Rules

Hard constraints:

• Naming rules
• Folder structure rules
• Data layer rules
• Architectural guardrails

References

• README:

• Roadmap:

• Related Skills:

  • /.skills/...

Naming & Placement

• Use kebab-case filenames: /.skills/<category>/<skill-name>.md

Categories:

• architecture → system-wide structural rules
• patterns → reusable implementation patterns
• workflows → step-by-step feature execution guides

Skill Linking Rule

• Skills MUST link to related skills if dependencies exist.

• Do not duplicate logic across skills.

• If overlap is detected:

  • Reference the existing skill instead of redefining it.

Skills form a directed knowledge graph, not isolated documents.

Safety

• Never include secrets.
• Never invent repo-specific conventions.
• Never contradict README or roadmap constraints.
• Never modify existing skills without explicit instruction.