Source profileQuality 94/100Review permissions

laurigates/claude-plugins/blueprint-plugin/skills/blueprint-work-order/SKILL.md

blueprint-work-order

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.

Source repository stars
53
Declared platforms
0
Static risk flags
2
Last source update
2026-08-24
Source checked
2026-08-25

Decision brief

What it does: where it fits

Create a work-order for isolated subagent execution, optionally linked to a GitHub issue.

Best for

  • Use when breaking a PRP into delegatable tasks or spawning from an issue.

Not for

  • Tasks that require unconfirmed production actions or broad system permissions.
  • Environments where the pinned source and install steps cannot be inspected.

Compatibility matrix

Platform support, with evidence labels

PlatformStatusEvidenceWhat to check
CodexNot declaredNo explicit evidencePortability before use
Claude CodeNot declaredNo explicit evidencePortability before use
CursorNot declaredNo explicit evidencePortability before use
Gemini CLINot declaredNo explicit evidencePortability before use
Open the compatibility checker

Installation

Inspect first. Install second.

The source command is displayed only when detected. A safe inspection prompt is always available so your agent can explain every action before execution.

Source-detected install commandSource
npx skills add https://github.com/laurigates/claude-plugins --skill "blueprint-plugin/skills/blueprint-work-order"
Safe inspection promptEditorial

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

What the source asks the agent to do

  1. 01

    Step 1: Analyze Current State

    Read docs/blueprint/feature-tracker.json for current phase and tasks

    Read docs/blueprint/feature-tracker.json for current phase and tasksRun git status to check uncommitted workRun git log -5 --oneline to see recent work
  2. 02

    Step 2: Read Relevant PRDs

    Read PRD files to understand requirements

    Read PRD files to understand requirementsIdentify next logical work unit based on:Work-overview progress
  3. 03

    Step 3: Determine Next Work Unit

    Should be: Specific: Single feature/component/fix Isolated: Minimal dependencies Testable: Clear success criteria Focused: 1-4 hours of work

    Specific: Single feature/component/fixIsolated: Minimal dependenciesTestable: Clear success criteria
  4. 04

    Step 4: Determine Minimal Context

    Files to modify/create (only relevant ones)

    Files to modify/create (only relevant ones)PRD sections (only specific requirements for this task)Existing code (only relevant excerpts, not full files)
  5. 05

    Step 5: Generate Work-Order

    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 ---

    Number: Find highest existing work-order number + 1 (001, 002, etc.)Name: NNN-brief-task-description.mdPRP-NNN

Permission review

Static risk signals and limitations

Runs scripts

medium · line 28

The documentation asks the agent to run terminal commands or scripts.

bash "${CLAUDE_SKILL_DIR}/../../scripts/get-automation-config.sh"

Writes files

medium · line 101

The documentation asks the agent to create, modify, or delete local files.

Proceed with the normal save path (Step 6): the local WO file,

Writes files

medium · line 277

The documentation asks the agent to create, modify, or delete local files.

Capture issue number and update work-order file:

Evidence record

Why each signal appears

EvidenceSourceComputedTestedEditorial
SignalValueEvidence typeMeaning
Quality score94/100ComputedDocumentation, specificity, maintenance, and trust rules
Repository stars53SourceRepository attention, not individual Skill quality
Compatibility0 platformsSourceDeclared in the catalog source record
Usage guideautomated source guideEditorialGenerated or reviewed according to the visible evidence level

Pinned source

Provenance and original SKILL.md

Repository
laurigates/claude-plugins
Skill path
blueprint-plugin/skills/blueprint-work-order/SKILL.md
Commit
5de06622d8def8c36f7f39d980300aaa15af4357
License
MIT
Collected
2026-08-25
Default branch
main
View the original SKILL.md

Generate a work-order document for isolated subagent execution with optional GitHub issue integration.

When to Use This Skill

Use this skill when...Use blueprint-prp-create instead when...
You're breaking a PRP into delegatable subagent tasksYou're creating the PRP itself with full research and validation gates
You want a focused TDD task packet with minimal contextYou 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

Flags

FlagDescription
--no-publishCreate local work-order only, skip GitHub issue creation
--from-issue NCreate work-order from existing GitHub issue #N (a work-order-draft proposal issue is promoted: packet consumed, label swapped to work-order)
--from-prp NAMECreate work-order from existing PRP (auto-populates context)

Default behavior: Creates both local work-order AND GitHub issue with work-order label.

Interaction Mode

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).

Prerequisites

  • Blueprint Development initialized (docs/blueprint/ exists)
  • At least one PRD exists (unless using --from-issue or --from-prp)
  • gh CLI authenticated (unless using --no-publish)

Mode: Create from PRP (--from-prp NAME)

When --from-prp NAME is provided:

  1. Read PRP:

    cat docs/prps/$NAME.md
    
  2. Extract PRP content:

    • Parse frontmatter for id, confidence score, implements references
    • Extract Objective section
    • Extract Implementation Blueprint tasks
    • Extract TDD Requirements
    • Extract Success Criteria
    • Note curated-rule references (.claude/rules/ entries)
  3. Verify confidence:

    • If confidence < 9: Warn that PRP may not be ready for delegation
    • Ask to proceed anyway or return to refine PRP
  4. Generate work-order:

    • Pre-populate from PRP content
    • Include relevant curated rules as inline context (not references)
    • Copy TDD requirements verbatim
    • Include file list from PRP's Codebase Intelligence section
  5. Continue to Step 6 (save and optionally publish)

