From sanctum
Prepares pull requests by running quality gates like linting/tests, drafting descriptions, self-reviewing changes, and tracking progress with TodoWrite before submission.
npx claudepluginhub athola/claude-night-market --plugin sanctumThis skill uses the workspace's default tool permissions.
Use this skill to stage changes and generate a PR summary. Run `Skill(sanctum:git-workspace-review)` first to capture the repository state and diffs.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Use this skill to stage changes and generate a PR summary. Run Skill(sanctum:git-workspace-review) first to capture the repository state and diffs.
Create TodoWrite items for these steps before starting:
pr-prep:workspace-reviewedpr-prep:quality-gatespr-prep:self-reviewedpr-prep:changes-summarizedpr-prep:testing-documentedpr-prep:pr-draftedpr-prep:content-verifiedMark each item as complete as the section is finished.
workspace-reviewed)Confirm that Skill(sanctum:git-workspace-review) is complete. If changes were staged after the initial review, re-execute the skill to refresh the context.
quality-gates)Execute formatting, linting, and tests using project-specific commands (e.g., make fmt, make lint, make test). Resolve all failures before proceeding. If a task cannot be executed locally, document the reason and the alternative validation performed. Language-specific commands and failure handling are detailed in modules/quality-gates.md.
If any plugin files changed (plugin.json, skills, commands,
agents, or hooks), run make docs-sync-check to verify
book/src/reference/capabilities-reference.md is current.
If it reports discrepancies, run /sync-capabilities --fix
or update the reference manually before proceeding.
self-reviewed)Read the diff as if you are a reviewer seeing it for the first time. This catches scope creep, stale debug code, and unclear changes before anyone else spends time on them.
Automated checks:
# Check for debug statements left in
git diff --cached --name-only | xargs grep -nE \
'(console\.log|print\(|debugger|TODO|FIXME|HACK|XXX)' \
2>/dev/null || true
# Check for commented-out code blocks (3+ consecutive lines)
git diff --cached | grep -c '^+.*//.*[a-zA-Z]' || true
# Check for formatting-only commits mixed with feature work
git log --oneline $(git merge-base HEAD origin/master)..HEAD | \
grep -iE '(fmt|format|lint|style|whitespace)' || true
Manual verification:
TODO markers left inIf issues are found, fix them before proceeding.
changes-summarized)Use the notes from the workspace review and the output of git diff --stat origin/main...HEAD to understand the scope. Identify key points in the diffs and group them into 2-4 paragraphs highlighting the technical changes and their rationale. Note breaking changes, migrations, or documentation updates.
testing-documented)List each test command executed and its result. Include manual verification steps where relevant. If tests were skipped, document the reason and the mitigation plan.
pr-drafted)Populate the standard template with Summary, Changes, Testing, and Checklist sections. Include issue references, screenshots, or follow-up TODO items. Template structure and examples are available in modules/pr-template.md.
content-verified)Apply Skill(scribe:slop-detector) principles to the draft. Verify that the PR description avoids tier-1 slop words (delve, comprehensive, leverage, utilize, robust, seamless) and formulaic phrases like "I'd be happy to" or "It should be noted." Ensure there is no AI attribution in the text and that all claims are grounded with evidence such as commands, numbers, or filenames. Use active voice and maintain a balanced structure with prose for context.
If the description contains slop, apply Skill(scribe:doc-generator) principles to ground claims with specifics, remove marketing language, and use direct statements.
Write the final PR description to the specified path, then display the file path and its contents for confirmation.
Do not include tool or AI attribution in the PR text. If changes are required mid-process, re-run quality gates. This skill covers preparation; pushing changes and opening the PR occurs outside this workflow.
If project-specific commands like make or npm are unavailable, verify the environment setup against the README. For permission errors, check write access to build directories. If a step fails without clear output, retry the command with verbose flags to inspect the logs.