← all publishers

Axidify

@axidify source repo

Report this profile Claim this profile

• 19 skills
• 0 followers
• 10 hours ago last updated

1. ▌
   CI · axidify

   Investigates failed CI checks or GitHub Actions on a branch or PR. Use when the user says CI failed, checks are red, or /ci. Maps failure to local repro.
   0 installs
2. ▌
   Pr · axidify

   Creates or updates a pull request with summary and test plan. Use when the user asks to open a PR, push for review, or says /pr. Only push when explicitly asked (or when invoked as Phase 0 of a requested release).
   0 installs
3. ▌
   Plan · axidify

   Designs an implementation approach before writing code. Use when the user asks to plan, design, architect, scope, or outline a feature; or says /plan. Do not implement until the user approves.
   0 installs
4. ▌
   Test · axidify

   Runs and interprets automated tests for a module or the whole project. Use when the user asks to test, verify behavior, check coverage, or says /test.
   0 installs
5. ▌
   Audit · axidify

   Brief project status (/status) or evidence-backed feature gap analysis (/audit). Use for "what's next", session pulse, what's implemented, or gap tables. Not for pre-commit diff review (review).
   0 installs
6. ▌
   Debug · axidify

   Finds root cause of bugs or unexpected behavior. Use for errors, failures, hydration issues, regressions, or when the user says /debug. Proposes a minimal fix; asks before implementing unless the user already asked to fix it.
   0 installs
7. ▌
   Review · axidify bundle

   Structured pre-commit code review in three passes: security, performance, clean code. Use when the user asks for a review, sanity check, or says /review; or before opening a PR. Runs build/tests when available. For deep security or performance use security or performance.
   0 installs
8. ▌
   Onboard · axidify

   Gets a first-time or broken local dev environment runnable. Use after clone, when install fails, when the user asks to set up the project, or before first implement. Complements discover-project with hands-on setup steps.
   0 installs
9. ▌
   Release · axidify

   Full ship flow: open a PR, merge it to main, then cut a semver release (version bump, changelog, docs, build verify, tag, push). Use when the user says release, /release, ship, or merge and release. Only commit, tag, or push as part of this requested flow (or when the user explicitly asks).
   0 installs
10. ▌
    Document · axidify

    Updates documentation to match the codebase. Use when the user asks to document, update docs, fix doc drift, or says /document. Supports module scope or organize pass for the whole docs tree.
    0 installs
11. ▌
    Refactor · axidify

    Improves code structure without changing behavior. Use for cleanup, deduplication, rename passes, or /refactor. Proposes first; implements after approval.
    0 installs
12. ▌
    Security · axidify

    Deep security review of code changes or a module. Use when the user asks for security review, threat check, or before auth, payments, or PII. Complements review pass 1. Not a substitute for professional pentest.
    0 installs
13. ▌
    Implement · axidify

    Implements a scoped code change with inspect-report-verify discipline. Use when the user asks to implement, build, add, fix, or create something; or says /implement. Not for question-only, plan-only, or unexplained-failure debugging.
    0 installs
14. ▌
    Performance · axidify

    Performance review of code changes or a hot path. Use when the user asks about slowness, optimization, N+1, bundle size, or scalability. Complements review pass 2. Not for micro-optimizing without evidence.
    0 installs
15. ▌
    Issue Tracking · axidify

    Track bugs, enhancements, and features in the current project's issue system. Use when the user asks to file, list, fix, close, or update an issue; mentions issue-log, GitHub Issues, Linear, or issue-style workflows.
    0 installs
16. ▌
    Discover Project · axidify

    Discovers how an unfamiliar repository is built before planning or implementing. Use when entering a new project, after clone, when stack or scripts are unclear, or when the user asks how this repo works.
    0 installs
17. ▌
    UI Browser Check · axidify

    Use Playwright MCP to inspect a running web app when the user reports a visual or interaction issue but cannot describe it precisely. Use when they mention layout, spacing, wrong copy, button behavior, hydration flash, or "something looks off" on any page or route.
    0 installs
18. ▌
    Web Design Engineer · axidify bundle

    High-quality visual design for standalone Web artifacts (HTML/React-CDN prototypes, slide decks, dashboards, motion demos) and design-led UI work in existing apps when exploration or craft matters. Use for: landing pages, interactive prototypes, HTML presentations, data-viz demos, design-system exploration, design critique, explicit browser acceptance/QA of artifacts, turning mockups/PRDs into viewable artifacts, or polishing UI with explicit design intent. Prefer implement for scoped app changes without a design exploration phase (bugfix, small feature, refactor). Prefer ui-browser-check when a running app "looks off" but code is unclear. Not for: back-end-only work, CLI tools, performance tuning, source-to-longform article conversion, or narration-driven click-through video presentations.
    0 installs
19. ▌
    Plan Driven Implementation · axidify bundle

    Executes features from a living docs/plans/*.md file: per-task implement, backend test, browser test, update plan (progress, issues, diversions), commit. Use when implementing from an implementation plan, updating plan progress, authoring docs/plans/, or when the user asks to follow the plan document or keep the plan updated. After plan approval, use instead of ad-hoc implement for multi-phase initiatives.
    0 installs