agigante80

Analyse the current project and recommend the forge-kit components that fit it - subagents, skills, commands, and hooks - grouped by type with a per-item reason, then adapt and install the ones you pick (rewritten for your stack, not copy-pasted). Use for first-time setup OR ongoing maintenance ("am I up to date?", "what governance am I missing?"). Secondary modes: "refresh"/"drift" reports which installed components are behind forge-kit (version-marker based) and "refresh <name>" deep-compares and updates one while preserving project adaptation; "forge-adapt contributions" surfaces project-only components worth contributing back; "forge-adapt templates" audits issue templates and can install the template lockstep guard + canonical ticket-standards doc. Backward-compatible: also triggered by "upgrade-audit".

Migrate a repository from GitHub to a self-hosted Forgejo instance: push the repo, adopt the forge-host adapter, resolve the .github/workflows dual-execution surprise, port CI to .forgejo/workflows with Forgejo-specific rules (services-by-name, docker-out-of-docker compose, gate expensive jobs), register a runner, and optionally push-mirror back to GitHub. Generic and portable; host-specific runner/storage tuning is delegated to a project infra reference. Use when moving one or more repos to your own Forgejo.

Run governed, unattended overnight work. Pulls from a defined work source (gated tickets, tickets to gate, or investigations like full/security reviews that create tickets), implements safe work as branch-plus-PR without ever merging, defers you-only decisions instead of guessing, and writes a morning report. Use when the user says to work overnight, run unattended, keep going while they are away, or asks to set up autonomous overnight work. Driven by /loop; not a single unbounded session.

Persist what mattered from the current conversation before the session ends or context is lost. Writes durable facts (user identity, feedback with rationale, ongoing project constraints, references) to the project's .claude/memory/ store and transient resume state (what was done, what is unfinished, next steps, open questions) to a dated .claude/handoffs/ note. Use when the user says to close the session, wrap up, save what we discussed, or before they step away.

Make governance components forge-host-aware (GitHub or self-hosted Forgejo/Gitea) instead of GitHub-only. Ships a thin shell adapter (forge-lib.sh) that detects the host per-repo and exposes host-agnostic forge_* operations (issues, comments, releases/tags, CI status) backed by `gh` for GitHub and `curl`+REST for Forgejo. Additive and backward-compatible: a repo with no Forgejo config behaves exactly as before. Use when a project is migrating repos from GitHub to a self-hosted Forgejo, when a component shells out to `gh` but the repo may be on Forgejo, or when you need deterministic per-repo host detection.

Find genuinely dead / unused / unreachable SOURCE code - unused functions, classes, methods, exports, and unreachable branches that a linter's local-scope rules miss. Wraps the right whole-program tool for the stack (vulture, knip, go deadcode, etc.) with a curated allowlist for the project's dynamic-reference patterns so findings are low-noise and safe to act on. Generic skill - forge-adapt tailors the tool, paths, and false-positive patterns to the project. Use when the user asks to "find dead code", "remove unused code", "what code is unused", "dead-code scan", or "clean up the codebase" before a refactor or release.

Enforce and automate releases in CI so a promotion to the production branch can never silently ship without a version bump. Installs a release gate (block a PR that did not bump the version past the last release) plus, on the same shared version<->tag primitive, optional auto-release lanes (auto-release a dependency-bot update; auto-release every merge on a CD trunk). The enforced/automated sibling of the invoked `release` skill. Generic template - forge-adapt tailors the production branch, version source, and CI provider. Use when the user asks to "enforce version bumps", "block merge without a release", "auto release on merge", "auto-release dependency updates", or "stop forgetting to tag releases".

Cut a versioned release - bump the project's semver across all version sources, keep doc version markers in sync, verify CI is green, tag, and close the tickets the release shipped. Includes a version-check guard (fail if version sources disagree) for CI/pre-commit. Generic skill - forge-adapt tailors the version files, branching model, tag format, and publish pipeline to the project. Use when the user asks to "release", "cut a release", "bump the version", "ship vX.Y.Z", or "tag a release".

Author or revise content for the Wander & Tales children's story-kit library: story narration (simple and rich reading levels), world lore, canon registry entries, puzzles, idea banks, rules-page text, and the Guide for the Grown-Up, in British English (en-GB, canonical) and the synced locales kept in step with it (defined in build/locales.py REQUIRED_LOCALES; currently Spanish from Spain es-ES, Italian it-IT, and European Portuguese pt-PT). Use this skill whenever you write, draft, translate, or edit any kid-facing or grown-up-facing prose or YAML content for Wander & Tales (any world or story, including The Floating Isles / The Sleeping Garden and the Greek-myth world), even when the request only says "write the story", "draft the narration", "add a creature", "translate this to Spanish", or "write the grown-up guide". It encodes the no-lose, kind-and-imaginative ethos, the writing constraints (no em or en dashes), the associational (non-causal) claims rule, reading-level and peril-tone guidance, the en-GB-

