eooo-io/skillr

Write AI instructions once, sync to every tool. One canonical format (.skillr/) compiles to CLAUDE.md, .cursor/rules, Copilot, Windsurf, Cline, and OpenAI configs.

Stars: 2 Language: PHP

Source: https://github.com/eooo-io/skillr

nesjett/agent-config-manager

A CLI tool for transferring AI agent configurations (skills, tools, rules, instructions) between different platforms like GitHub Copilot, Cursor, Claude, and Windsurf.

Stars: 1 Language: TypeScript

Source: https://github.com/nesjett/agent-config-manager

mateusz-pietras/ai-sync

o CLI that keeps a canonical .ai source of rules, skills, agents, prompts, and MCP config, then generates synchronized hard-copy setups for Cursor, GitHub Copilot, and Claude Code (including dynamic instructions/docs and template-driven automation) across repositories.

Stars: 1 Language: Go

Source: https://github.com/mateusz-pietras/ai-sync

JellyRock Developer Guide

JellyRock is a Jellyfin client for Roku devices allowing users to consume media from their personal Jellyfin servers.

Technologies used

• BrighterScript (.bs) - Primary language, compiles to BrightScript (.brs)
• (RSG) Roku Scene Graph (.xml) - Node-based UI framework (NOT HTML!)
• Jellyfin API - Via source/api/sdk.bs, Task Node pattern required

⚠️ Mandatory Agent Rules ⚠️

1. DO NOT make things up or assume
2. Ask clarifying questions when you are not sure about something
3. Focus on best practices, industry standards, and easy long term maintenance
4. ALWAYS look for the best possible solution to a problem then provide the user with their best options
5. Iterate on a plan with the user until they approve it, and only then begin coding
6. When finished coding a user approve plan, provide a list of app behavior for the user to manually test and any expected debug logging output

Development Context

Check relevant docs for specific areas:

• Adding user settings? → docs/dev/adding-user-settings.md
• Writing tests? → docs/dev/unit-tests.md
• Registry migrations? → docs/dev/registry-migrations.md All dev docs: docs/dev/

Architecture Overview

SceneManager System

• Stack navigation: pushScene(), popScene(), clearScenes()
• Lifecycle: OnScreenShown(), OnScreenHidden()
• Component hierarchy: JRScene → JRScreen/JRGroup
• Focus management with lastFocus preservation

Global State Structure

• m.global.app - App state
• m.global.constants - UI constants
• m.global.device - Device state
• m.global.server - The active Jellyfin server state
• m.global.user - Authenticated user state
• m.global.user.settings - User setting configuration. Contains child nodes user and policy, which hold the Jellyfin server authoritative config data. Example: m.global.user.settings.user, m.global.user.settings.policy

Folder Structure & Scoping Rules

Component Folder (components/)

• ONLY place XML files allowed in project
• XML + BS file pairs with same name auto-scope together
• Organized by feature (video/, login/, settings/, etc.)

Source Folder (source/)

• BS files only - no XML allowed
• Files auto-scope together, no imports needed
• BUT: Must import to use in components: import "pkg:/source/..."

Scripts Folder (scripts/)

• JavaScript files for NPM build processes
• Build automation and tooling scripts

Settings (settings/settings.json)

• Single source of truth for all app settings
• Default values and configuration options
• User preferences and app behavior controls

Tests Structure (tests/)

• Unit tests (source/unit/): Isolated function testing, no I/O
• Integration tests (source/integration/): Component interactions, real I/O allowed
• E2E tests (source/e2e/): UI automation (future RTA implementation)

Build (build/)

• Transpiled .brs files from BrighterScript compilation
• These are the actual deployed files shown in runtime logs

Roku-Specific Requirements

Render Thread Protection

• ALL API calls and I/O operations via Task Nodes only (use source/api/sdk.bs for API calls)
• Single field access: direct OK (m.global.device.locale)
• Multiple m.global.child access: cache local reference first (globalUser = m.global.user) to reduce render thread overhead
• Use getFields()/setFields() for bulk operations

Component Patterns

• File pairing: same base name auto-scopes XML+BS together
• Use import statements (not XML script tags)
• isValid() for conditional invalid checks
• onKeyEvent(): return true = handled, false = bubble up

Task Node Field Types

