timsquad 2.1.0 → 3.4.0

package/templates/common/claude/skills/methodology/bdd/SKILL.md

@@ -1,234 +0,0 @@
----
-name: bdd
-description: Behavior-Driven Development 가이드라인
-user-invocable: false
-compatible-with: [tdd, ddd]
----
-
-<skill name="bdd">
-  <purpose>비즈니스 행위 중심의 테스트 및 개발 방법론</purpose>
-
-  <philosophy>
-    <principle>비즈니스 언어로 요구사항 표현</principle>
-    <principle>Given-When-Then으로 시나리오 명세</principle>
-    <principle>살아있는 문서 (Living Documentation)</principle>
-    <principle>개발자, QA, 기획자 간 공통 언어</principle>
-  </philosophy>
-
-  <core-concepts>
-    <concept name="user-story">
-      <description>사용자 관점의 기능 설명</description>
-      <template>
-        As a [역할]
-        I want [기능]
-        So that [가치/이유]
-      </template>
-      <example>
-        As a 회원
-        I want 비밀번호를 재설정
-        So that 계정에 다시 접근할 수 있다
-      </example>
-    </concept>
-
-    <concept name="scenario">
-      <description>구체적인 행위 시나리오</description>
-      <template>
-        Given [사전 조건]
-        When [행위]
-        Then [기대 결과]
-      </template>
-    </concept>
-
-    <concept name="acceptance-criteria">
-      <description>인수 조건 - 기능 완료 기준</description>
-    </concept>
-  </core-concepts>
-
-  <gherkin-syntax>
-    <description>BDD 시나리오 작성 문법</description>
-
-    <example type="feature-file">
-      <title>로그인 기능</title>
-      <code><![CDATA[
-Feature: 사용자 로그인
-  사용자가 이메일과 비밀번호로 로그인할 수 있다
-
-  Background:
-    Given 회원가입된 사용자가 존재한다
-      | email           | password  |
-      | user@test.com   | password1 |
-
-  Scenario: 올바른 자격 증명으로 로그인 성공
-    Given 로그인 페이지에 접속한다
-    When 이메일 "user@test.com"을 입력한다
-    And 비밀번호 "password1"을 입력한다
-    And 로그인 버튼을 클릭한다
-    Then 대시보드 페이지로 이동한다
-    And "로그인 성공" 메시지가 표시된다
-
-  Scenario: 잘못된 비밀번호로 로그인 실패
-    Given 로그인 페이지에 접속한다
-    When 이메일 "user@test.com"을 입력한다
-    And 비밀번호 "wrongpassword"를 입력한다
-    And 로그인 버튼을 클릭한다
-    Then 로그인 페이지에 머무른다
-    And "이메일 또는 비밀번호가 올바르지 않습니다" 에러가 표시된다
-
-  Scenario Outline: 다양한 잘못된 입력
-    When 이메일 "<email>"을 입력한다
-    And 비밀번호 "<password>"를 입력한다
-    And 로그인 버튼을 클릭한다
-    Then "<error>" 에러가 표시된다
-
-    Examples:
-      | email          | password | error                    |
-      |                | pass     | 이메일을 입력해주세요      |
-      | invalid-email  | pass     | 올바른 이메일 형식이 아닙니다 |
-      | user@test.com  |          | 비밀번호를 입력해주세요    |
-      ]]></code>
-    </example>
-  </gherkin-syntax>
-
-  <implementation-patterns>
-    <pattern name="step-definitions" language="typescript">
-      <description>Gherkin 스텝을 코드로 연결</description>
-      <example>
-        <title>Playwright + Cucumber 예시</title>
-        <code><![CDATA[
-import { Given, When, Then } from '@cucumber/cucumber';
-import { expect } from '@playwright/test';
-
-Given('로그인 페이지에 접속한다', async function() {
-  await this.page.goto('/login');
-});
-
-When('이메일 {string}을 입력한다', async function(email: string) {
-  await this.page.fill('[data-testid="email-input"]', email);
-});
-
-When('비밀번호 {string}를 입력한다', async function(password: string) {
-  await this.page.fill('[data-testid="password-input"]', password);
-});
-
-When('로그인 버튼을 클릭한다', async function() {
-  await this.page.click('[data-testid="login-button"]');
-});
-
-Then('대시보드 페이지로 이동한다', async function() {
-  await expect(this.page).toHaveURL('/dashboard');
-});
-
-Then('{string} 메시지가 표시된다', async function(message: string) {
-  await expect(this.page.locator('[data-testid="toast"]'))
-    .toContainText(message);
-});
-        ]]></code>
-      </example>
-    </pattern>
-
-    <pattern name="api-bdd" language="typescript">
-      <description>API 테스트용 BDD</description>
-      <example>
-        <title>Vitest + SuperTest 예시</title>
-        <code><![CDATA[
-describe('Feature: 사용자 등록 API', () => {
-  describe('Scenario: 유효한 정보로 회원가입', () => {
-    it('Given 유효한 사용자 정보가 있다', () => {
-      ctx.userData = {
-        email: 'new@test.com',
-        password: 'SecurePass123!',
-        name: '홍길동'
-      };
-    });
-
-    it('When POST /api/users 요청을 보낸다', async () => {
-      ctx.response = await request(app)
-        .post('/api/users')
-        .send(ctx.userData);
-    });
-
-    it('Then 201 상태 코드를 반환한다', () => {
-      expect(ctx.response.status).toBe(201);
-    });
-
-    it('And 생성된 사용자 ID를 반환한다', () => {
-      expect(ctx.response.body.data.id).toBeDefined();
-    });
-  });
-});
-        ]]></code>
-      </example>
-    </pattern>
-  </implementation-patterns>
-
-  <bdd-vs-tdd>
-    <comparison>
-      <aspect name="관점">
-        <tdd>개발자 관점 (코드 단위)</tdd>
-        <bdd>사용자/비즈니스 관점 (행위 단위)</bdd>
-      </aspect>
-      <aspect name="언어">
-        <tdd>기술 용어 (함수, 클래스)</tdd>
-        <bdd>비즈니스 용어 (시나리오, 기능)</bdd>
-      </aspect>
-      <aspect name="테스트 대상">
-        <tdd>단위 테스트 중심</tdd>
-        <bdd>인수 테스트, E2E 중심</bdd>
-      </aspect>
-      <aspect name="문서화">
-        <tdd>코드가 문서</tdd>
-        <bdd>시나리오가 살아있는 문서</bdd>
-      </aspect>
-    </comparison>
-    <recommendation>TDD + BDD 함께 사용 권장 (보완 관계)</recommendation>
-  </bdd-vs-tdd>
-
-  <directory-structure>
-    <dir name="features">
-      <description>Gherkin feature 파일</description>
-      <file name="auth/login.feature" />
-      <file name="auth/register.feature" />
-      <file name="order/checkout.feature" />
-    </dir>
-    <dir name="step-definitions">
-      <description>스텝 구현</description>
-      <file name="auth.steps.ts" />
-      <file name="order.steps.ts" />
-      <file name="common.steps.ts" />
-    </dir>
-    <dir name="support">
-      <description>헬퍼, 훅</description>
-      <file name="world.ts" example="테스트 컨텍스트" />
-      <file name="hooks.ts" example="Before, After 훅" />
-    </dir>
-  </directory-structure>
-
-  <tools>
-    <tool name="cucumber-js">JavaScript/TypeScript Cucumber 구현</tool>
-    <tool name="playwright">E2E 테스트 러너</tool>
-    <tool name="jest-cucumber">Jest와 Cucumber 통합</tool>
-  </tools>
-
-  <rules>
-    <category name="필수">
-      <must>시나리오는 비즈니스 언어로 작성</must>
-      <must>Given-When-Then 형식 준수</must>
-      <must>하나의 시나리오는 하나의 행위만 테스트</must>
-      <must>시나리오는 독립적으로 실행 가능해야 함</must>
-    </category>
-    <category name="금지">
-      <must-not>기술 용어를 시나리오에 노출 (CSS selector, API endpoint 등)</must-not>
-      <must-not>테스트 간 상태 공유</must-not>
-      <must-not>UI 구현 세부사항 시나리오에 포함</must-not>
-    </category>
-  </rules>
-
-  <checklist>
-    <item priority="critical">Feature 파일이 비즈니스 언어로 작성됨</item>
-    <item priority="critical">Given-When-Then 형식 준수</item>
-    <item priority="high">시나리오가 독립적으로 실행 가능</item>
-    <item priority="high">Step Definition 재사용성 확보</item>
-    <item priority="medium">Background로 공통 전제조건 추출</item>
-    <item priority="medium">Scenario Outline으로 데이터 주도 테스트</item>
-  </checklist>
-</skill>

