skills.rest
guardiatechnology
guardiatechnologyOFFICIAL
Explore all skills by this author →
WebsiteGitHub

kata-architecture-brief

Map affected components and create proposed ADRs for issue-phase architecture briefs.

Updated Sep 3, 2025
Search Tags:#architecture#documentation#api design#adr#issue-driven#event design#scope mapping
One-click install
npx skills add https://github.com/guardiatechnology/design-system --skill kata-architecture-brief
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: kata-architecture-brief
Source: https://github.com/guardiatechnology/design-system/tree/main/.claude/skills/kata-architecture-brief
Command: npx skills add https://github.com/guardiatechnology/design-system --skill kata-architecture-brief

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill helps teams avoid vague architecture work by transforming an issue brief into a precise, reviewable architecture scope that maps impacted components and drives consistent decision-making.

Core Features & Use Cases

  • Affected component mapping: Identify which modules, contracts, specs, and events will change and consolidate them into a binding scope table.
  • Technical approach and architecture planning: Define the main flow, alternative/error/idempotency/retry flows, persistence needs, integrations, and observability.
  • Decision quality with ADR delegation: Determine which items require ADRs, delegate API/event design to specialist warriors when applicable, and generate proposed ADRs and the phase architecture document.

Quick Start

Use kata-architecture-brief to read phases 1 and 2 under .ahrena/issues/{n}/, then produce .ahrena/issues/{n}/03-architecture.md with the mapped scope, approach, specialist delegation references, and proposed ADRs.

Frequently Asked Questions about kata-architecture-brief

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I map affected components for an issue-driven architecture brief?▼

To map affected components for an architecture brief, identify changed modules, contracts, specs, and events, then consolidate them into a binding component table to enforce scope creep control.

What is the best way to document architectural decisions tied to an issue scope?▼

The best way to document architectural decisions is generating proposed ADRs tied to the architecture, persisted to docs/adr/ADR-* with proposed status, ensuring decisions are reviewable alongside the issue scope.

How do I define technical approach and error flows for REST API design?▼

Defining technical approach for REST API design requires specifying main, alternative, error, idempotency, and retry flows by coordinating specialist delegation to ensure comprehensive architecture planning.

Does this architecture documentation approach support CloudEvents event design?▼

Yes, this architecture documentation approach supports CloudEvents event design by coordinating specialist delegation for event design, ensuring event scope boundaries integrate into the architecture brief.

When do I need an architecture brief with a binding component table?▼

You need an architecture brief with a binding component table when executing issue-driven workflow Phase 3 tasks to identify scope boundaries, coordinate specialist delegation, and update workflow checkpoints for human approval.

Related Skills

Explore More Software Engineering Skills→
guardiatechnologyguardiatechnology

kata-requirements-brief

Convert Phase 1 issue briefs into numbered acceptance criteria and Definition of Done.

Official
Intermediate
JhabbigJhabbig

workflow-patterns

Coordinates TDD workflow execution and phase checkpoint management for Conductor-based implementation tasks.

Community
Advanced
duc01226duc01226

design-system

Generate design tokens and slide templates from a three-layer token architecture.

Community
Advanced
CarlosQ96CarlosQ96

create-control-manifest

Generate a flat control manifest from Accepted ADRs and technical preferences.

Community
Advanced