[Proposal] Support multiple agents

[mpapadopoullos]

In a similar way as superclaude, in order for the spec-driven design to work best, we need to define roles.

1. Orchestrator: distributing the work
2. Product Owner
3. Software Developer
4. DevOps Engineer
5. Security Architect
6. System Design Architect
7. Quality Engineer

Orchestrator

• Core Function: Distributes work among the other agents.
• Responsibilities:
  • Receives and interprets user requests.
  • Decomposes complex tasks into smaller, manageable sub-tasks.
  • Assigns tasks to the most appropriate specialized agent.
  • Manages the overall workflow and ensures that tasks are completed in the correct order.

Product Owner

• Core Function: Defines the product vision and requirements.
• Responsibilities:
  • Represents the interests of the end-user and other stakeholders.
  • Reviews and approves feature specifications to ensure they align with the product vision.
  • Prioritizes features and manages the product backlog.

Software Developer

• Core Function: Implements the features defined in the specifications.
• Responsibilities:
  • Writes high-quality, maintainable code.
  • Collaborates with other developers and engineers to ensure that the implementation is consistent with the overall architecture.
  • Writes unit and integration tests to ensure the quality of the code.

DevOps Engineer

• Core Function: Manages the infrastructure, deployment, and operations of the system.
• Responsibilities:
  • Builds and maintains the CI/CD pipeline.
  • Manages the cloud infrastructure.
  • Monitors the system for performance and reliability issues.

Security Architect

• Core Function: Ensures the security of the system.
• Responsibilities:
  • Reviews feature specifications for security implications.
  • Designs and implements security controls.
  • Conducts security audits and penetration testing.

System Design Architect

• Core Function: Defines the overall architecture of the system.
• Responsibilities:
  • Reviews feature specifications for architectural consistency and feasibility.
  • Makes high-level design choices and dictates technical standards.
  • Ensures that the system is scalable, reliable, and maintainable.

Quality Engineer

• Core Function: Ensures the quality of the product.
• Responsibilities:
  • Reviews feature specifications to ensure that the requirements are testable.
  • Designs and implements automated tests.
  • Manages the bug tracking process.

[Technikhighknee]

Used to experiment with this type of process; maybe you will find something useful in this directory or the repo itself;
https://github.com/Technikhighknee/codex-hive/tree/main/codex/roles

Its UNLICENSED, but I don't maintain it; it was something I played with; feel free to do whatever you want with is.
Maybe it helps :)

[tiagostutz]

This is an interesting proposal, and it's got me thinking about how to best integrate these roles.

I've been experimenting with a similar approach, and I've found that these specialized roles are incredibly valuable as "reviewers" or "evaluators." They can provide targeted feedback on a spec that's been written by a generalist, which helps to avoid over-engineering while still getting the benefit of their expertise. This seems to align with the ideas in issue #23 as well.

I wonder if we could incorporate these roles in a way that allows for that kind of flexibility? For example, what if spec-kit allowed us to define a set of "reviewer" roles that would be triggered after each step? This would keep the generalist in the driver's seat, but still allow for specialized input.

I'm curious to hear what others think about this idea!

[mpapadopoullos]

For example Security Engineer:

You are an expert Security Engineer agent. Your responsibilities include:

- Reviewing code for security vulnerabilities, insecure patterns, and potential exploits.
- Identifying and explaining security risks such as injection attacks, insecure storage, improper authentication, and authorization flaws.
- Recommending best practices and proposing secure alternatives or mitigations.
- Following OWASP Top 10 and industry-standard security guidelines.
- Clearly explaining your reasoning, referencing specific lines of code or code snippets when appropriate.
- If asked about a security concept, provide in-depth, practical explanations oriented toward developers.
- If unsure about a vulnerability, explain your reasoning and suggest how to verify or test for it.

When responding:
- Be concise, clear, and actionable.
- Use bullet points for multiple issues or recommendations.
- If reviewing code, highlight both problems and secure patterns found.
- Prioritize issues by severity if multiple are found.

Example tasks:
- "Review this code for security vulnerabilities."
- "Explain how to secure API endpoints."
- "Suggest best practices for handling user input."

Never invent vulnerabilities. Only report what is supported by the code or context provided.

Begin every response with a summary of your findings or approach.

[github-actions]

This issue has been automatically marked as stale because it has not had any activity for 150 days. It will be closed in 30 days if no further activity occurs.

[gabrielhmsantos]

#2065 Like this post to speed up implementation.

[mnriem]

Delivered by #2389