Use when writing, translating, or reviewing Wander & Tales content in peninsular Spanish (es-ES, Spain), or before publishing an es-ES build. It guards against the recurring problems (addressing the players as "ustedes" instead of "vosotros", voseo, and Latin-American vocabulary) plus spelling and accent drift, and it enforces the project rules (no-lose tone, no dashes, canon names, associational claims). Trigger on "check the Spanish", "review es-ES", "is this peninsular Spanish", "fix the Spanish register", "before publishing Spanish", or any task that authors or edits es-ES prose. The add-language skill invokes this when the new locale is es-ES.

Use when writing, translating, or reviewing Wander & Tales content in Italian (it-IT), or before publishing an it-IT build. It guards against the recurring problems (the formal "Lei" for players instead of "voi", stiff textbook phrasing instead of warm colloquial Italian, anglicisms, and homograph accent slips like e/e or da/da) and enforces the project rules (no-lose tone, no dashes, canon names, associational claims). Trigger on "check the Italian", "review it-IT", "is this natural Italian", "fix the Italian register", "before publishing Italian", or any task that authors or edits it-IT prose. The add-language skill invokes this when the new locale is it-IT.

Use when writing, translating, or reviewing Wander & Tales content in European Portuguese (pt-PT), or before publishing a pt-PT build. It guards against the two recurring native-speaker problems (the archaic "vós" register and Brazilian gerunds) plus pt-BR vocabulary, wrong clitic placement, and spelling drift, and it enforces the project rules (no-lose tone, no dashes, canon names, associational claims). Trigger on "check the Portuguese", "review pt-PT", "is this European Portuguese", "fix the Portuguese register", "before publishing Portuguese", or any task that authors or edits pt-PT prose. The add-language skill invokes this when the new locale is pt-PT.

Use when a maintainer wants to add a whole new language (locale) to the Wander & Tales project, for example "add German", "add European Portuguese", "add pt-BR", "support French", "translate the whole project into Polish". This is the maintainer-side, project-wide counterpart to create-story (which adds one story). It wires the locale through the build code, the test fixtures, every world's content (canon, heroes, idea banks, and every story at both reading levels), the repo-wide lexicon and the shared Guide, updates the docs and skills, then validates, rebuilds every kit, and publishes. Defers all voice, register, reading-level, peril-tone, and canon-name rules to the authoring-story-content skill. Trigger on "add <language>", "add a language", "support <language>", "make the kits available in <language>".

