Step-by-step Learning

/wor-agentic-architect

# Agentic Architect — Template Express

## What do you want to create?

- [ ] Agent Specialist
- [ ] Agent Supervisor
- [ ] Skill
- [X] Command
- [ ] Rule

## Entity description

**Tentative name:**
format-notes

**What exactly should it do?**
Receive raw meeting notes (pasted by the user) and produce a
structured summary with four sections: Decisions, Action Items
(with owner and deadline), Open Questions, and Next Steps.

**What does it receive as input?**
Unstructured meeting notes pasted by the user after invoking
the command.

**What does it produce as output?**
A formatted summary in Markdown with consistent sections.
The output is displayed directly to the user.

## Known constraints

**Is there anything this entity should never do?**
Never invent action items or attendees that are not in the
original notes. Never change the meaning of decisions.

**Are there any relevant restrictions?**
The output format must always follow the same four-section
structure, regardless of the input quality.

## Additional context

**Related entities:**
A Rule for the output format and a Knowledge Base with the
team roster (names, roles, responsibilities) to assign action
items correctly.

exports/meeting-notes-formatter/
├── .agents/
│   ├── workflows/
│   │   └── com-format-notes.md
│   ├── rules/
│   │   └── rul-output-format.md
│   └── knowledge-base/
│       └── kno-team-roster.md
├── .claude/         (auto-synced)
├── process-overview.md
└── CLAUDE.md

/wor-agentic-architect

# Agentic Architect — Template Express

## What do you want to create?

- [X] Agent Specialist
- [ ] Agent Supervisor
- [ ] Skill
- [ ] Command
- [ ] Rule

## Entity description

**Tentative name:**
code-reviewer

**What exactly should it do?**
Analyze the current git diff for bugs, style violations, and
security issues. Adapt its analysis strategy based on the type
of changes (frontend vs. backend, new code vs. refactor).
Produce a structured report with findings by severity.

**What does it receive as input?**
The current git diff or PR changeset, invoked directly by
the developer.

**What does it produce as output?**
A structured review report with findings categorized by
severity (critical, warning, info). Each finding includes
a specific line reference and an actionable suggestion.

## Known constraints

**Is there anything this entity should never do?**
Never produce cosmetic nitpicks or vague feedback like
"consider refactoring this." Every finding must be actionable
with a specific suggestion.

**Are there any relevant restrictions?**
Findings must follow a consistent structure: severity level,
line reference, description, and suggestion. Must respect
the team's style guide conventions.

## Additional context

**Related entities:**
A Skill for formatting the report output (ski-format-report).
A Rule enforcing review standards (severity levels, no nitpicks).
A Knowledge Base with team coding conventions (kno-style-guide).

exports/pr-review-assistant/
├── .agents/
│   ├── workflows/
│   │   └── age-spe-code-reviewer.md
│   ├── skills/
│   │   └── ski-format-report.md
│   ├── rules/
│   │   └── rul-review-standards.md
│   └── knowledge-base/
│       └── kno-style-guide.md
├── .claude/
├── process-overview.md
└── CLAUDE.md

/wor-agentic-architect

# Agentic Architect — Template Architect

## 1. What you want to agentize

**Name or title of the process:**
Customer Support Triage

**Describe the process in 2-4 sentences:**
Classify incoming support tickets by urgency and department,
then draft responses for urgent cases. The system should
reduce response time for critical tickets while ensuring
consistent quality across all responses.

**How is this done today, without the system?**
A support agent reads each ticket, manually assesses urgency
based on keywords and tone, checks an internal FAQ for known
issues, and writes a response. Critical tickets sometimes
wait in the general queue.

**What happens if the system doesn't exist or fails?**
Critical tickets get delayed. Response quality varies by
agent. SLA violations for urgent cases.

## 2. Process flow

**How does the process start?**
The user invokes the workflow with incoming ticket data
(subject, body, sender info).

**Main steps you have already identified:**
1. Classify ticket by urgency (critical/high/normal/low)
   and department (billing/technical/account/general)
2. For urgent tickets, draft an empathetic response using
   known solutions from the FAQ
3. Return classification + draft (if applicable)

**How does the process end?**
Returns a structured classification with urgency, department,
and — for urgent tickets — a draft response ready for review.

**Are there decisions or branches in the flow?**
Yes: after classification, only urgent tickets trigger the
draft-responder. Normal/low tickets only get classified.

**Are there repeating steps?**
No.

## 3. Technical context

**Does the process interact with external systems?**
No external APIs. Only internal Knowledge Base for product FAQ.

