rundesk-ai/rundesk-cli

스킬 작성하기

기존 소유자 재사용하기

패키지를 만들기 전에 기존 스킬 카탈로그를 검토하세요. 저장소 작업의 경우, 대상 카탈로그와 인가된 작업 공간 내 모든 관련 소스 카탈로그를 검색하세요. 인가된 라이브-라이브러리 작업의 경우, Rundesk의 카탈로그와 스킬 목록을 사용하고, 작업의 접근 경계를 우회하기 위해 라이브 라이브러리를 열지 마세요. 유사한 설명을 읽은 후, 본문과 관련 참조를 확인한 후 결정하세요.

요청된 기능이 사용자 의도, 워크플로우, 권한을 공유하는 경우 기존 소유자를 확장하세요. 두 번째 라우팅 표면을 만들지 말고, 대신 지원 스크립트, 참조, 또는 테스트를 추가하세요. 기능이 별도의 라우팅, 판단, 권한, 또는 증명을 필요로 할 때만 새 스킬을 만드세요. 그 차이를 기록하여 유사한 이름이 그 자체로 정당화되지 않도록 하세요.

아티팩트 선택하기

• 스킬은 명령 경계입니다: 언제 행동할지, 어떤 판단을 적용할지, 어떤 절차를 따를지, 그리고 결과를 어떻게 증명할지.
• 워크플로우 스크립트는 반복적인 로컬 변환, 검증, 또는 오케스트레이션을 위한 결정론적 메커니즘입니다.
• 통합은 외부 서비스 경계를 추가합니다: 자격 증명, 계정, 네트워크 실패, 권한, 또는 원격 효과.

일회성 자동화는 해당 프로젝트에 두고, 한 에이전트의 개인 반복 명령은 해당 에이전트의 스크립트 영역에 두세요. 미래 턴에서 라우팅이나 판단이 필요할 때만 스크립트를 스킬에 패키징하세요. 에이전트가 다시 해석해야 하는 산문으로 결정론적 코드를 대체하지 마세요.

재사용 가능한 스크립트를 배포하기 전에 재사용 가능한 워크플로우 스크립트를 읽으세요. 자격 증명, 프로필, OAuth, 네트워크, 또는 원격 효과를 사용하는 경우 외부 서비스 통합도 읽으세요.

안전하게 배치하기

라이브 생성이나 설치가 인가된 경우에만 local에 비공개 스킬을 만드세요. 초안, 검토, 저장소 변경, 또는 격리된 테스트의 경우, 명명된 작업 공간이나 임시 디렉터리를 사용하고, 결과가 나중에 어디로 갈지 알아내기 위해 라이브 라이브러리를 검사하거나 변경하지 마세요.

인가된 비공개 스킬의 경우, Rundesk에서 라이브러리를 요청하세요. RUNDESK_HOME에서 유추하거나 절대 경로를 포함하지 마세요. 다음 예시 이름을 바꾸세요:

skill_name=release-notes
skill_library=$("$RUNDESK_COMMAND" skills | sed -n '1s/^skills in //p')
test -n "$skill_library" || exit 1
mkdir -p "$skill_library/local/$skill_name"

<라이브러리>/local/<이름>/SKILL.md를 작성한 후, 명명된 에이전트에 권한을 부여하세요:

"$RUNDESK_COMMAND" skills grant "$RUNDESK_AGENT" local/release-notes

권한 부여는 현재 턴이 아닌 에이전트의 다음 턴에 검색 가능해집니다. 다른 설치를 위한 스킬을 만들기 전에 스킬 카탈로그 게시를 읽으세요. 게시된 스킬은 local이 아닌 카탈로그 저장소에 속합니다.

필요한 구조만 사용하기

<이름>/
├── SKILL.md          필수: 라우팅 및 핵심 절차
├── rundesk.json      선택 사항: 필수 환경 값
├── scripts/          선택 사항: 재사용 가능한 명령어
├── tests/            선택 사항: 카탈로그 테스트 영역이 소유하지 않은 스크립트 계약
├── references/       선택 사항: 조건부로 로드되는 세부 사항
└── assets/           선택 사항: 복사 또는 출력 자료

내용이 있는 경우에만 선택적 경로를 만드세요. README, 변경 로그, 설치 가이드, 생성 기록은 생략하세요.

라우팅을 먼저 작성하기

Frontmatter에는 name과 description만 있습니다.

• name을 디렉터리 이름과 일치시키세요. 최대 64자의 소문자, 숫자, 단일 하이픈을 사용하세요.
• 사용자 의도에 따라 라우팅하세요. 스킬 이름을 직접 언급하지 않는 간접 요청도 포함됩니다. Use when, Apply when 또는 이에 상응하는 적용 가능성 언어로 시작하세요. 프롬프트 구문은 트리거가 아닙니다.
• 두 개의 짧은 문장을 목표로 하세요: 적용 가능성, 그 다음 제공되는 특화된 워크플로우 또는 지식. Do not use는 가능성이 높은 근접 오류에 대해서만 추가하세요. 본문이 로드되기 전에 라우팅에 필요한 개념만 포함하세요. 단계, 테스트, 이점 주장, 구현 세부 사항은 생략하세요. 파일 유형, 도구, 또는 형식은 스킬이 트리거되어야 하는지 결정할 때만 언급하세요.
• 여전히 올바르게 라우팅되는 가장 짧은 설명을 사용하세요. 1,024자는 목표가 아니라 상한선입니다. 모든 트리거를 설명에 넣으세요. 각 소유자가 매 턴마다 비용을 지불하고 본문은 라우팅이 성공할 때까지 사용할 수 없기 때문입니다.

