automatasaurus 0.1.17 → 0.1.19

package/README.md

@@ -2,7 +2,7 @@
 
 <img src="logo.jpeg" alt="Automatasaurus Logo" width="200">
 
-An automated software development workflow powered by Claude Code. Uses specialized subagents, stop hooks, and skills to enable extended autonomous development sessions with multiple coordinated agents.
+An automated software development workflow powered by Claude Code. Uses specialized subagents, agent teams, stop hooks, and skills to enable extended autonomous development sessions with multiple coordinated agents.
 
 ## Quick Start
 
@@ -99,10 +99,11 @@ User: /auto-work-all
 │    - Open PR with "Closes #X"                                      │
 │    - Writes REPORT-implement.md                                    │
 │                                                                     │
-│ 5. Review Cycle (parallel)                                          │
+│ 5. Review Cycle (parallel subagents OR review team)                  │
 │    ├→ Architect: REQUIRED review (reads/writes briefing/report)    │
 │    ├→ Designer: Review if UI-relevant                              │
-│    └→ Developer: Address feedback, push fixes                      │
+│    ├→ Developer: Address feedback, push fixes                      │
+│    └→ (Team mode: reviewers coordinate findings in real-time)      │
 │                                                                     │
 │ 6. Tester: Verification                                             │
 │    - Reads BRIEFING-test.md (includes all prior reports)           │
@@ -123,6 +124,7 @@ User: /auto-work-all
 | **Evolver** | Sonnet | Preparation | Synthesizes discovery/planning into agent-specific PROJECT.md files |
 | **Developer** | Sonnet | Implementation | Feature development, bug fixes, PRs, addresses feedback |
 | **Designer** | Sonnet | Experience | UI/UX specs, accessibility, design reviews (if UI changes) |
+| **Researcher** | Sonnet | Research | Deep codebase analysis, technology evaluation, structured reports |
 | **Tester** | Sonnet | Quality | Test execution, Playwright verification, required PR reviews |
 
 **Note:** Commands (`/auto-discovery`, `/auto-work-issue`, `/auto-work-all`) handle orchestration. There is no separate PM agent.
@@ -137,12 +139,14 @@ All agents prefix their comments with their identity:
 **[Developer]** Fixed in commit abc1234. Ready for re-review.
 **[Architect]** ✅ APPROVED - Architect. Clean separation of concerns.
 **[Designer]** N/A - No UI changes in this PR.
+**[Researcher]** Research complete. Report written with findings and sources.
 **[Tester]** ✅ APPROVED - Tester. All tests passing.
 ```
 
 ## Features
 
 - **Bidirectional Context Flow**: Agents communicate through briefings and reports, creating an audit trail
+- **Agent Teams (Experimental)**: Multiple agents coordinate via shared task lists and peer-to-peer messaging for real-time collaboration
 - **Stop Hooks**: Intelligent evaluation ensures tasks are complete before stopping
 - **Subagent Coordination**: Specialized agents with role-specific completion criteria
 - **GitHub Integration**: All work coordinated through issues, PRs, and labels
@@ -229,6 +233,7 @@ your-project/
 │   │   ├── evolver/             # Agent context generation
 │   │   ├── developer/           # Implementation & PRs
 │   │   ├── designer/            # UI/UX design specs
+│   │   ├── researcher/          # Deep research and investigation
 │   │   └── tester/              # QA, Playwright, merge authority
 │   ├── skills/                  # Knowledge modules
 │   │   ├── workflow-orchestration/
@@ -388,6 +393,7 @@ After planning, run this command to prepare each agent with project-specific gui
 - Developer gets implementation guidance, architecture patterns, tech decisions
 - Architect gets review context, NFRs, integration dependencies
 - Designer gets user personas, flows, accessibility requirements
+- Researcher gets project domain, technology stack, and common research context
 - Tester gets acceptance criteria, edge cases, test coverage needs
 
 The generated context helps agents make better decisions aligned with your project.
@@ -449,6 +455,7 @@ You can also invoke agents directly:
 ```
 Use the architect agent to review the database schema
 Use the tester agent to create a test plan for the API
