draft-technical-approach

Convert a features specification into a DRAFT architecture.yaml with technology selections and prioritized NFRs.

3|Updated Jan 25, 2026
One-click install
npx skills add https://github.com/kapilvirenahuja/garura --skill draft-technical-approach
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: draft-technical-approach
Source: https://github.com/kapilvirenahuja/garura/tree/main/core/components/skills/draft-technical-approach
Command: npx skills add https://github.com/kapilvirenahuja/garura --skill draft-technical-approach

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Drafting an architecture from a features specification often stalls on ambiguous technology choices and missing, implementable constraints, slowing teams down before implementation can begin.

Core Features & Use Cases

  • Produce a concrete architecture.yaml artifact that names specific technologies, components, and rationale for each architectural component.
  • Derive non-functional requirements (NFRs) into a structured, prioritized nfrs section, optionally driven by profiles_ref (NFR Profile levels) for traceable decisions.
  • Incorporate existing knowledge when available by reading vision_path, product_yaml_path, and ltm_architecture_path to inform technology selection using matching “When to Choose/When to Avoid” patterns.

Quick Start

Use the draft-technical-approach skill to create architecture.yaml by converting your features.yaml into a DRAFT architecture blueprint at .garura/product/architecture/.

Frequently Asked Questions about draft-technical-approach

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

FAQPage Schema
How do I convert a features specification into a concrete architecture with technology selections?▼

You can convert a features specification into a concrete architecture by generating an architecture.yaml artifact that defines specific technologies, components, platforms, integrations, and prioritized non-functional requirements.

What is the best way to derive non-functional requirements for enterprise architecture?▼

Deriving non-functional requirements for enterprise architecture involves structuring prioritized NFRs from feature invariants, optionally using an NFR profile reference to ensure decisions are traceable and measurable.

How do I map deployment units and architectural components from a features.yaml file?▼

Mapping deployment units from a features.yaml file involves processing feature invariants and optional vision inputs to produce an architecture blueprint with explicit deployment unit mapping and measurable constraints.

Can I use existing product vision and long-term architecture knowledge to inform technology selection?▼

Yes, you can read existing vision paths, product yaml paths, and long-term memory architecture paths to inform technology selection by applying matching patterns for when to choose or avoid specific technologies.

What happens if my architecture.yaml artifact is already LOCKED?▼

If the architecture.yaml artifact is LOCKED, the system returns a structured failure and does not validate downstream, ensuring the draft status remains protected against unintended overwrites.

Does every architectural component in the generated blueprint need a rationale?▼

Yes, every requirement and architectural component in the generated blueprint must include explicit rationale to ensure technology decisions are justified and traceable within the enterprise delivery workflow.