# 나쁨: 라우팅에 도움이 되지 않는 구현 및 검증을 포함함.
description: 릴리스 노트를 만들 때 사용합니다. Git 기록을 읽고, 마크다운을 작성하고, 커밋을 그룹화하고, 링크를 확인하고, 검증을 실행하고, 정확한 형식의 간결한 내부 및 공개 버전을 생성합니다.

# 좋음: 의도, 제공되는 판단, 가장 가까운 경계만 명시함.
description: 출시된 저장소 변경 사항에서 릴리스 노트를 준비할 때 사용합니다. 검증된 기록에 기반한 대상별 워크플로우를 제공합니다. 출시되지 않은 계획에는 사용하지 마세요.

행동 지침만 유지하기

실행 순서에 따라 명령형 단계를 사용하세요. 독자가 추론하고, 편집하고, 일반 도구를 사용할 수 있다고 가정하세요. 문장이 실행을 변경하거나, 발생 가능한 실패를 방지하거나, 필요한 세부 사항을 라우팅할 때만 유지하세요.

• 핵심 절차, 하나의 강력한 기본값, 그리고 명백하지 않은 문제점을 SKILL.md에 유지하세요.
• 취약한 작업에는 정확한 명령어를 사용하세요. 여러 접근 방식이 작동하는 경우 간결한 판단을 사용하세요.
• 설명되지 않은 강조 대신 제약 조건이 방지하는 실패를 설명하세요.
• 각 참조를 언제 읽어야 하는지 소개하세요. 하나의 진실 공급원을 유지하세요. 다시 설명하는 대신 링크를 걸어주세요.
• 배경, 프로세스 역사, 날짜가 있는 주장, 이미 다른 곳에 로드된 규칙은 제거하세요.
• 관찰된 계약과 권장 기본값을 구분하세요. 기술적 제약 조건을 출처로 삼고, 실제 함정을 증상, 원인, 대체, 관찰 가능한 증명으로 가르치세요.

SKILL.md를 500줄 미만으로 유지하세요. 조건부 세부 사항은 연결된 참조로 한 단계 이동시키세요.

컨텍스트 예산 관리하기

부분	토큰 비용	유지 위치
description	매 턴마다	가장 짧은 완전한 트리거
SKILL.md	라우팅 후	핵심 절차, 기본값, 문제점
references/	읽을 때	조건부 세부 사항 및 더 큰 예제
scripts/	출력이 컨텍스트에 들어감	출력이 제한된 결정론적 작업
tests/	검증 전용	실행 가능한 계약 및 경계 사례
assets/	사용될 때	템플릿 및 출력 자료

짧은 예제를 선호하세요. 스크립트 출력을 다음 결정에 필요한 만큼만 제한하세요.

전체 스킬 증명하기

1. 디렉터리 이름, frontmatter 이름, 설명 구문, 제한 사항을 검증하세요.

2. 권한 부여가 필요할 때 적용하고, 다음 턴을 확인하세요:

   "$RUNDESK_COMMAND" skills list "$RUNDESK_AGENT"
   "$RUNDESK_COMMAND" skills doctor "$RUNDESK_AGENT"
   

3. 각 스크립트의 참조 소유 경계 매트릭스와 직접 실행 가능 진입점을 실행하세요.

4. 서로 다른 새로운 턴에서 직접 요청, 간접 요청, 그리고 근접 오류를 시도해보세요. 작업 전에 본문과 필요한 참조가 로드되는지 확인하세요. 복사된 프롬프트 구문이 아닌 카테고리별로 라우팅을 수정하세요.

5. 중요한 스킬의 경우, 스킬 없이 기본 기준선과 동일한 작업을 비교하세요. 그런 다음 별도의 테스트 에이전트가 예상 구현 없이 사용하도록 하세요. 아티팩트와 명령어를 직접 검토하세요. 에이전트의 요약은 증명이 아닙니다. 실질적인 개선을 얻지 못하는 지침은 제거하세요.

6. 생성된 글을 실행 가능한 정확성과 별도로 검토하세요: 라우팅 정밀도, 실행 순서, 유용한 판단, 간결성, 중복, 참조 규율. 녹색 스크립트 테스트는 글의 품질을 증명하지 않습니다. 사실적인 약속을 출처로 삼거나 관찰하세요. 실행 가능한 주장을 테스트하고 부분적 진실을 좁히세요. 의미적 주장에 대해 편리한 집계를 유지하면서 실제 관계나 결과를 변경하는 적대적 반례를 제시하세요. 돌연변이 검사는 잘못된 테스트 오라클을 수리할 수 없습니다. 빈 성공, 중복 증거, 모든 데이터 종속 출력 섹션을 포함한 전체 인터페이스를 검토하세요.