skills/prompt-generator/SKILL.md
Generate implementation prompts for phase-based project execution using an orchestration pattern. Use when users request prompts for implementing project phases, need orchestration prompts for multi-step implementations, ask for "/prompt", "generate prompt", "create implementation prompt", or want to create structured implementation instructions for subagent delegation. Outputs the prompt to chat and saves to docs/prompts folder.
npx skillsauth add mhylle/claude-skills-collection prompt-generatorInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Generate structured implementation prompts for phase-based project execution using an orchestrator/subagent pattern.
When triggered, gather these inputs from the user:
| Variable | Description | Example |
|----------|-------------|---------|
| PHASE_NUMBER | Phase identifier | "1", "2", "3" |
| PHASE_NAME | Descriptive phase name | "Foundation", "Data Pipeline" |
| PHASE_DOC_PATH | Path to phase plan document | /project/docs/plans/01-foundation.md |
| PROJECT_ROOT | Project root directory | /home/user/myproject |
| GENERAL_PLAN_PATH | Path to general plan (optional) | /project/docs/plans/00-general-plan.md |
| ADR_PATH | Path to ADR directory (optional) | /project/docs/decisions/ |
ADR Integration: The generated prompt will instruct the orchestrator to:
Ask the user for required variables. If context provides these values, confirm them:
To generate the implementation prompt, I need:
1. Phase number (e.g., 1, 2, 3)
2. Phase name (e.g., "Foundation", "Data Pipeline")
3. Path to the phase document
4. Project root directory
5. Path to general plan (optional)
Read the template from references/implementation-prompt-template.md and substitute all {PLACEHOLDER} values with user-provided inputs.
scripts/save_prompt.py to save to <PROJECT_ROOT>/docs/prompts/echo "<generated_prompt>" | python scripts/save_prompt.py <project_root> <phase_number> <phase_name>
The file is saved as: docs/prompts/phase-<N>-<name>.md
The generated prompt includes:
| Task Type | Pattern | Concurrency | |-----------|---------|-------------| | File creation (independent) | Parallel | High (5-7) | | File creation (dependent) | Sequential | Low (1-2) | | Testing/Validation | Per test suite | Medium (3-5) | | Docker/Infrastructure | Per service | Medium (3-4) | | Integration | Per integration point | Low (2-3) |
The generated prompt follows this structure:
Implement Phase {N}: {Name} of the trading platform...
IMPORTANT ORCHESTRATION REQUIREMENTS:
1. This is an ORCHESTRATION SESSION...
2. Use the implement-plan skill...
3. Spawn SUBAGENTS for all implementation...
4. Track progress using TodoWrite...
5. Coordinate subagents and validate...
## Implementation Strategy
[Phase overview, orchestration workflow, delegation patterns]
## Error Handling
[Failure analysis, rollback, escalation]
## Success Criteria Validation
[Automated and manual checks]
## Handoff to Next Phase
[Update implementation plan, completion documentation, context prep, clean state]
Generated prompts are automatically discovered and used by the implementation skills:
1. prompt-generator creates: docs/prompts/phase-2-data-pipeline.md
↓
2. implement-plan discovers prompt via Glob("docs/prompts/phase-*.md")
↓
3. implement-plan passes prompt path to implement-phase
↓
4. implement-phase uses prompt for detailed orchestration instructions
↓
5. On completion, implement-phase archives to: docs/prompts/completed/
Prompts must follow this naming pattern for auto-discovery:
docs/prompts/phase-<N>-<name>.md
Examples:
docs/prompts/phase-1-foundation.md → Phase 1
docs/prompts/phase-2-data-pipeline.md → Phase 2
docs/prompts/phase-3-agent-system.md → Phase 3
docs/prompts/
├── phase-1-foundation.md # Pending - ready for implementation
├── phase-2-data-pipeline.md # Pending - ready for implementation
├── phase-3-agent-system.md # Pending - ready for implementation
└── completed/ # Archived after successful completion
├── phase-1-foundation.md # Completed
└── phase-2-data-pipeline.md # Completed
implementation-prompt-template.md: Full prompt template with all placeholders and patternssave_prompt.py: Saves generated prompts to docs/prompts/ with metadata headertools
--- name: tt-workflow-build description: Tasktracker-native trigger for a PARALLEL build via the Claude Code Workflow tool. Thin by design — it does two things, then drives to done: (1) ensure a tasktracker project exists (use the existing one, or create one), then (2) start a dynamic `Workflow` that builds it, tracking the work in tasktracker and using the build + verify skills. It does NOT analyze parallelism up front, ask the user to choose a mode, hand back, or fall back to a sequential skil
tools
--- name: grumpy-reviewer description: A single grumpy, nitpicky structural code reviewer that runs as an isolated subagent and treats the code as third-party work submitted by a junior programmer for validation. It cares about exactly one thing — maintainability — judged through separation of concerns, service-oriented design, helper-method extraction, small files, and the rule of 7 (as any grouping nears 7 members, it pushes for sub-groupings). It is deliberately kept OUT of the implementation
development
--- name: tt-workflow-run description: Tasktracker-native autonomous build-loop orchestrator. Drives a first-class `workflow_run` end-to-end — create the run (Gate 1 lifecycle completeness + Gate 2 zero-defects-in), then loop while `getNextReadyTask(projectId)` returns a slice — `setActiveTask` → record a pre-slice `scanArchitectureDrift` baseline → delegate the slice to `/tt-implement-phase` (which does the code work, registers the architecture delta in-slice, and auto-logs defects/learnings/fr
tools
Tasktracker-native project-wide parallel audit using the Claude Code Workflow tool (dynamic workflows). Partitions a repo / backlog / architecture and fans out read-only agents (one per partition) that return schema-checked findings, aggregates them into a deduplicated, ranked risk register, and OPTIONALLY writes fixes back as tasks under a Bug Fix phase — with all tasktracker writes done by the PARENT, never the parallel agents (single global active-task pointer). Journaled and resumable, so a rate-limit or crash mid-audit resumes without re-running completed partitions. Use for large, embarrassingly-parallel, read/analyze-heavy jobs where each unit is self-contained and the output aggregates — audit every file/component for risk, find all architecture drift (scanArchitectureDrift) or duplicate tasks (detectDuplicates/auditDuplicates), per-file tech-debt sweep, test-coverage or security-surface scan across a whole project. Triggers on "/tt-workflow-audit", "audit the whole repo", "parallel audit", "scan every file/component", "find all drift/duplicates", "tech-debt sweep (tasktracker)", or any whole-project analyze-at-scale request inside a session with a tasktracker project. Prefer this over /codebase-audit or /code-quality-audit when the project is tracked in tasktracker AND you want the findings written back as tasks; prefer it over team-* modes when the units don't need to negotiate live (they just report).