New: 97,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Official agent skill

Deep Modules

by aws-samples in aws-samples/sample-multi-agent-orchestration-chat-on-agentcore

Apply Ousterhout's "deep modules" principle (narrow interface, deep implementation) when designing or refactoring classes and modules.

OfficialMIT-0Auto-check passedDevelopment

Install Deep Modules

skills CLI
$ npx skills add aws-samples/sample-multi-agent-orchestration-chat-on-agentcore --skill deep-modules -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install aws-samples/sample-multi-agent-orchestration-chat-on-agentcore deep-modules --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/aws-samples/sample-multi-agent-orchestration-chat-on-agentcore.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.agents/skills/deep-modules .claude/skills/deep-modules && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
deep-modules
GitHub stars
130
Token cost
~1.8k tokens
SKILL.md length
953 words
Files
1
Skills in repo
5
Repo updated
First seen
Licence
MIT-0

At a glance

Apply Ousterhout's "deep modules" principle (narrow interface, deep implementation) when designing or refactoring classes and modules.

  • Works in 4 steps: Small surface area. Field-level partial… → Stable signature under change. Adding a… → No leaking internals. Storage keys, SDK… → …
  • Adding new methods to a class
  • SKILL.md covers When to Apply, Decision Heuristics, The 4 Pillars and Anti-Patterns, plus 3 more sections
  • Instructions only: no scripts, shell commands, URLs or credentials in SKILL.md

What it does

Deep Modules is an agent skill from aws-samples/sample-multi-agent-orchestration-chat-on-agentcore, published by the product's own GitHub organization. Apply Ousterhout's "deep modules" principle (narrow interface, deep implementation) when designing or refactoring classes and modules. Use when adding new methods to a class, extracting shared logic, or reviewing repository / service code.

Its SKILL.md is about 1.8k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts.

It sits in Development, covering Refactoring. The repository describes itself as: Build & Share AI agents with your team. Full AgentCore, Full Serverless, Full TypeScript Sample. The licence is MIT-0.

When your agent uses it

  • Adding new methods to a class
  • Extracting shared logic
  • Reviewing repository / service code

Example prompts

  • “deep modules”
  • “/deep-modules”

Workflow steps

4 steps, taken from the first numbered list in SKILL.md.

  1. Small surface area. Field-level partial updates collapse into one update(id, patch).
  2. Stable signature under change. Adding a new updatable field or option must not break existing callers — favor patch / options objects over…
  3. No leaking internals. Storage keys, SDK types, SQL columns, and partition keys stay private. Public types describe the domain, not the…
  4. Single locus for cross-cutting policy. Logging, retry, idempotency, "tolerate missing", and error-mapping live in one private helper, not…

What it can do on your machine

Read from SKILL.md and the folder at commit 297d9c9. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md.

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Deep Modules loads about 1.8k tokens when it runs. Until then it costs about 63 tokens; SKILL.md has 953 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~63
When it runs · the whole SKILL.md, loaded when a task matches
~1.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from aws-samples/sample-multi-agent-orchestration-chat-on-agentcore at commit 297d9c9, republished under its MIT-0 licence (© aws-samples). 953 words, ~1,830 tokens.

