That's how subagents are supposed to work, they do 1 very simple task, they do not have context of what the main agent is working on either. Or very little (only the actual prompt it receives from main agent whatever that might be). That's the main issue with these subagents. You might want to check out somthing like Claude Flow, that might be one solution, although I haven't even tested that out myself yet.

Hi @albanx and @RensTillmann,

Thank you for taking the time to test the agents and share your feedback. While I appreciate the engagement, I'd like to encourage a more evidence-based approach to help improve the project.

Request for Specific Evidence

When reporting that agents are "too broad" or "very generic," it would be incredibly helpful to have:

1. Specific test cases: Which exact agents did you test? What prompts did you use? What was the expected vs actual output?

2. Quantifiable metrics:

   • Success/failure rate across multiple attempts
   • Time to completion comparisons
   • Quality measurements (did it compile? pass tests? meet requirements?)
   • Context token usage statistics

3. Reproducible examples:

   • Share the exact workflow you attempted
   • Include the agent configuration used
   • Provide input/output pairs that demonstrate the issue

4. Comparative analysis: What specific instructions or constraints would have improved the output? Can you A/B test your proposed improvements?

Scientific Approach

Rather than assertions like "they don't work" or "too generic," let's think scientifically:

• Hypothesis: "Agent X performs poorly on task Y"
• Method: Test with controlled inputs, measure outputs
• Data: Collect specific failures, patterns, success rates
• Analysis: Identify root causes with evidence

Contributing Improvements

This project actively welcomes pull requests! If you've identified specific improvements:

1. Fork the repository
2. Modify the agent definitions with your proposed specializations
3. Include test results showing the improvement
4. Submit a PR with before/after comparisons

For example, instead of saying "React component architecture descriptions are insufficient," you could:

• Show a specific component the current agent failed to create properly
• Propose exact additional constraints/instructions
• Demonstrate how your changes improve the output

Moving Forward

I genuinely want to improve these agents, but I need actionable, measurable feedback to do so. General statements without evidence don't provide a path forward. Please help by:

• Testing systematically
• Documenting failures precisely
• Measuring improvements quantitatively
• Contributing solutions directly

Looking forward to your specific findings and potential contributions!

Best regards

The placeholder approach is actually the answer to this. Agents that say 'React component architecture (hooks, context, performance)' are too abstract because they carry no project context -- they don't know your component directory, your state management convention, or what 'performance' means for your specific data shapes.

The pattern that works: ship agents with {{REPO_PATH}}, {{PRIMARY_CODE_DIR}}, {{TEST_COMMAND}} placeholders, then have a bootstrap step that explores the actual codebase and fills them in before the agent runs. The agent becomes specific to your project's conventions, not a generic description of a paradigm.

I built operating-kit around this -- the subagent templates (session-start, code-review, deploy, prod-logs) all ship with explicit placeholders and a bootstrap prompt that explores the repo and adapts them. The difference in behavior before/after filling in the actual project context is significant.

Agreed, and I'd put the missing piece precisely: "React component architecture
(hooks, context, performance)" has nothing in it that can come out false.

The definitions that actually changed behaviour for me all had four parts:

• trigger — the exact condition it applies to
• check — a command or string that is either true or false
• stop — what must not proceed until the check passes
• evidence — what has to be left behind

"Performance" fails all four. "Before adding a useEffect, state which prop or state
value it synchronises; if none, remove it" passes all four — the model has to produce
the sentence, so its absence is visible in the diff.

That's also why specialisation alone doesn't fix it. A narrow agent described in prose
drifts the same way a broad one does; it just drifts inside a smaller topic. What stops
the drift is the check, not the scope.

Five written that way, MIT: https://github.com/soul-sol/claude-md-patterns

Closing this as resolved. The agents were rewritten in September 2025 (commit 1276555), and the phrase you quoted is gone. For example, frontend-developer now covers React 19 and Next.js 15. If a specific agent still gives you generic output, please open an issue with the prompt and the output. I've hidden one promotional comment and locked the thread.