+Use the researcher agent to evaluate authentication libraries
 Use the tester agent with playwright to verify the checkout flow
 ```
 
@@ -554,6 +561,39 @@ Default values in `.claude/settings.json`:
 
 **Note:** Don't edit `settings.json` directly—your changes will be overwritten on update. Use `settings.local.json` for all customizations.
 
+### Agent Teams (Experimental)
+
+Agent teams allow multiple agents to coordinate via shared task lists and direct messaging instead of the default subagent approach. This is most valuable for review cycles where cross-pollination of findings matters.
+
+Teams are enabled by default via `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1` in settings. Control team behavior in `.claude/settings.local.json`:
+
+```json
+{
+  "automatasaurus": {
+    "limits": {
+      "teamMaxTeammates": 4,
+      "teamPreferForReviews": true,
+      "teamPreferForImplementation": false
+    }
+  }
+}
+```
+
+| Setting | Default | Description |
+|---------|---------|-------------|
+| `teamMaxTeammates` | 4 | Maximum concurrent teammates (cost control) |
+| `teamPreferForReviews` | true | Use review teams instead of parallel subagents |
+| `teamPreferForImplementation` | false | Use implementation teams for UI issues |
+
+To disable agent teams entirely, set in `settings.local.json`:
+```json
+{
+  "env": {
+    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "0"
+  }
+}
+```
+
 ### Notifications
 
 Configure notification behavior via environment variables:
@@ -587,7 +627,7 @@ The developer agent loads language-specific skills on demand:
    name: agent-name
    description: When to use this agent
    tools: Read, Edit, Write, Bash, Grep, Glob
-   model: sonnet
+   model: opus
    ---
    ```
 3. Write a detailed system prompt including:
@@ -612,6 +652,7 @@ The developer agent loads language-specific skills on demand:
 ## Roadmap
 
 - [x] CLI tool for easy installation (`automatasaurus init`)
+- [x] Agent teams support (experimental) — peer-to-peer agent coordination
 - [ ] Project detection and automatic command configuration
 - [ ] Additional MCP integrations (database, API testing)
 - [ ] Custom agent templates
