Best for
- Use when breaking a PRP into delegatable tasks or spawning from an issue.
laurigates/claude-plugins/blueprint-plugin/skills/blueprint-work-order/SKILL.md
Create a work-order for isolated subagent execution, optionally linked to a GitHub issue. Use when breaking a PRP into delegatable tasks or spawning from an issue.
Decision brief
Create a work-order for isolated subagent execution, optionally linked to a GitHub issue.
Compatibility matrix
| Platform | Status | Evidence | What to check |
|---|---|---|---|
| Codex | Not declared | No explicit evidence | Portability before use |
| Claude Code | Not declared | No explicit evidence | Portability before use |
| Cursor | Not declared | No explicit evidence | Portability before use |
| Gemini CLI | Not declared | No explicit evidence | Portability before use |
Installation
The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.
npx skills add https://github.com/laurigates/claude-plugins --skill "blueprint-plugin/skills/blueprint-work-order"Inspect the Agent Skill "blueprint-work-order" from https://github.com/laurigates/claude-plugins/blob/5de06622d8def8c36f7f39d980300aaa15af4357/blueprint-plugin/skills/blueprint-work-order/SKILL.md at commit 5de06622d8def8c36f7f39d980300aaa15af4357. List every install step, command, network request, credential, file read/write, external action, and rollback step. Explain whether it fits my task. Do not install or execute anything until I approve.
Workflow
Read docs/blueprint/feature-tracker.json for current phase and tasks
Read PRD files to understand requirements
Should be: Specific: Single feature/component/fix Isolated: Minimal dependencies Testable: Clear success criteria Focused: 1-4 hours of work
Files to modify/create (only relevant ones)
markdown name: blueprint-work-order --- id: WO-NNN created: {YYYY-MM-DD} status: pending implements: Source PRP or PRD - PRP-NNN relates-to: Related documents - ADR-NNNN github-issues: - N ---
Permission review
The documentation asks the agent to run terminal commands or scripts.
bash "${CLAUDE_SKILL_DIR}/../../scripts/get-automation-config.sh"The documentation asks the agent to create, modify, or delete local files.
Proceed with the normal save path (Step 6): the local WO file,The documentation asks the agent to create, modify, or delete local files.
Capture issue number and update work-order file:Evidence record
| Signal | Value | Evidence type | Meaning |
|---|---|---|---|
| Quality score | 94/100 | Computed | Documentation, specificity, maintenance, and trust rules |
| Repository stars | 53 | Source | Repository attention, not individual Skill quality |
| Compatibility | 0 platforms | Source | Declared in the catalog source record |
| Usage guide | automated source guide | Editorial | Generated or reviewed according to the visible evidence level |
Pinned source
Generate a work-order document for isolated subagent execution with optional GitHub issue integration.
| Use this skill when... | Use blueprint-prp-create instead when... |
|---|---|
| You're breaking a PRP into delegatable subagent tasks | You're creating the PRP itself with full research and validation gates |
| You want a focused TDD task packet with minimal context | You need a comprehensive context-gathered implementation plan |
You want to spawn a work-order from an existing PRP (--from-prp) | Use blueprint-prp-execute instead when running an already-written PRP |
You're creating a work-order from a GitHub issue (--from-issue) | Use confidence-scoring instead to evaluate readiness before delegating |
| Flag | Description |
|---|---|
--no-publish | Create local work-order only, skip GitHub issue creation |
--from-issue N | Create work-order from existing GitHub issue #N (a work-order-draft proposal issue is promoted: packet consumed, label swapped to work-order) |
--from-prp NAME | Create work-order from existing PRP (auto-populates context) |
Default behavior: Creates both local work-order AND GitHub issue with work-order label.
Before any closing AskUserQuestion menu, resolve the automation config:
bash "${CLAUDE_SKILL_DIR}/../../scripts/get-automation-config.sh"
When EFFECTIVE_INTERACTION_MODE=quiet and this invocation was
automation-initiated (autopilot, session bookend, drift-nudge follow-up — not
a slash command the user typed), skip closing navigation menus ("what next?" /
"create another?" style): apply the safe default and end with a one-line
receipt instead. Quiet mode never skips confirmation gates that guard writes —
only navigation menus. A direct user invocation always behaves fully
interactively (explicit intent overrides quiet; see ADR-0020).
docs/blueprint/ exists)--from-issue or --from-prp)gh CLI authenticated (unless using --no-publish)--from-prp NAME)When --from-prp NAME is provided:
Read PRP:
cat docs/prps/$NAME.md
Extract PRP content:
.claude/rules/ entries)Verify confidence:
Generate work-order:
Continue to Step 6 (save and optionally publish)
--from-issue N)When --from-issue N is provided:
Fetch issue:
gh issue view N --json title,body,labels,number
Parse issue content:
2a. Promote a work-order-draft proposal (ADR-0020 auto-draft channel):
If the issue carries the work-order-draft label, it is an auto-drafted
proposal from /blueprint:autopilot — its body already IS the full
work-order packet (title form [work-order-draft] PRP-NNN: <title>).
Promotion is the human committing act the draft channel preserves:
gh issue edit N --remove-label "work-order-draft" --add-label "work-order"feature-tracker.json tasks.pending, and the manifest id_registry
mutate HERE, at promotion — never at draft timeGenerate work-order:
042-...)Update issue with link:
gh issue comment N --body "Work-order created: \`docs/blueprint/work-orders/NNN-task-name.md\`"
# Ensure the label exists before applying it
if ! gh label list --search "work-order" --json name | jq -e '.[] | select(.name=="work-order")' >/dev/null 2>&1; then
gh label create work-order --description "AI-assisted work order" --color "0E8A16"
fi
gh issue edit N --add-label "work-order"
Continue to save and report (skip to Step 6 below)
docs/blueprint/feature-tracker.json for current phase and tasksgit status to check uncommitted workgit log -5 --oneline to see recent workShould be:
Good examples:
Bad examples (too broad):
NNN-brief-task-description.mdWork-order structure:
name: blueprint-work-order
---
id: WO-NNN
created: {YYYY-MM-DD}
status: pending
implements: # Source PRP or PRD
- PRP-NNN
relates-to: # Related documents
- ADR-NNNN
github-issues:
- N
---
# Work-Order NNN: [Task Name]
**ID**: WO-NNN
**GitHub Issue**: #N
**Status**: pending
## Objective
[One sentence describing what needs to be accomplished]
## Context
### Required Files
[Only files needed - list with purpose]
### PRD Reference
[Link to specific PRD section, not entire PRD]
### Technical Decisions
[Only decisions relevant to this specific task]
### Existing Code
[Only relevant code excerpts needed for integration]
## TDD Requirements
### Test 1: [Test Description]
[Exact test to write, with code template]
**Expected Outcome**: Test should fail
### Test 2: [Test Description]
[Exact test to write]
**Expected Outcome**: Test should fail
[More tests as needed]
## Implementation Steps
1. **Write Test 1** - Run: `[test_command]` - Expected: **FAIL**
2. **Implement Test 1** - Run: `[test_command]` - Expected: **PASS**
3. **Refactor (if needed)** - Run: `[test_command]` - Expected: **STILL PASS**
[Repeat for all tests]
## Success Criteria
- [ ] All specified tests written and passing
- [ ] [Specific functional requirement met]
- [ ] [Performance/security baseline met]
- [ ] No regressions (existing tests pass)
## Notes
[Additional context, gotchas, considerations]
## Related Work-Orders
- **Depends on**: Work-Order NNN (if applicable)
- **Blocks**: Work-Order NNN (if applicable)
Save to docs/blueprint/work-orders/NNN-task-name.md
Ensure zero-padded numbering (001, 002, 010, 100)
--no-publish)gh issue create \
--title "[WO-NNN] [Task Name]" \
--body "## Work Order: [Task Name]
**ID**: WO-NNN
**Local Context**: \`docs/blueprint/work-orders/NNN-task-name.md\`
### Related Documents
- **Implements**: {PRP-NNN or PRD-NNN}
- **Related ADRs**: {list of ADR-NNNN}
### Objective
[One-line objective from work order]
### TDD Requirements
- [ ] Test 1: [description]
- [ ] Test 2: [description]
### Success Criteria
- [ ] [Criterion 1]
- [ ] [Criterion 2]
---
*AI-assisted development work order. See linked file for full execution context.*" \
--label "work-order"
Capture issue number and update work-order file:
# Extract issue number from gh output
gh issue create ... 2>&1 | grep -oE '#[0-9]+' | head -1
Update the **GitHub Issue**: line in the work-order file with the issue number.
docs/blueprint/feature-tracker.jsonAdd new work-order to pending tasks:
jq '.tasks.pending += [{"id": "WO-NNN", "description": "[Task name]", "source": "PRP-NNN", "added": "YYYY-MM-DD"}]' \
docs/blueprint/feature-tracker.json > tmp.json && mv tmp.json docs/blueprint/feature-tracker.json
Update docs/blueprint/manifest.json ID registry:
{
"id_registry": {
"documents": {
"WO-NNN": {
"path": "docs/blueprint/work-orders/NNN-task-name.md",
"title": "[Task Name]",
"implements": ["PRP-NNN"],
"github_issues": [N],
"created": "{date}"
}
},
"github_issues": {
"N": ["WO-NNN", "PRP-NNN"]
}
}
}
Also update the source PRP/PRD to add this work-order to its tracking.
Work-order created!
ID: WO-NNN
Work-Order: 003-jwt-token-generation.md
Location: docs/blueprint/work-orders/003-jwt-token-generation.md
GitHub Issue: #42 (or "Local only" if --no-publish)
Traceability:
- Implements: PRP-002 (OAuth Integration)
- Related: ADR-0003 (Session Storage)
Objective: [Brief objective]
Context included:
- Files: [List files]
- Tests: [Number of tests specified]
- Dependencies: [Key dependencies]
Ready for execution:
- Can be executed by subagent with isolated context
- TDD workflow enforced (tests specified first)
- Clear success criteria defined
- PR should use "Fixes #42" to auto-close issue
- Commit messages should use: feat(WO-NNN): description
Use AskUserQuestion:
question: "Work-order ready. What would you like to do?"
options:
- label: "Execute this work-order (Recommended)"
description: "Start working on the task with TDD workflow"
- label: "Create another work-order"
description: "Generate the next task from pending items"
- label: "Delegate to subagent"
description: "Hand off for isolated execution"
- label: "I'm done for now"
description: "Exit - work-order is saved and ready"
Based on selection:
/project:continue with work-order context/blueprint:work-order again| Condition | Action |
|---|---|
| No PRDs exist | Guide to write PRDs first |
| No tasks in feature-tracker | Ask for current phase/status |
| Task unclear | Ask user what to work on next |
gh not authenticated | Warn and fallback to --no-publish behavior |
Issue already has work-order label | Warn, ask to update or create new |
Fixes #N in body/titlecompleted/ directoryThe work-order label identifies issues created from this workflow. Create it in your repo if it doesn't exist:
gh label create work-order --description "AI-assisted work order" --color "0E8A16"
Use --no-publish when:
Can publish later by manually creating issue and updating work-order file.
Frequently asked questions
Create a work-order for isolated subagent execution, optionally linked to a GitHub issue.
The source record exposes this install command: npx skills add https://github.com/laurigates/claude-plugins --skill "blueprint-plugin/skills/blueprint-work-order". Inspect the command and pinned source before running it.
Static rules flagged exec-script, write-files in the source; the page lists the matching lines and excerpts.
Alternatives
vasilyu1983/AI-Agents-public
Scans public GitHub repos for agent skills, dev practices, and code patterns. Use when enriching skills, setting team policy, or researching a build domain.
tikalk/adlc-team-skills
Generate a full Architecture Description (AD.md) from accepted ADRs using multi-agent DAG orchestration. Use when accepted ADRs exist and you need to produce or update unified architecture documentation.
ffroliva/gflow-cli
Multi-dimensional LLM council review of an open PR (default) or a local feature branch (§ 8 branch mode, invoked via `/gflow:branch-review`). Five baseline dimensions (correctness, quality, security, tests, memory-hygiene) plus adaptive dimensions per surface (transports / data / CLI / docs / auth / BDD / scripts / release-gate). Each agent invokes specialized skills (security-review, code-review, verify) for its dimension. Reads files via `git show <sha>:<path>` to avoid stale-working-tree fals
apache/airflow
Replace the manual commit-by-commit classification step in `breeze release-management prepare-provider-documentation` with AI-driven classification. For each provider with pending changes, analyze every PR (batched into one sub-agent per provider, not one per PR), pay special attention to potentially breaking changes by inspecting the actual diff, scope multi-provider PRs to the current provider's slice, ask the release manager when uncertain, and apply version bumps + changelog entries. Use dur