ワンクリックで
pwrl-work-triage
Classify work input and extract foundational context for execution
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
メニュー
Classify work input and extract foundational context for execution
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Extract, classify, deduplicate, structure, and save learnings from code, commits, tasks, and documentation
Create structured implementation plans with three tiers (Fast/Standard/Deep). Pure skill pipeline orchestrator—no agent routing.
Review code changes through 4-phase micro-skill pipeline (scope, prepare, analyze, report)
Execute implementation work efficiently through 4-phase micro-skill pipeline
Verify repository state and confirm session completion before committing.
Create a clear session commit with state and next steps. Orchestrates checkpoint and commit micro-skills, optionally chains to pwrl-learnings.
| name | pwrl-work-triage |
| description | Classify work input and extract foundational context for execution |
| argument-hint | [Task file path, plan path, or bare prompt. Leave blank to use latest task] |
ask_user_question, ask_user, ask_user_input, vscode/askQuestions or any available extension/tool for user interaction for all decisionsPurpose: Entry point to the work execution workflow. Classifies the input (task file, plan file, or bare prompt), extracts relevant context, estimates complexity, resolves dependencies, and returns a structured context object for downstream skills.
<input_document> #$ARGUMENTS </input_document>
| Type | Detection | Example |
|---|---|---|
| Task file | Contains unit-id in YAML frontmatter | docs/tasks/to-do/2026-06-05-u1-task.md |
| Plan file | No unit-id in frontmatter, points to docs/plans/ | docs/plans/2026-06-05-001-plan.md |
| Bare prompt | Neither of the above | "Add email validation to user signup" |
After triage, produce a context object with fields varying by input type:
inputType: task | plan | prompt
complexity: trivial | small | medium | large
blockedBy: []
# Type-specific fields below
Detailed shape per input type is documented in each classification section.
Determine the input type:
docs/tasks/ and points to a file with unit-id in frontmatter → Task filedocs/plans/ or contains plan in filename → Plan fileWhen input is a task file path:
Step 1 — Read frontmatter:
Extract these fields from the YAML frontmatter:
| Field | Required | Description |
|---|---|---|
unit-id | Yes | Stable task identifier (e.g., S1, U1) |
plan | Yes | Relative path to linked plan file |
status | Yes | Current status: to-do, in-progress, for-review, done |
dependencies | No | List of task unit-ids this depends on |
files | No | List of primary files affected by this task |
github-issue | No | GitHub issue number (if linked to an issue) |
created | No | Creation date |
Step 2 — Load linked plan file:
plan fieldStep 3 — Resolve dependencies:
docs/tasks/INDEX.md (or INDEX-S*.md) to check each dependency's statusdone or for-review → dependency metto-do or in-progress → add to blockedBy listblockedBy as "missing"Step 4 — Estimate complexity (from task scope):
files count and task body lengthtrivialsmallmediumlargeStep 5 — Discover cross-plan dependencies (NEW):
docs/plans/*.md for all active plan filesStep 6 — Check for circular dependencies (multi-plan scope, UPDATED):
Output context:
inputType: task
taskFile: docs/tasks/to-do/2026-06-05-u1-task.md
unit-id: S1
plan: docs/plans/2026-06-05-002-plan.md
status: to-do
dependencies: [S2, S3]
files: [src/utils.ts, src/api.ts]
githubIssue: 123 # or null if absent
complexity: medium
blockedBy: []
dependencyChain: [S2 → S3 → S4]
globalDependencyGraph: { S1: [S2, S3], S2: [U1], U1: [] }
crossPlanDeps: [{ from: S2, fromPlan: plan-002, to: U1, toPlan: plan-001 }]
When input is a plan file path (no unit-id):
Step 1 — Read plan frontmatter:
| Field | Description |
|---|---|
id | Plan identifier (e.g., 2026-06-05-002) |
tier | Planning tier: Fast, Standard, Deep |
status | active, draft, archived |
created | Creation date |
updated | Last update date |
Step 2 — Extract implementation units:
### U1, ### S1, **U1:**)Step 3 — Estimate complexity from unit count:
| Units | Complexity | Expected Mode |
|---|---|---|
| 1-2 | trivial / small | Inline execution |
| 3-5 | medium | Serial execution |
| 6+ | large | Serial with possible parallel subsets |
Output context:
inputType: plan
planFile: docs/plans/2026-06-05-002-plan.md
planId: 2026-06-05-002
tier: Standard
planStatus: active
units:
- unit-id: U1
name: Input Triage
files: [pwrl-work-triage/SKILL.md]
approach: Extract Phase 0 logic
- unit-id: U2
name: Environment Setup
files: [pwrl-work-prepare/SKILL.md]
approach: Extract Phase 1 logic
complexity: medium
estimatedTasks: 5
When input is a freeform text description:
Step 1 — Estimate complexity by heuristic:
Apply rules in order:
| Signal | Complexity |
|---|---|
| Single file, no behavior change (rename, config, styling) | trivial |
| 1-2 files, clear bounded scope, no cross-cutting concerns | small |
| 3-5 files, moderate logic, behavior change, tests needed | medium |
| 6+ files, architectural work, security, payments, auth, core systems | large |
Step 2 — Scan codebase for context:
Step 3 — Warn if complexity is large:
If complexity is large:
/pwrl-plan workflow firstOutput context:
inputType: prompt
prompt: "Add email validation to user signup"
complexity: medium
complexitySignals:
- "Affects 3-5 files"
- "Behavior changes to existing logic"
- "Multiple test scenarios needed"
relatedPatterns:
- "src/validators/phone.ts" # similar validation pattern
planningRecommended: false
After classifying input, ask the user to choose their engagement level for this workflow. Use the platform's ask_user_question extension (or equivalent) to present the following three options:
Question: "How would you like to proceed with this workflow?"
Options:
docs/learnings/pattern/interaction-mode-three-mode-propagation-2026-06-29.md §"Future Refinements" for the full risk-classification roadmap.Store selection in context:
interactionMode: detailed | smart | yolo
Propagation: The interactionMode value flows into pwrl-work-prepare, pwrl-work-execute, pwrl-work-review, and pwrl-work-sync-status artifacts. Each downstream phase reads the value and adjusts its confirmation behavior:
Backward compatibility note: Downstream phases (e.g., older pwrl-work-execute builds) that still assume a two-value enum must treat any value other than detailed as yolo until upgraded. The smart value is new as of 2026-06-29.
| Scenario | Handling |
|---|---|
| Task file not found | Log path; ask user: "Provide a different path or create a new task?" |
| Plan file not found | Log path; ask user: "Provide a different path or use /pwrl-plan?" |
| Circular dependencies | Walk dep tree; fail with Circular: [A→B→C→A]; ask user to resolve |
| Missing dependencies | Log; add to blockedBy; warn: "Not found in INDEX. Proceeding may cause ordering issues." |
| Input is empty | Ask user: "What would you like to work on?" |
| File unreadable | Log error; ask user: "Cannot read file. Retry or provide different path?" |
| Malformed frontmatter | Log details; ask user to fix frontmatter and retry |
Complexity is large (bare prompt) | Warn; require user confirmation before proceeding |
| Task references non-existent plan | Warn; proceed with caution |
Retry limit: 3 attempts per operation, then ask user to fix manually.
Fallback: If all retries fail, log the error and ask user: "Retry, skip, or abort?"
.pwrlrc.json — For GitHub integration check (though actual syncing happens in pwrl-work-sync-status)docs/analysis/2026-06-05-pwrl-work-structure-analysis.mdpwrl-work skill (Phase 0: Triage Input, lines 26-48)pwrl-work-prepare (consumes this skill's output context)