Use when implementing a new feature, adding functionality, or building a capability that needs requirements gathering, planning, and test-driven implementation with progress tracking. Accepts optional Jira or ClickUp ticket URLs/IDs to seed requirements from card details.
From dev-workflownpx claudepluginhub infraspecdev/tesseract --plugin dev-workflowThis skill uses the workspace's default tool permissions.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Guides idea refinement into designs: explores context, asks questions one-by-one, proposes approaches, presents sections for approval, writes/review specs before coding.
Structured feature implementation workflow: optionally fetch context from a Jira/ClickUp ticket, gather requirements, optionally prototype frontend design, plan, write tests first, implement with parallel sub-agents committing after each step, and verify. All artifacts are tracked in a feature/<name>/ directory.
The user provides one or more of:
PROJ-123, https://team.atlassian.net/browse/PROJ-123)https://app.clickup.com/t/abc123)When NOT to use:
digraph feature_flow {
rankdir=TB;
node [shape=box];
init [label="1. Initialize Feature"];
ticket [label="2a. Fetch Ticket?\n(if URL/ID provided)" shape=diamond];
fetch [label="2a. Fetch Card Details"];
clarify [label="2b. Clarify Requirements"];
frontend [label="2.5 Frontend Prototype?\n(if UI feature)" shape=diamond];
design [label="2.6 Design & Sample HTML"];
plan [label="3. Write Implementation Plan"];
approve [label="4. Get User Approval" shape=diamond];
tdd [label="5. TDD: Write Failing Tests"];
implement[label="6. Implement + Commit per Step"];
verify [label="7. Verify & Review"];
done [label="Done"];
init -> ticket;
ticket -> fetch [label="yes"];
ticket -> clarify [label="no"];
fetch -> clarify;
clarify -> frontend;
frontend -> design [label="yes"];
frontend -> plan [label="no"];
design -> plan;
plan -> approve;
approve -> plan [label="revise"];
approve -> tdd [label="approved"];
tdd -> implement;
implement -> verify;
verify -> implement [label="failing"];
verify -> done [label="passing"];
}
Always checkout a new branch from main before starting work:
git checkout main && git pull && git checkout -b feat/<feature-name>
Create the feature tracking directory:
feature/<feature-name>/
requirements.md # Captured from user Q&A
plan.md # Implementation steps
sample.html # Frontend prototype (UI features only)
Derive <feature-name> from the user's description. Use kebab-case (e.g., per-component-versioning, auto-tag-releases).
If the user provided a Jira or ClickUp ticket URL or ID:
*.atlassian.net/browse/PROJ-123 or PROJ-123app.clickup.com/t/TASK_ID or a ClickUp task IDmcp__atlassian__jira_get_issue if available, otherwise WebFetch the Jira REST API (/rest/api/3/issue/PROJ-123)sprint_status), otherwise WebFetch the ClickUp API (/api/v2/task/TASK_ID)requirements.md with the extracted details — use the card content as the starting point, not a replacement for clarificationIf no ticket is provided, skip to Step B.
ALWAYS ask questions before writing code, even when a ticket was provided — tickets often have gaps. Use AskUserQuestion with 2-4 focused questions grouped by:
| Category | Example Questions |
|---|---|
| Scope | What exactly should this feature do? What's out of scope? |
| Behavior | What inputs/outputs? What happens on error? Edge cases? |
| Integration | What existing code/systems does this touch? |
| Acceptance | How do we know this is done? What does success look like? |
When a ticket was provided, skip questions already answered by the card and focus on:
Rules:
Write to feature/<feature-name>/requirements.md:
# Feature: <Name>
## Source
[Ticket URL if provided, otherwise "User request"]
## Description
[What this feature does — 1-2 sentences]
## Requirements
- [Bullet list of specific requirements from ticket + user answers]
## Out of Scope
- [What this feature does NOT do]
## Acceptance Criteria
- [ ] [Testable criteria — from ticket if available, refined with user input]
- [ ] [Testable criteria]
Skip this phase if the feature has no user-facing UI.
If the feature involves any frontend work (new pages, layouts, components, or visual redesign):
Use superpowers:brainstorming to ask ONE question at a time:
If a tone is uncertain, generate 2-3 sample HTML variants (one per option) so the user can compare visually before deciding. Save each as sample-<option-name>.html in the feature folder.
sample.htmlUse frontend-design skill to produce feature/<feature-name>/sample.html.
The sample must:
<!-- MOODLE NOTE: {{#courses}} loop — data from layout/frontpage.php -->
Show the user the sample. Do not write plan.md until the design direction is approved. If the user wants changes, iterate on sample.html first, then update requirements.md with the confirmed design tokens, fonts, and palette before moving to Phase 3.
Explore the codebase to understand existing patterns, then write feature/<feature-name>/plan.md:
# Implementation Plan: <Name>
## Files to Create/Modify
- `path/to/file.ts` — [what changes and why]
## Steps
### Step 1: [Title]
**Test:** [What test to write first]
**Implementation:** [What code to write]
**Files:** [Which files]
**Commit:** feat(<feature-name>): step 1 — [one-line description]
### Step 2: [Title]
...
## Parallel Work
[Which steps are independent and can use sub-agents]
## Risks
- [Anything that might go wrong]
Use Task agents (type: Explore) to investigate the codebase in parallel when you need to understand multiple areas simultaneously.
Show the user a summary of the plan. Use AskUserQuestion:
"I've written the requirements and plan to
feature/<name>/. The plan has N steps. Would you like to proceed, revise, or stop here?"
NEVER proceed to implementation without explicit approval.
REQUIRED: Write tests BEFORE implementation code.
For each step in the plan:
If the project has no test framework:
Red flags — STOP if you catch yourself:
Use Task agents (type: general-purpose) for independent steps.
For each implementation step:
Sub-agent prompt template:
Implement [step description].
Context:
- Feature requirements: [path to requirements.md]
- Implementation plan: [path to plan.md]
- Relevant files: [list]
Write the implementation code to make the failing test pass.
Follow existing code patterns in the project.
Do not modify files outside the listed scope.
Rules for sub-agents:
After each step passes its test and you have verified the output, commit immediately before starting the next step:
# Stage only the files changed in this step — never git add -A or git add .
git add path/to/changed/file1 path/to/changed/file2
git commit -m "$(cat <<'EOF'
feat(<feature-name>): step N — <one-line description>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
EOF
)"
Commit message rules:
feat(<feature-name>): step N — <description> (e.g. feat(homepage-redesign): step 2 — add frontpage layout PHP)git add -A or git add .sample.html section it implementsAfter the final step, do a single git status to confirm nothing uncommitted remains.
After implementation:
## Verification
- [ ] All tests pass
- [ ] Linter/formatter clean
- [ ] Each acceptance criterion met
- [ ] No unintended side effects
- [ ] Every step has a commit
- [ ] sample.html matches the shipped implementation
If anything fails, go back to Phase 6 for the failing step.
Use the code-reviewer agent (superpowers:requesting-code-review) for a final review before declaring done.
| Mistake | Fix |
|---|---|
| Treating ticket as complete spec | Tickets have gaps — always clarify with the user |
| Skipping requirements gathering | Always ask at least 1 round of questions |
| Skipping the design prototype for UI features | Create sample.html before plan.md — saves rework |
| Implementing before tests | Delete code, write test first, start over |
| Monolithic sub-agent tasks | Break into focused, single-step agents |
| Not reading existing code first | Explore before planning — match existing patterns |
| Over-engineering the feature | Implement exactly what was asked, nothing more |
| Forgetting to verify | Run tests and review BEFORE claiming done |
| Giant end-of-feature commit | Commit after each step — keeps history readable and rollback safe |
git add -A or git add . | Stage specific files only to avoid committing secrets or binaries |