com um clique
pwrl-work-triage
Classify work input and extract foundational context for execution
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Menu
Classify work input and extract foundational context for execution
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional 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)