claude-code-plugin-ref…
Explain plugin, skill, command, agent, and hook mechanics used here. Use when authoring or debugging plugins. Do not use for ops; use night-market-operations.
Build composable skill modules with hub-and-spoke loading. Use when token budget is tight.
$ npx -y skills add athola/claude-night-market --skill modular-skills --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/modular-skillsContext preview
The summary Claude sees to decide when to auto-load this skill.
Build composable skill modules with hub-and-spoke loading. Use when token budget is tight.
name: modular-skills description: 'Build composable skill modules with hub-and-spoke loading. Use when token budget is tight.' alwaysApply: false category: workflow-optimization tags: - architecture - modularity - tokens - skills - design-patterns - skill-design - token-optimization dependencies: [] tools: [] usage_patterns: - skill-design - architecture-review - token-optimization - refactoring-workflows complexity: intermediate model_hint: standard estimated_tokens: 1200 modules: - modules/antipatterns-and-migration.md - modules/core-workflow.md - modules/design-philosophy.md - modules/enforcement-patterns.md - modules/implementation-patterns.md - modules/optimization-techniques.md - modules/troubleshooting.md - modules/design-patterns.md
`abstract:skill-authoring`)
This framework breaks complex skills into focused modules to keep token usage predictable and avoid monolithic files. We use progressive disclosure: starting with essentials and loading deeper technical details via `@include` or `Load:` statements only when needed. This approach prevents hitting context limits during long-running tasks.
Modular design keeps file sizes within recommended limits, typically under 150 lines. Shallow dependencies and clear boundaries simplify testing and maintenance. The hub-and-spoke model allows the project to grow without bloating primary skill files, making focused modules easier to verify in isolation and faster to parse.
Three tools support modular skill development:
We design skills around single responsibility and loose coupling. Each module focuses on one task, minimizing dependencies to keep the architecture cohesive. Clear boundaries and well-defined interfaces prevent changes in one module from breaking others. This follows Anthropic's Agent Skills best practices: provide a high-level overview first, then surface details as needed to maintain context efficiency.
**Deprecated**: `skills/shared/modules/` directories. This pattern caused orphaned references when shared modules were updated or removed.
**Current pattern**: Each skill owns its modules at `skills/<skill-name>/modules/`. When multiple skills need the same content, the primary owner holds the module and others reference it via relative path (e.g., `../skill-authoring/modules/description-writing.md`). The validator flags any remaining `skills/shared/` directories.
Analyze modularity using `scripts/skill_analyzer.py`. You can set a custom threshold for line counts to identify files that need splitting.
python scripts/skill_analyzer.py --file path/to/SKILL.md --threshold 100
From Python, use `analyze_skill` from `abstract.skill_tools`.
Estimate token consumption to verify your skill stays within budget. Run this from the skill directory:
python scripts/tokens.py
Check for structure and pattern compliance before deployment.
python scripts/abstract_validator.py --scan
Start by assessing complexity with `skill_analyzer.py`. If a skill exceeds 150 lines, break it into focused modules following the patterns in `../../docs/examples/modular-skills/`. Use `token_estimator.py` to check efficiency and `abstract_validator.py` to verify the final structure. This iterative process maintains module maintainability and token efficiency.
Identify modules needing attention by checking line counts and missing Table of Contents. Any module over 100 lines requires a TOC after the frontmatter to aid navigation.
# Find modules exceeding 100 lines
find modules -name "*.md" -exec wc -l {} + | awk '$1 > 100'Our standards prioritize concrete examples and a consistent voice. Always provide actual commands in Quick Start sections instead of abstract descriptions. Use third-person perspective (e.g., "the project", "developers") rather than "you" or "your". Each code example should be followed by a validation command. For discoverability, descriptions must include at least five specific trigger phrases.
## Table of Contents - [Section Name](#section-name) - [Examples](#examples) - [Troubleshooting](#troubleshooting)
Standard patterns for triggers and for deciding whether a skill applies:
Detailed guides for implementation and maintenance:
A plugin marketplace for Claude Code. Install only the plugins you need to run git workflows, code review, spec-driven development, and autonomous agents from inside your Claude Code session.
Explain plugin, skill, command, agent, and hook mechanics used here. Use when authoring or debugging plugins. Do not use for ops; use night-market-operations.
States load-bearing decisions, invariants, and weak points. Use when judging a design change. Do not use for gating; use night-market-change-control.
Rebuild the dev environment: uv, Python tiers, pins, traps. Use when onboarding or toolchain breaks. Do not use for daily commands; use night-market-operations.
Classify, gate, and review changes. Use when landing a PR, releasing, or amending rules. Do not use for failure triage; use night-market-debugging-playbook.
Search and record project memory (Discussions, journal, ADRs). Use before re-investigating anything. Do not use for settled battles; see failure-archaeology.
Bind loop 'done' to unfakeable gates. Use to harden egregore/herald loops or promote completion_integrity. Not for QA gates; use night-market-validation-and-qa.