/decompose-architecture-aggregate
Use when a project has Architecture data that needs migrating to fine-grained entities (Decisions, Invariants, Components, Dependencies). Guides the agent through reading, mapping, confirming, and executing the migration with user oversight.
$ npx -y skills add jumbocontext/jumbo.cli --skill decompose-architecture-aggregate --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/decompose-architecture-aggregate
Context preview
The summary Claude sees to decide when to auto-load this skill.
Use when a project has Architecture data that needs migrating to fine-grained entities (Decisions, Invariants, Components, Dependencies). Guides the agent through reading, mapping, confirming, and executing the migration with user oversight.
SKILL.md
decompose-architecture-aggregate.SKILL.mdname: decompose-architecture-aggregate
description: Use when a project has Architecture data that needs migrating to fine-grained entities (Decisions, Invariants, Components, Dependencies). Guides the agent through reading, mapping, confirming, and executing the migration with user oversight.
Decompose Architecture Aggregate
Migrate Architecture entity data to fine-grained entities with user confirmation at each step.
The Architecture entity is deprecated. Its sections map to dedicated entity types as defined in `ARCHITECTURE_MIGRATION_MAPPING` (src/application/context/architecture/ArchitectureDeprecationConstants.ts):
| Architecture Section | Target Entity | Command | |---|---|---| | patterns | Decisions | `jumbo decision add` | | principles | Invariants | `jumbo invariant add` | | organization | Invariants | `jumbo invariant add` | | dataStores | Components | `jumbo component add` | | stack | Dependencies | `jumbo dependency add` |
Protocol
1. Read Current Architecture
jumbo architecture view
Parse the output. If no Architecture data exists, inform the user and stop.
2. Build Proposed Mappings
For each non-empty section in the Architecture view, build a mapping proposal:
- **patterns** — Each pattern becomes a Decision. Draft: `--title`, `--context` (use the pattern description), `--rationale` (why this pattern was chosen, if stated).
- **principles** — Each principle becomes an Invariant. Draft: `--title`, `--description` (the principle text), and `--rationale` if the source explains why the principle is non-negotiable.
- **organization** — Each organization entry becomes an Invariant. Draft: `--title`, `--description` (the organizational rule), and `--rationale` if the source explains why the rule is non-negotiable.
- **dataStores** — Each data store becomes a Component. Draft: `--name`, `--type` (select from: service, db, queue, ui, lib, api, worker, cache, storage), `--description`, `--responsibility`, `--path` (ask the user if not derivable from the data).
- **stack** — Each stack entry becomes a Dependency. Draft: `--name`, `--ecosystem` (e.g., npm, pip, maven, service), `--package-name`, `--version-constraint` (if known).
3. Present Mappings for User Confirmation
Present all proposed mappings to the user in a single summary, grouped by target entity type. For each proposed mapping, show:
- The source section and original data
- The target entity type
- The drafted command with all flags
Ask the user to confirm, adjust, skip, or augment each mapping. Do not execute any commands until the user has reviewed the full set.
4. Execute Confirmed Mappings
Execute each confirmed mapping one at a time using the appropriate `jumbo` command:
- `jumbo decision add --title "..." --context "..." [--rationale "..."] [--alternative "..."]`
- `jumbo invariant add --title "..." --description "..." [--rationale "..."]`
- `jumbo component add --name "..." --type "..." --description "..." --responsibility "..." --path "..."`
- `jumbo dependency add --name "..." --ecosystem "..." --package-name "..." [--version-constraint "..."]`
Report the result of each command (success or failure) before proceeding to the next.
5. Present Summary
After all confirmed mappings are processed, present a summary:
- Count of entities created per type (Decisions, Invariants, Components, Dependencies)
- List of skipped items and the reason (user chose to skip, or data was insufficient)
- Any errors encountered during execution
Read more
name: decompose-architecture-aggregate description: Use when a project has Architecture data that needs migrating to fine-grained entities (Decisions, Invariants, Components, Dependencies). Guides the agent through reading, mapping, confirming, and executing the migration with user oversight.
Decompose Architecture Aggregate
Migrate Architecture entity data to fine-grained entities with user confirmation at each step.
The Architecture entity is deprecated. Its sections map to dedicated entity types as defined in `ARCHITECTURE_MIGRATION_MAPPING` (src/application/context/architecture/ArchitectureDeprecationConstants.ts):
| Architecture Section | Target Entity | Command | |---|---|---| | patterns | Decisions | `jumbo decision add` | | principles | Invariants | `jumbo invariant add` | | organization | Invariants | `jumbo invariant add` | | dataStores | Components | `jumbo component add` | | stack | Dependencies | `jumbo dependency add` |
Protocol
1. Read Current Architecture
jumbo architecture view
Parse the output. If no Architecture data exists, inform the user and stop.
2. Build Proposed Mappings
For each non-empty section in the Architecture view, build a mapping proposal:
- **patterns** — Each pattern becomes a Decision. Draft: `--title`, `--context` (use the pattern description), `--rationale` (why this pattern was chosen, if stated).
- **principles** — Each principle becomes an Invariant. Draft: `--title`, `--description` (the principle text), and `--rationale` if the source explains why the principle is non-negotiable.
- **organization** — Each organization entry becomes an Invariant. Draft: `--title`, `--description` (the organizational rule), and `--rationale` if the source explains why the rule is non-negotiable.
- **dataStores** — Each data store becomes a Component. Draft: `--name`, `--type` (select from: service, db, queue, ui, lib, api, worker, cache, storage), `--description`, `--responsibility`, `--path` (ask the user if not derivable from the data).
- **stack** — Each stack entry becomes a Dependency. Draft: `--name`, `--ecosystem` (e.g., npm, pip, maven, service), `--package-name`, `--version-constraint` (if known).
3. Present Mappings for User Confirmation
Present all proposed mappings to the user in a single summary, grouped by target entity type. For each proposed mapping, show:
- The source section and original data
- The target entity type
- The drafted command with all flags
Ask the user to confirm, adjust, skip, or augment each mapping. Do not execute any commands until the user has reviewed the full set.
4. Execute Confirmed Mappings
Execute each confirmed mapping one at a time using the appropriate `jumbo` command:
- `jumbo decision add --title "..." --context "..." [--rationale "..."] [--alternative "..."]`
- `jumbo invariant add --title "..." --description "..." [--rationale "..."]`
- `jumbo component add --name "..." --type "..." --description "..." --responsibility "..." --path "..."`
- `jumbo dependency add --name "..." --ecosystem "..." --package-name "..." [--version-constraint "..."]`
Report the result of each command (success or failure) before proceeding to the next.
5. Present Summary
After all confirmed mappings are processed, present a summary:
- Count of entities created per type (Decisions, Invariants, Components, Dependencies)
- List of skipped items and the reason (user chose to skip, or data was insufficient)
- Any errors encountered during execution
Repo: jumbocontext/jumbo.cli
Other skills on jumbocli.
- /codify-jumbo-goal
Use when a Jumbo goal has been approved by QA review and needs architectural reconciliation before closing. Captures new learnings, updates stale entities, and ensures documentation reflects the work performed.
Open skill - /define-jumbo-goals
Add Jumbo goals liberally to decompose objectives into finite units of work with bounded context. Use when defining new Jumbo goals from user requests, or to augment your own work to maintain scope while ensuring complementary work is registered.
Open skill - /formalize-objectives
Use when the user's prompt is delivered outside the execution context of an existing Jumbo goal, the prompt is imbued with an objective that is not already defined as a Jumbo goal.
Open skill - /jumbo-add-component
Use liberally when you create, discover, or modify a software component. Registers the component with Jumbo so future sessions have accurate architectural context.
Open skill - /jumbo-add-decision
Use liberally when you make an architectural choice, select a technology, or reject an alternative. Records the decision so future sessions understand why the codebase looks the way it does.
Open skill - /jumbo-add-dependency
Use liberally when you introduce, discover, or upgrade a third-party package or external service. Registers the dependency so future sessions know what the project relies on.
Open skill