Mode: Create from Existing Issue (--from-issue N)

When --from-issue N is provided:

  1. Fetch issue:

    gh issue view N --json title,body,labels,number
    
  2. Parse issue content:

    • Extract objective from title/body
    • Extract any TDD requirements or success criteria if present
    • Note existing labels

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:

  • Consume the packet verbatim as the work-order content (the draft body supersedes step 3's re-generation; still verify the referenced PRP exists and its confidence is current — warn if it dropped below 9)
  • In step 4, additionally swap the labels: gh issue edit N --remove-label "work-order-draft" --add-label "work-order"
  • Proceed with the normal save path (Step 6): the local WO file, feature-tracker.json tasks.pending, and the manifest id_registry mutate HERE, at promotion — never at draft time
  1. Generate work-order:

    • Number matches issue number (e.g., issue #42 → work-order 042-...)
    • Pre-populate from issue content
    • Add context sections (files, PRD reference, etc.)
  2. 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"
    
  3. Continue to save and report (skip to Step 6 below)


Mode: Create New Work-Order (Default)

Step 1: Analyze Current State

  • Read docs/blueprint/feature-tracker.json for current phase and tasks
  • Run git status to check uncommitted work
  • Run git log -5 --oneline to see recent work
  • Find existing work-orders (count them for numbering)

Step 2: Read Relevant PRDs

  • Read PRD files to understand requirements
  • Identify next logical work unit based on:
    • Work-overview progress
    • PRD phase/section ordering
    • Git history (what's been done)

Step 3: Determine Next Work Unit

Should be:

  • Specific: Single feature/component/fix
  • Isolated: Minimal dependencies
  • Testable: Clear success criteria
  • Focused: 1-4 hours of work

Good examples:

  • "Implement JWT token generation methods"
  • "Add input validation to registration endpoint"
  • "Create database migration for users table"

Bad examples (too broad):

  • "Implement authentication"
  • "Fix bugs"

Step 4: Determine Minimal Context

  • Files to modify/create (only relevant ones)
  • PRD sections (only specific requirements for this task)
  • Existing code (only relevant excerpts, not full files)
  • Dependencies (external libraries, environment variables)

Step 5: Generate Work-Order

  • Number: Find highest existing work-order number + 1 (001, 002, etc.)
  • Name: NNN-brief-task-description.md

Work-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)

Step 6: Save Work-Order

Save to docs/blueprint/work-orders/NNN-task-name.md Ensure zero-padded numbering (001, 002, 010, 100)

Step 7: Create GitHub Issue (unless --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.

Step 8: Update docs/blueprint/feature-tracker.json

Add 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

Step 8.5: Update Manifest

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.

Step 9: Report

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

Step 10: Prompt for Next Action

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:

  • "Execute this work-order" → Run /project:continue with work-order context
  • "Create another work-order" → Run /blueprint:work-order again
  • "Delegate to subagent" → Provide handoff instructions for subagent execution
  • "I'm done" → Exit

Key Principles

  • Minimal context: Only what's needed, not full files/PRDs
  • Specific tests: Exact test cases, not vague descriptions
  • TDD enforced: Tests specified before implementation
  • Clear criteria: Unambiguous success checkboxes
  • Isolated: Task should be doable with only provided context
  • Transparent: GitHub issue provides visibility to collaborators

Error Handling

ConditionAction
No PRDs existGuide to write PRDs first
No tasks in feature-trackerAsk for current phase/status
Task unclearAsk user what to work on next
gh not authenticatedWarn and fallback to --no-publish behavior
Issue already has work-order labelWarn, ask to update or create new

GitHub Integration Notes

Completion Flow

  1. Work completed on work-order
  2. PR created with Fixes #N in body/title
  3. Work-order moved to completed/ directory
  4. Issue auto-closes when PR merges

Label Convention

The 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"

Offline Mode

Use --no-publish when:

  • Working offline
  • Private experimentation
  • Issue visibility not needed

Can publish later by manually creating issue and updating work-order file.

Frequently asked questions

What to verify before installation and use

What does the blueprint-work-order source document cover?

Create a work-order for isolated subagent execution, optionally linked to a GitHub issue.

How do I install blueprint-work-order?

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.

Which permission-related actions were detected?

Static rules flagged exec-script, write-files in the source; the page lists the matching lines and excerpts.

Alternatives

Compare before choosing

Computed 9880

vasilyu1983/AI-Agents-public

research-git

Scans public GitHub repos for agent skills, dev practices, and code patterns. Use when enriching skills, setting team policy, or researching a build domain.

Computed 95131

tikalk/adlc-team-skills

architect-implement

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.

Computed 95125

ffroliva/gflow-cli

pr-council-review

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

Computed 9446,599

apache/airflow

prepare-providers-documentation

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