What makes pr-prep notable?

1.6K downloads. Trust evidence available

How should pr-prep be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

pr-prep

Prepares pull requests by running quality gates, drafting descriptions, and validating tests Skill: pr-prep Owner: athola Summary: Prepares pull requests by running quality gates, drafting descriptions, and validating tests Tags: latest:1.9.19 Version history: v1.9.19 | 2026-08-26T13:20:31.922Z | user Release v1.9.19 v1.9.17 | 2026-07-30T05:40:35.559Z | user Release v1.9.17 v1.9.16 | 2026-07-14T19:57:29.055Z | user Release v1.9.16 v1.9.14 | 2026-06-30T18:05:20.969Z | user Release v1.9.14 v1.9.13 | 2026-06-27

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.6k

Updated

Oct 10, 2026

Version

1.9.19

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.6K downloads reported by the source. Last updated 10/10/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 10, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 10, 2026
Adoption signal: 1.6K downloadsadoption · observed Oct 10, 2026
Latest release: 1.9.19release · observed Aug 26, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17emme0e2m3cpf7k2jvp3a84984b8z9:nm-sanctum-pr-prep

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-athola-nm-sanctum-pr-prep/snapshot"

Documentation

CLAWHUB

144,646 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: pr-prep
description: |
  Prepares pull requests by running quality gates, drafting descriptions, and validating tests
version: 1.9.8
triggers:
  - git
  - pr
  - pull-request
  - quality-gates
  - testing
  - completing a feature and ready for review
metadata: {"openclaw": {"homepage": "https://github.com/athola/claude-night-market/tree/master/plugins/sanctum", "emoji": "\ud83e\udd9e", "requires": {"config": ["night-market.sanctum:shared", "night-market.sanctum:git-workspace-review", "night-market.imbue:proof-of-work", "night-market.imbue:justify", "night-market.imbue:structured-output", "night-market.scribe:slop-detector", "night-market.scribe:doc-generator"]}}}
source: claude-night-market
source_plugin: sanctum
---