package/templates/common/claude/skills/methodology/ddd/SKILL.md

@@ -1,311 +0,0 @@
----
-name: ddd
-description: Domain-Driven Design 전략적 설계 가이드라인
-user-invocable: false
-compatible-with: [tdd, bdd]
-note: 전술적 패턴(Aggregate, Entity 등)은 architectures/에 포함됨
----
-
-<skill name="ddd">
-  <purpose>복잡한 도메인을 효과적으로 모델링하는 전략적 설계 방법론</purpose>
-
-  <philosophy>
-    <principle>도메인 전문가와 개발자의 협업</principle>
-    <principle>유비쿼터스 언어 (Ubiquitous Language)</principle>
-    <principle>모델 주도 설계 (Model-Driven Design)</principle>
-    <principle>경계 컨텍스트로 복잡성 분리</principle>
-  </philosophy>
-
-  <strategic-vs-tactical>
-    <strategic location="이 스킬">
-      <item>Bounded Context (경계 컨텍스트)</item>
-      <item>Ubiquitous Language (유비쿼터스 언어)</item>
-      <item>Context Map (컨텍스트 맵)</item>
-      <item>Subdomain (서브도메인)</item>
-    </strategic>
-    <tactical location="architectures/ 및 patterns/">
-      <item>Aggregate, Entity, Value Object → clean/backend.xml</item>
-      <item>Repository → patterns/repository.xml</item>
-      <item>Domain Event → patterns/event-sourcing.xml</item>
-    </tactical>
-  </strategic-vs-tactical>
-
-  <core-concepts>
-    <concept name="ubiquitous-language">
-      <description>
-        도메인 전문가와 개발자가 공유하는 공통 언어.
-        코드, 문서, 대화 모두에서 동일한 용어 사용.
-      </description>
-      <example type="bad">
-        <code><![CDATA[
-// 개발자 용어로 작성 - 도메인 전문가가 이해 못함
-class DataProcessor {
-  processRecord(record: Record) {
-    if (record.status === 1) {
-      this.updateFlag(record, true);
-    }
-  }
-}
-        ]]></code>
-      </example>
-      <example type="good">
-        <code><![CDATA[
-// 유비쿼터스 언어 사용 - 도메인 전문가도 이해 가능
-class OrderFulfillment {
-  shipOrder(order: Order) {
-    if (order.isPaid()) {
-      order.markAsShipped();
-    }
-  }
-}
-        ]]></code>
-      </example>
-      <practice>
-        <item>용어 사전 (Glossary) 작성 및 유지</item>
-        <item>코드 리뷰 시 도메인 용어 준수 확인</item>
-        <item>도메인 전문가와 정기적 용어 검토</item>
-      </practice>
-    </concept>
-
-    <concept name="bounded-context">
-      <description>
-        특정 도메인 모델이 적용되는 명시적 경계.
-        같은 용어도 컨텍스트마다 다른 의미를 가질 수 있음.
-      </description>
-      <example>
-        <title>"Product"의 다른 의미</title>
-        <context name="Catalog">상품 정보, 설명, 이미지</context>
-        <context name="Inventory">재고 수량, 위치, SKU</context>
-        <context name="Pricing">가격, 할인, 프로모션</context>
-        <context name="Shipping">무게, 크기, 배송 제한</context>
-      </example>
-      <guidelines>
-        <guideline>하나의 Bounded Context = 하나의 팀</guideline>
-        <guideline>하나의 Bounded Context = 하나의 코드베이스 (또는 모듈)</guideline>
-        <guideline>컨텍스트 간 통신은 명시적 인터페이스로</guideline>
-      </guidelines>
-    </concept>
-
-    <concept name="subdomain">
-      <description>비즈니스 도메인의 논리적 분할</description>
-      <types>
-        <type name="core">
-          <description>비즈니스 핵심 차별화 요소</description>
-          <strategy>최고 인력 투입, 자체 개발</strategy>
-          <example>쿠팡의 로켓배송 시스템</example>
-        </type>
-        <type name="supporting">
-          <description>Core를 지원하지만 차별화 요소 아님</description>
-          <strategy>아웃소싱 또는 적당한 품질</strategy>
-          <example>내부 관리 시스템</example>
-        </type>
-        <type name="generic">
-          <description>모든 비즈니스에 공통</description>
-          <strategy>구매 또는 오픈소스 사용</strategy>
-          <example>결제, 인증, 이메일 발송</example>
-        </type>
-      </types>
-    </concept>
-
-    <concept name="context-map">
-      <description>Bounded Context 간의 관계를 시각화</description>
-      <relationships>
-        <relationship name="partnership">
-          <description>두 팀이 함께 성공/실패. 긴밀한 협력</description>
-          <diagram>[Context A] ←Partnership→ [Context B]</diagram>
-        </relationship>
-        <relationship name="shared-kernel">
-          <description>공유 모델. 양쪽 합의 필요</description>
-          <diagram>[Context A] ←Shared Kernel→ [Context B]</diagram>
-          <warning>변경 시 양쪽 영향. 최소화 권장</warning>
-        </relationship>
-        <relationship name="customer-supplier">
-          <description>Upstream(공급자)이 Downstream(고객) 요구 수용</description>
-          <diagram>[Supplier] →Customer-Supplier→ [Customer]</diagram>
-        </relationship>
-        <relationship name="conformist">
-          <description>Downstream이 Upstream 모델을 그대로 수용</description>
-          <diagram>[Upstream] →Conformist→ [Downstream]</diagram>
-          <usecase>외부 API 연동 시</usecase>
-        </relationship>
-        <relationship name="anticorruption-layer">
-          <description>번역 레이어로 외부 모델로부터 보호</description>
-          <diagram>[External] →ACL→ [Our Context]</diagram>
-          <usecase>레거시 시스템 연동, 외부 API</usecase>
-        </relationship>
-        <relationship name="open-host-service">
-          <description>잘 정의된 프로토콜로 서비스 제공</description>
-          <diagram>[Context] →OHS/PL→ [Multiple Consumers]</diagram>
-        </relationship>
-        <relationship name="published-language">
-          <description>표준화된 교환 언어 (JSON Schema, Protobuf)</description>
-        </relationship>
-      </relationships>
-    </concept>
-  </core-concepts>
-
-  <context-map-example>
-    <title>이커머스 Context Map</title>
-    <diagram><![CDATA[
-┌─────────────────────────────────────────────────────────────────┐
-│                        E-Commerce System                         │
-├─────────────────────────────────────────────────────────────────┤
-│                                                                  │
-│  ┌──────────────┐      Partnership      ┌──────────────┐        │
-│  │   Catalog    │◄─────────────────────►│   Pricing    │        │
-│  │   Context    │                       │   Context    │        │
-│  └──────┬───────┘                       └──────────────┘        │
-│         │                                                        │
-│         │ Customer-Supplier                                      │
-│         ▼                                                        │
-│  ┌──────────────┐                       ┌──────────────┐        │
-│  │    Order     │      Shared Kernel    │  Inventory   │        │
-│  │   Context    │◄─────────────────────►│   Context    │        │
-│  └──────┬───────┘      (Product ID)     └──────────────┘        │
-│         │                                                        │
-│         │ ACL                                                    │
-│         ▼                                                        │
-│  ┌──────────────┐                       ┌──────────────┐        │
-│  │   Shipping   │                       │   Payment    │        │
-│  │   Context    │                       │   Context    │        │
-│  └──────────────┘                       └──────┬───────┘        │
-│                                                 │ ACL            │
-│                                                 ▼                │
-│                                         ┌──────────────┐        │
-│                                         │    Stripe    │        │
-│                                         │  (External)  │        │
-│                                         └──────────────┘        │
-└─────────────────────────────────────────────────────────────────┘
-    ]]></diagram>
-  </context-map-example>
-
-  <anticorruption-layer-pattern>
-    <description>외부 모델로부터 도메인 보호</description>
-    <example language="typescript">
-      <title>Stripe 결제 연동 ACL</title>
-      <code><![CDATA[
-// 외부 모델 (Stripe)
-interface StripePaymentIntent {
-  id: string;
-  amount: number;           // cents
-  currency: string;
-  status: 'succeeded' | 'pending' | 'failed';
-  payment_method: string;
-}
-
-// 우리 도메인 모델
-interface Payment {
-  id: PaymentId;
-  amount: Money;            // 우리의 Money Value Object
-  status: PaymentStatus;    // 우리의 enum
-  orderId: OrderId;
-}
-
-// Anti-Corruption Layer
-class StripePaymentAdapter implements PaymentGateway {
-  constructor(private stripe: Stripe) {}
-
-  async processPayment(payment: Payment): Promise<PaymentResult> {
-    // 도메인 → 외부 모델 변환
-    const intent = await this.stripe.paymentIntents.create({
-      amount: payment.amount.toCents(),  // Money → cents
-      currency: payment.amount.currency.toLowerCase(),
-    });
-
-    // 외부 모델 → 도메인 변환
-    return this.toPaymentResult(intent);
-  }
-
-  private toPaymentResult(intent: StripePaymentIntent): PaymentResult {
-    return {
-      success: intent.status === 'succeeded',
-      transactionId: TransactionId.create(intent.id),
-      status: this.mapStatus(intent.status),
-    };
-  }
-
-  private mapStatus(stripeStatus: string): PaymentStatus {
-    const mapping: Record<string, PaymentStatus> = {
-      'succeeded': PaymentStatus.COMPLETED,
-      'pending': PaymentStatus.PROCESSING,
-      'failed': PaymentStatus.FAILED,
-    };
-    return mapping[stripeStatus] ?? PaymentStatus.UNKNOWN;
-  }
-}
-      ]]></code>
-    </example>
-  </anticorruption-layer-pattern>
-
-  <event-storming>
-    <description>도메인 이벤트를 중심으로 도메인 모델링하는 워크샵 기법</description>
-    <steps>
-      <step order="1">Domain Events 도출 (주황색 포스트잇)</step>
-      <step order="2">Commands 식별 (파란색)</step>
-      <step order="3">Aggregates 그룹핑 (노란색)</step>
-      <step order="4">Bounded Context 경계 그리기</step>
-      <step order="5">Context Map 작성</step>
-    </steps>
-    <tip>도메인 전문가와 함께 진행</tip>
-  </event-storming>
-
-  <directory-structure-by-context>
-    <description>Bounded Context별 코드 구조 (모노레포)</description>
-    <structure><![CDATA[
-packages/
-├── catalog/                    # Catalog Context
-│   ├── src/
-│   │   ├── domain/
-│   │   ├── application/
-│   │   └── infrastructure/
-│   └── package.json
-│
-├── order/                      # Order Context
-│   ├── src/
-│   │   ├── domain/
-│   │   ├── application/
-│   │   └── infrastructure/
-│   └── package.json
-│
-├── inventory/                  # Inventory Context
-│   └── ...
-│
-└── shared/                     # Shared Kernel (최소화)
-    ├── src/
-    │   ├── value-objects/     # ProductId, Money 등 공유 VO
-    │   └── events/            # 통합 이벤트 스키마
-    └── package.json
-    ]]></structure>
-  </directory-structure-by-context>
-
-  <rules>
-    <category name="필수">
-      <must>용어 사전 (Glossary) 작성 및 유지</must>
-      <must>코드에서 유비쿼터스 언어 사용</must>
-      <must>Bounded Context 경계 명확히 정의</must>
-      <must>컨텍스트 간 통신은 명시적 인터페이스로</must>
-      <must>외부 시스템 연동 시 ACL 사용</must>
-    </category>
-    <category name="권장">
-      <should>Core Subdomain에 최고 리소스 투입</should>
-      <should>Generic Subdomain은 구매/오픈소스 활용</should>
-      <should>Event Storming으로 도메인 모델링</should>
-      <should>Context Map 문서화 및 최신 유지</should>
-    </category>
-    <category name="금지">
-      <must-not>Bounded Context 간 도메인 모델 직접 공유</must-not>
-      <must-not>하나의 Aggregate가 여러 Context에 걸침</must-not>
-      <must-not>기술 용어를 도메인 모델에 사용</must-not>
-    </category>
-  </rules>
-
-  <checklist>
-    <item priority="critical">용어 사전 존재 및 최신화</item>
-    <item priority="critical">Bounded Context 경계 정의됨</item>
-    <item priority="critical">코드가 유비쿼터스 언어 사용</item>
-    <item priority="high">Context Map 문서화</item>
-    <item priority="high">외부 연동에 ACL 적용</item>
-    <item priority="high">Subdomain 분류 (Core/Supporting/Generic)</item>
-    <item priority="medium">Event Storming 워크샵 진행</item>
-  </checklist>
-</skill>