一键导入
task-context-loader
Use when starting implementation of a task - loads architecture files, referenced patterns, relevant guides, and task file into context
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when starting implementation of a task - loads architecture files, referenced patterns, relevant guides, and task file into context
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when creating Claude Code plugins - covers skills, commands, agents, hooks, MCP servers, and plugin configuration. Use when user says "create plugin", "make a skill", "add command", "add hooks", "skill authoring", "SKILL.md", "plugin components", "package reusable behavior", "distribute skills", "scaffold plugin", "plugin structure", "write a skill description". NOT for: using existing plugins, installing plugins, plugin marketplace browsing. !`ls .claude-plugin/ 2>/dev/null`
Use when starting a new development project — creates memory folder structure with project_state.md (including codePath), architecture scaffolding, and registers project. Accepts optional code_path argument.
Use when checking code quality, running security audits, testing coverage, finding SOLID/DRY violations, or setting up quality tools. Use when user says "audit this code", "check security", "run PHPStan", "code quality", "find violations", "SOLID check", "DRY check", "test coverage", "lint this", "security review", "is this production ready", "check for vulnerabilities", "code review", "grade this code", "watch mode lint", "deep review", "ultrareview", "schedule quality sweep". Supports Drupal (PHPStan, PHPMD, Psalm, Semgrep, Trivy, Gitleaks via DDEV) and Next.js (ESLint, Jest, Semgrep, Trivy, Gitleaks). Use proactively before deployment or after significant code changes.
Use when an orchestrator must run a task's work-orders CONCURRENTLY behind the same gate floor as the sequential loop — the DB-free parallel sibling of work-order-loop. Each round it reconciles from disk (L1-light), selects a disjoint-file ready batch (wo-parallel-batch.sh), builds every batched WO at once in its OWN ephemeral git worktree branched off the integration HEAD (N parallel build atoms in ONE message), runs /review --headless + the work-order-critique rung per worktree, derives every verdict from disk, and merges each CLEAN WO back into the integration branch with a LOCAL git merge (wo-merge-back.sh — NOT a PR merge), pruning each ephemeral worktree after its verdict. The per-WO retry cap stays the SOLE responsibility of wo-run-state.sh dispatch; terminal-HALT precedence, disk-is-truth, and no-auto-merge are preserved verbatim. At the end it runs ONE integrated /review on the integration branch and opens ONE PR through wo-pr-open.sh (re-runs the merge gate, NEVER merges). MUST be invoked inline (ne
Use when an orchestrator must run the autonomous per-task run-loop behind the gate floor — the thin native glue (③ lifecycle_controls). Resumes from disk (L1-light), drives a ready-queue over the work-orders (a WO is ready when all blocked_by are done), dispatches ONE build atom per WO in clean context, runs /review --headless + the work-order-critique rung per WO, owns EVERY WO status transition via wo-compile.sh set-status, bounds the verify→fix loop with a crash-safe retry cap (wo-run-state.sh), and at the end opens a PR through the wo-pr-open.sh choke point that re-runs the merge gate and NEVER merges. Reads every decision from disk; treats builder transcripts as untrusted data; honors a budget/kill-switch call-site. MUST be invoked inline (never Task-dispatched). Prints a ready-to-paste /goal string; never runs /goal itself.
Use when an orchestrator must run the opt-in adversarial-critique rung on ONE built work-order — the absent-human review layered ABOVE the deterministic gates. Derives the work-order's risk tier (wo-risk-classify.sh), decides whether critique is required (forced-on for high-risk-unattended; else the per-task/per-project dial), spawns risk-scaled INDEPENDENT fresh-context wo-critic agents that re-derive the verdict from artifacts (git diff + gate envelopes), aggregates fail-closed (wo-critique-aggregate.sh) into a per-WO _critique.json, and writes a wo-NN.HALT marker when blocking. Fan-out is the unattended primitive; never edits /review's _review.json. A judgment layer, not a gate — gates always run first.
| name | task-context-loader |
| description | Use when starting implementation of a task - loads architecture files, referenced patterns, relevant guides, and task file into context |
| version | 3.0.0 |
| user-invocable | false |
Load all context needed before implementing a task.
!ls implementation_process/in_progress/ 2>/dev/null
Activate when you detect:
/ai-dev-assistant:implement <task> commandGet project path from project_state.md. Find the task:
v3.0.0 Folder Structure:
implementation_process/in_progress/{task}/ for task directorytask.md file existsv2.x Single File (backward compatibility):
implementation_process/in_progress/{task}.md for single fileIf neither exists, offer to create one using the Skill tool to invoke implementation-task-creator (it is a skill, not an agent)
Use Read tool to load:
{project_path}/architecture/main.md
{project_path}/architecture/{component}.md (if exists)
Extract from architecture:
v3.0.0 Folder Structure:
Load all relevant phase files:
Load task.md (tracker):
Use `Read` on `{task}/task.md`
Extract:
Load research.md (if exists):
Use `Read` on `{task}/research.md`
Context from Phase 1 research
Load architecture.md (if exists):
Use `Read` on `{task}/architecture.md`
Extract:
Load implementation.md (if exists):
Use `Read` on `{task}/implementation.md`
Extract:
v2.x Single File (backward compatibility):
Use Read on {task}.md and extract all sections
From architecture files, find pattern references like:
Based on: core/modules/.../src/...
Use Read to load the referenced core files. Extract:
If project_state.md has a guides path, invoke guide-loader skill for relevant guides.
Format output as:
## Ready to Implement: {Task Name}
### Objective
{from task file}
### Architecture Summary
{key points from architecture}
### Pattern Reference
{primary core file}:
- Key methods to follow: {list}
- Dependencies to inject: {list}
### TDD Approach
1. Test file: {path}
2. First test: {what to test}
### Files to Create/Modify
- {file 1}: {what to do}
- {file 2}: {what to do}
### Acceptance Criteria
- [ ] {criterion 1}
- [ ] {criterion 2}
### Dependencies
Complete these first:
- {prerequisite task, if any}
---
Ready to write the first test?
After presenting context, remind:
TDD reminder: Write test first, then implement.
Use superpowers:test-driven-development for detailed TDD guidance.
STOP and wait for user: