91 lines
3.6 KiB
Markdown
91 lines
3.6 KiB
Markdown
---
|
|
name: "using-superpowers"
|
|
description: "응답 전에 관련 스킬을 먼저 확인하고 호출하는 운영 규칙입니다. 어떤 작업이든 적절한 스킬 적용 여부를 먼저 판단해야 할 때 호출합니다."
|
|
---
|
|
|
|
# 스킬 사용 운영 규칙
|
|
|
|
이 스킬은 대화나 작업을 시작할 때, 어떤 스킬을 먼저 확인하고 어떻게 적용할지에 대한 기본 운영 원칙을 정의합니다.
|
|
|
|
## 최우선 규칙
|
|
|
|
관련 스킬이 조금이라도 적용될 가능성이 있다면, 응답이나 행동 전에 먼저 스킬을 호출합니다.
|
|
|
|
질문에 답하기 전, 코드 읽기 전, 구현 시작 전, 명확화 질문을 하기 전에도 먼저 검토합니다.
|
|
|
|
단 1%의 가능성이라도 있다면 먼저 확인하는 쪽이 기본값입니다.
|
|
|
|
## 우선순위
|
|
|
|
스킬 지시보다 사용자 지시가 항상 우선합니다.
|
|
|
|
1. 사용자 명시 지시
|
|
2. 스킬 지시
|
|
3. 시스템 기본 동작
|
|
|
|
즉, 스킬이 어떤 워크플로를 권장하더라도 사용자가 다른 방식을 명확히 요구하면 사용자 지시를 따릅니다.
|
|
|
|
## 기본 흐름
|
|
|
|
- 사용자 메시지를 받으면 먼저 관련 스킬 가능성을 판단합니다.
|
|
- 관련 가능성이 있으면 즉시 스킬을 호출합니다.
|
|
- 호출된 스킬에 체크리스트가 있으면 작업 목록을 만들고 순서대로 따릅니다.
|
|
- 그 다음에야 응답, 질문, 구현, 조사 같은 행동을 합니다.
|
|
|
|
중요한 점은, "먼저 조금만 확인하고 나서 스킬을 쓰자"가 아니라 "스킬을 먼저 확인하고 나서 어떻게 확인할지 결정한다"는 순서입니다.
|
|
|
|
## 스킬 우선 적용 순서
|
|
|
|
여러 스킬이 동시에 맞을 수 있다면 아래 순서를 기준으로 봅니다.
|
|
|
|
1. **프로세스 스킬** - 작업 방식을 정하는 스킬
|
|
2. **구현 스킬** - 실제 구현이나 산출물을 만드는 스킬
|
|
|
|
예:
|
|
|
|
- "무언가를 만들자" -> brainstorming 먼저, 그다음 구현 스킬
|
|
- "버그를 고치자" -> debugging 먼저, 그다음 도메인 스킬
|
|
|
|
즉, 프로세스를 정하는 스킬이 항상 구현 스킬보다 먼저입니다.
|
|
|
|
## 흔한 자기합리화 경고
|
|
|
|
다음 생각이 들면 흐름을 다시 점검합니다.
|
|
|
|
- 이건 간단하니까 스킬이 필요 없겠다
|
|
- 먼저 코드 좀 보고 나서 생각하자
|
|
- 빠르게 확인만 하고 나중에 스킬을 쓰자
|
|
- 이 정도는 기억으로 처리해도 되겠다
|
|
- 질문이니까 작업이 아니다
|
|
- 스킬이 너무 과한 것 같다
|
|
- 이건 그냥 간단한 확인이다
|
|
- 이전에 본 적 있는 스킬이라 다시 안 읽어도 된다
|
|
|
|
이런 생각은 대부분 스킬 적용을 건너뛰려는 신호입니다.
|
|
|
|
## 적용 절차
|
|
|
|
실제 적용 절차는 아래와 같습니다.
|
|
|
|
1. 사용자 메시지를 받습니다.
|
|
2. 관련 스킬 가능성을 먼저 판단합니다.
|
|
3. 조금이라도 관련 있다면 스킬을 호출합니다.
|
|
4. 스킬의 체크리스트나 절차를 작업 흐름에 반영합니다.
|
|
5. 그 다음 응답, 조사, 구현을 진행합니다.
|
|
|
|
## 원칙
|
|
|
|
- 스킬은 선택이 아니라 작업 방식의 일부로 본다
|
|
- 단순한 작업일수록 오히려 프로세스를 지켜 과잉 추정을 줄인다
|
|
- 기억에 의존하지 말고 현재 스킬 내용을 기준으로 판단한다
|
|
- 관련성이 아주 낮아 보여도, 가능성이 있으면 먼저 확인한다
|
|
|
|
## 기대 결과
|
|
|
|
이 스킬의 목적은 다음 상태를 만드는 것입니다.
|
|
|
|
- 관련 스킬이 빠지지 않는다
|
|
- 작업 접근 순서가 일관된다
|
|
- 응답 전에 방법론이 먼저 고정된다
|
|
- 임의 판단과 과잉 추정이 줄어든다
|