• assocarray: Pass multiple input parameters
• node/nodearray: Handle large data transfers
• string: Simple single parameters

Input Event Handling

• onKeyEvent(key, press) as boolean
• return true = event consumed, no bubble
• return false = event bubbles up to parent

Development Workflow

IDE Integration

• BSConfig validation runs automatically
• Real-time linting (no manual NPM run lint)
• Build errors caught by IDE (no manual build commands)

Agent Restrictions

• Cannot run tests (manual execution required)
• Cannot modify CHANGELOG.md (CI-controlled only)
• Cannot execute build/deploy (IDE handles compilation)

Code Standards

• Use roku-log for component and class logging
• Use print statements sparingly and only when absolutely necessary (roku-log only works in components/classes)
• Fix issues at source, not usage points
• Use comments for JSDoc style function definitions, complex code, any Roku specific oddities, and best practices
• Update/create unit tests for all changes
• 2 spaces indentation, PascalCase class names - camelCase everything else

<!-- BACKLOG.MD GUIDELINES START -->

Instructions for the usage of Backlog.md CLI Tool

1. Source of Truth

• Tasks live under backlog/tasks/ (drafts under backlog/drafts/).
• Every implementation decision starts with reading the corresponding Markdown task file.
• Project documentation is in backlog/docs/.
• Project decisions are in backlog/decisions/.

2. Defining Tasks

Title

Use a clear brief title that summarizes the task.

Description: (The "why")

Provide a concise summary of the task purpose and its goal. Do not add implementation details here. It should explain the purpose and context of the task. Code snippets should be avoided.

Acceptance Criteria: (The "what")

List specific, measurable outcomes that define what means to reach the goal from the description. Use checkboxes (- [ ]) for tracking. When defining ## Acceptance Criteria for a task, focus on outcomes, behaviors, and verifiable requirements rather than step-by-step implementation details. Acceptance Criteria (AC) define what conditions must be met for the task to be considered complete. They should be testable and confirm that the core purpose of the task is achieved. Key Principles for Good ACs:

• Outcome-Oriented: Focus on the result, not the method.
• Testable/Verifiable: Each criterion should be something that can be objectively tested or verified.
• Clear and Concise: Unambiguous language.
• Complete: Collectively, ACs should cover the scope of the task.
• User-Focused (where applicable): Frame ACs from the perspective of the end-user or the system's external behavior.
  • Good Example: "- [ ] User can successfully log in with valid credentials."
  • Good Example: "- [ ] System processes 1000 requests per second without errors."
  • Bad Example (Implementation Step): "- [ ] Add a new function handleLogin() in auth.ts."

Task file

Once a task is created it will be stored in backlog/tasks/ directory as a Markdown file with the format task-<id> - <title>.md (e.g. task-42 - Add GraphQL resolver.md).

Additional task requirements

• Tasks must be atomic and testable. If a task is too large, break it down into smaller subtasks. Each task should represent a single unit of work that can be completed in a single PR.

• Never reference tasks that are to be done in the future or that are not yet created. You can only reference previous tasks (id < current task id).

• When creating multiple tasks, ensure they are independent and they do not depend on future tasks.
  Example of wrong tasks splitting: task 1: "Add API endpoint for user data", task 2: "Define the user model and DB schema".
  Example of correct tasks splitting: task 1: "Add system for handling API requests", task 2: "Add user model and DB schema", task 3: "Add API endpoint for user data".

3. Recommended Task Anatomy

# task‑42 - Add GraphQL resolver

## Description (the why)

Short, imperative explanation of the goal of the task and why it is needed.

## Acceptance Criteria (the what)

- [ ] Resolver returns correct data for happy path
- [ ] Error response matches REST
- [ ] P95 latency ≤ 50 ms under 100 RPS

## Implementation Plan (the how)

1. Research existing GraphQL resolver patterns
2. Implement basic resolver with error handling
3. Add performance monitoring
4. Write unit and integration tests
5. Benchmark performance under load

## Implementation Notes (only added after working on the task)

- Approach taken
- Features implemented or modified
- Technical decisions and trade-offs
- Modified or added files

6. Implementing Tasks

Mandatory sections for every task:

• Implementation Plan: (The "how") Outline the steps to achieve the task. Because the implementation details may change after the task is created, the implementation notes must be added only after putting the task in progress and before starting working on the task.
• Implementation Notes: Document your approach, decisions, challenges, and any deviations from the plan. This section is added after you are done working on the task. It should summarize what you did and why you did it. Keep it concise but informative.

