agemon 0.1.0 → 6.3.0

package/assets/skills/architecture/agemon-architecture/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/assets/skills/architecture/agemon-architecture/NOTICE.md

@@ -0,0 +1,9 @@
+# Vendored skill
+
+- Source: https://github.com/nathankim0/clean-architecture-skills
+- Path in source: plugins/clean-architecture/skills/clean-architecture
+- Commit: 0022fbb712f28517aa07a531fd82c70a9e531beb
+- Retrieved: 2026-08-17
+- License: MIT — see `LICENSE` in this directory.
+
+- Renamed from `clean-architecture` to `agemon-architecture` for agemon branding — installed skills should read as agemon's own, not a third-party project name.

package/assets/skills/architecture/agemon-architecture/SKILL.md

@@ -0,0 +1,275 @@
+---
+name: agemon-architecture
+description: Review code and provide design guidance based on Clean Architecture principles. Checks dependency rule, layer separation, crossing boundaries, and SOLID principles. Use when asked to review architecture, check dependencies, or design with clean architecture principles.
+---
+
+# Clean Architecture Review Skill
+
+## Overview
+
+This skill analyzes and reviews code based on Robert C. Martin's (Uncle Bob) Clean Architecture principles.
+
+## When to Use
+
+- When user requests "clean architecture" review
+- When asked about "architecture review", "dependency check", or "layer separation"
+- When designing new features with clean architecture
+
+## Instructions
+
+### 1. Project Structure Analysis
+
+First, understand the project's directory structure:
+- Check if layers are separated
+- Examine module/package structure
+- Identify dependency direction
+
+### 2. The Dependency Rule
+
+**Core Principle**: Source code dependencies must only point inward (toward higher-level policies).
+
+```
+┌─────────────────────────────────────────────────────────┐
+│                  Frameworks & Drivers                    │
+│  ┌─────────────────────────────────────────────────┐    │
+│  │              Interface Adapters                  │    │
+│  │  ┌─────────────────────────────────────────┐    │    │
+│  │  │              Use Cases                   │    │    │
+│  │  │  ┌─────────────────────────────────┐    │    │    │
+│  │  │  │           Entities              │    │    │    │
+│  │  │  └─────────────────────────────────┘    │    │    │
+│  │  └─────────────────────────────────────────┘    │    │
+│  └─────────────────────────────────────────────────┘    │
+└─────────────────────────────────────────────────────────┘
+                    ← Dependencies flow inward
+```
+
+Checklist:
+- Do inner layers avoid referencing outer layers?
+- Are Entities unaware of Use Cases, Adapters, and Infrastructure?
+- Do Use Cases avoid directly referencing Adapters or Infrastructure?
+- Is DIP applied when crossing boundaries?
+
+### 2-1. Crossing Boundaries
+
+The flow of control and source code dependency can point in opposite directions.
+
+```
+Controller → Use Case → Presenter
+     ↓           ↓           ↑
+[dependency] [dependency] [inverted!]
+```
+
+Example: When Use Case needs to call Presenter
+- Directly referencing Presenter from Use Case violates the dependency rule
+- **Solution**: Define Output Port (interface) inside Use Case, Presenter implements it
+
+```typescript
+// Use Case Layer (inner)
+interface OrderOutputPort {
+  presentOrder(order: OrderData): void;
+}
+
+class CreateOrderUseCase {
+  constructor(private outputPort: OrderOutputPort) {}
+  execute() {
+    // ... business logic
+    this.outputPort.presentOrder(orderData);
+  }
+}
+
+// Adapter Layer (outer) - depends on Use Case
+class OrderPresenter implements OrderOutputPort {
+  presentOrder(order: OrderData): void {
+    // Transform for UI
+  }
+}
+```
+
+### 2-2. What Data Crosses Boundaries
+
+**Principle**: Data crossing boundaries should be simple data structures (DTOs).
+
+```typescript
+// Bad: Passing Entity directly
+class GetUserUseCase {
+  execute(): User { // Returning Entity directly
+    return this.userRepository.findById(id);
+  }
+}
+
+// Good: Transform to DTO
+class GetUserUseCase {
+  execute(): UserResponseDTO { // Simple data structure
+    const user = this.userRepository.findById(id);
+    return { id: user.id, name: user.name };
+  }
+}
+```
+
+Checklist:
+- Are Entities or Database Rows not crossing boundaries directly?
+- Are external framework data formats not penetrating inner layers?
+- Are appropriate DTOs defined for each layer?
+
+### 3. Layer Structure Review
+
+#### Entities (Domain Layer)
+- Contains core business rules
+- No external dependencies
+- Least likely to change
+
+Checklist:
+- Does Entity avoid depending on frameworks?
+- Does it contain only pure business logic?
+- Are there no external library imports?
+
+#### Use Cases (Application Layer)
+- Application-specific business rules
+- Orchestrates Entities to implement features
+- Defines interfaces for external systems
+
+Checklist:
+- Does each Use Case have a single responsibility?
+- Are Input/Output ports clearly defined?
+- Does it use Repository interfaces (not implementations)?
+
+#### Interface Adapters
+- Handles data transformation
+- Contains Controllers, Presenters, Gateways
+- Can apply patterns like MVC, MVVM
+
+Checklist:
+- Is transformation between DTOs and Entities happening here?
+- Is the separation between external and internal formats clear?
+
+#### Frameworks & Drivers (Infrastructure Layer)
+- DB, Web Framework, external services
+- Mostly glue code
+- Most likely to change
+
+Checklist:
+- Are framework dependencies isolated to this layer?
+- Are Repository implementations located here?
+
+### 4. SOLID Principles Review
+
+Object-oriented design principles used in Clean Architecture implementation. **DIP** is essential for Crossing Boundaries.
+
+| Principle | Description | Clean Architecture Relevance |
+|-----------|-------------|------------------------------|
+| **SRP** | A class should have only one reason to change | Layer responsibility separation |
+| **OCP** | Open for extension, closed for modification | Extension through interfaces |
+| **LSP** | Subtypes must be substitutable for base types | Implementation replaceability |
+| **ISP** | Don't depend on interfaces you don't use | Port interface segregation |
+| **DIP** | Depend on abstractions, not concretions | **Core of Crossing Boundaries** |
+
+## Output Format
+
+Provide review results in this format:
+
+```markdown
+# Clean Architecture Review Report
+
+## Summary
+- Overall Assessment: [Good/Needs Improvement/Critical]
+- Key findings summary
+
+## Dependency Rule Analysis
+- List of violations
+- Improvement suggestions
+
+## Layer Structure Review
+### Entities: [Good/Needs Improvement]
+### Use Cases: [Good/Needs Improvement]
+### Interface Adapters: [Good/Needs Improvement]
+### Infrastructure: [Good/Needs Improvement]
+
+## Recommendations
+1. High priority improvements
+2. Medium priority improvements
+3. Long-term suggestions
+```
+
+## Important Notes
+
+### Clean Architecture is Not a Silver Bullet
+
+- Not all projects require exactly 4 layers
+- Layer count is flexible as long as the dependency rule is followed
+- Apply according to project scale and complexity
+
+### Common Pitfalls to Avoid
+
+1. **Over-obsession with layers**: Layer separation is not the goal itself
+2. **Over-abstraction**: Creating interfaces with only one implementation
+3. **Superficial adoption**: Relying on IDE refactoring while ignoring actual dependency rules
+4. **Over-engineering for the future**: Adding complexity for unlikely changes
+
+### Key Questions
+
+Always consider these questions during review:
+- "Does this separation actually provide benefits?"
+- "Is the dependency rule truly being followed?"
+- "Is the impact scope minimized when changes occur?"
+
+### Practical Verification
+
+Ask yourself if you're really benefiting from Clean Architecture:
+- Is it the layer separation that helps, or just IDE auto-refactoring?
+- Is a Repository interface with only one implementation really necessary?
+- Are you over-abstracting for a 0.001% chance of future change?
+- Can you rename a class in outer modules without affecting inner modules?
+
+## Language-Specific Examples
+
+### TypeScript/JavaScript
+```typescript
+// Good: Dependency Inversion
+interface UserRepository {
+  findById(id: string): Promise<User>;
+}
+
+class GetUserUseCase {
+  constructor(private userRepository: UserRepository) {}
+}
+
+// Bad: Depending on concrete implementation
+class GetUserUseCase {
+  constructor(private userRepository: PostgresUserRepository) {}
+}
+```
+
+### Python
+```python
+# Good: Interface definition using Protocol
+from typing import Protocol
+
+class UserRepository(Protocol):
+    def find_by_id(self, id: str) -> User: ...
+
+# Bad: Direct implementation import
+from infrastructure.postgres import PostgresUserRepository
+```
+
+### Java/Kotlin
+```kotlin
+// Good: Interface segregation
+interface UserRepository {
+    fun findById(id: String): User?
+}
+
+class GetUserUseCase(
+    private val userRepository: UserRepository
+)
+
+// Bad: Using concrete implementation
+class GetUserUseCase(
+    private val userRepository: JpaUserRepository
+)
+```
+
+## References
+
+- [The Clean Architecture - Robert C. Martin](https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html)
+- Clean Architecture: A Craftsman's Guide to Software Structure and Design (Book)

