agentleFS
Sign inStart free
tranhieutttranhieutt/software_development_department/.claude/skills/team-feature/SKILL.md

team-feature

Skill71 starsChanged 7 months agoMITView on GitHub

When this skill is invoked, orchestrate the feature team through a structured delivery pipeline. Decision Points: At each phase transition, use AskUserQuestion to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase. Use the Task tool to spawn each team member as a subagent: - subagent_type: product-manager - subagent_type: ux-designer - subagent_type: backend-developer - subagent_type:…

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When this skill is invoked, orchestrate the feature team through a structured delivery pipeline.

    line 12
  2. Distinctive:

    Use the Task tool to spawn each team member as a subagent:

    line 28
  3. Distinctive:

    Always provide full context in each agent's prompt (feature requirements, existing patterns, API conventions).

    line 35
  4. Distinctive:

    Write the user story and acceptance criteria

    line 41
  5. Very specific:

    Use AskUserQuestion to get approval on:

    line 54
  6. Distinctive:

    Test against acceptance criteria

    line 68
  7. Distinctive:

    Update documentation if needed (delegate to tech-writer)

    line 75

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

When this skill is invoked, orchestrate the feature team through a structured delivery pipeline.

Decision Points: At each phase transition, use AskUserQuestion to present the user with the subagent's proposals as selectable options. Write the agent's full analysis in conversation, then capture the decision with concise labels. The user must approve before moving to the next phase.

Team Composition

  • product-manager — Feature scope, user stories, acceptance criteria
  • ux-designer — User flows, wireframes, interaction design
  • backend-developer — API design and implementation
  • frontend-developer — UI components and client-side integration
  • qa-engineer — Test planning and validation

How to Delegate

Use the Task tool to spawn each team member as a subagent:

  • subagent_type: product-manager
  • subagent_type: ux-designer
  • subagent_type: backend-developer
  • subagent_type: frontend-developer
  • subagent_type: qa-engineer

Always provide full context in each agent's prompt (feature requirements, existing patterns, API conventions). Launch independent agents in parallel where the pipeline allows (e.g., backend + UX design can proceed in parallel after spec is approved).

Pipeline

Phase 1: Feature Specification

Delegate to product-manager:

  • Write the user story and acceptance criteria
  • Define out-of-scope explicitly
  • Identify success metrics
  • Output: PRD or user story with acceptance criteria

Phase 2: Design (parallel)

Launch in parallel:

  • ux-designer: User flow, wireframes, interaction spec for the feature
  • backend-developer: API contract design (endpoints, request/response schemas)

Both must complete before Phase 3.

Phase 3: Review Designs

Use AskUserQuestion to get approval on:

  • UX flow and wireframes
  • API contract

Iterate until approved.

Phase 4: Implementation (parallel where possible)

  • backend-developer: Implement approved API endpoints and business logic
  • frontend-developer: Implement UI components (can start with mock data if backend not ready)

Once backend is done, frontend-developer integrates with real API.

Phase 5: QA

Delegate to qa-engineer:

  • Test against acceptance criteria
  • Cross-browser/cross-device testing if relevant
  • Regression testing on adjacent features
  • Output: Test report with pass/fail per acceptance criterion

Phase 6: Handoff

  • Address QA findings
  • Update documentation if needed (delegate to tech-writer)
  • Confirm feature is ready for release review (/gate-check)

Output

A summary covering: acceptance criteria coverage, API status, UI status, test results, and any outstanding items.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free