Odoo 16
unclecatvn/agent-skills
Odoo 16 development reference for Python models and ORM (search, domain, readgroup, compute fields), XML/CSV data and views, OWL/JS client code, QWeb reports, security (ACL, record rules, groups)…
A skill your agent uses when adding or refactoring EasyPostman modules, shared code, plugin contracts, UI utilities, i18n, settings, theme/font handling, or deciding where a class belongs.
Install Module Architecture Boundaries
$ npx skills add lakernote/easy-postman --skill module-architecture-boundaries -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install lakernote/easy-postman module-architecture-boundaries --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/lakernote/easy-postman.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.codex/skills/module-architecture-boundaries .claude/skills/module-architecture-boundaries && rm -rf skills-srcUse ~/.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/
Install the "module-architecture-boundaries" agent skill from https://github.com/lakernote/easy-postman/tree/master/.codex/skills/module-architecture-boundaries into .claude/skills/module-architecture-boundaries/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "module-architecture-boundaries", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/lakernote/easy-postman/tree/master/.codex/skills/module-architecture-boundariesType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add lakernote/easy-postman --skill module-architecture-boundaries -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install lakernote/easy-postman module-architecture-boundaries --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/lakernote/easy-postman.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.codex/skills/module-architecture-boundaries .agents/skills/module-architecture-boundaries && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "module-architecture-boundaries" agent skill from https://github.com/lakernote/easy-postman/tree/master/.codex/skills/module-architecture-boundaries into .agents/skills/module-architecture-boundaries/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "module-architecture-boundaries", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add lakernote/easy-postman --skill module-architecture-boundaries -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install lakernote/easy-postman module-architecture-boundaries --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/lakernote/easy-postman.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.codex/skills/module-architecture-boundaries .cursor/skills/module-architecture-boundaries && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "module-architecture-boundaries" agent skill from https://github.com/lakernote/easy-postman/tree/master/.codex/skills/module-architecture-boundaries into .cursor/skills/module-architecture-boundaries/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "module-architecture-boundaries", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/lakernote/easy-postman.git --path .codex/skills/module-architecture-boundaries--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add lakernote/easy-postman --skill module-architecture-boundaries -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install lakernote/easy-postman module-architecture-boundaries --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/lakernote/easy-postman.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.codex/skills/module-architecture-boundaries .gemini/skills/module-architecture-boundaries && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "module-architecture-boundaries" agent skill from https://github.com/lakernote/easy-postman/tree/master/.codex/skills/module-architecture-boundaries into .gemini/skills/module-architecture-boundaries/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "module-architecture-boundaries", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install lakernote/easy-postman module-architecture-boundariesInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add lakernote/easy-postman --skill module-architecture-boundaries -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/lakernote/easy-postman.git skills-src && mkdir -p .github/skills && cp -r skills-src/.codex/skills/module-architecture-boundaries .github/skills/module-architecture-boundaries && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "module-architecture-boundaries" agent skill from https://github.com/lakernote/easy-postman/tree/master/.codex/skills/module-architecture-boundaries into .github/skills/module-architecture-boundaries/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "module-architecture-boundaries", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add lakernote/easy-postman --skill module-architecture-boundaries -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install lakernote/easy-postman module-architecture-boundaries --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/lakernote/easy-postman.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.codex/skills/module-architecture-boundaries .opencode/skills/module-architecture-boundaries && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "module-architecture-boundaries" agent skill from https://github.com/lakernote/easy-postman/tree/master/.codex/skills/module-architecture-boundaries into .opencode/skills/module-architecture-boundaries/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "module-architecture-boundaries", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
module-architecture-boundaries- GitHub stars
- 722
- Token cost
- ~3.9k tokens
- SKILL.md length
- 1,771 words
- Files
- 1
- Skills in repo
- 5
- Repo updated
- First seen
- Licence
- Apache-2.0
At a glance
A skill your agent uses when adding or refactoring EasyPostman modules, shared code, plugin contracts, UI utilities, i18n, settings, theme/font handling, or deciding where a class belongs.
- Works in 12 steps: Put non-UI base capabilities in… → Put plugin extension contracts in… → Put request specification models in… → …
- Refactoring EasyPostman modules
- SKILL.md covers Source of truth, Placement rules, Plugin Compatibility Boundary and Update Boundaries, plus 5 more sections
- Calls mvn
What it does
Module Architecture Boundaries is an agent skill from lakernote/easy-postman. Use when adding or refactoring EasyPostman modules, shared code, plugin contracts, UI utilities, i18n, settings, theme/font handling, or deciding where a class belongs.
Its SKILL.md is about 3.9k 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 Frontend & Design, covering API testing, Internationalization and Refactoring. It works with Postman. The repository describes itself as: An open-source API debugging and stress testing tool inspired by Postman and a simplified JMeter, optimized for developers with a clean UI and powerful features. The licence is Apache-2.0.
When your agent uses it
- Refactoring EasyPostman modules
- Plugin contracts
- Theme/font handling
- Deciding where a class belongs
Example prompts
- “/module-architecture-boundaries”
Workflow steps
12 steps, taken from the first numbered list in SKILL.md.
- Put non-UI base capabilities in easy-postman-foundation.
- Put plugin extension contracts in easy-postman-plugin-api.
- Put request specification models in easy-postman-request-core.
- Put collection domain models and neutral import parsing in easy-postman-collection-core.
- Put HTTP transport runtime in easy-postman-http-runtime.
- Put the self-hosted Mock Server runtime in easy-postman-mock-core.
- Put shared Swing design-system code in easy-postman-ui.
- Put plugin loading mechanics in easy-postman-plugin-runtime.
- Put performance domain core contracts in easy-postman-performance-core: editable plan data, executable plan.json, runtime contracts…
- Put MCP protocol mechanics in easy-postman-mcp: official SDK integration, observable stdio lifecycle, tool schemas/annotations, structured…
- Put host platform framework capabilities in easy-postman-platform when they can be separated from concrete app UI.
- Keep concrete host UI and composition in easy-postman-app.
What it can do on your machine
Read from SKILL.md and the folder at commit 442d7ed. 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
Shell commands in SKILL.md call:
mvn
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
Module Architecture Boundaries loads about 3.9k tokens when it runs. Until then it costs about 50 tokens; SKILL.md has 1,771 words of instructions outside code blocks.
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 lakernote/easy-postman at commit 442d7ed, republished under its Apache-2.0 licence (© lakernote). 1,771 words, ~3,872 tokens.
Download SKILL.mdSave it as
.claude/skills/module-architecture-boundaries/SKILL.md (or your agent's skills folder).- name
- module-architecture-boundaries
- description
- Use when adding or refactoring EasyPostman modules, shared code, plugin contracts, UI utilities, i18n, settings, theme/font handling, or deciding where a class belongs.
Module Architecture Boundaries
Use this skill before adding shared code or moving code between modules. The goal is to keep EasyPostman's Maven modules small enough to reason about and strict enough that future changes do not turn into a catch-all common layer.
Source of truth
Read docs/ARCHITECTURE_MODULES_zh.md first when the task is about module placement, architecture cleanup, shared UI, plugin contracts, i18n, theme, font, settings, startup, update, welcome/help, request core, collection core, API core, or performance core.
Placement rules
Put non-UI base capabilities in
easy-postman-foundation. Examples: shared DTOs, enums, constants, config paths, JSON helpers, system utilities, user-setting helpers, i18n mechanism, base message keys, and generic parsing/formatting helpers such as Cron, JSON Path, XML, file-size, file-extension, time-display, and HTTP header constants.Put plugin extension contracts in
easy-postman-plugin-api. Examples:EasyPostmanPlugin,PluginContext,PluginDescriptor, service interfaces, toolbox/script/snippet contracts.Put request specification models in
easy-postman-request-core. Examples:HttpRequestItem,SavedResponse,HttpHeader,HttpParam,HttpFormData,HttpFormUrlencoded,CookieInfo, auth/body/protocol enums, redirect metadata, and transport-auth metadata. Keep it UI-free and transport-implementation-free: no Swing, OkHttp, app service/panel code, plugin runtime, or concrete send/render implementation.Put collection domain models and neutral import parsing in
easy-postman-collection-core. Examples:RequestGroup,CollectionNode,CollectionNodeType,CollectionParseResult, collection auth parsing helpers, and Postman collection parsing. Keep it UI-free and host-free: no Swing/AWT, OkHttp, app service/panel/runtime code, platform, plugin runtime, IOC, or concrete send/render implementation.Put HTTP transport runtime in
easy-postman-http-runtime. Examples:PreparedRequest,HttpResponse,HttpEventInfo, runtime settings/provider, OkHttp adapters, TLS/client certificate ports, Cookie store, SSE callbacks, redirect execution, UI-neutral interaction sinks, and network observation sinks. Keep it UI-free and host-free: no Swing/AWT, appSettingManager, app plugin-host accessors, panel code, platform IOC, or JavaFX/Swing-specific adapters.Put the self-hosted Mock Server runtime in
easy-postman-mock-core. Examples: mock definition DTOs, Example route snapshots, method/path/query/header/body matching, JDKHttpServer, bounded call logs, volatile session state, optional shared access-key enforcement, and the neutralMockScriptExecutorport. Keep it UI-free and host-free: no Swing/AWT, collection/request models, app services, GraalVM, OkHttp/Netty, platform IOC, or plugin runtime. Collection mapping, workspace persistence, GraalJS adaptation, headless CLI, and Swing UI stay ineasy-postman-app.Put shared Swing design-system code in
easy-postman-ui. Examples:FontsUtil,IconUtil,NotificationCenter,EditorThemeUtil,ModernColors, reusable toolbar buttons/search/table/dialog/form controls such asEditButton,SaveButton,WrapToggleButton,EasyComboBox,EasyJSpinner,EasyPasswordField, and the icons/resources those reusable components directly reference. UI singleton framework classes such asUiSingletonFactory,UiSingletonPanel,UiSingletonMenuBar, plus Swing refresh/save helpers such asIRefreshableandDebouncedSaveSupport, also belong here. Generic action/control/status icons such as save, copy, paste, search, clear, cancel, close, delete, duplicate, eye, info, warning, arrows, chevrons, wrap, start, stop, send, connect, collapse, expand, more, detail, import, and export belong here. Do not duplicate the sameicons/*.svgresource path ineasy-postman-app, and do not make official plugins depend on app-only icon resources.Put plugin loading mechanics in
easy-postman-plugin-runtime. Examples: plugin scanning, descriptor parsing, classloaders, registry, lifecycle, disabled/uninstall state.Put performance domain core contracts in
easy-postman-performance-core: editable plan data, executableplan.json, runtime contracts, stats/report snapshots, worker assignments, and asset references. Keep concrete GUI/headless execution adapters ineasy-postman-appuntil the app execution semantics can be extracted without pulling in Swing, workspace services, or app-only state.Put MCP protocol mechanics in
easy-postman-mcp: official SDK integration, observable stdio lifecycle, tool schemas/annotations, structured result mapping, and the minimalEasyPostmanMcpBackendcontract. It may depend on foundation and the MCP SDK, but must not depend on app, Swing, workspace storage, scripts, or concrete request execution. Keepmcp serveCLI composition, workspace authorization, environment loading, upload-file constraints, Cookie call isolation, redaction, result-detail limits, and the backend implementation in app.Put host platform framework capabilities in
easy-postman-platformwhen they can be separated from concrete app UI. Current examples: the custom IOC container undercom.laker.postman.ioc, and update discovery core undercom.laker.postman.platform.update(version comparison, update source selection, asset resolution, changelog fetching/formatting, update result models). Future examples: startup orchestration, welcome/help, settings center, and theme/font application orchestration.Keep concrete host UI and composition in
easy-postman-app. Examples:App,MainFrame, menus, app-only panels, settings pages, update dialogs, update download/install/exit flow, welcome/help pages, and concrete startup wiring that still depends on app UI. Do not recreate a generic app model package for HTTP runtime exchange snapshots. Domain-specific app models should live with their owner package, such asfunctional.model,script.model,stream,snippet,history,certificate,variable,environment, orservice.curl.Keep HTTP request preparation adapters separated from HTTP transport runtime. Request preparation, validation, collection inheritance, variable resolution, scripts, and default request factories may stay in
easy-postman-app/http.requestwhile they still depend on app services. URL/query helpers belong in request-core. Transport execution belongs ineasy-postman-http-runtime. Swing implementations belong in UI adapters such ascom.laker.postman.panel.http.runtime, and app-specific runtime bootstrap belongs undercom.laker.postman.http.runtime.app.
Plugin Compatibility Boundary
Before removing, renaming, moving, or changing signatures/behavior for public types in modules that plugins may depend on, check whether old plugin JARs can still link against the new host. This includes easy-postman-plugin-api, easy-postman-foundation, and easy-postman-ui, because official and third-party plugins use them with provided scope.
Treat these as plugin-platform breaking changes:
- Deleting or renaming a public class, enum, method, constructor, field, package, resource path, or descriptor key that a plugin could reference.
- Changing method signatures, enum constants, constructor requirements, service contracts, extension-point semantics, or runtime loading behavior.
- Moving shared UI entry points such as notification, icon, color, font, or reusable component APIs without a binary-compatible facade.
When the change is intentionally incompatible, do all of this in the same patch:
- Bump root
pom.xmlplugin.platform.versionto the next incompatible platform version. Do not userevisionfor this. - Ensure official plugin
pom.xmlfiles resolveplugin.minPlatformVersionandplugin.maxPlatformVersionto the new platform version. If the plugins are rebuilt for the host release, update their plugin<version>andplugin.minAppVersionto the release they require. - Update plugin runtime/update tests so an old platform range, such as the previous
plugin.platform.version, is rejected before plugin code is loaded. - Do not edit existing catalog entries for already-published plugin JARs to claim a new platform range. Those entries are tied to their existing
sha256. New platform ranges belong to new rebuilt plugin artifacts generated by the plugin release workflow. If a catalog must be edited manually, update bothplugin-catalog/andeasy-postman-plugins/plugin-manager/src/main/resources/plugin-catalog/.
If preserving compatibility is the goal instead, keep a binary-compatible facade or overload with the old package/class/signature and add tests for old entry points. Do not bump plugin.platform.version for a compatible refactor.
Show full SKILL.md (732 more words)Show less
Update Boundaries
- Put update discovery core in
platform:UpdateInfo,UpdateCheckFrequency,VersionChecker,VersionComparator,UpdateSourceSelector, release sources, asset resolvers, changelog service/formatter, and Windows registry/package-mode helpers. - Keep concrete update UX in
app:AppUpdateCheckCoordinator,UpdateUiController,UpdateDownloader, update dialogs/notifications, manual-download/open-browser commands, install prompts, and app shutdown for installation. platformupdate code must not import appSettingManager; inject a minimal provider such asUpdateSettingsProviderand adapt it in app withSettingManager::getUpdateSourcePreference.
I18n, Fonts, Theme
- I18n mechanism and cross-module generic labels belong in
foundation:I18nUtil,CommonI18n,CommonMessageKeys, andcommon-messages*. - I18n resources follow their owner: generic short labels such as OK, Cancel, Save, Copy, Close, Search, Success, Error, Warning, and Tip in foundation common bundles; shared UI component-specific strings in
ui(ui-messages*); host strings inapp(messages_*); plugin strings in each plugin. - Font helpers and typography rules belong in
ui; startup application of font settings belongs inplatformonce decoupled from app-specific wiring. - Theme tokens, semantic colors, icon color strategies, RSyntaxTextArea editor theme XMLs, and reusable UI resources belong in
ui; FlatLaf installation and theme switching belong inplatformonce decoupled from app-specific wiring. FlatLaf properties tied to app LAF classes can stay inappuntil those classes move. - Primary-color buttons must use on-primary icon color. Icons on blue/brand buttons stay white and must not switch with the light/dark theme foreground.
SVG Icon Guidance
README.mdandREADME_zh.mddeclare SVG icons are sourced from Lucide /lucide-icons/lucideunder the ISC license. For new or refreshed generic UI/action/sidebar icons, start from Lucide before inventing custom paths.- Keep single-color themeable SVGs as
viewBox="0 0 24 24",fill="none",stroke="currentColor",stroke-width="2",stroke-linecap="round", andstroke-linejoin="round"to match existing sidebar icons. - Use
IconUtil.createThemed(...)for neutral sidebar/status/tool icons so light and dark themes can recolor them. Use fixed-color SVGs orIconUtil.create(...)only for brand, protocol, or status assets that intentionally carry their own colors. - Resource ownership still applies: generic actions in
easy-postman-ui, app/domain icons in app, plugin icons in plugin resources. Do not duplicateicons/*.svgnames across modules.
Code Style And Testability
- Use Lombok for ordinary boilerplate when it makes code smaller and clearer:
@Slf4j,@RequiredArgsConstructor,@Getter/@Setter, model annotations, and@UtilityClassfor stateless static helpers. Avoid Lombok only when explicit code is clearer for Swing lifecycle, validation-heavy construction, or framework compatibility. - Do not add production hooks, injectable exits, extra state, or abstraction layers only to make a test possible if that makes the production code more complex. Prefer testing observable behavior through existing public/package APIs, focused static architecture tests, or a simpler production fix with a smaller test. Add a seam only when it also improves real design, not just test mechanics.
Anti-patterns
- Do not use a vague
commonmodule as the default destination. - Do not create a vague
easy-postman-coremodule for unrelated request, collection, runtime, and UI concerns. - Do not put Swing code in
foundation. - Do not put request specification models back into
easy-postman-app. - Do not make
easy-postman-request-coredepend on Swing, OkHttp, app service/panel code, or plugin runtime. - Do not put collection core models or Postman collection parsing back into
easy-postman-app. - Do not make
easy-postman-collection-coredepend on Swing, OkHttp, app service/panel/runtime code, platform, plugin runtime, or IOC. - Do not make
easy-postman-mock-coredepend on Swing/AWT, collection/request models, app services, GraalVM, OkHttp/Netty, platform IOC, or plugin runtime. Keep it self-hosted and dependency-light; LAN/server binding is allowed, but cloud control planes and team authorization are not. - Do not make HTTP runtime/service classes depend directly on Swing/panel or app
SettingManager; adapt UI through neutral sinks/dispatchers and settings throughHttpRuntimeSettingsProviderso Swing, CLI tests, and future JavaFX hosts can provide separate implementations. - Do not put UI view-state, importer scratch DTOs, script snippets, functional runner rows/results, stream message types, certificate settings rows, or history records back into
easy-postman-app/src/main/java/com/laker/postman/model. - Do not put plugin service contracts in
foundation. - Do not put shared reusable UI components directly in
app. - Do not make shared UI components depend on app-owned message bundles, icons, editor themes, or other app resources.
- Do not duplicate generic short labels in
ui-messages*or plugin message bundles whenCommonMessageKeysalready owns them. - Do not make plugins depend on
easy-postman-app. - Do not make
easy-postman-mcpdepend oneasy-postman-app, Swing, workspace persistence, scripts, or concrete HTTP execution. - Do not introduce new app-local color/font/button conventions before checking
easy-postman-ui. - Do not duplicate same-named
icons/*.svgresources betweeneasy-postman-appandeasy-postman-ui; shared control icons belong inui, app/domain icons stay with their owning app/plugin module. If a plugin references an icon, it must be plugin-owned or UI-owned.
Verification
For module-boundary changes, run:
mvn -q -pl easy-postman-app -am -Dtest=ModuleArchitectureBoundaryTest -Dsurefire.failIfNoSpecifiedTests=false test
mvn -q -pl easy-postman-plugin-runtime -am -Dtest=PluginRuntimeTest -Dsurefire.failIfNoSpecifiedTests=false test
mvn -q -pl easy-postman-app -am -Dtest=PluginUpdateCheckerTest -Dsurefire.failIfNoSpecifiedTests=false test
mvn -q -pl easy-postman-platform -am -Dtest=UpdateSourceSelectorTest,PlatformDownloadUrlResolverTest,AppReleaseSelectorTest -Dsurefire.failIfNoSpecifiedTests=false test
mvn -q -DskipTests compile© lakernote, Apache-2.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 .codex/skills/module-architecture-boundaries of lakernote/easy-postman.
Open the folder on GitHubat commit 442d7ed
Compare with similar skills
Module Architecture Boundaries 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.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Module Architecture Boundaries this skilllakernote/easy-postman | 722 | — | ~3.9k | Automated safety check: Pass | Apache-2.0 | |
| Odoo 16unclecatvn/agent-skills | 143 | — | ~1.4k | Automated safety check: Pass | MIT | |
| Designlang TokensManavarya09/design-extract | 4.2k | — | ~247 | Automated safety check: Pass | MIT | |
| Odoo 17unclecatvn/agent-skills | 143 | — | ~1.4k | Automated safety check: Pass | MIT | |
| Odoo 18unclecatvn/agent-skills | 143 | — | ~1.3k | Automated safety check: Pass | MIT | |
| Experience Lwc Rtl Validateforcedotcom/sf-skills | 1.1k | — | ~2.8k | Automated safety check: Pass | Apache-2.0 |
Similar skills
Designlang Tokens
Manavarya09/design-extract
A skill your agent uses when styling UI for postman.com — references the extracted design system tokens instead of inventing colors, spacing, or typography.
Odoo 17
unclecatvn/agent-skills
Odoo 17 development reference for Python models and ORM (search, domain, readgroup, compute fields), XML/CSV data and views, OWL/JS client code, QWeb reports, security (ACL, record rules, groups)…
Odoo 18
unclecatvn/agent-skills
Odoo 18 development reference for Python models and ORM (search, domain, readgroup, compute fields), XML/CSV data and views, OWL/JS client code, QWeb reports, security (ACL, record rules, groups)…
Experience Lwc Rtl Validate
forcedotcom/sf-skills
A skill your agent uses to review a Lightning Web Component (.html, .js, .css files) for right-to-left (RTL) internationalization correctness, producing a finding list with code-level fixes covering…
Valgo
cohesivestack/valgo
Add, refactor, debug, review, explain, or migrate type-safe validation in consumer Go applications using github.com/cohesivestack/valgo.
More from lakernote/easy-postman
Swing Intellij Dialog Style
lakernote/easy-postman
A skill your agent uses when modifying EasyPostman Swing dialogs, popups, wizards, or modal flows to better match IntelliJ IDEA or FlatLaf settings-style visual hierarchy, especially when read-only…
Fontsutil Font Usage
lakernote/easy-postman
A skill your agent uses when modifying EasyPostman Swing UI fonts, especially when dialogs, labels, tables, tabs, or renderers look too large or too small, or when a change needs to stay consistent…
Swing Flatlaf Miglayout Principles
lakernote/easy-postman
A skill your agent uses when modifying EasyPostman Swing forms, tool-window panels, localized English/Chinese text layouts, or FlatLaf/MigLayout layouts, especially when refactors introduce clipped…
Swing UI Test Headless Guard
lakernote/easy-postman
A skill your agent uses when adding or updating EasyPostman Swing/TestNG UI tests that may run in headless CI or no-display Linux environments.
Related
Works with
Categories
Questions about Module Architecture Boundaries
What does Module Architecture Boundaries do?
A skill your agent uses when adding or refactoring EasyPostman modules, shared code, plugin contracts, UI utilities, i18n, settings, theme/font handling, or deciding where a class belongs. Module Architecture Boundaries is an agent skill from lakernote/easy-postman. Use when adding or refactoring EasyPostman modules, shared code, plugin contracts, UI utilities, i18n, settings, theme/font handling, or deciding where a class belongs.
When should I use Module Architecture Boundaries?
Module Architecture Boundaries fits situations like: refactoring EasyPostman modules; plugin contracts; theme/font handling; deciding where a class belongs.
How do I install Module Architecture Boundaries in Claude Code?
Run `npx skills add lakernote/easy-postman --skill module-architecture-boundaries -a claude-code`. Or copy the skill folder (.codex/skills/module-architecture-boundaries in lakernote/easy-postman) into .claude/skills/module-architecture-boundaries in your project. Claude Code loads it when a task matches its description.
How do I install Module Architecture Boundaries in Codex?
Run `npx skills add lakernote/easy-postman --skill module-architecture-boundaries -a codex`. Or copy the skill folder (.codex/skills/module-architecture-boundaries in lakernote/easy-postman) into .agents/skills/module-architecture-boundaries in your project. Codex loads it when a task matches its description.
Can I use Module Architecture Boundaries 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 lakernote/easy-postman --skill module-architecture-boundaries -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/module-architecture-boundaries, .gemini/skills/module-architecture-boundaries, .github/skills/module-architecture-boundaries and .opencode/skills/module-architecture-boundaries in your project.
What does Module Architecture Boundaries need to run?
Going by SKILL.md and its folder, Module Architecture Boundaries needs the command-line tools its instructions call (mvn).
Does Module Architecture Boundaries 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 Module Architecture Boundaries 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 Module Architecture Boundaries use?
Module Architecture Boundaries is published under the Apache-2.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Module Architecture Boundaries use?
About 3.9k tokens (SKILL.md is roughly 15k 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 Module Architecture Boundaries?
Skills that share tags, products or a category with Module Architecture Boundaries: Odoo 16 (unclecatvn/agent-skills, 143 stars), Designlang Tokens (Manavarya09/design-extract, 4.2k stars), Odoo 17 (unclecatvn/agent-skills, 143 stars) and Odoo 18 (unclecatvn/agent-skills, 143 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Module Architecture Boundaries?
lakernote (a GitHub user) maintains it in lakernote/easy-postman, which has 722 GitHub stars. The repository holds 5 skills in this directory. The repository was last updated on October 9, 2026.
Source: lakernote/easy-postman on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.