From T.L-AutoDevelop-Pro
Queue-aware autonomous .NET development pipeline. Accepts a task text or a task file and auto-merges successful work.
How this skill is triggered — by the user, by Claude, or both
Slash command
/T.L-AutoDevelop-Pro:TLA-developThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
CRITICAL: You are the Main-Claude orchestrator. You do not implement the requested code changes yourself.
CRITICAL: You are the Main-Claude orchestrator. You do not implement the requested code changes yourself.
This command uses the same shared queue as /develop, but it differs in two ways:
sourceCommand = "TLA-develop"Allowed before any worker pipe starts: Read, Glob, Grep, Bash.
Do not edit repository files directly in this skill.
Use one Bash call to verify:
git rev-parse --is-inside-work-tree returns trueIf the check fails, stop and explain the problem.
Find *.sln and *.slnx in the current directory and up to two parent directories.
Use the absolute solution path for all later script calls.
Find scheduler.ps1 from the installed plugin and derive:
scheduler.ps1claude-usage-gate.ps1If scheduler.ps1 cannot be found, stop.
Before doing any queue work, run the shared prepare check:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<scheduler.ps1>" -Mode prepare-environment -SolutionPath "<solution>"
Interpret the prepare result strictly:
status == "blocked": stop and report the blocker before any autonomous queue actionstatus == "ready" or status == "cleaned": continuestatus == "warning": continue, but report the remaining warningsAlways surface:
queueProgressSummaryqueueStallcircuitBreakerInterpret $ARGUMENTS as follows:
Task-file mode rules:
[after: <task id or earlier task number>][priority: high|normal|low][serial]Semantics:
[after: ...] is a hard execution dependency, not just a planning hint.[after: ...] must run in a later wave and must not start in parallel with their dependency target.Every extracted task must be registered with:
taskTextsourceCommand = "TLA-develop"sourceInputType = "file" or "inline"allowNuget = true only if the surrounding task context explicitly requires package installationdeclaredDependenciesdeclaredPriorityserialOnlyUse Windows %TEMP%, not bash /tmp, for all PowerShell-facing paths.
Create one local run id and a shared temp directory such as %TEMP%\claude-develop.
For each new task create:
The prompt file must exist on disk before register-tasks is called.
The scheduler now rejects registrations with a missing, empty, or unreadable promptFile.
Write prompt markdown and registration JSON with explicit UTF-8 encoding.
Do not rely on PowerShell here-strings for JSON escaping; prefer object -> ConvertTo-Json -> UTF-8 file writes so arbitrary Unicode task text survives intact.
Do not inline multiline PowerShell prompt-writing logic inside bash-quoted -Command "..." strings. Write files with direct UTF-8 file writes instead.
After writing each prompt file, verify it is non-empty and still contains a readable task line before calling register-tasks.
Each task prompt file must contain:
## Task
<task text>
## Solution
<absolute solution path>
Run the usage gate in probe mode with -ThresholdPercent 90.
Use this initial probe only to:
Interpret the initial probe strictly:
Important:
Launch-cost constant:
PIPE_USAGE_PERCENT = 8Autonomous wait rules:
fiveHourResetAt is available, call the usage gate in wait mode with the same threshold and let it wait until the gate opens.probe again.wait path.User-facing reporting:
fiveHourUtilizationfiveHourResetAt when availablewait or the conservative 1-hour retry loopPIPE_USAGE_PERCENT% * pipeCount, currently 8% * pipeCount)Use the same queue procedure as /develop:
snapshot-queueregister-taskssnapshot-queue againscheduler-agentapply-plansnapshot-queue againThe planner input must include:
manual_debug_needed tasksUse completedTaskBriefs only as advisory planning context for recently touched files, shared modules, and conflict risk. Do not treat them as hard dependency evidence when they are vague or failure-only.
Before any launch attempt, if the latest queue snapshot reports queueStall.status == "stalled", do one automatic stall-recovery cycle:
scheduler-agent again on the latest snapshotapply-plansnapshot-queue againIf the same queueStall.signature is still stalled after that single recovery cycle, stop and report the stalled queue state instead of looping.
Before starting any task in startableTaskIds, run a fresh launch-gate check for this exact launch set.
Launch-gate procedure:
candidateTaskIds from startableTaskIds, preserving order and excluding tasks already running.candidateTaskIds is empty, do not run the gate and do not start anything.probe mode with -ThresholdPercent 90.probecurrentUsage = fiveHourUtilization from the fresh available probe result.candidateTaskIds that fits under the projected threshold using:
estimatedWaveCost = pipeCount * PIPE_USAGE_PERCENTprojectedUsage = currentUsage + estimatedWaveCostprojectedUsage < 90 fitfiveHourResetAt is available, use gate wait for the no-fit case. If it is not available, stop and report that blocked usage did not include a usable reset time.wait returns unavailable instead of a fresh open result, switch to the normal 1-hour unavailable retry policy.For each task in the allowed fitting launch set, launch:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<scheduler.ps1>" -Mode run-task -SolutionPath "<solution>" -TaskId "<task id>"
The scheduler resolves worker PowerShell in this order:
AUTODEV_POWERSHELL_COMMANDpwsh / pwsh.exepowershell.exeThese workers may run in parallel when their current wave allows it.
Immediately after launching the current wave, hand queue waiting back to the scheduler:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File "<scheduler.ps1>" -Mode wait-queue -SolutionPath "<solution>"
Interpret the wait result strictly:
status == "woke" and reason == "task_completed": snapshot the queue again and continue with section 9status == "woke" and reason == "merge_ready": snapshot the queue again and continue with section 9status == "woke" and reason == "breaker_opened": stop and report the breaker state plus the returned progress snapshotstatus == "woke" and reason == "queue_changed": snapshot the queue again, report the changed progress state, and continue conservatively with section 9status == "timeout": report the returned progress snapshot and stop cleanly without inventing your own shell sleep or re-entry loopDo not replace scheduler waiting with sleep, timeout, or ad hoc polling commands.
Report to the user:
manual_debug_neededusageProjectionqueueProgressSummaryrunningTaskProgressqueuedTaskProgressrecentQueueEventsIf circuitBreaker.status == "manual_override", report that the breaker is temporarily suppressed until manualOverrideUntil.
Do not reduce this to only "started" / "queued" lines when richer progress data is available.
Whenever wait-queue wakes or you re-enter while tasks may have progressed:
queueStall.status == "stalled", do one automatic stall-recovery cycle:
scheduler-agent on the latest snapshotapply-plansnapshot-queue againqueueStall.signature is still stalled, report that the queue remains stalled and stop instead of loopingqueueProgressSummaryrunningTaskProgressqueuedTaskProgressmergeTaskProgressrecentQueueEventssourceCommand.nextMergeTaskId is present, call prepare-merge, then inspect the returned task record and its sourceCommand.sourceCommand = "TLA-develop", call resolve-merge -Decision commit immediately.sourceCommand = "develop", stop and ask the user to test it before any merge commit.nextMergeTaskId may stay empty even when pendingMergeTaskIds is non-empty. This is expected while other tasks in the same wave are still queued or running. Detached worker retries no longer block merge turns for already finished wave work.
Use a normal English merge commit message that describes the actual change. Do not use squash wording.
For TLA-develop, if merge preparation fails only because local dev hosts are locking build outputs, the scheduler may automatically taskkill the blocking Visual Studio / IIS Express style processes once and retry the merge build.
If prepare-merge fails:
The scheduler may preserve an accepted branch and retry merge preparation separately when the worker result itself is still valid.
The scheduler owns retries.
Treat these task states as retryable scheduled work:
If a task enters manual_debug_needed, do not treat it as an ordinary scheduled retry. Report that repeated inconclusive investigation produced no new evidence and that the task now waits for repo changes, replanning, or explicit requeue.
Each task gets at most 3 full attempts.
If a task reaches terminal failure, report that clearly.
Run the scheduler-agent planning pass whenever the queue materially changes:
queueStall.status == "stalled"Do not continue using stale wave assignments after the queue changed. Do not continue using stale usage information either. Every launch decision must use a fresh usage probe plus projected wave cost.
Keep updates short and factual. Report:
When progress fields are present, prefer structured status lines over generic text like "No output available."
npx claudepluginhub tleiott/t.l-marketplace4cctoolz --plugin T.L-AutoDevelop-ProWorkflow optimizations for .NET developers using Claude Code: parallel git worktrees, plan mode, token budget discipline, and verification loops. Activates on productivity, context, or workflow mentions.
Orchestrates task execution with git worktree isolation, TDD implementation, validation loop, and merge for phrases like 'execute task N' or 'implement TASK-NNN'.
Executes implementation plans by dispatching fresh subagents per task with dependency analysis, concurrent execution, and built-in two-stage self-review for spec compliance and code quality.