package/assets/skills/code-quality/agemon-clean-code/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 forrestchang and SwarmClaw AI contributors
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/assets/skills/code-quality/agemon-clean-code/NOTICE.md

@@ -0,0 +1,9 @@
+# Vendored skill
+
+- Source: https://github.com/swarmclawai/andrej-karpathy-skills
+- Path in source: skills/karpathy-guidelines
+- Commit: 29b8bc1d0e1905d777b2983343abb058b13c2e54
+- Retrieved: 2026-08-17
+- License: MIT — see `LICENSE` in this directory.
+- Canonical source per that repo's own README; content also mirrors several other forks of the same Karpathy-derived guidelines.
+- Renamed from `karpathy-guidelines` to `agemon-clean-code` for agemon branding — installed skills should read as agemon's own, not a third-party project name.

package/assets/skills/code-quality/agemon-clean-code/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: agemon-clean-code
+description: Behavioral guidelines to reduce common LLM coding mistakes. Use when writing, reviewing, or refactoring code to avoid overcomplication, make surgical changes, surface assumptions, and define verifiable success criteria.
+---
+
+# Karpathy Guidelines
+
+Behavioral guidelines to reduce common LLM coding mistakes, derived from [Andrej Karpathy's observations](https://x.com/karpathy/status/2015883857489522876) on LLM coding pitfalls.
+
+**Tradeoff:** These guidelines bias toward caution over speed. For trivial tasks, use judgment.
+
+## 1. Think Before Coding
+
+**Don't assume. Don't hide confusion. Surface tradeoffs.**
+
+Before implementing:
+- State your assumptions explicitly. If uncertain, ask.
+- If multiple interpretations exist, present them - don't pick silently.
+- If a simpler approach exists, say so. Push back when warranted.
+- If something is unclear, stop. Name what's confusing. Ask.
+
+## 2. Simplicity First
+
+**Minimum code that solves the problem. Nothing speculative.**
+
+- No features beyond what was asked.
+- No abstractions for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for impossible scenarios.
+- If you write 200 lines and it could be 50, rewrite it.
+
+Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
+
+## 3. Self-Documenting Code (strict)
+
+**Code must be understandable from its structure, names, and control flow alone. Needing an explanation is a defect, not a documentation gap.**
+
+- Use descriptive names that make values, conditions, and operations clear without commentary.
+- Keep functions focused; split code when a reader must mentally track unrelated steps at once.
+- Prefer clear intermediate variables and small helpers over dense expressions or hidden side effects.
+- If a reviewer — or you, re-reading your own change — has to ask "what does this do?" or "why is this here?" about *what*/*how* logic, that logic must be renamed, restructured, or split until it's obvious. Do not resolve that question with a comment.
+- Add a comment only when it records non-obvious context that cannot be made clear in code at all, such as a compatibility constraint, external contract, or intentionally surprising decision. Never use one to explain *what*/*how* something works.
+
+Before finishing, read the changed code with its why-comments hidden. If its purpose or flow is unclear without them, it isn't done — simplify or split it further, don't add explanation.
+
+## 4. Surgical Changes
+
+**Touch only what you must. Clean up only your own mess.**
+
+When editing existing code:
+- Don't "improve" adjacent code, comments, or formatting.
+- Don't refactor things that aren't broken.
+- Match existing style, even if you'd do it differently.
+- If you notice unrelated dead code, mention it - don't delete it.
+
+When your changes create orphans:
+- Remove imports/variables/functions that YOUR changes made unused.
+- Don't remove pre-existing dead code unless asked.
+
+The test: Every changed line should trace directly to the user's request.
+
+## 5. Goal-Driven Execution
+
+**Define success criteria. Loop until verified.**
+
+Transform tasks into verifiable goals:
+- "Add validation" → "Write tests for invalid inputs, then make them pass"
+- "Fix the bug" → "Write a test that reproduces it, then make it pass"
+- "Refactor X" → "Ensure tests pass before and after"
+
+For multi-step tasks, state a brief plan:
+```
+1. [Step] → verify: [check]
+2. [Step] → verify: [check]
+3. [Step] → verify: [check]
+```
+
+Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.

package/assets/skills/code-quality/agemon-house-rules/SKILL.md

@@ -0,0 +1,103 @@
+---
+name: agemon-house-rules
+description: Code-quality directives for simplicity, DRY architecture, zero-waste edits, self-documenting naming, surgical scope control, and goal-driven execution. Use when writing, editing, or reviewing code to keep changes minimal, readable, and traceable to the actual request.
+---
+
+# Agemon House Rules
+
+A compact set of code-quality directives distilled from agemon's own repo-wide agent rules
+([github.com/Korak-997/agemon](https://github.com/Korak-997/agemon), `AGENTS.md`). They cover the mechanics of
+writing and editing code well — not what to build, but how to build it without leaving a mess.
+
+## 1. Simplicity First
+
+Minimum code that solves the problem. Nothing speculative.
+
+- No features beyond what was asked.
+- No abstractions built for single-use code.
+- No "flexibility" or "configurability" that wasn't requested.
+- No error handling for scenarios that can't occur.
+- If a solution is 200 lines and could reasonably be 50, rewrite it.
+
+Test: *"Would a senior engineer call this overcomplicated?"* If yes, simplify.
+
+## 2. Modular, DRY Architecture
+
+- Design solutions as independent, loosely coupled modules with a single responsibility each.
+- Abstract genuinely repeated logic into reusable functions or classes — no logic duplicated across the
+  codebase.
+- This does not override Rule 1. Modularize and abstract only where responsibilities are truly distinct or
+  logic is truly reused. Don't invent module boundaries or shared abstractions for one-off, single-use code
+  just to look "architected."
+
+## 3. Zero-Waste Policy (scoped to your own changes)
+
+- Code you write must contain no dead code, redundant variables, or unused imports.
+- When your edits make existing code unreachable or unused (orphaned imports, variables, functions), remove
+  them.
+- Do **not** remove pre-existing dead code or unrelated unused code outside your change — flag it instead of
+  touching it (see Rule 5).
+
+## 4. Narrative Flow — Self-Documenting Code (strict)
+
+- Code should read top-to-bottom like a clear narrative; a developer should be able to follow the logic
+  without jumping around or guessing.
+- Use highly descriptive, semantic names (`process_pending_invoice_queue`, not `proc_inv`) — naming carries
+  the explanation, not comments.
+- Replace magic numbers and unexplained literals with named, descriptive constants.
+- **If code needs an explanation to be understood, that's a defect in the code, not a gap for a comment to
+  fill.** Rewrite, rename, or split it until it reads clearly on its own — in both writing and review, "what
+  does this do?" or "why is this here?" about *what*/*how* logic means it needs a rewrite, not a comment.
+- Comments are allowed only for genuinely non-obvious *why* that can't be expressed in code at all — a
+  regulatory requirement, a workaround for a specific bug or library quirk, a non-obvious algorithmic choice.
+  Never use a comment to restate what the code already says, and never use one to explain *what*/*how*.
+- Before finishing, re-read the changed code with its why-comments hidden. If the purpose or flow is unclear
+  without them, simplify or split it further before calling the task done.
+
+## 5. Surgical Execution & Scope Control
+
+- Touch only what the task requires. Every changed line should trace directly to the request.
+- Don't "improve" adjacent code, comments, or formatting. Don't refactor things that aren't broken.
+- Match existing style, even where you'd personally do it differently.
+- When editing multiple files, apply and present changes file-by-file so mistakes are easy to catch. Within a
+  single file, deliver the edit as one consolidated change rather than fragmenting it across multiple partial
+  passes.
+- If you notice bugs, tech debt, security gaps, or optimization opportunities outside the task's scope, name
+  them to the user rather than fixing them inline or staying silent — scope creep and silent omission are both
+  failure modes here.
+
+## 6. Goal-Driven Execution
+
+Define success criteria. Loop until verified.
+
+- Translate vague tasks into verifiable goals:
+  - "Add validation" → "Write tests for invalid inputs, then make them pass."
+  - "Fix the bug" → "Write a test that reproduces it, then make it pass."
+  - "Refactor X" → "Ensure tests pass before and after."
+- Consider realistic edge cases relevant to the task; use assertions where they add real safety, not as
+  decoration.
+- For multi-step tasks, state a brief plan before executing:
+  ```
+  1. [Step] → verify: [check]
+  2. [Step] → verify: [check]
+  3. [Step] → verify: [check]
+  ```
+- Strong success criteria allow independent looping; weak criteria ("make it work") force constant
+  clarification — avoid the latter.
+
+## 7. Performance & Security by Default
+
+- Every change, regardless of size, should consider the performance and security implications of the code it
+  touches — not just changes explicitly framed as "security" or "performance" work.
+- Within the current task's scope, default to the most secure and performant reasonable option: parameterized
+  queries over string concatenation, proper input validation/sanitization, least-privilege access, avoiding
+  N+1 queries and unnecessary re-computation, etc.
+- This does not license speculative optimization or defensive code nobody asked for — Rule 1 still applies.
+- If a genuine security or performance issue exists but fixing it is outside the current change's scope, name
+  it rather than fixing it inline or leaving it unmentioned.
+
+## When Rules Conflict
+
+Rule 1 (Simplicity) is the tiebreaker against Rule 2 (Modularity) — don't abstract for its own sake. Rule 5
+(Surgical scope) is the tiebreaker against every other rule when a task is ambiguous about how far to reach —
+when in doubt, touch less, and say what you didn't touch and why.

package/assets/skills/commit/agemon-commit/SKILL.md

@@ -0,0 +1,87 @@
+---
+name: agemon-commit
+description: Use when writing a commit message or preparing a commit — staging review, message structure, splitting unrelated changes, and what belongs in the body vs. what doesn't.
+---
+
+# Agemon Commit Discipline
+
+A compact set of rules for turning a diff into a commit. Covers what to check before staging, how to
+structure the message, and when a diff should become more than one commit.
+
+## 0. Never Commit — Hand Off the Message
+
+- Never run `git commit` (or any command that creates a commit). Preparing the message is the job; creating
+  the commit is the user's.
+- Output the finished commit message and let the user run the commit themselves.
+- This holds even if the user has approved commits in this session before — never assume standing
+  permission to run `git commit` unless told explicitly and unambiguously that it applies going forward.
+
+## 1. Before Staging
+
+- Run `git status`, `git diff` (unstaged), and `git diff --cached` (staged) before deciding what goes in —
+  `git diff` alone omits already-staged changes, letting them bypass review. Never stage with a blanket
+  `git add -A` or `git add .` without reviewing what it picks up — untracked files may be scratch output,
+  credentials, or unrelated in-progress work.
+- If `git status` shows files you didn't expect to touch, find out why before including them.
+- Check diff contents, not just filenames, for anything that looks like a secret (`.env` values, tokens,
+  keys) even in files with innocuous names.
+
+## 2. One Commit, One Change
+
+- A commit should represent a single logical change. If the diff mixes an unrelated fix, a refactor, and a
+  feature, split it into separate commits rather than describing all three in one message.
+- Don't bundle "while I was in there" cleanup with the actual change — that belongs in its own commit, if
+  it belongs at all (see agemon's Surgical Execution directive).
+
+## 3. Message Structure
+
+This repo enforces [Conventional Commits](https://www.conventionalcommits.org/) — via `.githooks/commit-msg`
+locally and `commitlint` + PR-title linting in CI. Every subject line must use the required format, not just
+as a style preference:
+
+```
+<type>[(scope)][!]: <description>
+```
+
+- Allowed types: `feat`, `fix`, `perf`, `refactor`, `docs`, `test`, `build`, `ci`, `chore`, `revert` (matches
+  `.githooks/commit-msg`).
+- Scope is optional, lowercase, and names a module/concept (`auth`, `installer`) — not a specific filename.
+- Description: imperative mood ("add", "fix", "remove" — not "added", "adds", "fixing"), lowercase after the
+  colon, no trailing period.
+- Subject line under ~50 characters where possible, hard cap ~72.
+- If the change breaks backward compatibility, append `!` before the colon (`feat(api)!: ...`) **and** add a
+  `BREAKING CHANGE:` footer explaining the break.
+- Lead the body with *why*, not *what*. The diff already shows what changed; a reader with the diff open
+  doesn't need it repeated in prose. State the reason, motivation, or problem being solved.
+- Use a body only when the subject line can't carry the necessary context — a one-line change with an
+  obvious reason doesn't need one. Wrap body lines at ~72 characters, separated from the subject by one
+  blank line.
+
+## 4. Follow Existing Convention
+
+- Before writing a message, check `git log --oneline -20` on the current repo to confirm the prevailing
+  style still matches Section 3 (type casing, scope naming). Match it.
+- The type prefix itself is never optional in this repo — the commit-msg hook and CI both reject a subject
+  line without one, so there is no "no convention discernible" fallback to a bare imperative subject.
+
+## 5. Issue References — Always Ask
+
+- Before finalizing any commit message, ask the user whether this commit should close an issue, and if so,
+  what to include:
+  - **Closes/Fixes #N** — use only when this commit fully resolves the issue; it auto-closes on merge.
+  - **Refs #N** / "Relates to #N" — use when the commit is related but doesn't fully resolve the issue; it
+    links without closing.
+- Never invent an issue number, and never guess Closes vs. Refs on the user's behalf — always confirm which
+  one they want, and for which number, even if a plausible issue seems implied by the task.
+- Don't mix `Closes` and `Refs` for the same issue across multiple commits on one branch.
+
+## 6. What Not to Do
+
+- Don't claim a commit "fixes" or "resolves" something without having verified it (see
+  `agemon-verify-before-done`) — a commit message is a durable record, and false claims in it mislead
+  future readers doing `git blame` archaeology.
+- Never add attribution, co-author, or tool-generated lines (e.g. `Co-Authored-By: <agent name>`,
+  "Generated with ..."). The message is authored by the user; it carries no mention of the agent or tool
+  that drafted it, even if a session-level default elsewhere suggests otherwise.
+- Don't amend or rewrite history (`commit --amend`, rebase) on commits already pushed or shared, and never
+  force-push, without explicit confirmation.

package/assets/skills/design/agemon-design/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Eduardo Calvo
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.