How do I install the Sac Design With skill?

Run npx skillmds@latest add spillwavesolutions/sac-design-with in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Sac Design With safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Sac Design With?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Sac Design With free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Sac Design With?

spillwavesolutions (@spillwavesolutions) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Sac Design With by spillwavesolutions

Name: Sac Design With
Author: spillwavesolutions

Sac Design With

Use the SAC architecture second brain when designing new features, services, APIs, mobile apps, web apps, or infra. Loads progressive-disclosure packs (blast radius, contracts, deps, environments) so design work reuses existing topology instead of inventing in a vacuum. Trigger on design, new service, new API, new feature, architecture impact, or "how should we build".

File contents

Design with the Architecture Second Brain

SAC is not only for reverse-engineering. After the second brain exists, use it as the default context when proposing:

New features / product slices
New services or packages
New APIs / contracts
New web or mobile clients
New pipelines, environments, or infra

Process

Locate the bundle
Prefer knowledge/ in the target repo (or path the user names).
Name the design intent
One sentence: what is new and where it attaches (domain, client, backend).
Retrieve a context card (do not run search/pack in this parent):

Spawn architecture-retriever via skill sac-retrieve. Pass the design intent as the query, an optional seed service/API path, and the bundle. Consume only the retrieval card. If the card says deepen-2hop or blast-radius, spawn the retriever again — do not run sac_pack.py / sac_search.py / sac_blast_radius.py here.

Project-memory (meetings, decisions, features) is an orthogonal fan-out to PKC knowledge-retriever.
Answer before inventing (use pack + concepts):
- Which System / Service / Package already owns this domain?
- What ApiContracts exist? Extend vs new surface?
- What Database / Cache / ObjectStorage / SearchIndex / Event surfaces would be touched?
- Auth: existing IdentityProvider / IamRole patterns?
- Deploy: which Environment / Pipeline / InfrastructureStack?
- Ownership and GlossaryTerm for naming and team?
Propose the design grounded in the graph:
- Author or update diagrams (sequence, component, ERD, wireframes) as Mermaid/PlantUML listings in diagram concepts.
- Name new Module / Class / Function concepts when the design adds code shape.
- Prefer extend/reuse edges (calls, exposes_api, depends_on_package) over greenfield silos.
- Call out blast radius (what breaks if the new thing fails or the shared API changes).
- List new OKF concepts to author after the design is accepted (Service, ApiContract, …).
- Optionally write a DecisionRecord under decisions/ once the choice is made.
Do not re-scan the whole monorepo unless the second brain is missing or stale — design from the knowledge graph first.

Output shape

## Design intent
…

## Existing landscape (from second brain)
- Services / packages / APIs touched
- Data & identity
- Deploy path

## Options
1. …
2. …

## Recommendation
…

## Blast radius
…

## Concepts to add/update after build
- …

Connectivity

Live wiki/ticket/cloud detail still comes from host skills/MCPs when needed; the second brain is the primary structured memory for what already exists.

---name: sac-design-withdescription: Use the SAC architecture second brain when designing new features, services, APIs, mobile apps, web apps, or infra. Loads progressive-disclosure packs (blast radius, contracts, deps, environments) so design work reuses existing topology instead of inventing in a vacuum. Trigger on design, new service, new API, new feature, architecture impact, or "how should we build".---# Design with the Architecture Second BrainSAC is not only for reverse-engineering. **After** the second brain exists, useit as the default context when proposing:- New features / product slices - New services or packages - New APIs / contracts - New web or mobile clients - New pipelines, environments, or infra ## Process1. **Locate the bundle** Prefer `knowledge/` in the target repo (or path the user names).2. **Name the design intent** One sentence: *what* is new and *where* it attaches (domain, client, backend).3. **Retrieve a context card** (do not run search/pack in this parent): Spawn **`architecture-retriever`** via skill `sac-retrieve`. Pass the design intent as the query, an optional seed service/API path, and the bundle. Consume **only** the retrieval card. If the card says `deepen-2hop` or `blast-radius`, spawn the retriever again — do not run `sac_pack.py` / `sac_search.py` / `sac_blast_radius.py` here. Project-memory (meetings, decisions, features) is an orthogonal fan-out to PKC `knowledge-retriever`.4. **Answer before inventing** (use pack + concepts): - Which **System / Service / Package** already owns this domain? - What **ApiContracts** exist? Extend vs new surface? - What **Database / Cache / ObjectStorage / SearchIndex / Event** surfaces would be touched? - Auth: existing **IdentityProvider / IamRole** patterns? - Deploy: which **Environment / Pipeline / InfrastructureStack**? - **Ownership** and **GlossaryTerm** for naming and team?5. **Propose the design** grounded in the graph: - Author or update **diagrams** (sequence, component, ERD, wireframes) as Mermaid/PlantUML listings in diagram concepts. - Name new **Module / Class / Function** concepts when the design adds code shape. - Prefer extend/reuse edges (`calls`, `exposes_api`, `depends_on_package`) over greenfield silos. - Call out blast radius (what breaks if the new thing fails or the shared API changes). - List **new OKF concepts** to author after the design is accepted (Service, ApiContract, …). - Optionally write a `DecisionRecord` under `decisions/` once the choice is made.6. **Do not** re-scan the whole monorepo unless the second brain is missing or stale — design from the knowledge graph first.## Output shape```markdown## Design intent…## Existing landscape (from second brain)- Services / packages / APIs touched- Data & identity- Deploy path## Options1. …2. …## Recommendation…## Blast radius…## Concepts to add/update after build- …```## ConnectivityLive wiki/ticket/cloud detail still comes from host **skills/MCPs** when needed;the second brain is the primary structured memory for *what already exists*.

Frequently asked questions