Task Development Workflow

TDD-first development workflow with structured planning, task tracking, and PR-based code review. Use when building software projects that require clarificat...

Security Scan

The skill is an instruction-only TDD/PR workflow guide that matches its description and requests no installs, credentials, or unexpected system access.

Purpose & Capability

The name/description (TDD-first task workflow, Trello task tracking, PR-based review) matches the actual instructions. All required actions are process and human-workflow steps (planning, tests, branches, PRs, Trello card moves). There are no unrelated environment variables, binaries, or config paths requested.

Instruction Scope

SKILL.md and references only give procedural guidance (questions to ask, TDD steps, Trello board columns, PR templates, branch rules). It does not instruct the agent to read system files, environment variables, or send data to external endpoints. One operational note: it mentions 'push force with lease' as a conflict resolution step (an operational risk to repository history if used improperly) but that is a process recommendation rather than hidden automation or exfiltration.

Install Mechanism

No install spec and no code files — this is instruction-only, which is the lowest-risk install surface. Nothing will be downloaded or written to disk by the skill itself.

Credentials

The skill declares no required environment variables, credentials, or config paths. It references Trello and Git workflows but does not request Trello/GitHub tokens or other secrets; if you later automate parts of this workflow, you will need to supply appropriate scoped credentials separately.

Persistence & Privilege

always is false and the skill does not request persistent system presence or modify other skills/configuration. Autonomous invocation is allowed by default on the platform, but this skill contains only guidance and cannot perform privileged actions on its own.

Assessment

This is a guidance-only workflow (no code, installs, or credential requests) and is internally consistent with its stated purpose. It appears safe to use as a process checklist. Two practical cautions: (1) the publisher/source and homepage are missing—prefer skills with identifiable provenance if that matters to you, and (2) if you later attach automation (e.g., scripts that integrate with Trello or GitHub), only grant minimal-scoped credentials and be careful with force-push operations, which can rewrite repository history.

Task Workflow

A structured development workflow enforcing quality through planning, TDD, and code review.

Workflow Overview

Clarify → Plan → Approve → Implement (TDD) → PR → Review → Merge → Next Task

Phase 1: Clarification

Before any implementation, ask questions to clarify:

• Business requirements and goals
• UI/UX flow expectations
• Architecture decisions
• Technical constraints
• Ambiguous requirements

Do not proceed until requirements are clear.

Phase 2: Planning & Approval

1. Present a detailed plan with task breakdown
2. Keep tasks small and focused
3. Wait for explicit approval before starting
4. No implementation without approval

Phase 3: Task Tracking Setup

Set up Trello board (or similar) with columns:

• 📝 Backlog
• 📋 To Do
• 🔨 In Progress
• 🔍 Review
• ✅ Done

All tasks must be tracked on the board.

Phase 4: Implementation (Per Task)

For each task:

1. Move card to "In Progress"
2. Write tests first (TDD):
   • Define expected behavior in tests
   • Run tests (should fail)
   • Implement the feature
   • Run tests (should pass)
3. Commit after task completion
4. Tests may be skipped only with explicit approval

Phase 5: Branching & PR Policy

Rules:

• Never push directly to main
• Never change the default branch — main must always remain default
• Create feature branches for each task

After task completion:

1. Open PR from task branch → main
2. Include Trello task link in PR description
3. Move card to "Review"
4. Notify Reviewer with both Trello link and PR link

Phase 6: PR Feedback Loop

When CR comments arrive:

1. Move task back to "In Progress"
2. Address all review comments
3. Push fixes
4. Notify Reviewer to re-review (include both links)

Repeat until approved.

Phase 7: Merge Gate

• Only pick the next task after current PR is merged
• Move completed card to "Done"
• Then proceed to next task from "To Do"

Flow Diagram

Backlog → To Do → In Progress → Review → Done
                      ↑            │
                      └─── CR ─────┘

New Project Bootstrap

For new projects:

1. Create repository with initial README
2. Push to remote
3. Then begin implementation tasks

Key Principles

• Quality over speed — TDD catches bugs early
• Small tasks — easier to review and merge
• Clear communication — always notify reviewers
• No shortcuts — follow the process every time