← all publishers

davidvujic

@davidvujic source repo

Report this profile Claim this profile

• 48 skills
• 0 followers
• 6 hours ago last updated

1. ▌
   Commit · davidvujic

   Create a conventional commit from staged changes, with a diff-derived description body and a Code Health gate.
   0
   installs
2. ▌
   QA Check · davidvujic

   Run lint and unit tests. Uses a project QA skill or the commands documented in the project's AGENTS.md/rules when present; otherwise discovers them in one shell call from Justfile, Makefile, pyproject.toml or package.json.
   0
   installs
3. ▌
   Coding Style · davidvujic

   General coding style policy for generated code: restrictive on comments, concise docstrings for modules and functions.
   0
   installs
4. ▌
   Concise Style · davidvujic

   Concise communication, without sacrificing readability and still maintaining technical accuracy. Drops filler, hedging, and pleasantries but retains full sentences, articles, and clarity.
   0
   installs
5. ▌
   Planning Style · davidvujic

   Produce an implementation plan with a functional-leaning, idiomatic style mindset; prefers lightweight data structures over dataclasses/pydantic unless justified.
   0
   installs
6. ▌
   Fp Idiomatic Style · davidvujic

   Coding style policy for generated code: prefer idiomatic language conventions with a functional-leaning approach (pure-ish functions, composability), and prefer lightweight data structures over heavy schema/class abstractions unless clearly justified.
   0
   installs
7. ▌
   Git Changes Context · davidvujic

   Obtain the unified diff of the current branch against its base, trying remote then local base refs in a fixed order, and report which command produced it.
   0
   installs
8. ▌
   Explaining Code Health · davidvujic

   Use when a user asks what Code Health means, how to interpret scores, or why Code Health matters in daily development.
   0
   installs
9. ▌
   Safeguarding AI Generated Code · davidvujic

   Use when AI-generated or AI-modified changes need a Code Health gate before commit, handoff, or pull request.
   0
   installs
10. ▌
    Guiding Refactoring With Code Health · davidvujic

    Use when refactoring unhealthy code and needing Code Health findings to choose small safe steps and verify improvement.
    0
    installs
11. ▌
    Making The Business Case For Code Health · davidvujic

    Use when a user asks for ROI, stakeholder justification, delivery impact, or defect-risk reduction from improving Code Health in a file.
    0
    installs
12. ▌
    Polylith Diff · davidvujic

    List Polylith bricks whose **implementation** changed since a git tag using `poly diff`. Use for release notes, selective deploys ("which projects need rebuilding?"), and PR scope review. For TEST-code diffs, use `polylith-testing` instead.
    0
    installs
13. ▌
    Polylith Libs · davidvujic

    Inspect third-party libraries used per Polylith project with `poly libs`. Use when the user wants to see dependency usage, audit version drift across projects, find which projects use a given library, or compare library declarations vs. the lock file. Read-only — for a CI gate use `polylith-check` instead.
    0
    installs
14. ▌
    Polylith Sync · davidvujic

    Run `poly sync` to update each project's `[tool.polylith.bricks]` table with the bricks actually imported. Use this whenever a brick is added, removed, or its imports change — and before `poly check` or a release.
    0
    installs
15. ▌
    Polylith Check · davidvujic

    Validate a Polylith workspace with `poly check` — the canonical CI gate. Verifies brick imports against project `pyproject.toml`s, third-party library declarations vs. the lock file, and (under `--strict`) cross-project version consistency. Exits 1 on failure. Use when the user wants to lint, validate, verify, or CI-gate a Polylith workspace.
    0
    installs
16. ▌
    Polylith Testing · davidvujic

    List Polylith bricks and projects affected by **test-code** changes since a git tag using `poly test diff`. Use for selective test runs in CI ("which tests do I need to run?"). For implementation-code diffs, use `polylith-diff` instead.
    0
    installs