> **Night Market Skill** — ported from [claude-night-market/sanctum](https://github.com/athola/claude-night-market/tree/master/plugins/sanctum). For the full experience with agents, hooks, and commands, install the Claude Code plugin.


# Pull Request Preparation Workflow

## Usage

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.

## Required Progress Tracking

Create `TodoWrite` items for these steps before starting:
1. `pr-prep:workspace-reviewed`
2. `pr-prep:quality-gates`
3. `pr-prep:self-reviewed`
4. `pr-prep:changes-summarized`
5. `pr-prep:testing-documented`
6. `pr-prep:pr-drafted`
7. `pr-prep:content-verified`

Mark each item as complete as the section is finished.

## Step 1: Review Workspace (`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.

## Step 2: Run Quality Gates (`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`.

### Capabilities Reference Sync

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.

## Step 2.5: Self-Review Pass (`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:**

```bash
# 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 f

_meta.json

{
  "ownerId": "kn7d107jg9jv602h9ytsegydq184a42s",
  "slug": "nm-sanctum-pr-prep",
  "version": "1.9.19",
  "publishedAt": 1787750431922
}

modules/pr-template.md

# Pull Request Template Structure

## Standard Template Sections

### 1. Summary (Required)
Brief 1-2 sentence description of what the PR accomplishes and why.

**Good Examples:**
```markdown
## Summary
Add support for modular skills to reduce token usage and improve skill maintainability through progressive loading.
```

```markdown
## Summary
Fix authentication bug causing session timeout errors by implementing proper token refresh logic.
```

**Avoid:**
- Implementation details (save for Changes section)
- Vague descriptions like "various improvements"
- AI/tool attribution

### 2. Changes (Required)
Bullet list of specific changes grouped logically, explaining both what and why.

**Structure:**
```markdown
## Changes
- **Category 1**: What changed and why
  - Sub-detail if needed
- **Category 2**: What changed and why
- **Breaking changes**: Highlight any breaking changes first
```

**Good Examples:**
```markdown
## Changes
- **API**: Add `read_yaml()` and `to_pdf()` functions for symmetric I/O pattern
- **Session Management**: Introduce `ResumeSession` class to centralize configuration
- **Documentation**: Update README with new API examples and migration guide
- **Breaking**: Remove deprecated `generate_pdf()` function (use `to_pdf()` instead)
```

### 3. Testing (Required)
List each validation step taken, with commands and results.

**Format:**
```markdown
## Testing
- `make test` - all 47 tests passing
- `make lint` - no warnings
- `pytest --cov` - 94% coverage (up from 89%)
- Manual verification: Tested PDF generation with 3 resume templates
- CI will run: cross-platform tests, integration tests
```

**Include:**
- Exact commands run
- Pass/fail status and counts
- Coverage changes if significant
- Manual testing performed
- What will run in CI (if different from local)

### 4. Checklist (Required)
Standard quality checklist for all PRs.

**Template:**
```markdown
## Checklist
- [ ] Code follows project style guidelines
- [ ] Tests pass locally
- [ ] Documentation updated if needed
- [ ] Breaking changes documented (if applicable)
```

**Extended Checklist (for complex PRs):**
```markdown
## Checklist
- [ ] Code follows project style guidelines
- [ ] Tests pass locally
- [ ] Tests added/updated for new functionality
- [ ] Documentation updated if needed
- [ ] Breaking changes documented (if applicable)
- [ ] Migration guide provided (if needed)
- [ ] Backward compatibility maintained (or breaking change justified)
- [ ] Performance impact assessed
- [ ] Security implications reviewed
```

## Optional Sections

### Screenshots/Visual Changes
For UI, CLI output, or visual changes:
```markdown
## Screenshots
**Before:**
[screenshot or command output]

**After:**
[screenshot or command output]
```

### Follow-up TODOs
For work deferred to future PRs:
```markdown
## Follow-up Work
- [ ] Add integration tests for edge cases (Issue #123)
- [ ] Update deployment documentation
- [ ] Performance optimization for large files
```

### Issue Referenc

modules/quality-gates.md

# Quality Gates Pattern Reference

## Common Quality Gate Commands by Language

### Python Projects
```bash
# Formatting
make format          # or: black . && isort .
ruff format .
uv run ruff format .

# Linting
make lint            # or: ruff check .
mypy .
pylint src/

# Testing
make test            # or: pytest
pytest --cov=src --cov-report=term
uv run pytest
```

### JavaScript/TypeScript Projects
```bash
# Formatting
npm run format       # or: prettier --write .
yarn format

# Linting
npm run lint         # or: eslint .
yarn lint

# Testing
npm test
yarn test
jest --coverage
```

### Go Projects
```bash
# Formatting
go fmt ./...
gofmt -w .

# Linting
golangci-lint run
go vet ./...

# Testing
go test ./...
go test -v -cover ./...
```

### Rust Projects
```bash
# Formatting
cargo fmt

# Linting
cargo clippy -- -D warnings

# Testing
cargo test
cargo test --all-features
```

## Failure Handling Patterns

### When Quality Gates Fail
1. **Capture the exact error output** - Don't summarize, show actual failures
2. **Fix failures immediately** - Never proceed with failing tests
3. **Re-run after fixes** - Confirm all gates pass before continuing
4. **Document what was fixed** - Include in PR testing section

### Common Failure Categories
- **Formatting issues**: Auto-fix with formatter, then re-run
- **Linting warnings**: Address or document why they're acceptable
- **Test failures**: Fix the code or update tests as needed
- **Type errors**: Resolve type mismatches or add proper annotations

## Alternative Validation Approaches

### When Local Tests Can't Run
- **Missing dependencies**: Document what's missing and CI strategy
- **Environment constraints**: Note platform-specific limitations
- **Integration tests**: Explain which will run in CI only
- **Manual verification**: Document steps taken locally instead

### CI/CD Integration Notes
```markdown
## Testing
- Local: `make test` - all unit tests passing
- CI will run: integration tests, E2E tests, cross-platform builds
- Manual verification: Tested CLI commands locally on Ubuntu 22.04
```

## Quality Gate Checklist
- [ ] Formatting passes (no diffs after format command)
- [ ] Linting passes (no warnings or errors)
- [ ] All tests pass locally
- [ ] Type checking passes (if applicable)
- [ ] Build succeeds (if applicable)
- [ ] Manual smoke testing completed

## Special Cases

### Pre-commit Hooks
If project has pre-commit hooks:
```bash
pre-commit run --all-files
```
Document any hooks that were run.

### Multiple Test Suites
```bash
# Unit tests
pytest tests/unit/

# Integration tests
pytest tests/integration/

# E2E tests (may run in CI only)
# Skipped locally - runs in CI environment
```

### Performance Tests
Note if performance benchmarks exist but weren't run:
```markdown
## Testing
- Unit tests: passing
- Performance benchmarks: skipped (run in dedicated CI job)
```

modules/todowrite-patterns.md

---
parent_skill: sanctum:shared
name: todowrite-patterns
description: TodoWrite naming conventions and patterns for sanctum skills
category: patterns
tags: [todowrite, naming, conventions]
estimated_tokens: 150
---

# TodoWrite Patterns for Sanctum

## Naming Convention
All sanctum skills follow a consistent pattern for TodoWrite items:
```
<skill-name>:<step-name>
```

The skill name matches the frontmatter `name` field, and the step name describes the specific workflow phase.

## Examples from Sanctum Skills

### git-workspace-review
```
git-review:repo-confirmed
git-review:status-overview
git-review:diff-stat
git-review:diff-details
```

### commit-messages
Commit messages skill does not use TodoWrite as it's a single-step artifact generation workflow.

### pr-prep
```
pr-prep:workspace-reviewed
pr-prep:quality-gates
pr-prep:self-reviewed
pr-prep:changes-summarized
pr-prep:testing-documented
pr-prep:pr-drafted
pr-prep:content-verified
```

### doc-updates
```
doc-updates:context-collected
doc-updates:targets-identified
doc-updates:consolidation-checked
doc-updates:edits-applied
doc-updates:guidelines-verified
doc-updates:accuracy-verified
doc-updates:preview
```

### version-updates
```
version-update:context-collected
version-update:target-files
version-update:version-set
version-update:docs-updated
version-update:verification
```

## Task Deletion (Claude Code 2.1.20+)

TaskUpdate now supports deleting tasks. Use deletion to clean up completed workflow items and reduce clutter in the `/tasks` view.

> **2.1.21 fix**: Task IDs are no longer reused after deletion. On 2.1.20, deleting a task and creating a new one could silently reuse the same ID, leaking old state into new tasks. Upgrade to 2.1.21+ if using task deletion.

### When to Delete
- After a workflow completes successfully and all items are marked done
- Stale items from interrupted or abandoned workflows
- Temporary tracking items that served their purpose

### When NOT to Delete
- Items that serve as audit trails (proof-of-work items)
- Items referenced by other active workflows
- Items the user may want to review later

### Deletion Pattern
```
# After workflow completion, clean up tracking items:
TaskUpdate(id: "pr-prep:workspace-reviewed", delete: true)
TaskUpdate(id: "pr-prep:quality-gates", delete: true)
```

### Recommended Approach
Create → Complete → (optionally) Delete stale items after workflow success. Keep proof-of-work and audit items intact.

## Best Practices

### Step Naming
- Use present tense verbs (collected, identified, applied, verified)
- Keep names concise (2-3 words max)
- Make the outcome clear from the name
- Order steps sequentially in the workflow

### When to Skip TodoWrite
- Single-step workflows (like commit-messages)
- Quick utilities that complete in one operation
- Read-only analysis with no discrete phases

### Integration
- Create all TodoWrite items at workflow start
- Mark items complete immediately after finishing each step
- Use TodoWrite as

Github ReposUpdated 15h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.