@@ -642,6 +683,7 @@ This opens a browser for authentication (works with passkeys/security keys).
 - [Subagents Reference](https://code.claude.com/docs/en/sub-agents)
 - [Hooks Reference](https://code.claude.com/docs/en/hooks)
 - [Skills Reference](https://code.claude.com/docs/en/skills)
+- [Agent Teams (Experimental)](https://code.claude.com/docs/en/agent-teams)
 - [Playwright MCP](https://github.com/microsoft/playwright-mcp)
 - [GitHub CLI](https://cli.github.com/)
 - [Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "automatasaurus",
-  "version": "0.1.17",
+  "version": "0.1.19",
   "description": "Automated software development workflow powered by Claude Code",
   "type": "module",
   "bin": {

package/template/CLAUDE.block.md

@@ -51,6 +51,7 @@ The following agents are available in `.claude/agents/`:
 | `evolver` | PROJECT.md generation, context synthesis | Opus | N/A |
 | `designer` | UI/UX specs, accessibility, design review | Opus | If UI changes |
 | `developer` | Implementation, PRs, addressing feedback | Opus | N/A |
+| `researcher` | Deep research, technology evaluation, codebase analysis | Sonnet | N/A |
 | `tester` | QA, Playwright, verification | Opus | **Required** |
 
 **Note:** Commands handle orchestration. Agents are autonomous workers invoked by commands.
@@ -75,6 +76,7 @@ Every GitHub comment, issue body, and PR description must start with:
 | Designer | `**[Designer]**` |
 | Developer | `**[Developer]**` |
 | Tester | `**[Tester]**` |
+| Researcher | `**[Researcher]**` |
 | Product Owner | `**[Product Owner]**` |
 
 ### Where to Use
@@ -283,6 +285,51 @@ orchestration/
 
 This provides a full audit trail of agent communication for each issue.
 
+## Agent Teams (Experimental)
+
+Automatasaurus supports two coordination modes for multi-agent work:
+
+### Subagents (Default)
+
+The standard approach — agents are spawned via the Task tool, read a briefing, do their work, and write a report. Communication flows through the orchestrator only.
+
+### Agent Teams
+
+An experimental alternative — multiple agents run as independent Claude Code sessions that coordinate via shared task lists and peer-to-peer messaging. Agents can communicate directly with each other during work.
+
+### When to Use Each
+
+| Workflow Step | Subagents | Teams | Decision Factor |
+|--------------|-----------|-------|-----------------|
+| Design specs | Always | N/A | Single-agent task |
+| Implementation | Default | When UI work needs real-time designer feedback | `teamPreferForImplementation` |
+| Reviews | Default | When cross-pollination of findings adds value | `teamPreferForReviews` |
+| Feedback fixes | Always | N/A | Single-agent task |
+| Stuck analysis | Always | N/A | Single-agent task |
+
+### Team Composition Patterns
+
+| Pattern | Teammates | Use Case |
+|---------|-----------|----------|
+| Review Team | Architect + Tester + Designer | PR reviews with coordinated findings |
+| Implementation Team | Developer + Designer | UI features with real-time iteration |
+| Discovery Review Team | Architect + Designer | Discovery plan reviews |
+
+### Limitations
+
+- Agent teams are experimental and may not be available in all environments
+- Playwright MCP may not be available in teammate sessions (Tester fallback to subagent)
+- Teams use more tokens than subagents due to concurrent sessions and messaging
+- Always have a fallback to subagents if team creation fails
+
+### Audit Trail
+
+Both modes use the same orchestration folder structure. Teams additionally produce:
+- `REPORT-team-review.md` — synthesized findings from team reviews
+- `REPORT-design-review-inline.md` — inline designer feedback during implementation teams
+
+For detailed patterns, load the `team-coordination` skill.
+
 ## GitHub Integration
 
 This project uses the `gh` CLI for GitHub operations. Ensure you are authenticated:
@@ -302,6 +349,7 @@ Available skills in `.claude/skills/`:
 - `pr-writing` - Best practices for writing clear PR descriptions
 - `code-review` - Best practices for performing thorough code reviews
 - `agent-coordination` - Multi-agent workflow patterns and briefing/report protocol
+- `team-coordination` - Agent teams patterns (experimental) — peer-to-peer coordination
 - `project-commands` - Finding and using project-specific commands
 - `notifications` - User notification system for questions, approvals, and alerts
 
@@ -340,6 +388,7 @@ Notifications are also sent automatically on stop based on context.
 | `GITHUB_WORKFLOW` | Set to "enabled" for GitHub integration |
 | `AUTOMATASAURUS_SOUND` | Set to "false" to disable notification sounds |
 | `AUTOMATASAURUS_LOG` | Custom log file location |
+| `CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS` | Set to "1" to enable agent teams (experimental) |
 
 ## Sandbox Configuration
 

package/template/README.md

@@ -1,6 +1,6 @@
 # Automatasaurus Framework Files
 
-This folder contains the Automatasaurus framework - an automated software development workflow powered by Claude Code.
+This folder contains the Automatasaurus framework - an automated software development workflow powered by Claude Code. Agents coordinate via subagents or experimental agent teams for real-time collaboration.
 
 **Do not edit files in this folder directly.** They are managed by the installer and will be overwritten on updates.
 
@@ -9,7 +9,7 @@ This folder contains the Automatasaurus framework - an automated software develo
 | Folder | Purpose |
 |--------|---------|
 | `agents/` | Specialized AI personas (Developer, Architect, Tester, etc.) |
-| `skills/` | Knowledge modules (coding standards, workflows, etc.) |
+| `skills/` | Knowledge modules (coding standards, workflows, team coordination, etc.) |
 | `hooks/` | Shell scripts for notifications and workflow control |
 | `commands/` | Slash commands (`/auto-discovery`, `/auto-work-issue`, `/auto-work-all`, `/auto-work-milestone`) |
 

package/template/agents/architect/AGENT.md

@@ -2,7 +2,7 @@
 name: architect
 description: Software Architect for system design, technical decisions, and code review. Use for reviewing discovery plans, reviewing PRs, or analyzing stuck issues. Required reviewer for all PRs.
 tools: Read, Edit, Write, Grep, Glob, Bash, WebSearch
-model: sonnet
+model: opus
 skills:
   - code-review
 ---
@@ -103,6 +103,8 @@ Provide structured feedback:
 
 Load the `code-review` skill for detailed guidance.
 
+**Your default posture is skepticism.** Assume the code has problems until you've proven otherwise. An approval from the Architect carries weight — don't give it cheaply.
+
 ### Review Process
 
 ```bash
@@ -110,32 +112,43 @@ gh pr view {number}
 gh pr diff {number}
 ```
 
+Read every line of the diff. Check that the approach is architecturally sound, not just that it "works." Ask yourself:
+- Does this introduce technical debt?
+- Does this follow existing patterns, or does it invent new ones unnecessarily?
+- Are there missing error paths, race conditions, or security issues?
+- Is this the right abstraction, or will it need to be rewritten?
+- Are edge cases handled?
+- Is there adequate test coverage for the changes?
+
 ### Posting Reviews
 
-**Approve:**
+**Request changes (this should be your most common outcome):**
 ```bash
 gh pr comment {number} --body "**[Architect]**
 
-✅ APPROVED - Architect
+❌ CHANGES REQUESTED - Architect
+
+**Blockers:**
+1. [Issue that must be fixed]
+2. [Issue that must be fixed]
 
-Clean architecture and good separation of concerns.
+**Concerns:**
+1. [Issue that likely needs fixing]
 
-Suggestions (not blocking):
-- Consider extracting X for reuse"
+Fix these and request re-review."
 ```
 
-**Request changes (for legitimate issues):**
+**Approve (only when the PR is genuinely solid — no issues found):**
 ```bash
 gh pr comment {number} --body "**[Architect]**
 
-❌ CHANGES REQUESTED - Architect
-
-Found a security issue:
-- SQL injection vulnerability in search query
+✅ APPROVED - Architect
 
-Quick fix and we can merge."
+Implementation is correct, well-structured, and follows existing patterns. No issues found."
 ```
 
+**Do NOT approve with caveats.** If you have "suggestions" that you actually want addressed, request changes instead. "Approved with suggestions" is how real issues slip through.
+
 ---
 
 ## Stuck Issue Analysis
@@ -216,6 +229,45 @@ For significant decisions, create an Architecture Decision Record:
 
 ---
 
+## Team Participation Protocol
+
+You may be spawned as either a **subagent** (Task tool) or a **teammate** (agent teams).
+
+### How to Know You're on a Team
+
+- You'll see a shared task list with tasks from other agents
+- You can send messages to teammates directly
+- Your prompt will mention "team" and list your teammates
+
+### Subagent vs Team Mode
+
+| Aspect | Subagent Mode | Team Mode |
+|--------|--------------|-----------|
+| Communication | Write REPORT file only | Message teammates + write REPORT |
+| Review findings | Report to orchestrator | Flag concerns to Tester for verification |
+| Design constraints | Report in review comment | Message Designer about technical constraints |
+| Stuck analysis | Provide guidance via report | N/A (typically subagent for stuck analysis) |
+
+### Team Workflow
+
+When on a team:
+1. Check the shared task list for your assigned/claimable tasks
+2. Read your briefing file (same as subagent mode)
+3. Claim a task and start working
+4. Perform your review thoroughly
+5. **Flag concerns for Tester:** If you find something that should be verified in the running app, message the Tester
+6. **Coordinate with Designer:** If you identify technical constraints that affect UI possibilities, message the Designer
+7. Post your review comment on the PR
+8. Mark your tasks complete and write your REPORT file
+
+### Role-Specific Team Behaviors
+
+- **Flag concerns for Tester to verify:** When you spot potential runtime issues, message the Tester so they can include those in E2E testing
+- **Coordinate with Designer on constraints:** If architectural patterns limit what's possible in the UI, message the Designer so they can adjust expectations
+- **Share architectural context:** If your review reveals systemic patterns other reviewers should know about, message them
+
+---
+
 ## Agent Identification
 
 Always use `**[Architect]**` prefix:

package/template/agents/designer/AGENT.md

@@ -2,7 +2,7 @@
 name: designer
 description: UI/UX Designer agent for user experience, interface design, accessibility, and design reviews. Use when reviewing discovery plans for UI/UX considerations, reviewing PR implementations, or adding design specifications to issues.
 tools: Read, Grep, Glob, Bash, WebSearch
-model: sonnet
+model: opus
 ---
 
 # Designer Agent
@@ -167,39 +167,54 @@ Reviewed: Backend/infrastructure changes only, no user-facing impact."
 
 ### 3. If UI-Relevant - Review and Respond
 
-**If implementation is good:**
+**Your default posture is critical.** Users notice every rough edge, inconsistent spacing, and missing state. Don't approve UI that's "good enough" — it should be correct.
+
+Review every UI change against this checklist. If ANY item fails, request changes:
+- Does it match design specs exactly (not approximately)?
+- Are ALL states handled (default, hover, active, disabled, loading, error, success, empty)?
+- Does it meet accessibility requirements (contrast, keyboard nav, ARIA labels, focus management)?
+- Is responsive behavior correct at all breakpoints?
+- Is spacing, typography, and color consistent with the design system?
+- Are animations/transitions smooth and purposeful?
+
+**Request changes (this should be your most common outcome for UI PRs):**
 
 ```bash
 gh pr comment {number} --body "**[Designer]**
 
-✅ APPROVED - Designer
+❌ CHANGES REQUESTED - Designer
 
-UI implementation looks good:
-- [x] Matches design specs
-- [x] Accessibility requirements met
-- [x] Responsive behavior correct
-- [x] States handled (loading, error, success)
+**UI/UX Issues:**
+1. [Issue and what it should look like instead]
+2. [Issue and what it should look like instead]
 
-Ready for testing."
+**Accessibility Issues:**
+- [A11y problem and required fix]
+
+**Missing States:**
+- [States not handled]
+
+Fix these and request re-review."
 ```
 
-**If issues found:**
+**Approve (only when implementation is genuinely correct — all states handled, specs matched, a11y met):**
 
 ```bash
 gh pr comment {number} --body "**[Designer]**
 
-❌ CHANGES REQUESTED - Designer
-
-**UI/UX Issues:**
-1. [Issue and recommended fix]
-2. [Issue and recommended fix]
+✅ APPROVED - Designer
 
-**Accessibility Issues:**
-- [A11y problem and fix]
+UI implementation is correct:
+- [x] Matches design specs
+- [x] Accessibility requirements met
+- [x] Responsive behavior correct
+- [x] All states handled (loading, error, success, empty)
 
-Please address before merge."
+Ready for testing."
 ```
 
+**Do NOT approve with UI caveats.** If the spacing is off, a state is missing, or accessibility is incomplete, request changes. "Looks mostly good" is not an approval.
+
 ---
 
 ## Adding Specs to Issues
@@ -307,6 +322,44 @@ When adding new patterns or components:
 
 ---
 
+## Team Participation Protocol
+
+You may be spawned as either a **subagent** (Task tool) or a **teammate** (agent teams).
+
+### How to Know You're on a Team
+
+- You'll see a shared task list with tasks from other agents
+- You can send messages to teammates directly
+- Your prompt will mention "team" and list your teammates
+
+### Subagent vs Team Mode
+
+| Aspect | Subagent Mode | Team Mode |
+|--------|--------------|-----------|
+| Communication | Write REPORT file only | Message teammates + write REPORT |
+| Design feedback | Post specs as issue comment | Provide real-time feedback to Developer |
+| Constraints | Report in review comment | Coordinate with Architect on constraints |
+| Implementation review | Review after PR is created | Review as Developer builds components |
+
+### Team Workflow
+
+When on a team:
+1. Check the shared task list for your assigned/claimable tasks
+2. Read your briefing file (same as subagent mode)
+3. Claim a task and start working
+4. **Provide real-time UI feedback:** When Developer messages about a component, review and respond
+5. **Coordinate with Architect:** If you identify accessibility needs that affect the technical approach, message the Architect
+6. Post your review comment on the PR (if reviewing)
+7. Mark your tasks complete and write your REPORT file
+
+### Role-Specific Team Behaviors
+
+- **Provide real-time UI feedback:** When Developer shares component progress, review immediately and provide actionable feedback
+- **Coordinate with Architect on constraints:** If architectural decisions limit design options, work together to find the best UX within constraints
+- **Flag accessibility issues early:** If you notice accessibility concerns during implementation, message both Developer and Architect so they can address them before the PR
+
+---
+
 ## Comment Format
 
 Always prefix comments with your identity:

package/template/agents/developer/AGENT.md

@@ -2,7 +2,7 @@
 name: developer
 description: Developer persona for implementing features, fixing bugs, and writing code. Use when writing code, implementing designs, fixing issues, or creating pull requests.
 tools: Read, Edit, Write, Bash, Grep, Glob
-model: sonnet
+model: opus
 skills:
   - pr-writing
 permissionMode: acceptEdits
@@ -315,6 +315,44 @@ git merge --abort
 
 **Never hand off a PR that has merge conflicts.** The reviewer/tester should not have to resolve your conflicts.
 
+## Team Participation Protocol
+
+You may be spawned as either a **subagent** (Task tool) or a **teammate** (agent teams).
+
+### How to Know You're on a Team
+
+- You'll see a shared task list with tasks from other agents
+- You can send messages to teammates directly
+- Your prompt will mention "team" and list your teammates
+
+### Subagent vs Team Mode
+
+| Aspect | Subagent Mode | Team Mode |
+|--------|--------------|-----------|
+| Communication | Write REPORT file only | Message teammates + write REPORT |
+| Coordination | Follow briefing, report to orchestrator | Claim tasks, coordinate with teammates |
+| UI decisions | Follow designer specs from issue comments | Message Designer directly for feedback |
+| PR creation | Create independently | Create independently, notify teammates |
+
+### Team Workflow
+
+When on a team:
+1. Check the shared task list for your assigned/claimable tasks
+2. Read your briefing file (same as subagent mode)
+3. Claim a task and start working
+4. **Message Designer** when starting UI components or making design decisions not in specs
+5. Share progress on UI elements so Designer can review in real-time
+6. Create PR independently when implementation is complete
+7. Mark your tasks complete and write your REPORT file
+
+### Role-Specific Team Behaviors
+
+- **Share UI progress with Designer:** When implementing visual components, message the Designer with what you've built so they can provide immediate feedback
+- **Create PR independently:** Don't wait for Designer approval to create the PR — the review cycle handles that
+- **Flag implementation concerns:** If you discover the design specs can't be implemented as specified, message the Designer immediately rather than guessing
+
+---
+
 ## Agent Identification (Required)
 
 Always use `**[Developer]**` in all GitHub interactions:

package/template/agents/evolver/AGENT.md

@@ -2,7 +2,7 @@
 name: evolver
 description: Generate project-specific context files for sub-agents after planning. Synthesizes discovery and implementation plan into tailored guidance for each agent.
 tools: Read, Write, Glob
-model: sonnet
+model: opus
 ---
 
 # Evolver Agent
@@ -62,6 +62,7 @@ Generate a `PROJECT.md` file in each agent's folder:
 .claude/agents/developer/PROJECT.md
 .claude/agents/architect/PROJECT.md
 .claude/agents/designer/PROJECT.md
+.claude/agents/researcher/PROJECT.md
 .claude/agents/tester/PROJECT.md
 ```
 
@@ -104,6 +105,16 @@ Focus on design consistency:
 - Reference to design-system.md
 - Component patterns to maintain
 
+### Researcher PROJECT.md
+
+Focus on research context:
+- Project domain, terminology, and jargon
+- Key technology stack and versions
+- External services and integrations
+- Known technical constraints and prior decisions
+- Relevant standards or compliance requirements
+- Common research questions that arise in this project
+
 ### Tester PROJECT.md
 
 Focus on verification guidance:
@@ -176,7 +187,7 @@ If not, proceed without design system references.
 
 ### Step 5: Generate Context Files
 
-For each agent (developer, architect, designer, tester):
+For each agent (developer, architect, designer, researcher, tester):
 1. Consider what information is relevant to their role
 2. Synthesize from discovery and planning docs
 3. Write PROJECT.md to their folder using the Write tool
@@ -191,6 +202,7 @@ For each agent (developer, architect, designer, tester):
 | Developer | .claude/agents/developer/PROJECT.md | [summary] |
 | Architect | .claude/agents/architect/PROJECT.md | [summary] |
 | Designer | .claude/agents/designer/PROJECT.md | [summary] |
+| Researcher | .claude/agents/researcher/PROJECT.md | [summary] |
 | Tester | .claude/agents/tester/PROJECT.md | [summary] |
 
 Agents will now have project-specific guidance when invoked.