17. ▌
    Polylith Concepts · davidvujic

    Provides foundational knowledge about Polylith architecture, including the glossary (bases, components, projects, workspaces), theme layouts, and package manager mapping. Use this when you need to understand Polylith terminology or how the repository is structured conceptually before taking action.
    0
    installs
18. ▌
    Polylith Base Creation · davidvujic

    Create a Polylith base with `poly create base` — the entry point of a deployable application (HTTP API, CLI, message-queue consumer, AWS Lambda handler, GCP Cloud Function, scheduled job). Use when the user wants to add a service, API, endpoint, handler, or any new entry point to a Polylith workspace.
    0
    installs
19. ▌
    Polylith Brick Removal · davidvujic

    Safely remove a Polylith brick (component or base) from the workspace. Use when the user wants to delete, remove, or tear down a component or base.
    0
    installs
20. ▌
    Polylith Workspace Setup · davidvujic

    Scaffold a new Polylith workspace with `poly create workspace`. Use when the user wants to initialize / set up / start / bootstrap Polylith from scratch in a directory (creates `workspace.toml` and the `bases/`, `components/`, `projects/`, `development/` directories).
    0
    installs
21. ▌
    Polylith Component Creation · davidvujic

    Create a Polylith component with `poly create component` — a reusable, isolated brick implementing business logic, a feature, a domain module, or a capability. Use when adding non-entry-point code that bases or other components will import.
    0
    installs
22. ▌
    Polylith Project Management · davidvujic

    Create a deployable Polylith project with `poly create project` — a lightweight `pyproject.toml` under `projects/<name>/` that references bricks for deployment as a Docker image, wheel, AWS Lambda, GCP Cloud Function, or other artifact. Use when the user wants a new deployable, service, microservice, or release target.
    0
    installs
23. ▌
    Polylith Workspace Inspection · davidvujic

    Show **brick × project usage** with `poly info` — which projects use which bricks, plus workspace counts. Use for "workspace overview", "which projects use X", "find orphaned bricks". For brick-to-brick dependencies, use `polylith-dependency-visualization`.
    0
    installs
24. ▌
    Polylith Dependency Management · davidvujic

    Add or manage third-party dependencies in a Polylith workspace. Use when the user wants to install a new library (e.g., requests, fastapi) for a brick or project.
    0
    installs
25. ▌
    Polylith Dependency Visualization · davidvujic

    Visualize **brick × brick** dependencies with `poly deps` — find circular dependencies, inspect a brick's public interface, and detect interface-bypass violations. Use for "what depends on what", "circular deps", "interface violation". For brick × project usage, use `polylith-workspace-inspection`.
    0
    installs
26. ▌
    Polylith Migrate Dedupe · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator` (optional, runs only when opted in during `polylith-migrate-discover`). Do not load directly — load `polylith-migrate-orchestrator` first.] Identify and execute controlled deduplication of code during migration (if the user opts in).
    0
    installs
27. ▌
    Polylith Migrate Discover · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Create `migration/<PROJECT>/state.md` and `migration/<PROJECT>/manifest.md` by inspecting the existing project under `projects/<PROJECT>/`.
    0
    installs
28. ▌
    Polylith Migrate Orchestrator · davidvujic

    [ENTRY POINT] Load this skill first when the user asks to migrate a non-Polylith Python project to Polylith (e.g. "migrate `projects/<name>` to Polylith"). Drives the full migration workflow plus optional tooling conversions; do not load any other `polylith-migrate-*` skill directly — they are sub-skills this orchestrator invokes.
    0
    installs
29. ▌
    Polylith Migrate Update Tests · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Update test files to import from the compatibility shim or the new namespace, ensuring test stability after namespace migration.
    0
    installs
30. ▌
    Polylith Migrate Generate Shim · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Generate a compatibility shim that re-exports all symbols from the new base location to maintain backward compatibility during namespace migration.
    0
    installs
31. ▌
    Polylith Migrate Convert Linter · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator` (optional, runs only when opted in during `polylith-migrate-discover`). Do not load directly — load `polylith-migrate-orchestrator` first.] Align the project's linter and formatter with the **workspace's** configured tool (whatever it is — ruff, black+isort+flake8, pylint, etc.). Removes project-specific config and consolidates rules into the workspace root.
    0
    installs
