# TEL304: Designing a Custom Application from a Skill Book
https://www.telosready.com/skills/TEL304?v=1
Step-by-step process for analysing a skill book to design a custom AI-embedded application — extracting a glossary, domain model, tools, and workflows, then producing both an executive summary and a detailed technical breakdown.

## Instructions
# Designing a Custom Application from a Skill Book

A skill book encodes a business's intellectual property — its processes, standards, and domain knowledge. This skill explains how to take that skill book and use it as the primary input for designing a custom, AI-embedded application. The output is not a PRD. It is a layered design built from the ground up, where the skill book is the source of truth and the software is its derivative.

The principle: **the skill book is the IP. The source code is a proof that the skill book is good.**

---

## Before You Start

List all skills in the skill book and read their descriptions. This gives you the big picture before diving into detail. For a skill book with 50 or more skills, read every description, then dive into 5–10 of the most domain-rich skills to extract key concepts and relationships. This is an iterative process — the goal is breadth first, depth later.

Do not start with the user experience. Do not write requirements lists. Build from the bottom up.

---

## Step 1 — Build the Glossary

Extract all meaningful terms, concepts, and entities from the skills. The glossary is your frame of reference. It establishes the language of the domain and prevents ambiguity in every layer that follows.

**What to capture:**
- Core nouns (entities, objects, things the business tracks or acts on)
- Key verbs (actions the business performs)
- Status terms (stages, states, categories)
- Domain-specific jargon and their plain-English meanings
- Relationships implied by language ("a lead becomes a prospect", "a job has tasks")

**Output:** A flat glossary — term, definition, notes on how it's used in context.

The glossary is not a final document. Expect it to evolve as you move through the later steps.

---

## Step 2 — Build the Domain Model

Using the glossary as input, extract the domain model. This is the data layer of the application — the entities, their attributes, and the relationships between them. Think of it as a conceptual database schema, but do not call it that in non-technical conversations.

**What to identify:**
- Core entities (the main things the system needs to store and manage)
- Key attributes of each entity (the data fields that matter)
- Relationships between entities (one-to-many, many-to-many, parent-child)
- Status flows (how entities move through stages over time)

**Example:** In a sales skill book, you might extract: Lead, Prospect, Company, Contact, Communication, Stage, Opportunity — and the relationships between them.

Keep this high-level. You are not designing a database schema. You are understanding the shape of the business's data so every subsequent layer is grounded in something real.

---

## Step 3 — Identify the Tools

Tools are the discrete capabilities the system needs — the things a user or an AI agent can do. Every skill in the skill book implies tools: data it needs access to, and actions it needs to be able to take.

Work through each skill and ask two questions:
1. **What information does the AI need to complete this skill?** (read access to data, external lookups, memory)
2. **What actions does the AI need to take?** (write to records, send communications, trigger external systems, create new entities)

**Categorise tools into two types:**

**AI Tools** — capabilities the agent uses autonomously:
- Reading and querying data records
- Creating, updating, and archiving records
- Sending emails, messages, or notifications
- Calling external APIs or integrating with third-party systems
- Running scheduled checks or status evaluations

**UI Tools** — capabilities exposed to human users:
- Viewing dashboards and summaries
- Drilling into records and detail views
- Taking manual actions (approve, reject, assign, escalate)
- Submitting forms and updating data
- Filtering, searching, and organising information

The same underlying capability should be available to both user and AI where possible — this symmetry is a design principle. If a user can send a follow-up email, the AI should be able to as well, using the same tool.

---

## Step 4 — Define the Workflows

Workflows are the sequences of actions triggered by events or user intent. Define two tracks:

### AI Workflows

Start with triggers. What events or conditions cause the AI to act?

- A new record is created (e.g. a lead arrives)
- A status changes (e.g. a job moves to "ready for review")
- A scheduled interval fires (e.g. every hour, do a status check)
- A user explicitly requests action (e.g. "summarise this week's activity")

For each trigger, define:
1. **What context is injected** — what data and memory the agent receives at the start
2. **Which skills are relevant** — what the agent will retrieve and follow
3. **What tools it will use** — the actions it can take
4. **What the expected outcome is** — what "done" looks like

AI workflows are not scripts. They are structured starting points that allow the agent to apply skills intelligently within defined boundaries.

### User Workflows

Think about the jobs users come in to do. A user workflow is not a feature list — it is a job-to-be-done.

- "I need to find a specific customer quickly and see their full history"
- "I need to see what leads I have and where each one stands"
- "I need to know what actions are waiting for me today"

For each user job:
- What information do they need to see at a glance?
- What do they need to drill into?
- What actions do they need to take?
- How does the AI assist or act on their behalf within this workflow?

Design for navigation and clarity — high-level summary first, detail on demand.

---