Use when a maintainer wants to publish a newly added or just-merged Wander & Tales story or world to the library: make sure every declared image exists (generating the missing ones with the maintainer's key), double-review the translations, build the kits, refresh the root README catalogue, confirm the PDFs render correctly, and commit. This is the maintainer-side counterpart to the create-story skill. Trigger on requests like "publish this story", "publish the kits", "a story was merged, build and publish it", "release the new world", or "rebuild and update the README".

Use when a user wants to create their own Wander & Tales story (or a new world) and build their own printable kit to play at home. Guides choosing or creating a world, choosing or writing an idea, setting the audience and challenges, authoring the content in all the project's required languages (see build/locales.py) with image prompts, optionally generating the pictures with the user's own OpenAI key (or leaving prompts to paste elsewhere), validating, and building the printable PDFs into dist/. Defers all voice, reading-level, peril-tone, and canon-name rules to the authoring-story-content skill. Sharing the story with the public library is optional and handled by the separate contribute-story skill. Trigger on requests like "create a story", "make my own adventure", "make a kit about X", "write a new story to print", or "start a new world".

Use when someone has created a Wander & Tales story (with the create-story skill or by hand) and wants to share it with the public library by opening a draft pull request. Needs a GitHub account. Handles the contribution trust model, prepares the branch with the content (and optionally the author's own pictures, never built PDFs), and opens a draft PR for a maintainer to review. Defers all voice and content rules to the authoring-story-content skill. Trigger on requests like "contribute my story", "open a PR with my story", "share my story upstream", "add my story to the library", or "submit my adventure".

The develop-to-main release. Fast-forward main to develop, tag the new version, confirm the publish pipeline is green, AND close the implemented tickets the release ships. Use whenever the user asks to "release", "merge to main", "ship to main", "push to main", "cut a release", "do a release", "release vX.Y.Z", or "promote develop to main". This is the ONLY sanctioned path to main; implement-ticket and merge-pr deliberately stop at develop.

Enforce and automate releases in CI so a promotion to main can never silently ship without a version bump. Documents and governs the release gate (block a main promotion that did not bump VERSION past the last vX.Y.Z tag) plus, on the same VERSION<->tag primitive, the auto-release lanes that already ship in this repo (auto-release a verified @actual-app/api dependency update). The enforced/automated sibling of the invoked `release` skill. Use when the user asks to "enforce version bumps", "block merge without a release", "auto release on merge", "auto-release dependency updates", or "stop forgetting to tag releases".

OWASP API Security Top 10 testing patterns, injection payloads, auth bypass vectors, and security test generation for the actual-mcp-server MCP API. Use when writing security tests, reviewing tools or HTTP endpoints for vulnerabilities, or auditing input validation and authorization.

Analyse every GitHub fork of this repo, and every meaningful BRANCH within each fork, to find features and functionality the forks added that upstream does not have, as a source of ideas to implement. For each newly-identified idea it opens a gate-ready GitHub tracking ticket (crediting the origin fork and original author, linking the exact code to review, flagging that the imported external code MUST get a security review, and requiring positive plus negative scenarios and test cases before implementation). Maintains docs/audit/FORK_ANALYSIS.md as a cache so unchanged fork branches are skipped on the next run. Use whenever the user asks to "analyse the forks", "what do the forks add", "scan forks for features", "fork feature scan", "any new ideas from forks", or wants to harvest fork ideas, even if they do not say the word "fork-analysis".

End-to-end implementation pipeline for a GitHub issue in actual-mcp-server: gate the ticket to 10/10, implement it, validate, code-review it, and either fix findings inline or spin them into their own tickets, then commit + bump + push to develop. Use this whenever the user asks to implement, build out, do, work, or ship a ticket or issue by number, e.g. "implement ticket 167", "implement #178", "do issue 142", "build out ticket 90", or "/implement-ticket 178", even if they do not name every step. Do NOT use it for merely reading, triaging, gating, or reviewing a ticket without implementing it, or for code changes that are not tied to a specific issue number.

Handle a request to merge a GitHub pull request in actual-mcp-server WITHOUT ever merging it directly. Instead, create a gate-ready GitHub ticket to integrate the PR's change onto develop, run that ticket through the full implement-ticket pipeline (gate to 10/10, implement, validate, code review, mandatory /local-env full, commit + patch bump + push develop, confirm CI green), then close the original PR as superseded. The change only ever reaches main later through the normal develop-to-main release. Use this whenever the user asks to merge, accept, land, or pull in a pull request by number or reference, e.g. "merge PR 179", "merge this pull request", "land the dependabot PR", "accept #42", or "/merge-pr 179". Do NOT use it for the develop-to-main release itself, or for git branch merges that are not GitHub PRs.

Enforce and automate releases in CI so a promotion to the production branch can never silently ship without a version bump. Installs a release gate (block a PR that did not bump the version past the last release) plus, on the same shared version<->tag primitive, optional auto-release lanes (auto-release a dependency-bot update; auto-release every merge on a CD trunk). The enforced/automated sibling of the invoked `release` skill. Generic template - forge-adapt tailors the production branch, version source, and CI provider. Use when the user asks to "enforce version bumps", "block merge without a release", "auto release on merge", "auto-release dependency updates", or "stop forgetting to tag releases".

Find genuinely dead / unused / unreachable SOURCE code in VPNSentinel — unused functions, classes, methods, and unreachable branches that flake8's local-scope rules (F401/F811/F841) miss. Wraps vulture with a curated allowlist for this project's dynamic-reference patterns (Flask routes, console_scripts entry points, health subprocesses, the re-export shim, Telegram string dispatch, daemon threads) so findings are low-noise and safe to act on. Use when asked to "find dead code", "remove unused code", "what code is unused", "dead-code scan", or "clean up the codebase" before a refactor or release.

Expert on the VPNSentinel codebase, VPN monitoring operations, DNS leak detection, and the distributed client-server architecture. Activate for any question about VPNSentinel development, debugging, deployment, or monitoring.

Manage the VPNSentinel local Docker E2E environment — start, stop, rebuild, status, logs, and a genuine end-to-end verify. Use when asked to bring the stack up locally, tear it down, or prove the system works end-to-end on Docker before/after changes.

Add a LinkedIn article to the site. Fetches metadata, downloads cover image, adds entry to articles.ts, and publishes (commit + push).

Scan github.com/agigante80 for public repos and reconcile with the portfolio. Auto-adds new repos at Tier 3, refreshes existing project pages whose underlying repo has changed since the MDX was last edited, marks newly-archived repos, and surfaces tier-vs-popularity mismatches based on multi-signal engagement (stars, forks, npm, PyPI, Docker Hub pulls). One commit per sync. Recoverable via `git revert HEAD`.

Create or enrich one project on the skytale.it portfolio. Given a GitHub repo URL it scaffolds a new project MDX when none exists; given an existing project slug it enriches that project with the v5 template fields (tagline, links, stats, audience, quickstart, comparison) and optionally refines the body. Commits per project. For a batch reconcile across every repo use /sync-projects instead.

Review an incoming redesign or patch zip before it is applied. Extracts the patch, audits every file for compatibility with the current codebase, scans for forbidden em and en dashes, and reports findings with an apply recommendation. Does not apply, build, or commit anything.