IMPORTANT: Do not implement anything else that deviates from the Acceptance Criteria. If you need to implement something that is not in the AC, update the AC first and then implement it or create a new task for it.

2. Typical Workflow

# 1 Identify work
backlog task list -s "To Do" --plain

# 2 Read details & documentation
backlog task 42 --plain
# Read also all documentation files in `backlog/docs/` directory.
# Read also all decision files in `backlog/decisions/` directory.

# 3 Start work: assign yourself & move column
backlog task edit 42 -a @{yourself} -s "In Progress"

# 4 Add implementation plan before starting
backlog task edit 42 --plan "1. Analyze current implementation\n2. Identify bottlenecks\n3. Refactor in phases"

# 5 Break work down if needed by creating subtasks or additional tasks
backlog task create "Refactor DB layer" -p 42 -a @{yourself} -d "Description" --ac "Tests pass,Performance improved"

# 6 Complete and mark Done
backlog task edit 42 -s Done --notes "Implemented GraphQL resolver with error handling and performance monitoring"

7. Final Steps Before Marking a Task as Done

Always ensure you have:

1. ✅ Marked all acceptance criteria as completed (change - [ ] to - [x])
2. ✅ Added an ## Implementation Notes section documenting your approach
3. ✅ Run all tests and linting checks
4. ✅ Updated relevant documentation

8. Definition of Done (DoD)

A task is Done only when ALL of the following are complete:

1. Acceptance criteria checklist in the task file is fully checked (all - [ ] changed to - [x]).
2. Implementation plan was followed or deviations were documented in Implementation Notes.
3. Automated tests (unit + integration) cover new logic.
4. Static analysis: linter & formatter succeed.
5. Documentation:
   • All relevant docs updated (any relevant README file, backlog/docs, backlog/decisions, etc.).
   • Task file MUST have an ## Implementation Notes section added summarising:
     • Approach taken
     • Features implemented or modified
     • Technical decisions and trade-offs
     • Modified or added files
6. Review: self review code.
7. Task hygiene: status set to Done via CLI (backlog task edit <id> -s Done).
8. No regressions: performance, security and licence checks green.

⚠️ IMPORTANT: Never mark a task as Done without completing ALL items above.

9. Handy CLI Commands

Purpose	Command
Create task	backlog task create "Add OAuth"
Create with desc	backlog task create "Feature" -d "Enables users to use this feature"
Create with AC	backlog task create "Feature" --ac "Must work,Must be tested"
Create with deps	backlog task create "Feature" --dep task-1,task-2
Create sub task	backlog task create -p 14 "Add Google auth"
List tasks	backlog task list --plain
View detail	backlog task 7 --plain
Edit	backlog task edit 7 -a @{yourself} -l auth,backend
Add plan	backlog task edit 7 --plan "Implementation approach"
Add AC	backlog task edit 7 --ac "New criterion,Another one"
Add deps	backlog task edit 7 --dep task-1,task-2
Add notes	backlog task edit 7 --notes "We added this and that feature because"
Mark as done	backlog task edit 7 -s "Done"
Archive	backlog task archive 7
Draft flow	backlog draft create "Spike GraphQL" → backlog draft promote 3.1
Demote to draft	backlog task demote <task-id>

10. Tips for AI Agents

• Always use --plain flag when listing or viewing tasks for AI-friendly text output instead of using Backlog.md interactive UI.
• When users mention to create a task, they mean to create a task using Backlog.md CLI tool.

<!-- BACKLOG.MD GUIDELINES END -->

copilot instructions

linting, formatting, type checking, and building

after completing a task, you may want to run these quality checks. it may be easiest to run them all together from a single command first. to do that, run the deno task allchecks command:

lint, fmt, type check, build

deno task allchecks

here are some individual checks you can also run if needed. generally if allchecks fails, it's most efficient to keep repeatedly calling allchecks until it passes.

linting

deno task lint

formatting

deno fmt --check src

to apply formatting, simply run

deno fmt src

type checking

deno check src

building

deno task build

edge cases

if dependencies are missing, you may need to run deno install. assume that the user has already done this and don't run an install unless you get an error indicating something is missing.