lwpt

Cuts a release so the tag always contains its own changelog: computes the next version from the conventional commits, writes the changelog and bumps the version on a release branch, opens a release pull request, and only after it is squash-merged tags the merge commit and waits for CI to publish the GitHub release — never a changelog pull request that lands after the tag and isn't in the release. Uses a version passed in by the user, or otherwise recommends one from the changes since the last release and asks the user to confirm before proceeding. Defaults to git-cliff for changelog generation but works with any changelog tool or a hand-maintained changelog, and bumps the version with the project's own tooling regardless of language. Use when the user runs /create-release or asks to cut, tag, or publish a release, bump the version, or generate release notes.

Prepare LWPT for a release by running the full project and E2E gates, checking the latest cross-platform CI result, auditing architecture drift across source and documentation, previewing the changelog, applying approved truth-sync fixes, and opening a draft preparation PR. Stops before version selection, changelog generation, tagging, or publishing, which belong to /create-release. Use when the user runs /prepare-release or asks to prepare LWPT for a release.

Turns a raw idea or feature request (no GitHub issue) into a confirmed mini-spec by asking follow-up questions about scope, desired outcome, and success criteria, then implements it with the same rigor as /implement-issue: reads AGENTS.md/area context, VISION.md when present, and applicable stack/conventions skills, runs a full-context investigation, invokes the grill skill when registered, presents two to four distinct options, and stops for the user's choice before coding unless automatic mode was requested, updates the branch against origin's default branch, implements the chosen option, searches project context for DEFINITION_OF_READY.md before implementation, runs verification (UI/UX checks plus the project's full check gate), reviews against the spec's success criteria and project-context DEFINITION_OF_DONE.md before handoff, runs a /review code review, and always hands off via /create-pr. Use when the user runs /implement-idea or wants to build something that is not an existing issue.

Creates a well-structured GitHub issue from a tagline or short description in any repository, investigating for duplicates, reading VISION.md when present, and invoking the grill skill (grill-with-docs / grill-me) as a mandatory gate before drafting, using the project's issue template and label conventions, and capturing UI/UX context (screenshots, design references, accessibility, responsive, theme) when the change is user-facing. Use when the user runs /create-issue or asks to file a GitHub issue.

Validates a GitHub issue against the current codebase, reading the nearest AGENTS.md/CLAUDE.md, VISION.md when present, area context, and any applicable stack/conventions skills first. Runs a full-context investigation (real project commands, whole code path, no shortcuts), handles already-fixed issues by closing or adding regression tests, invokes the grill skill when registered, then presents implementation options and stops for the user's choice before coding unless automatic mode was requested. Updates the branch against origin's default branch, implements the chosen option, searches project context for DEFINITION_OF_READY.md before implementation, runs verification (UI/UX checks plus the project's full check gate), reviews against the issue's acceptance criteria and project-context DEFINITION_OF_DONE.md before handoff, runs a /review code review, and always hands off via /create-pr. Use when the user runs /implement-issue with an issue number.

Review a project's roadmap from freshly-pulled data — assess current state and release cadence, measure delivery velocity from history, and verify candidate work against the source — then produce a parallelized, throughput-anchored version plan, and (optionally, on confirmation) create the milestones and issues. Use when the user wants to review the roadmap, plan upcoming versions/releases, decide when to cut the next release, or sequence a backlog into a realistic plan.

Commits relevant local changes, merges the remote default branch when the branch is behind, pushes to the current PR branch, and refreshes PR title/body when stale. Use when the user runs /update-pr or asks to update a pull request with the latest commits.

Commits relevant local changes, pushes a focused branch, and opens a draft pull request on the current GitHub repository using the project's PR template (single or multi-template). Use when the user runs /create-pr.

Default git workflow for the user's repositories: feature branches off the remote default branch, merge (never rebase) to take baseline updates, plain pushes (no --force or --force-with-lease), always-new commits (no amend), and squash-merge for all pull requests. Use when running any git action — branching, syncing, conflict resolution, committing, pushing, or merging — on the user's repos.

Language-agnostic repo structure conventions used across the user's projects in any language — the user-facing README.md structure (name, logo, description, install, usage, optional background, contribution, references), the docs/ template (application, architecture, code-style, quick-start, tooling, deployment), the AGENTS.md template with a Hard Constraints section (symlinked to CLAUDE.md), nested area AGENTS.md for multi-area repos, optional CONTRIBUTING.md, the canonical VISION.md, DEFINITION_OF_READY.md, and DEFINITION_OF_DONE.md governance files, the pre-commit hook contract with Lefthook as the default and explicit alternatives, scripts directory in the project's own language, co-located tests, the .agents/skills folder symlinked to .claude/skills, and changelog generation with git-cliff. Stack-specific tools (test runners, linters, generators) live in the matching stack skill. Use when scaffolding or restructuring any repo, writing AGENTS.md or docs, or laying out folders.

Resolves outstanding review comments on the current pull request by replying in-thread and pushing fixes in any GitHub repository, without leaving new top-level PR or issue comments. Prefers the /resolve-reviews skill when it is available and falls back to a standalone workflow otherwise. Use when the user runs /review-pr.

Defines the user's FreePascal toolchain — FPC as the compiler in Delphi mode by default, the contract every project's build system must satisfy, the contract every project's formatter / linter must satisfy, Lefthook pre-commit, and co-located unit tests. Implementation of the build system and the formatter is the project's choice (Pascal program, Makefile, shell script, etc.) as long as the contract holds. Implementation specifics for any individual project (engine rules, spec compliance, runtime configuration, etc.) belong in that project's own AGENTS.md and docs. Use when scaffolding or working in a FreePascal project that follows this toolchain.