home / skills / popup-studio-ai / bkit-claude-code / phase-1-schema

phase-1-schema skill

/skills/phase-1-schema

This skill defines unified terminology and data structures for the project, enabling consistent communication and clear schema design.

npx playbooks add skill popup-studio-ai/bkit-claude-code --skill phase-1-schema

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.4 KB
---
name: phase-1-schema
description: |
  Skill for defining terminology and data structures used throughout the project.
  Covers domain terminology, entities, relationships, and schema design.

  Use proactively when starting a new project or when data structures are unclear.

  Triggers: schema, terminology, data model, entity, 스키마, 用語, データモデル, 数据模型,
  esquema, terminología, modelo de datos, schéma, terminologie, modèle de données,
  Schema, Terminologie, Datenmodell, schema, terminologia, modello dati

  Do NOT use for: UI-only changes, deployment, or when schema is already defined.
agent: bkit:pipeline-guide
allowed-tools:
  - Read
  - Write
  - Glob
  - Grep
user-invocable: false
imports:
  - ${PLUGIN_ROOT}/templates/pipeline/phase-1-schema.template.md
  - ${PLUGIN_ROOT}/templates/shared/naming-conventions.md
next-skill: phase-2-convention
pdca-phase: plan
task-template: "[Phase-1] {feature}"
---

# Phase 1: Schema/Terminology Definition

> Define terminology and data structures used throughout the project

## Purpose

Unify the language of the project. Ensure all team members (or AI) communicate using the same terms and clearly understand data structures.

## What to Do in This Phase

1. **Build Glossary**: Map business terms + global standards
2. **Identify Entities**: Determine what "things" exist
3. **Define Relationships**: Relationships between entities
4. **Design Schema**: Define data structures

## Glossary

### Why is it Needed?

**Explaining business terms to Claude Code every time is tedious**.
Creating a glossary allows:
- Claude to automatically reference for context understanding
- Team communication consistency
- Reduced onboarding time for new team members/AI

### Term Categories

| Category | Description | Example |
|----------|-------------|---------|
| **Business Terms** | Internal proprietary terms | "Caddy" (golf booking assistant) |
| **Global Standards** | Industry common or technical standard terms | "OAuth", "REST API" |
| **Mapping** | Business ↔ Global correspondence | "Member" = User, "Payment" = Payment |

### Glossary Template

```markdown
## Business Terms (Internal Terms)

| Term | English | Definition | Global Standard Mapping |
|------|---------|------------|------------------------|
| Caddy | Caddy | AI assistant that helps book golf rounds | Booking Assistant |
| Round | Round | One 18-hole golf play | Session, Booking |
| Green Fee | Green Fee | Golf course usage fee | Usage Fee |

## Global Standards

| Term | Definition | Reference |
|------|------------|-----------|
| OAuth 2.0 | Authentication protocol | RFC 6749 |
| REST | API architecture style | - |
| UUID | Universal Unique Identifier | RFC 4122 |

## Term Usage Rules

1. Use **English** in code (`Caddy`, `Round`)
2. Use **local language** in UI/docs (Caddy, Round)
3. API responses prioritize **global standards** (`booking_assistant`)
```

### Claude Code Auto-Reference Setup

To have Claude automatically reference the glossary:

**Method 1**: Include in CLAUDE.md
```markdown
## Term Reference
For this project's term definitions, see `docs/01-plan/glossary.md`.
```

**Method 2**: Add term rules to project CLAUDE.md
```markdown
<!-- Add to CLAUDE.md -->
Project terms are defined in docs/01-plan/glossary.md.
Always reference when using business terms.
```

## Deliverables

```
docs/01-plan/
├── glossary.md         # Glossary (recommended new)
│   ├── Business Terms
│   ├── Global Standards
│   └── Mapping Table
├── schema.md           # Data schema
├── terminology.md      # (existing) → recommend merging into glossary.md
└── domain-model.md     # Domain model
```

## PDCA Application

- **Plan**: Identify what entities/terms are needed
- **Design**: Design schema structure, relationships
- **Do**: Write documentation
- **Check**: Review for omissions/contradictions
- **Act**: Finalize and proceed to Phase 2

## Level-wise Application

| Level | Application Level |
|-------|------------------|
| Starter | Simple (core terms only) |
| Dynamic | Detailed (all entities) |
| Enterprise | Detailed (per microservice) |

## Example Questions

```
"What are the core 'things' this project deals with?"
"What are the relationships between users, products, orders...?"
"Are 'member' and 'user' the same or different?"
```

## Template

See `templates/pipeline/phase-1-schema.template.md`

## Next Phase

Phase 2: Coding Convention → Now that terms are defined, define code rules

Overview

This skill defines project terminology and data structures to unify language across teams and AI. It produces a glossary, entity list, relationship map, and a canonical schema to reduce ambiguity and speed onboarding. Use it proactively at project start or when data definitions are unclear.

How this skill works

The skill guides you to build a glossary mapping business terms to global standards, identify core entities, and document relationships. It then translates those artifacts into a readable data schema and domain model files for project reference. Deliverables include glossary.md, schema.md, and domain-model.md so AI agents and developers can auto-reference consistent terms.

When to use it

  • Starting a new project or new domain discovery phase
  • When data structures or terminology are inconsistent or disputed
  • Onboarding new team members or integrating AI agents
  • Before designing APIs, databases, or integrations
  • When preparing domain documents for automated agents to reference

Best practices

  • Write business terms in English for code and map to local-language UI as needed
  • Include global-standard mappings (UUID, OAuth, REST) for API consistency
  • Keep glossary and schema files versioned and referenced by agent prompts
  • Start with a minimal core glossary and expand iteratively (PDCA)
  • Validate relationships with sample queries or ER diagrams to catch omissions

Example use cases

  • Define whether "member" and "user" are synonymous and pick canonical field names
  • Map internal product terms to public API names for integration partners
  • Create a domain-model.md to drive database schema and ORM models
  • Provide a canonical glossary file so Claude or other agents auto-reference terms
  • Split schema per microservice level for enterprise architectures

FAQ

What files should I create to capture results?

Create docs/01-plan/glossary.md, schema.md, and domain-model.md. Add terminology.md only if merging legacy content.

How detailed should the initial glossary be?

Start with core business terms and global standards. Use PDCA to expand depth as the project matures.