**Are there points where a human must review?**
The drafted response is always reviewed by a human before sending.

**Are there irreversible actions?**
No. The system classifies and drafts but never sends.

## 4. Existing skills and entities

**Reusable skills:**
A sentiment-check skill (ski-sentiment-check) that both agents
can use to analyze emotional tone and detect frustration.

## 5. Known constraints

**Is there anything the system should never do?**
Never send a response automatically. Never downgrade a ticket
that shows frustration signals.

**Are there relevant restrictions?**
SLA compliance: critical tickets must be responded to within
1 hour, standard within 24 hours.

## 6. Expected result

**What does success look like?**
All tickets classified correctly by urgency and department.
Urgent tickets have a draft response within minutes. Zero
SLA violations for critical cases.

exports/customer-support-triage/
├── .agents/
│   ├── workflows/
│   │   ├── wor-support-triage.md
│   │   ├── age-spe-classifier.md
│   │   └── age-spe-draft-responder.md
│   ├── skills/
│   │   └── ski-sentiment-check.md
│   ├── rules/
│   │   └── rul-sla-compliance.md
│   └── knowledge-base/
│       └── kno-product-faq.md
├── .claude/
├── process-overview.md
└── CLAUDE.md

/wor-agentic-architect

# Agentic Architect — Template Architect

## 1. What you want to agentize

**Name or title of the process:**
Sprint Planning Pipeline

**Describe the process in 2-4 sentences:**
End-of-sprint automation: analyze what happened (retrospective),
calculate velocity and capacity for the next sprint, then plan
the next sprint by prioritizing and assigning backlog items.
The pipeline can be triggered manually or automatically when
the sprint closes.

**How is this done today, without the system?**
The PM manually reviews completed tickets, gathers feedback,
calculates velocity in a spreadsheet, reviews the backlog,
scores items, assesses risk, and drafts the sprint plan.
Takes 4-6 hours spread across multiple meetings.

**What happens if the system doesn't exist or fails?**
Sprint planning takes too long, velocity estimates are
inconsistent, high-risk items slip through undetected, and
capacity is over-committed.

## 2. Process flow

**How does the process start?**
Either: (a) the user invokes the workflow manually, or
(b) a Hook triggers it automatically when the sprint is
marked as closed.

**Main steps you have already identified:**
1. Retro analysis: review completed tickets, identify what
   went well, what didn't, and recurring blockers
2. Velocity calculation: compute rolling velocity across
   last 3 sprints, adjust for availability
3. Sprint planning: prioritize backlog items using scoring
   and risk assessment, draft the plan within capacity

**How does the process end?**
Produces a complete sprint plan document. The user can then
invoke a separate publish command to export it.

**Are there decisions or branches in the flow?**
Sequential: each agent depends on the previous one's output.
No conditional branches, but the planner adjusts based on
velocity and risk data.

**Are there repeating steps?**
No.

## 3. Technical context

**Does the process interact with external systems?**
No external APIs. Internal Knowledge Base with team data,
OKRs, and availability.

**Are there points where a human must review?**
The final sprint plan should be reviewed before publishing.

**Are there irreversible actions?**
No. Publishing is a separate manual command.

## 4. Existing skills and entities

**Reusable skills:**
- A backlog-scorer skill (ski-backlog-scorer) for prioritizing
  items by business value, effort, and OKR alignment
- A risk-assessment skill (ski-risk-assessment) for evaluating
  technical, dependency, and knowledge-gap risks

## 5. Known constraints

**Is there anything the system should never do?**
Never commit a sprint plan that exceeds team capacity. Never
include more than 2 high-risk items per sprint.

**Are there relevant restrictions?**
Capacity constraints are hard limits. Risk limits are hard
limits. Both must be enforced by a Rule.

## 6. Expected result

**What does success look like?**
A complete sprint plan that respects velocity, capacity, and
risk constraints. Ready for review and publishing. Generated
in minutes instead of hours.

exports/sprint-planning-pipeline/
├── .agents/
│   ├── workflows/
│   │   ├── wor-sprint-pipeline.md
│   │   ├── age-spe-retro-analyst.md
│   │   ├── age-spe-velocity-calculator.md
│   │   └── age-spe-sprint-planner.md
│   ├── skills/
│   │   ├── ski-backlog-scorer.md
│   │   └── ski-risk-assessment.md
│   ├── rules/
│   │   └── rul-capacity-constraints.md
│   ├── knowledge-base/
│   │   └── kno-team-okrs.md
│   └── hooks/
│       └── hok-sprint-close.md
├── .claude/
├── process-overview.md
└── CLAUDE.md