common

Plugin common from marketplace konglabs-agent-skills in KongPedia/agent-skills. Commands read from the repo's manifest — 11 days ago.

Skills (18)

• architecture-patterns

  Compare Clean, Hexagonal and domain-driven architecture for an actual module/service boundary, tangled policy/I/O or dependency cycle. Use across languages when those responsibilities are in scope; not a requirement to add layers or interfaces to every project.

• best-practice-research

  Research current best practices, technical reference implementations or version-sensitive guidance using primary sources and the owning repository's actual constraints. Not a dependency installer or automatic implementation workflow.

• brainstorming

  Clarify genuinely unresolved goals, constraints or design choices before a new feature or project. Use for requested design discussion; do not reopen decisions or force interviews for clear authorized work.

• code-review-excellence

  Master effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing review standards, or mentoring developers.

• codebase-design

  Shared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-navigable, or when another skill needs the deep-module vocabulary.

• deprecation-and-migration

  Plan or implement an explicitly requested public-interface removal or API migration with consumer accounting, compatibility and rollback. Not routine refactoring, inactivity-based deletion or permission for deployments.

• docs-sync

  Audit or update repository documentation and agent guidance against the requested implementation scope.

• domain-modeling

  Clarify domain vocabulary, ownership and invariants using the consuming project's existing glossary and ADR conventions; draft changes only when authorized.

• monorepo-contract-change

  Coordinate a shared API, schema, event, public package, or native-interface change across monorepo producers and consumers. Not needed for an isolated internal refactor.

• observability-and-instrumentation

  Design, add or review logging, metrics, tracing or alerting for a concrete diagnostic gap. Use when those signals are requested or needed to explain a measured failure; not every production feature, routine prose change or an automatic telemetry-stack migration.

• ponytail

  Use when implementing new functionality, refactoring, or deciding whether an abstraction or dependency is needed, especially when the user requests Ponytail, YAGNI, the smallest complete solution, or less over-engineering.

• security-and-hardening

  Review or implement security-relevant trust boundaries, authentication, authorization, sensitive data handling, dependency-audit findings or untrusted-input defenses. Use when those controls are in task scope or a concrete security risk is identified; not every feature or routine prose edit.

• spec-driven-development

  Maintain a specification for meaningful behavior, compatibility, or cross-package changes, with explicit proposed/current status and verification evidence. Not mandatory ceremony for small fixes or prose edits.

• systematic-debugging

  Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

• test-driven-development

  Use failing-first behavioral tests for new or changed behavior and bug fixes. Use characterization for preserved behavior and static checks for prose or directory-only scaffolds.

• verification-before-completion

  Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always

• writing-for-agents

  Design or substantively revise skills, AGENTS.md, CLAUDE.md or instruction documents consumed by agents. Use for routing, progressive disclosure and checkable completion criteria; not ordinary product prose or typo-only edits.

• writing-plans

  Turn an accepted specification or clear multi-step requirement into bounded implementation tasks with exact owners, interfaces and verification evidence. Not required for a trivial edit or a new permission gate.

Subagents (4)

• architect

  Read-only architecture analysis of ownership, package boundaries and the smallest sound design.

• code-reviewer

  Independently review scope, behavior, guidance routing, compatibility and verification without implementing fixes.

• executor

  Complete an assigned bounded code, document or skeleton task using the owning package's exact guidance.

• verifier

  Match completion claims to observed evidence at the actual task layer without changing implementation.

Similar plugins