When an agent is woken by a comment (Resume Delta or Wake Payload), the
skill now explicitly instructs it to skip Steps 1-4 (identity, approvals,
inbox, pick work) and go directly to checkout. This prevents agents from
wastefully fetching their full assignment list and announcing "checking my
paperclip tasks" when they already know exactly which issue to work on.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Add explicit Paperclip skill guidance for reviewer/approver heartbeats and document that execution-policy decisions use PATCH /api/issues/:issueId rather than a separate endpoint.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Document blockedByIssueIds field, issue_blockers_resolved and
issue_children_completed wake reasons, and blockedBy/blocks response
arrays in both SKILL.md and api-reference.md so agents know how to
set and use first-class issue dependencies.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Greptile flagged that worked examples in task-workflow.md and
api-reference.md still used ["todo"] instead of the full
expectedStatuses array. Aligned them with the rest of the PR.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Root cause: when someone commented on an in_review task, the heartbeat
wakeup was triggered but the agent couldn't re-checkout the task because
expectedStatuses only included todo/backlog/blocked. The in_review status
was never handled in the checkout flow or the heartbeat procedure.
Changes:
- Add wakeCommentId to issue_commented and issue_reopened_via_comment
context snapshots (consistent with issue_comment_mentioned)
- Add in_review to checkout expectedStatuses in heartbeat skill
- Update Step 3 fallback query to include in_review status
- Update Step 4 to prioritize in_review tasks when woken by comment
- Add explicit issue_commented wake reason handling in Step 4
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Adds a new skill that documents how to create and manage Paperclip
routines — recurring tasks that fire on a schedule, webhook, or API
call and dispatch an execution issue to the assigned agent.
Drop "api" from the trigger kind dropdown and disable the "webhook"
option with a "COMING SOON" label until it's ready.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
- Add updateCompanyBrandingSchema restricting agent-updatable fields to name,
description, brandColor, and logoAssetId
- Update PATCH /api/companies/:companyId to allow CEO agents with branding-only
fields while keeping admin fields (status, budget, etc.) board-only
- Allow agents to GET /api/companies/:companyId for reading company info
- issuePrefix (company slug) remains protected — not in any update schema
- Document branding APIs in SKILL.md quick reference and api-reference.md
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Add upload, list, get content, and delete attachment endpoints
to the Key Endpoints table so agents know about the attachments API.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Resolve conflicts by keeping the issue-documents work alongside upstream heartbeat-context, worktree branding, and adapter runtime updates.
Co-Authored-By: Paperclip <noreply@paperclip.ing>
Add commit co-author requirement for Paperclip agents and fix markdown
lint issues (blank lines before lists, table column alignment).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Document the agent local-cli command for manual CLI usage and add a
step-by-step self-test playbook for validating assignment flows.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
New Steps 3-5 in the release skill:
- Step 3: Publish canary to npm with --tag canary (latest untouched)
- Step 4: Smoke test canary in Docker (uses existing smoke infrastructure)
- Step 5: Promote canary to latest after verification
Also updates idempotency table for new intermediate states (canary
published but not promoted) and adds release flow summary.
Script changes still needed: --canary flag for release.sh, --promote
command for dist-tag promotion.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- release-changelog: Step 0 checks for existing changelog file before
generating. Asks reviewer to keep/regenerate/update. Never overwrites
silently. Clarifies this skill never triggers version bumps.
- release: Step 0 idempotency table covering all steps. Tag check before
npm publish prevents double-release. Task search before creation prevents
duplicate follow-up tasks. Supports iterating on changelogs pre-publish.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
