| name | arch-lifecycle-delivery |
| description | Use when an architect must decide which architecture lifecycle stage to enter next, route to the correct stage methodology skill, and apply the merged lifecycle backbone as one coherent delivery chain rather than as separate old and new skill systems. |
| version | 1.2.0 |
| author | Architect Skill Pack |
| license | MIT |
| metadata | {"hermes":{"tags":["architect","lifecycle","routing","delivery","stage-gates"],"related_skills":["arch-lifecycle-demand-survey-methodology","arch-lifecycle-solution-design-methodology","arch-lifecycle-tech-overview-methodology","arch-lifecycle-tech-detailed-methodology","arch-lifecycle-deploy-ops-methodology","ddd-domain-modeling-for-architecture","design-patterns-and-refactoring"]}} |
Architect Lifecycle Delivery
Overview
This skill serves the architect role's lifecycle backbone and routing skill.
It now belongs entirely to the new arch-lifecycle-* system.
Its role is not to duplicate each stage methodology skill, but to:
- decide the correct lifecycle entry point
- keep stage boundaries clear
- preserve the integrated delivery-chain doctrine that gives the whole family coherence
Core principle:
architecture is a staged reduction of uncertainty, not one giant diagram and not a late cleanup after coding starts.
When to Use
Use when:
- the user asks for 架构方案、设计方案、概要设计、详细设计、技术方案、设计交付包, but the current stage is not yet explicit
- the architect must take work from 0 or from a midstream stage and choose the correct entry point
- the team is mixing business framing, solution design, overview design, detailed design, and deploy/ops handoff responsibilities together
- the architect needs one top-level delivery chain to coordinate survey, diagrams, risk, and handoff
Do not use when:
- the current stage is already explicit and the correct methodology skill can be loaded directly
- the main question is a cross-stage specialist judgment such as DDD boundary modeling or code-structure refactoring rather than lifecycle routing
Lifecycle Family Map
Primary methodology skills:
arch-lifecycle-demand-survey-methodologyarch-lifecycle-solution-design-methodologyarch-lifecycle-tech-overview-methodologyarch-lifecycle-tech-detailed-methodologyarch-lifecycle-deploy-ops-methodology
Recurring companion skills worth keeping separate:
arch-lifecycle-solution-design-biz-arch-diagrammingarch-lifecycle-tech-overview-functional-arch-diagrammingarch-lifecycle-tech-overview-system-arch-diagrammingarch-lifecycle-tech-detailed-technical-arch-diagrammingarch-lifecycle-tech-detailed-core-flow-diagrammingarch-lifecycle-deploy-ops-deployment-arch-diagramming
Cross-stage specialists that stay outside the main lifecycle chain:
ddd-domain-modeling-for-architecturedesign-patterns-and-refactoring
Stage Routing Rules
- from vague需求 →
arch-lifecycle-demand-survey-methodology
- from confirmed调研 →
arch-lifecycle-solution-design-methodology
- from confirmed解决方案 →
arch-lifecycle-tech-overview-methodology
- from confirmed概要设计 →
arch-lifecycle-tech-detailed-methodology
- from confirmed详细设计 →
arch-lifecycle-deploy-ops-methodology
Integrated Delivery Backbone
1. Frame the problem before drawing architecture
First answer:
- who is asking
- what current problem exists
- what target result is expected
- what success metric or ROI matters
- what is out of scope
Minimum output:
- current state
- desired state
- key constraints
- main trade-off axis
If you cannot state the problem in result terms, do not proceed to architecture diagrams yet.
2. Survey mature solutions before inventing one
Inspect, at minimum:
- similar open-source systems
- mature product patterns
- industry-standard architecture practices
Look beyond README-level marketing. Inspect:
- capabilities
- interfaces / configuration surfaces
- boundaries and constraints
- runtime requirements
- extension points
- known limitations
For each serious candidate, classify the path:
- direct adoption
- adaptation / secondary development
- interface-level borrowing
- deliberate rejection
Minimum output:
- surveyed references
- reuse judgment per reference
- why the recommended path wins
3. Produce the solution-design layer
This is the business / mid-layer design, not the code-level design.
It should answer:
- what business flow is being changed
- what roles / actors exist
- what domain objects or major conceptual boundaries exist
- what the end-to-end solution shape is
- what milestones, rollout constraints, and first-order risks matter
Typical artifacts:
- business flow diagram
- domain boundary sketch
- solution architecture diagram
- milestone / rollout outline
- first-order risk list
Rule:
solution design explains how the problem will be solved operationally, not yet how every component is implemented.
4. Produce the technical-design layer
This is where solution intent becomes implementable architecture.
At minimum, cover:
- overview / context
- terminology
- design goals
- alternatives and evaluation
- system decomposition
- technical architecture
- key flows / states / sequences
- data structures and persistence
- external interfaces
- non-functional requirements
- known risks
For non-trivial systems, include 1-2 clearly different alternatives.
Evaluate them across weighted criteria such as:
- performance
- reliability
- complexity
- operability
- delivery speed
- cost
- extensibility
Do not present a single path as inevitable unless the constraints truly collapse the search space.
5. Produce deployment / operations handoff
Architecture is not finished when the design doc stops.
At minimum, hand off:
- physical topology / deployment shape
- network and dependency assumptions
- deployment SOP
- operations SOP
- monitoring / alerting expectations
- backup / recovery expectations
- rollback / failure-path handling
- ownership and escalation path
If the design has no run-stage handoff, it is still incomplete.
Diagram Responsibility Map
Use different diagrams for different questions.
- Business flow: which actors, steps, and handoffs make up the end-to-end path?
- Domain model / boundary sketch: what major conceptual objects and boundaries matter?
- Solution architecture: what are the major solution blocks and their relationships?
- Functional architecture: how are capabilities layered?
- System architecture: what subsystems, dependencies, and communications exist?
- Technical architecture: which concrete stacks, engines, middleware, and execution paths realize the system?
- State / sequence / flow: how does one key run branch, retry, fail, and end?
- ER / data model: what persistent structures and relationships must exist?
- Physical / deployment view: where does the system run and how is it connected?
Boundary and Review Rules
- Different diagrams answer different questions and should not be collapsed into one picture.
- If one diagram only repeats another, merge or drop it.
- If one unresolved question requires a different concern boundary, add the missing view.
- If a stakeholder disagreement is really about runtime, data, ownership, or deployment shape, do not hide it inside a generic overall-architecture picture.
- Risk should change structure choices early, not appear only in QA or operations appendices.
Common Pitfalls
-
Using this skill as a substitute for the stage methodology skills.
It is the backbone, not the full per-stage doctrine source.
-
Jumping from vague demand directly into coding or detailed design.
-
Letting one architecture artifact swallow all neighboring artifact responsibilities.
Verification Checklist