32. ▌
    Polylith Migrate Refactor Tests · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Restructure unit tests to align with the workspace's Polylith theme.
    0
    installs
33. ▌
    Polylith Migrate Analyze Imports · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Analyze the project's import graph to find how the original namespace is referenced, choose the namespace-rewrite strategy (shim vs shimless), detect circular imports, and list symbols exported by the original namespace.
    0
    installs
34. ▌
    Polylith Migrate Extract To Base · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Extract all application code from `projects/<PROJECT>/` into a temporary migration base.
    0
    installs
35. ▌
    Polylith Migrate Prepare Project · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Clean up the project subfolder and consolidate dependencies after extracting application code into bases.
    0
    installs
36. ▌
    Polylith Migrate Verify Stability · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Verify that the migration did not break the project by running test discovery, checking for circular imports, and ensuring the compatibility shim covers all necessary symbols.
    0
    installs
37. ▌
    Polylith Migrate Distribute Wiring · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Distribute app-wiring code from the residual component into the appropriate bases and shared components.
    0
    installs
38. ▌
    Polylith Migrate Definition Of Done · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Define the criteria for completing the migration process.
    0
    installs
39. ▌
    Polylith Migrate Split Big Component · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Split the big component (`components/<top_ns>/<INITIAL_BASE_NAME>/`) into multiple focused components.
    0
    installs
40. ▌
    Polylith Migrate Convert Type Checker · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator` (optional, runs only when opted in during `polylith-migrate-discover`). Do not load directly — load `polylith-migrate-orchestrator` first.] Align the project's type checker with the **workspace's** configured tool (whatever it is — mypy, pyright, ty, etc.). Removes project-specific config and consolidates settings into the workspace root.
    0
    installs
41. ▌
    Polylith Migrate Automate Import Updates · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Update imports in the new base location to reference the new namespace instead of the original namespace.
    0
    installs
42. ▌
    Polylith Migrate Convert Package Manager · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator` (optional, runs only when opted in during `polylith-migrate-discover`). Do not load directly — load `polylith-migrate-orchestrator` first.] Convert the project's `pyproject.toml` to PEP 621/uv-workspaces format and register it as a uv-workspace member. **Opinionated about uv** — only applies when the workspace itself uses uv. Skip otherwise.
    0
    installs
43. ▌
    Polylith Migrate Detect Circular Imports · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Detect and report circular imports introduced by the namespace migration.
    0
    installs
44. ▌
    Polylith Migrate Resolve Circular Imports · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Resolve circular imports by updating imports in the new base location to avoid referencing the compatibility shim.
    0
    installs
45. ▌
    Polylith Migrate Split Component Internals · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Split monolithic `core.py` files in shared components into domain-focused modules.
    0
    installs
46. ▌
    Polylith Migrate Extract Standalone Modules · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Extract foundational modules (e.g., `consts.py`, `exceptions.py`, or similar) from the residual component into standalone components.
    0
    installs
47. ▌
    Polylith Migrate Isolate Base And Big Component · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Shrink the temporary migration base into thin base(s) + one big component. Bases contain only entrypoints/wiring, while the big component contains everything else.
    0
    installs
48. ▌
    Polylith Migrate Isolate Shared And Project Logic · davidvujic

    [Internal sub-skill of `polylith-migrate-orchestrator`. Do not load directly — load `polylith-migrate-orchestrator` first, which drives all phases.] Identify and isolate shared and project-specific logic in monolithic components (e.g., `models`, `schemas`, or similar).
    0
    installs