품질 전략 스킬 (Quality Strategy Skills)
Claude Code 스킬로, 인터뷰를 통해 소프트웨어 품질 전략을 수립합니다. — 프로젝트에 중요한 사람이 누구인지, 그들이 무엇을 가치 있게 여기는지, 어디에 취약한지, 그리고 이에 대해 무엇을 해야 하는지 — 그리고 이를 실행으로 전환하는 테스트 전략과 도구 전략을 포함합니다. 프로젝트의 품질이 무엇을 의미하는지 모르는 에이전트가 대부분의 코드를 작성할 때, 명시적인 전략은 에이전트가 잘못된 방향으로 자신감 있게 코드를 배포하는 것을 막아줍니다.
Edmund Pringle의 품질 프레임워크에 기반합니다. 품질은 중요한 누군가에게 가치를 제공하는 것입니다. 테스팅은 실제로 무엇이 사실인지 알아내기 위한 조사입니다. 위험은 품질에 대한 위협입니다. 개인 개발자, 소규모 팀, 엔지니어링 리더 — 그리고 에이전트가 작업하는 모든 코드베이스에 적합합니다. 저장소가 필요하지 않습니다. 아이디어 단계에서 실행하는 것도 최우선 사용 사례입니다.
상태: 알파 (alpha). 첫 번째 테스터 그룹과 공유되었습니다. 스킬은 작동하며 가상 사용자에 대해 엄격하게 테스트되었지만, 실제 환경에서의 사용 경험은 제한적입니다. 거친 부분이 있을 수 있으며, 문제가 발생하면 알려주세요(피드백). 그리고 알려진 제한 사항을 먼저 읽어주세요 — 우리는 문제점을 숨기지 않습니다.
설치
이것은 Claude Code 플러그인입니다:
/plugin marketplace add tollens-ai/quality-strategy-skills
/plugin install quality-strategy@tollens
그런 다음, 모든 프로젝트에서 /quality-strategy로 시작하세요. 출력은 프로젝트 루트의 quality/strategy.md에 저장됩니다. (이름이 다른 플러그인과 충돌하는 경우, 스킬은 네임스페이스로도 사용 가능합니다. 예: /quality-strategy:test-strategy)
새 버전이 정기적으로 출시됩니다 — 업데이트를 받으려면 claude plugin update quality-strategy를 실행하세요; CHANGELOG.md에 변경 사항이 명시되어 있습니다.
일반적인 흐름
/quality-strategy— 주요 기능입니다. 구조화된 인터뷰를 통해quality/strategy.md를 생성하고, 내장된 감사를 수행하며, 후속 작업을 안내합니다./test-strategy— 전략을 조사 계획으로 전환합니다: 무엇을, 어떤 순서로, 인간과 에이전트 간에 어떻게 나누어 알아낼지./tooling-strategy— 문서를 통해 아직 측정하거나 판단할 수 없는 항목이 드러났을 때(흔하며, 실패라기보다는 발견입니다): 누락된 오라클과 계측기를 위한 우선순위가 매겨진 구축 계획입니다. 위험 지도가 대부분 맹목적일 때 2단계와 3단계가 바뀝니다 — 스킬이 순서를 스스로 권장하며, 항상 무시할 수 있습니다./strategy-variants(선택 사항) — 유통하기 위한 한 페이지 요약본 또는 클라이언트에게 안전한 버전입니다./quality-artefacts(선택 사항) — 원하는 뷰를 설명하면 ("품질 상태에 대한 트윗 가능한 요약", "내 일일 회의를 위한 결제 위험 대시보드") 전략으로부터 맞춤형의 독립적인 SVG/HTML 아티팩트를 설계합니다 — Unknowns에 대해 정직하고, 스크린샷을 찍어 공유할 수 있도록 제작됩니다. 작업 예제는examples/fernly/quality/artefacts/에 있습니다.
스킬들이 어떻게 함께 작동하는지
사용자가 직접 시작하는 다섯 가지 스킬(굵은 글씨); 나머지는 스킬이 실행될 때 호출하는 검사 및 감사(점선 화살표 — 각각 독립 실행도 가능합니다). 스킬별 세부 사항: docs/SKILLS.md.
flowchart TD
QS["<b>/quality-strategy</b><br/>7단계 인터뷰 — 여기서 시작"]
OA["/oracle-adequacy<br/><i>'현재 위치' 주장을 실제로<br/>판단할 수 있는가?</i>"]
CC["/contradiction-check<br/><i>내부 일관성,<br/>모든 단계 경계</i>"]
OD["/operational-distillation<br/><i>TL;DR + 문서 상단의<br/>트라이어지 루브릭</i>"]
QSR["/quality-strategy-review<br/><i>마무리 감사</i>"]
SDOC[/"quality/strategy.md"/]
TS["<b>/test-strategy</b><br/>조사 계획"]
TA["/tooling-adequacy<br/><i>각 학습 요구를 실제로<br/>답변할 수 있는가?</i>"]
TSR["/test-strategy-review<br/><i>마무리 감사</i>"]
TDOC[/"quality/test-strategy.md"/]
TOOL["<b>/tooling-strategy</b><br/>오라클/계측기 구축 계획"]
ODOC[/"quality/tooling-strategy.md"/]
SV["<b>/strategy-variants</b><br/>대상별 변형"]
VDOC[/"한 페이지 ·<br/>클라이언트 안전 버전"/]
QA["<b>/quality-artefacts</b><br/>맞춤형 공유 가능 시각 자료"]
ADOC[/"quality/artefacts/<br/>*.svg · *.html"/]
BUILD["오라클 및 계측기 구축"]
QS -.-> OA
QS -.-> CC
QS -.-> OD
QS -.-> QSR
QS --> SDOC
SDOC -->|"위험 지도가 대부분<br/>답변 가능"| TS
SDOC -->|"위험 지도가 대부분 맹목 —<br/>Unknowns + 오라클 갭"| TOOL
SDOC -->|"유통할 무언가가<br/>필요함"| SV
SDOC -->|"한눈에 볼 수 있는 무언가가 필요함 —<br/>원하는 뷰를 설명"| QA
TS -.-> TA
TS -.-> TSR
TS --> TDOC
TDOC -->|"차단된 학습 요구 —<br/>더 명확해진 수요"| TOOL
TOOL --> ODOC
ODOC --> BUILD
BUILD -.->|"Unknowns이 알 수 있게 됨 —<br/>위험 지도 업데이트,<br/>학습 요구 차단 해제"| SDOC
SV --> VDOC
QA --> ADOC
classDef sub fill:#f6f6f6,stroke:#aaaaaa,color:#444444
class OA,CC,OD,QSR,TA,TSR sub
classDef doc fill:#fdf6e3,stroke:#b58900,color:#333333
class SDOC,TDOC,ODOC,VDOC,ADOC doc
이 구조는 팩의 네 가지 질문을 따릅니다 — 좋은 것이 무엇인가? 어떻게 알 수 있는가? 좋은가? 어떻게 좋게 만드는가? — 그리고 하나의 규칙을 따릅니다: 판단할 수 있는 것만 조사할 수 있습니다. 따라서 위험 지도의 상태에 따라 조사 계획이 먼저 올지 구축 계획이 먼저 올지 결정됩니다.
예상되는 점
- 인터뷰 방식입니다. 품질 전략은 코드에서 유추할 수 없습니다 — 누가 중요한지, 그들이 무엇을 가치 있게 여기는지, 무엇이 비목표인지 모두 잘못 추측될 것입니다. 스킬은 저장소를 미리 읽어 정보에 기반한 질문을 합니다; 모든 중요한 사항은 추측되지 않고 질문됩니다.
- 기준을 유지합니다. 작업이 작게 느껴진다고 해서 비목표를 건너뛰거나 엄격함을 낮추지 않습니다 — 그 거부가 핵심입니다. 사용자에 맞게 표현을 조정하고, 막힐 때 명확하게 표시된 시작 추측을 제공합니다.
- 살아있는 문서를 생성합니다. 읽고, 업데이트하고, 의사 결정 시점에 사용하도록 설계되었습니다 — 한 번 작성하고归档하는 것이 아닙니다.
- 실제 사고가 필요합니다. 여러 세션에 걸쳐 1~2영업일의 인지 시간을 계획하세요 — 스킬은 중단 및 재개를 위해 설계되었으며 깔끔하게 이어집니다. 몇 시간보다 빠른 것은 일반적으로 너무 빠르게 대답하고 있음을 의미합니다.
- 저장소가 필요 없습니다. 아이디어 단계에서 사전 읽기는 추측을 스캔 결과로 포장하는 대신 인터뷰에서 도출되었음을 정직하게 말하며, 인터뷰가 평소와 같이 부담을 짊어집니다.
알려진 제한 사항
- AI/비결정적 제품에 대한 전용 차원이 아직 없습니다 — "정확성"이 분포를 이루고 표류하는 메트릭인 시스템. 이해관계자/위험/계획 메커니즘은 여전히 도움이 됩니다; "좋은 것이 무엇이고 어떻게 알 수 있는가"라는 핵심은 직접 작성해야 합니다. 최우선 연구 항목입니다(ROADMAP.md).
- 주로 시뮬레이션에서 검증되었습니다. 많은 시뮬레이션 사용자에 대해 스트레스 테스트되고 적대적으로 검토되었습니다; 실제 환경 사용 경험은 제한적입니다. 잠정적인 판단은 무엇이 우리의 마음을 바꿀지와 함께
OPEN-QUESTIONS.md에 기록됩니다. /tooling-strategy는 가장 최신 스킬이며 사용 경험이 가장 적습니다 — 거친 부분이 더 있을 것으로 예상됩니다.- 일률적인 강도(cadence)입니다. 프로젝트 규모에 관계없이 모든 실행이 동일한 철저한 처리를 받습니다; 동일한 엄격함의 더 가벼운 뷰는 로드맵에 있지만, 더 낮은 기준은 아닙니다.
- 단일 릴리스 깊이입니다. 심층 분석은 한 번에 하나의 릴리스를 다룹니다; 다음 릴리스의 컨텍스트가 실제가 되면 수정 모드로 다시 실행하세요.
출처
이것은 Tollens의 첫 번째 오픈 소스 릴리스입니다 — 엔지니어링 관리 컨설턴트로서, 프로젝트에서 "좋음"이 무엇을 의미하는지, 그리고 실제로 얼마나 좋은지에 대한 암묵적인 감각을 사람과 AI 에이전트 모두가 추론할 수 있는 명시적이고 살아있는 지도로 전환합니다. 이 팩은 독립 실행형 맛보기이며, 계정이 필요 없습니다 — 하지만 독립 실행형 스킬이지 종단 간 워크플로는 아닙니다: 문서를 팀 프로세스에 맞추는 것은 여러분의 몫입니다. 전체 Tollens 제품(개발 중)은 종단 간 버전입니다 — 모든 단계를 지원하는 에이전트, 피드백 루프, 증거 및 보고, 릴리스 신뢰도 평가.
간단히 말해: 이 팩은 '당신은 여기' 화살표가 있는 지도입니다. Tollens는 내비게이션입니다 — 전체 여정을 위한 턴바이턴, 경로에서 벗어날 때 재계산, 신뢰할 수 있는 예상 도착 시간.
파일 위치
- docs/SKILLS.md — 스킬별 참조, 계획된 스킬 포함.
- ROADMAP.md — 다음에 올 것 (주요 사항: AI/비결정적 제품을 위한 품질 차원).
examples/fernly/— 가상 프로젝트에 대한 완전한 작업 샘플: 전체 전략, 테스트 전략, 세 개의 생성된 아티팩트. 하나의 프로젝트 답변이며, 템플릿이 아닙니다 — README를 참조하세요.PHILOSOPHY.md— 핵심; 스킬이 왜 그렇게 작동하는지.OPEN-QUESTIONS.md— 불확실성 하에서 내려진 설계 결정과 무엇이 우리의 마음을 바꿀지.skills/— 스킬 자체.
피드백
문제가 발생하면 알려주세요: 이슈 열기. 가장 가치 있는 보고는 구체적입니다 — 무엇을 실행했는지, 무엇이 생성되었는지, 무엇을 기대했는지. 특히 원하는 것: 인터뷰가 놓친(또는 불필요하게 제기한) 차원, 추측했어야 할 것을 추론한 부분, 그리고 알려진 제한 사항이 설명보다 더 심각하게 작용하는 경우.
크레딧
품질 프레임워크는 Edmund Pringle에 의해 만들어졌으며, 이 팩이 직접 참조하는 오픈 소스 **quality brain**으로 정제되었습니다; 그의 블로그 시리즈가 이 주제에 대한 가장 훌륭한 이야기체 읽을거리입니다. 이 프레임워크는 컨텍스트 기반 테스팅 전통(Bach, Bolton, Weinberg)을 기반으로 합니다. 스킬 구현은 Yanqing Cheng이 했습니다. Claude Code로 구축되었습니다.
라이선스
선택에 따라 MIT 또는 Apache-2.0 중 하나의 조건에 따라 라이선스가 부여됩니다. 명시적으로 달리 명시하지 않는 한, Apache-2.0 라이선스에 정의된 대로 귀하가 이 작업에 포함시키기 위해 의도적으로 제출한 모든 기여는 추가 약관 없이 위와 같이 이중 라이선스가 부여됩니다.