## Step 5 — Produce the Outputs

The design process produces two outputs. Both are derived from the four layers above — the same content, presented at different levels of detail.

### Output A — Executive Summary (non-technical)

A concise, outcome-based summary intended for a non-technical decision-maker. The goal is to help them understand what the software does and what the AI does — without technical detail.

**Structure:**
- **What the system does** — one paragraph, plain language
- **Core data** — a short list of the key things the system tracks (entities from the domain model, named in plain language)
- **What users do** — a short list of the main jobs a user comes in to perform
- **What the AI does** — a short list of the key autonomous workflows (e.g. "Automatically responds to new leads within 5 minutes using your skill book")

Keep this to one page. Every item should be outcome-based. Avoid technical terms.

### Output B — Detailed Design Overview (technical)

A structured breakdown of all four layers. This is not a full specification — it is a breadth-first view of the full system, designed to communicate scope and structure without diving into the implementation of every piece.

**Structure:**
1. **Glossary** — key terms and definitions
2. **Domain model** — entities, key attributes, and relationships
3. **AI tools** — list of agent capabilities with a one-line description of each
4. **UI tools** — list of user-facing capabilities with a one-line description of each
5. **User workflows** — the main jobs users perform, mapped to the tools and data they use
6. **AI workflows** — triggers, context, relevant skills, and expected outcomes for each automated workflow

This output is the foundation for scoping, development planning, and further design. It is not a finalised spec — it is a starting point that gets refined as the system is built.

---

## The Living Skill Book

Designing and building the application does not end the skill book's role. Once the application is live, the skill book is embedded into the AI agent. The agent uses it at runtime — retrieving relevant skills to guide its actions, interpret data, and interact with users.

The skill book should be treated as a living document:
- When the AI produces a poor outcome, improve the relevant skill
- When a new business process emerges, add a skill to capture it
- When a tool is added or changed, update the skills that reference it
- Periodically review skills for accuracy and relevance

**The quality of the skill book determines the quality of the agent.** If the software doesn't make sense or the agent behaves poorly, the first place to look is the skill book — not the code.

---

## What Not to Do

- Do not start with the user interface
- Do not write a requirements document before building the domain model
- Do not try to design every detail of every workflow before the domain is stable
- Do not treat the skill book as a one-time input — it is a permanent part of the system

---

## References

- **TEL301** — Five Essentials of Agentic AI (harness, unit of work, workflows, memory, skills)
- **TEL302** — How Telos Builds Software (the layered build process this design feeds into)
- **TEL202** — Building a Skill Book (how skills are created and structured)

# Designing a Custom Application from a Skill Book

A skill book encodes a business's intellectual property — its processes, standards, and domain knowledge. This skill explains how to take that skill book and use it as the primary input for designing a custom, AI-embedded application. The output is not a PRD. It is a layered design built from the ground up, where the skill book is the source of truth and the software is its derivative.

The principle: **the skill book is the IP. The source code is a proof that the skill book is good.**

---

## Before You Start

List all skills in the skill book and read their descriptions. This gives you the big picture before diving into detail. For a skill book with 50 or more skills, read every description, then dive into 5–10 of the most domain-rich skills to extract key concepts and relationships. This is an iterative process — the goal is breadth first, depth later.

Do not start with the user experience. Do not write requirements lists. Build from the bottom up.

---

## Step 1 — Build the Glossary

Extract all meaningful terms, concepts, and entities from the skills. The glossary is your frame of reference. It establishes the language of the domain and prevents ambiguity in every layer that follows.

**What to capture:**
- Core nouns (entities, objects, things the business tracks or acts on)
- Key verbs (actions the business performs)
- Status terms (stages, states, categories)
- Domain-specific jargon and their plain-English meanings
- Relationships implied by language ("a lead becomes a prospect", "a job has tasks")

**Output:** A flat glossary — term, definition, notes on how it's used in context.

The glossary is not a final document. Expect it to evolve as you move through the later steps.

---

## Step 2 — Build the Domain Model

Using the glossary as input, extract the domain model. This is the data layer of the application — the entities, their attributes, and the relationships between them. Think of it as a conceptual database schema, but do not call it that in non-technical conversations.

**What to identify:**
- Core entities (the main things the system needs to store and manage)
- Key attributes of each entity (the data fields that matter)
- Relationships between entities (one-to-many, many-to-many, parent-child)
- Status flows (how entities move through stages over time)

**Example:** In a sales skill book, you might extract: Lead, Prospect, Company, Contact, Communication, Stage, Opportunity — and the relationships between them.

Keep this high-level. You are not designing a database schema. You are understanding the shape of the business's data so every subsequent layer is grounded in something real.

---

## Step 3 — Identify the Tools

Tools are the discrete capabilities the system needs — the things a user or an AI agent can do. Every skill in the skill book implies tools: data it needs access to, and actions it needs to be able to take.

