define-architectural-drivers
Skill4 starsChanged 3 months agoMITView on GitHub
WHEN/WHERE/WHO: [Scheduling: System analysts or architects analyzing raw product requirements before design begins.] HOW: [Structural: Use this SKILL to extract and formalize unstructured requirements into the four types of architectural drivers.] WHY: [Scheduling: Architecture cannot be designed without clear constraints and prioritized quality attribute scenarios.]
In this repository61 other files it gives its agents.
- activate-personalSkill
- analyze-with-tactics-questionnairesSkill
- apply-agile-testing-quadrantsSkill
- apply-architectural-tacticsSkill
- apply-attribute-driven-designSkill
- apply-fundamentals-of-data-visualizationSkill
- apply-oopsi-modelSkill
- apply-screenplay-patternSkill
- apply-specification-by-exampleSkill
- blog-topic-discoverSkill
- build-agent-memory-systemsSkill
- build-business-objectives-modelSkill
- build-data-dictionarySkill
- build-feature-treeSkill
- comment-alive-test-driven-developmentSkill
- conduct-event-stormingSkill
- create-ecosystem-mapSkill
- create-living-documentationSkill
- create-skill-from-bookSkill
- CREATING-SKILL-TEMPLATESkill
- define-bounded-contextsSkill
- define-ubiquitous-languageSkill
- design-agentic-screenplay-modelSkill
- design-agent-perception-layersSkill
- design-agent-planningSkill
- design-agent-reward-functionsSkill
- design-agents-using-patternsSkill
- design-architecture-viewpointsSkill
- design-autonomous-ai-interfacesSkill
- design-ddd-aggregatesSkill
- design-tool-use-sandboxingSkill
- document-architectural-decisionsSkill
- document-legacy-codebaseSkill
- doc-with-usage-exampleSkill
- draft-srs-documentSkill
- elicit-requirements-modelsSkill
- evolve-skill-with-wikiSkill
- extract-business-rulesSkill
- facilitate-example-mappingSkill
- facilitate-user-story-mappingSkill
- implement-agent-observabilitySkill
- implement-agent-reflectionSkill
- improve-existing-skillSkill
- improve-user-storySkill
- managing-ai-projectsSkill
- orchestrate-multi-agent-collaborationSkill
- prioritize-requirementsSkill
- review-c4-modelSkill
- review-data-engineeringSkill
- save-as-skillSkill
- scaffold-cmake-cxx-sanitize-gtest-envSkill
- skill-commonSkill
- task-commit-triggerSkill
- test-case-with-demoSkill
- test-case-with-readmeSkill
- test-driven-developmentSkill
- UnitTesting-convert2CaTDDSkill
- update-my-resumeSkill
- update-spec-contextSkill
- validate-requirements-criteriaSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
8 rules. About 0 are common, 8 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 13
When this skill is activated, first load skill-common and apply the shared conventions it defines: canonical section order, frontmatter …
- Distinctive: line 28
If an architect tries to design a system based purely on "it needs to be fast and secure," the resulting architecture will be flawed.
- Distinctive: line 43
Transfer Check: Verify the workflow still works for both greenfield architecture design and legacy-extension planning.
- Distinctive: line 44
Stop Rule: If the inputs cannot support measurable response measures, stop and ask for explicit targets before drafting the drivers …
- Distinctive: line 47
Do not invent drivers; infer them only from the provided inputs.
- Distinctive: line 51
If the input lacks sufficient detail to create testable response measures (e.g., "fast"), stop and ask the user to provide specific SLA …
- Distinctive: line 82
Verify that at least one Quality Attribute Scenario is defined.
- Distinctive: line 83
Ensure that every scenario has a quantifiable "Response Measure".
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Define Architectural Drivers
Common Contract (Load First)
When this skill is activated, first load skill-common and apply the shared conventions it defines: canonical section order, frontmatter rules, anti-pattern guidance, and the Review In Mind loop in review-in-mind. This skill adds only domain-specific rules below.
Who
System analysts, product owners, and architects. The agent uses this skill to translate business language into architectural constraints.
What
This skill extracts and formalizes unstructured product requirements into strict Architectural Drivers. It outputs a structured document detailing Design Purpose, Quality Attribute Scenarios, Primary Functionality, and Architectural Concerns.
When
Invoke this skill at the very beginning of a project, before any architectural design (ADD 3.0) occurs. Trigger phrases include: "extract drivers," "formalize requirements," "write quality attribute scenarios," or "prepare for architecture design."
Where
Applies to raw Product Requirements Documents (PRDs), user story backlogs, and stakeholder interview transcripts.
Why
If an architect tries to design a system based purely on "it needs to be fast and secure," the resulting architecture will be flawed. This skill forces those vague requirements into testable Quality Attribute Scenarios (e.g., "Under peak load, 99% of requests complete in <200ms").
Inputs
- Raw requirements documents (PRD, user stories).
- Business goals.
Output (Logical Evidence)
- A completed Architectural Drivers Document.
Optimization Readiness
- Failure Signals: Drivers are invented instead of inferred, quality attributes stay vague, response measures remain untestable, or prioritization is disconnected from business risk.
- Evidence To Collect: Source requirements, extracted driver lists, quality attribute scenarios, prioritization rationale, and reviewer feedback on missing or ambiguous drivers.
- Safe Mutation Boundaries: Refine extraction prompts, scenario templates, and prioritization guidance without changing the core requirement to derive measurable drivers from provided inputs.
- Acceptance Criteria: Accept revisions only if the skill produces explicit drivers, formal quality attribute scenarios with measurable response measures, and a ranking tied to business value or architectural risk.
- Rejected Revision Handling: Record weak scenario phrasings, invented constraints, and non-measurable driver patterns so they are not reused blindly.
- Transfer Check: Verify the workflow still works for both greenfield architecture design and legacy-extension planning.
- Stop Rule: If the inputs cannot support measurable response measures, stop and ask for explicit targets before drafting the drivers document.
Constraints (Logical Boundaries)
- Do not invent drivers; infer them only from the provided inputs.
- Quality Attributes must be written as 6-part scenarios (Source, Stimulus, Artifact, Environment, Response, Response Measure).
One More Thing
If the input lacks sufficient detail to create testable response measures (e.g., "fast"), stop and ask the user to provide specific SLA targets.
How (Structural Workflow)
Phase 1: Context Extraction
- Extract the Design Purpose: Why are we designing this architecture? (e.g., greenfield project, extending a legacy system, improving performance).
- Extract the Primary Functionality: Identify the top 3-5 core use cases the system must support.
Phase 2: Constraint and Concern Identification
- Identify Constraints: List technical, business, and timeline limitations (e.g., "Must use AWS," "Must launch by Q3").
- Identify Architectural Concerns: Note internal technical goals (e.g., "Establish a CI/CD pipeline," "Use microservices").
Phase 3: Formalizing Quality Attributes
- Scan for non-functional requirements (speed, safety, uptime, adaptability).
- Convert vague statements into formal Quality Attribute Scenarios. Each scenario must have a measurable response.
Phase 4: Prioritization
- Rank the scenarios and use cases based on business value and architectural risk.
Resources
- Driver Extraction Template
Review In Mind (ReviewInMindGenie)
Execute the common review loop in review-in-mind before delivering.
Review lens for this skill:
- Are the four driver types (design purpose, QAS, functionality, concerns) explicitly separated?
- Is each quality attribute scenario measurable with stimulus/response/measure?
- Are implicit drivers in the raw text surfaced, not dropped?
Validation
- Verify that at least one Quality Attribute Scenario is defined.
- Ensure that every scenario has a quantifiable "Response Measure".
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.