Download SKILL.mdSave it as .claude/skills/deep-modules/SKILL.md (or your agent's skills folder).
name
deep-modules
description
Apply Ousterhout's "deep modules" principle (narrow interface, deep implementation) when designing or refactoring classes and modules. Use when adding new methods to a class, extracting shared logic, or reviewing repository / service code.

Deep Modules — Narrow Interface, Deep Implementation

A deep module hides a lot of complexity behind a small public surface. Cost of a module ≈ interface_complexity / functionality. Optimize for fewer public methods, stable signatures, and policy concentrated in one place — not for fewer lines per file.

This skill is language- and project-agnostic design guidance. Moca-specific conventions live in coding-style (e.g. nanoid vs uuid, ESM .js extensions). Use both together.

When to Apply

  • DO: repositories, services, data-access layers, reusable utilities, tool definitions.
  • DO NOT (blindly):
    • Express route handlers — declarative, thin handlers are easier to read than "deep" ones.
    • React components — prop count is a separate concern (split with hooks, not by hiding state).
    • Test files — explicitness usually beats deduplication.

Decision Heuristics

Use this table during design and code review. If two or more rows match, the module is probably too shallow.

SmellDiagnostic QuestionLikely Fix
Method names enumerate fields (updateXxxAndYyy, setStatus, setTitle)Does the caller need to know the storage schema to pick a method?Collapse to update(id, patch) with an optional-fields object
Same try / catch + error-name branch repeated 3+ timesIs this a policy (e.g. "tolerate missing") or a per-call decision?Extract a private wrapper; each public method becomes one line
Public method takes 4+ args, several optionalDo callers pass undefined to skip args?Take an options object; drop unused fields entirely
Return value exposes internal identifiers (partition key, sequence number, marshalled item)Does any caller actually use them?Return a DTO; do not leak storage shape
Each method calls marshall / unmarshall (or equivalent serialization) directlyIs the conversion the same in every method?Extract toItem / fromItem private mappers
fromItem deletes a denylist of storage keys (PK / SK / GSI*) before returningIs the strip-list maintained separately from the list of keys toItem adds?Project onto a domain-field allowlist instead — anything not named is dropped by construction, so a new index key can never leak
Module has 6+ public methods that share one nounCan you describe what the module does in one sentence?Merge methods, or split into two modules with different nouns

The 4 Pillars

A deep module has all four:

  1. Small surface area. Field-level partial updates collapse into one update(id, patch).
  2. Stable signature under change. Adding a new updatable field or option must not break existing callers — favor patch / options objects over positional args.
  3. No leaking internals. Storage keys, SDK types, SQL columns, and partition keys stay private. Public types describe the domain, not the table. The storage→domain mapper should select the domain fields (allowlist), not strip known storage keys (denylist): a denylist must be kept in sync with whatever the write path adds, and the day they drift an internal key leaks silently.
  4. Single locus for cross-cutting policy. Logging, retry, idempotency, "tolerate missing", and error-mapping live in one private helper, not duplicated per method.

Anti-Patterns

  • Pass-through method — service.updateTitle() only delegates to repo.updateTitle(). If the wrapper adds nothing, lift the call to the next layer up.
  • Method-per-field — setName / setStatus / setDescription siblings. Use one update(id, patch).
  • Over-decomposed helpers — splitting a 30-line module across 5 files. Depth is measured by narrowness of public API, not by file count. (Distinct from splitting to narrow the public surface — separating contract from implementation behind one entry point is fine; what's discouraged is fragmenting the logic.)
  • Premature interface extraction — declaring a TypeScript interface for a class with one implementation and one caller. Wait for the second caller.
  • Leaky DTOs — returning the storage row (with PK / SK / GSI columns) from a public method "for convenience". Once exposed, removal becomes a breaking change.
Show full SKILL.md (362 more words)Show less

If You Do Extract an Interface

The default is still "don't" — wait for the second implementation or a mocking seam (see the anti-pattern above). But when you extract one deliberately (e.g. to publish a reference contract ahead of need), keep the interface narrow by separating contract from implementation:

  • The contract — the interface plus the types its methods take and return — is the only thing a caller reads. Place the method input/output types with the interface, not in the shared model file: they only mean something next to the method they feed.
  • The data model (what the entity is) stays separate from the operation types (how you act on it). Dependencies point one way: implementation → contract → model.
  • Expose one entry point (a barrel) and let only the composition root construct the concrete implementation. Callers depend on the interface; nobody else names the class.
  • This is the one case where adding files reduces interface complexity — it is not the over-decomposition the anti-pattern warns about, because it narrows the public surface rather than fragmenting logic.

Self-Check Before Adding a Public Method

Ask, in order:

  1. Can an existing method absorb this with one extra option / patch field?
  2. Does the proposed method name encode internal schema (field names, table columns, SDK verbs)?
  3. If the next similar requirement arrives, will it add a 7th, 8th, 9th method?
  4. What can be made private to keep the public surface stable across the next change?

If any answer is "yes" to (1)–(3), redesign before adding the method.

Example (Moca)

packages/agent/src/repositories/sessions-repository.ts originally exposed 6 public methods, three of which are partial-update variants:

exists / get / create
updateSessionTimestamp / updateSessionAgentAndStorage / updateSessionTitle

Caller has to pick the right method based on which DynamoDB attributes are being touched — i.e. the public API encodes the storage schema.

A deep version:

exists / get / create / update(sessionId, patch)

with private helpers concentrating cross-cutting concerns:

  • key(sessionId) — single source of { userId: pk, sessionId } marshalling.
  • tolerateMissing(label, fn) — one place that maps ConditionalCheckFailedException to a warn-and-skip.
  • buildUpdate(patch) — pure function turning a SessionPatch into UpdateExpression + ExpressionAttributeValues, always stamping updatedAt.
  • toItem / fromItem — the only places that touch marshall / unmarshall.

The composition layer (sessions-service.ts) keeps its userId-first public contract; only its internal calls switch from repo.updateSessionTitle(...) to repo.update(id, { title }). Surface for downstream callers is unchanged.

© aws-samples, MIT-0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in .agents/skills/deep-modules of aws-samples/sample-multi-agent-orchestration-chat-on-agentcore.

Open the folder on GitHubat commit 297d9c9

Compare with similar skills

Deep Modules next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Deep Modules compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Deep Modules this skillaws-samples/sample-multi-agent-orchestration-chat-on-agentcore130—~1.8kAutomated safety check: PassMIT-0
Guidelinesakash-network/node1.1k22 repos~577Automated safety check: PassMIT
Component Refactoringlangflow-ai/langflow156k—~3.5kAutomated safety check: PassMIT
Migrate Core Code to Submodulestinyhumansai/openhuman41k—~2.6kAutomated safety check: PassGPL-3.0
ast-grep Structural Searchcode-yeongyu/oh-my-openagent70k—~3.3kAutomated safety check: PassMIT
Systematic Code Refactoringluongnv89/claude-howto42k—~3kAutomated safety check: PassMIT

Similar skills

  • Guidelines

    akash-network/node

    Behavioral guidelines to reduce common LLM coding mistakes. An agent skill from akash-network/node.

    1.1k GitHub starsUsed in 22 repos~577 tokens
    DevelopmentAuto-check passed

  • Component Refactoring

    langflow-ai/langflow

    Refactor high-complexity React components in Langflow frontend.

    156k GitHub stars~3.5k tokensUpdated today
    DevelopmentAuto-check passed

  • Migrate Core Code to Submodules

    tinyhumansai/openhuman

    Plans and carries out moving non-host-specific code and its tests from the OpenHuman core into vendored tiny submodule libraries, then releases the submodule and re-pins the host.

    41k GitHub stars~2.6k tokensUpdated today
    DevelopmentAuto-check passed

  • ast-grep Structural Search

    code-yeongyu/oh-my-openagent

    Searches and rewrites code by syntax-tree shape across 25 languages with ast-grep, for codemods, structural queries and YAML lint rules, using a Python wrapper script.

    70k GitHub stars~3.3k tokensUpdated today
    DevelopmentAuto-check passed

  • Systematic Code Refactoring

    luongnv89/claude-howto

    Guides refactoring in phases based on Martin Fowler's method: research, test coverage check, planning and small tested steps, with your approval at each phase.

    42k GitHub stars~3k tokensUpdated 7 days ago
    DevelopmentAuto-check passed

  • Codex

    skills-directory/skill-codex

    A skill your agent uses when the user asks to run Codex CLI (codex exec, codex resume) or references OpenAI Codex for code analysis, refactoring, or automated editing

    1.5k GitHub starsUsed in 3 repos~1.8k tokens
    DevelopmentAuto-check passed

More from aws-samples/sample-multi-agent-orchestration-chat-on-agentcore

  • Moca Guide

    aws-samples/sample-multi-agent-orchestration-chat-on-agentcore

    Official

    How to use Moca itself — what this platform can do and how to ask for it.

    130 GitHub stars~794 tokensUpdated today
    Auto-check passed

  • Doc Drift Detection

    aws-samples/sample-multi-agent-orchestration-chat-on-agentcore

    Official

    Detect semantic drift between documentation and source code.

    130 GitHub stars~714 tokensUpdated today
    Auto-check passed

  • UI Design

    aws-samples/sample-multi-agent-orchestration-chat-on-agentcore

    Official

    UI/UX design rules, Atomic Design placement, design tokens, component conventions, and responsive patterns for the Moca frontend.

    130 GitHub stars~1.5k tokensUpdated today
    Auto-check passed

  • Coding Style

    aws-samples/sample-multi-agent-orchestration-chat-on-agentcore

    Official

    Design decisions, implicit rules, and anti-patterns for the Moca project.

    130 GitHub stars~1.2k tokensUpdated today
    Auto-check passed

Categories

Questions about Deep Modules

What does Deep Modules do?

Apply Ousterhout's "deep modules" principle (narrow interface, deep implementation) when designing or refactoring classes and modules. Deep Modules is an agent skill from aws-samples/sample-multi-agent-orchestration-chat-on-agentcore, published by the product's own GitHub organization. Apply Ousterhout's "deep modules" principle (narrow interface, deep implementation) when designing or refactoring classes and modules.

When should I use Deep Modules?

Deep Modules fits situations like: adding new methods to a class; extracting shared logic; reviewing repository / service code.

How do I install Deep Modules in Claude Code?

Run `npx skills add aws-samples/sample-multi-agent-orchestration-chat-on-agentcore --skill deep-modules -a claude-code`. Or copy the skill folder (.agents/skills/deep-modules in aws-samples/sample-multi-agent-orchestration-chat-on-agentcore) into .claude/skills/deep-modules in your project. Claude Code loads it when a task matches its description.

How do I install Deep Modules in Codex?

Run `npx skills add aws-samples/sample-multi-agent-orchestration-chat-on-agentcore --skill deep-modules -a codex`. Or copy the skill folder (.agents/skills/deep-modules in aws-samples/sample-multi-agent-orchestration-chat-on-agentcore) into .agents/skills/deep-modules in your project. Codex loads it when a task matches its description.

Can I use Deep Modules in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add aws-samples/sample-multi-agent-orchestration-chat-on-agentcore --skill deep-modules -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/deep-modules, .gemini/skills/deep-modules, .github/skills/deep-modules and .opencode/skills/deep-modules in your project.

What does Deep Modules need to run?

SKILL.md names no scripts, command-line tools or credentials: Deep Modules is instructions for the agent only.

Does Deep Modules access the network?

SKILL.md contains no URLs. Any network use would come from the scripts or tools the agent runs. This is read from the text; nothing was executed.

Is Deep Modules safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Deep Modules use?

Deep Modules is published under the MIT-0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Deep Modules use?

About 1.8k tokens (SKILL.md is roughly 7.3k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Deep Modules?

Skills that share tags, products or a category with Deep Modules: Guidelines (akash-network/node, 1.1k stars), Component Refactoring (langflow-ai/langflow, 156k stars), Migrate Core Code to Submodules (tinyhumansai/openhuman, 41k stars) and ast-grep Structural Search (code-yeongyu/oh-my-openagent, 70k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Deep Modules?

aws-samples (a GitHub organization, an official publisher) maintains it in aws-samples/sample-multi-agent-orchestration-chat-on-agentcore, which has 130 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on October 6, 2026.

Source: aws-samples/sample-multi-agent-orchestration-chat-on-agentcore on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.