architecture-readiness
Use this skill to create Product Owner Specifications documenting business requirements before architecture design
Best use case
architecture-readiness is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
Use this skill to create Product Owner Specifications documenting business requirements before architecture design
Teams using architecture-readiness should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/architecture-readiness/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How architecture-readiness Compares
| Feature / Agent | architecture-readiness | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
Use this skill to create Product Owner Specifications documenting business requirements before architecture design
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# Architecture Readiness Skill ## Description This skill helps Product Owners document business requirements and context before architecture design begins. It provides templates and guidance for creating Product Owner Specifications that feed into technical ARCHITECTURE.md documents. The skill includes two primary functions: 1. **PO Spec Creation**: Templates and guidance for documenting business requirements 2. **PO Spec Evaluation**: Scoring methodology to assess if a PO Spec is ready for architecture team handoff ## When to Use This Skill Invoke this skill when: - User asks to create a Product Owner Specification - User asks about documenting business requirements for architecture - User mentions "business context", "product requirements", or "requirements gathering" in relation to architecture - User wants to prepare business documentation before technical architecture design - User asks to evaluate or score a Product Owner Specification - User wants to know if their PO Spec is ready for the architecture team ## Files in This Skill - **PRODUCT_OWNER_SPEC_GUIDE.md**: Comprehensive guide with 8-section template, examples, and best practices - **templates/PO_SPEC_TEMPLATE.md**: Quick-start template for creating a new PO Specification - **PO_SPEC_SCORING_GUIDE.md**: Weighted scoring methodology to evaluate PO Spec readiness (0-10 scale) ## How to Use This Skill ### For PO Spec Creation When this skill is activated for document creation: 1. **Read the guide**: Load PRODUCT_OWNER_SPEC_GUIDE.md to understand the 8-section structure 2. **Understand user context**: Ask clarifying questions about their product/feature 3. **Provide appropriate template**: - For guidance and understanding: Reference PRODUCT_OWNER_SPEC_GUIDE.md - For quick start: Provide templates/PO_SPEC_TEMPLATE.md 4. **Guide document creation**: Help user fill out each section with business context 5. **Reference mapping**: Explain how PO Spec maps to ARCHITECTURE.md (see guide Section "Mapping to ARCHITECTURE.md") ### For PO Spec Evaluation When this skill is activated to evaluate a PO Spec: 1. **Read the scoring guide**: Load PO_SPEC_SCORING_GUIDE.md to understand the weighted scoring methodology 2. **Read the PO Spec**: Load the user's Product Owner Specification document 3. **Evaluate each section**: Assess completeness of all 8 sections using the evaluation criteria 4. **Calculate weighted score**: Apply section weights and compute total score (0-10 scale) 5. **Provide detailed feedback**: - Overall score and readiness interpretation - Section-by-section breakdown showing completeness % - Identify gaps in critical sections (Use Cases, Business Constraints, Business Objectives) - Provide actionable recommendations for improvement 6. **Determine readiness**: Score ≥7.5/10 indicates ready for architecture team handoff ## Key Principles - **Business-focused**: No technical details or architecture decisions in PO Spec - **User-centric**: Emphasize user needs, personas, and pain points - **Measurable**: All goals and success criteria must be quantifiable - **Constraint-aware**: Document all business constraints (budget, timeline, compliance) ## Integration with Other Skills **Relationship to architecture-docs skill:** - architecture-readiness (this skill) → Creates **business** requirements (PO Spec) - architecture-docs skill → Creates **technical** architecture (ARCHITECTURE.md) **Workflow:** 1. Product Owner uses architecture-readiness skill → Creates PO Spec 2. PO Spec handed off to architecture team 3. Architecture team uses architecture-docs skill → Creates ARCHITECTURE.md ## Example Invocations ### Example 1: Creating a PO Spec ``` User: "I want to create a Product Owner Specification for a new mobile payment feature" Claude (with architecture-readiness skill activated): 1. Load PRODUCT_OWNER_SPEC_GUIDE.md to understand structure 2. Ask clarifying questions: - What business problem does this solve? - Who are the target users? - What are the business objectives and success metrics? - Are there regulatory/compliance requirements? 3. Guide user through 8 sections: - Business Context - Stakeholders & Users - Business Objectives - Use Cases - User Stories - User Experience Requirements - Business Constraints - Success Metrics & KPIs 4. Provide template sections as needed 5. Explain how completed PO Spec feeds into ARCHITECTURE.md ``` ### Example 2: Evaluating a PO Spec ``` User: "Can you evaluate my Product Owner Spec and tell me if it's ready for the architecture team?" Claude (with architecture-readiness skill activated): 1. Load PO_SPEC_SCORING_GUIDE.md to understand scoring methodology 2. Read the user's PRODUCT_OWNER_SPEC.md file 3. Evaluate each section: - Section 1 (Business Context): 80% complete - Section 2 (Stakeholders): 60% complete - Section 3 (Business Objectives): 90% complete - Section 4 (Use Cases): 100% complete - Section 5 (User Stories): 70% complete - Section 6 (UX Requirements): 85% complete - Section 7 (Business Constraints): 95% complete - Section 8 (Success Metrics): 80% complete 4. Calculate weighted score: 8.85/10 5. Provide feedback: - "Your PO Spec scores 8.85/10 - Good, ready for architecture design" - "Excellent: Use Cases, Business Constraints, Business Objectives" - "Minor gaps: Stakeholders & Users section needs more detailed personas" - "Recommendation: Proceed with architecture design; clarify user personas during kickoff" ``` ## Common User Requests **PO Spec Creation:** - "Help me document business requirements" → Use PRODUCT_OWNER_SPEC_GUIDE.md - "I need a template for product specifications" → Provide templates/PO_SPEC_TEMPLATE.md - "How does this relate to the architecture document?" → Reference "Mapping to ARCHITECTURE.md" section in guide - "What should I include in use cases vs user stories?" → Reference Sections 4 and 5 of guide **PO Spec Evaluation:** - "Evaluate my PO Spec" → Use PO_SPEC_SCORING_GUIDE.md to score the document - "Is my PO Spec ready for the architecture team?" → Score and assess readiness (≥7.5/10) - "What's missing from my business requirements?" → Identify gaps using evaluation criteria - "How can I improve my PO Spec score?" → Provide actionable recommendations based on section weights ## Success Criteria ### For PO Spec Creation A well-formed Product Owner Specification should: - ✅ Have all 8 sections completed - ✅ Include specific, measurable success criteria - ✅ Define user personas with real pain points - ✅ Document all business constraints (budget, timeline, compliance) - ✅ Use business language (avoid technical jargon) - ✅ Map clearly to ARCHITECTURE.md inputs - ✅ Score ≥7.5/10 on the weighted scoring methodology ### For PO Spec Evaluation A quality evaluation should: - ✅ Assess all 8 sections using the evaluation criteria from PO_SPEC_SCORING_GUIDE.md - ✅ Calculate weighted score correctly (applying section weights) - ✅ Provide clear readiness determination (Ready ≥7.5/10, Not Ready <7.5/10) - ✅ Give specific, actionable feedback for each gap identified - ✅ Prioritize feedback on high-weight sections (Use Cases, Business Constraints, Business Objectives) - ✅ Explain what needs to be added/improved to reach readiness threshold
Related Skills
architecture-analysis
Comprehensive frontend architecture analyzer that identifies technology stacks, build tools, and architectural patterns. Use when you need to quickly understand a project's structure, dependencies, and technical configuration. Provides analysis for Vue/React/Angular frameworks, Node.js environments, package managers, TypeScript usage, linters, and architecture patterns with multiple output formats including executive summaries and visualizations.
adinsights-release-readiness
Synthesize ADinsights release readiness from router, scope, contract, docs, and optional validation checks. Use when deciding go/no-go readiness, release gate status, or pre-merge release risk.
triatu-architecture
Clean Architecture guidance for Triatu: layering, dependencies, and where code belongs. Use when adding new modules, moving code across layers, or updating architecture decisions and docs.
multi-cloud-architecture
Design multi-cloud architectures using a decision framework to select and integrate services across AWS, Azure, and GCP. Use when building multi-cloud systems, avoiding vendor lock-in, or leveragin...
gcp-architecture
Google Cloud Platform architecture patterns and best practices. Use when designing, deploying, or reviewing GCP infrastructure including GKE, Cloud Run, Cloud Functions, BigQuery, and IAM.
express-microservices-architecture
Complete guide for building scalable microservices with Express.js including middleware patterns, routing strategies, error handling, production architecture, and deployment best practices
codebase-architecture-analysis
Analyze a GitHub codebase to create comprehensive architecture documentation including ASCII diagrams, component relationships, data flow, hosting infrastructure, and file structure assessment.
architecture-specialist
提供系统架构设计、技术选型、架构审查和组件设计能力。当需要设计新系统、重构现有架构或进行架构审查时使用。
architecture-decision-records
Write and maintain Architecture Decision Records (ADRs) following best practices for technical decision documentation. Use when documenting significant technical decisions, reviewing past architectural choices, or establishing decision processes.
architecture-decision-record
ADR format and methodology for documenting significant technical decisions with context, alternatives considered, and consequences. Use when making or documenting architectural decisions.
alibaba-cloud-architecture
Alibaba Cloud architecture patterns and best practices. Use when designing, deploying, or reviewing infrastructure on Alibaba Cloud including ECS, ACK, Function Compute, and OSS.
Tech Stack & Architecture Decision
Define and document the technology stack and architecture decisions for a project. Use when the user needs to choose a tech stack, make architecture decisions, define infrastructure choices, or document technology selections. Triggers on requests like "define the tech stack", "choose technologies", "architecture decisions", "what stack should we use", or any request to select and document frontend, backend, database, auth, hosting, and infrastructure choices for a project.