Work through each skill and ask two questions:
1. **What information does the AI need to complete this skill?** (read access to data, external lookups, memory)
2. **What actions does the AI need to take?** (write to records, send communications, trigger external systems, create new entities)

**Categorise tools into two types:**

**AI Tools** — capabilities the agent uses autonomously:
- Reading and querying data records
- Creating, updating, and archiving records
- Sending emails, messages, or notifications
- Calling external APIs or integrating with third-party systems
- Running scheduled checks or status evaluations

**UI Tools** — capabilities exposed to human users:
- Viewing dashboards and summaries
- Drilling into records and detail views
- Taking manual actions (approve, reject, assign, escalate)
- Submitting forms and updating data
- Filtering, searching, and organising information

The same underlying capability should be available to both user and AI where possible — this symmetry is a design principle. If a user can send a follow-up email, the AI should be able to as well, using the same tool.

---

## Step 4 — Define the Workflows

Workflows are the sequences of actions triggered by events or user intent. Define two tracks:

### AI Workflows

Start with triggers. What events or conditions cause the AI to act?

- A new record is created (e.g. a lead arrives)
- A status changes (e.g. a job moves to "ready for review")
- A scheduled interval fires (e.g. every hour, do a status check)
- A user explicitly requests action (e.g. "summarise this week's activity")

For each trigger, define:
1. **What context is injected** — what data and memory the agent receives at the start
2. **Which skills are relevant** — what the agent will retrieve and follow
3. **What tools it will use** — the actions it can take
4. **What the expected outcome is** — what "done" looks like

AI workflows are not scripts. They are structured starting points that allow the agent to apply skills intelligently within defined boundaries.

### User Workflows

Think about the jobs users come in to do. A user workflow is not a feature list — it is a job-to-be-done.

- "I need to find a specific customer quickly and see their full history"
- "I need to see what leads I have and where each one stands"
- "I need to know what actions are waiting for me today"

For each user job:
- What information do they need to see at a glance?
- What do they need to drill into?
- What actions do they need to take?
- How does the AI assist or act on their behalf within this workflow?

Design for navigation and clarity — high-level summary first, detail on demand.

---

## Step 5 — Produce the Outputs

The design process produces two outputs. Both are derived from the four layers above — the same content, presented at different levels of detail.

### Output A — Executive Summary (non-technical)

A concise, outcome-based summary intended for a non-technical decision-maker. The goal is to help them understand what the software does and what the AI does — without technical detail.

**Structure:**
- **What the system does** — one paragraph, plain language
- **Core data** — a short list of the key things the system tracks (entities from the domain model, named in plain language)
- **What users do** — a short list of the main jobs a user comes in to perform
- **What the AI does** — a short list of the key autonomous workflows (e.g. "Automatically responds to new leads within 5 minutes using your skill book")

Keep this to one page. Every item should be outcome-based. Avoid technical terms.

### Output B — Detailed Design Overview (technical)

A structured breakdown of all four layers. This is not a full specification — it is a breadth-first view of the full system, designed to communicate scope and structure without diving into the implementation of every piece.

**Structure:**
1. **Glossary** — key terms and definitions
2. **Domain model** — entities, key attributes, and relationships
3. **AI tools** — list of agent capabilities with a one-line description of each
4. **UI tools** — list of user-facing capabilities with a one-line description of each
5. **User workflows** — the main jobs users perform, mapped to the tools and data they use
6. **AI workflows** — triggers, context, relevant skills, and expected outcomes for each automated workflow

This output is the foundation for scoping, development planning, and further design. It is not a finalised spec — it is a starting point that gets refined as the system is built.

---

## The Living Skill Book

Designing and building the application does not end the skill book's role. Once the application is live, the skill book is embedded into the AI agent. The agent uses it at runtime — retrieving relevant skills to guide its actions, interpret data, and interact with users.

The skill book should be treated as a living document:
- When the AI produces a poor outcome, improve the relevant skill
- When a new business process emerges, add a skill to capture it
- When a tool is added or changed, update the skills that reference it
- Periodically review skills for accuracy and relevance

**The quality of the skill book determines the quality of the agent.** If the software doesn't make sense or the agent behaves poorly, the first place to look is the skill book — not the code.

---

## What Not to Do

- Do not start with the user interface
- Do not write a requirements document before building the domain model
- Do not try to design every detail of every workflow before the domain is stable
- Do not treat the skill book as a one-time input — it is a permanent part of the system

---

## References

- **TEL301** — Five Essentials of Agentic AI (harness, unit of work, workflows, memory, skills)
- **TEL302** — How Telos Builds Software (the layered build process this design feeds into)
- **TEL202** — Building a Skill Book (how skills are created and structured)