bryan/agent-team
1
0
Fork 0
mirror of https://github.com/itme-brain/agent-team.git synced 2026-05-08 13:50:12 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

fix(protocol): tighten workflow contract

Browse source
This commit is contained in:
Bryan Ramos 2026-04-03 12:48:23 -04:00
parent 3a2d565aaa
commit 54acfec834
4 changed files with 16 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

2
agents/auditor.md
View file

@ -80,7 +80,7 @@ typecheck_status: pass | fail | skipped
--- ---
``` ```
**Hard rule:** `security_findings.critical > 0` or `build_status: fail` or `test_status: fail` requires `signal: fail`. **Hard rule:** `security_findings.critical > 0` or `security_findings.high > 0` or `build_status: fail` or `test_status: fail` requires `signal: fail`.
Then the markdown body: Then the markdown body:

6
agents/reviewer.md
View file

@ -28,7 +28,7 @@ Shell access is intentionally unavailable in this role to enforce read-only beha
## Claim verification ## Claim verification
- **Acceptance criteria** — walk each criterion explicitly by number. Clean code that doesn't do what was asked is a FAIL. - **Acceptance criteria** — when acceptance criteria are provided, walk each criterion explicitly by number. Clean code that doesn't do what was asked is a FAIL.
- **API and library usage** — verify against official docs ${WEB_SEARCH} when the implementation uses external APIs, libraries, or non-obvious patterns - **API and library usage** — verify against official docs ${WEB_SEARCH} when the implementation uses external APIs, libraries, or non-obvious patterns
- **File and path claims** — do they exist? - **File and path claims** — do they exist?
- **Logic correctness** — does the implementation actually solve the problem? - **Logic correctness** — does the implementation actually solve the problem?
@ -57,6 +57,8 @@ ac_coverage:
**Hard rule:** `critical_count > 0` requires `signal: fail`. **Hard rule:** `critical_count > 0` requires `signal: fail`.
Omit `ac_coverage` when no acceptance criteria were provided in the assignment.
Then the markdown body: Then the markdown body:
### Review: [scope] ### Review: [scope]
@ -75,6 +77,8 @@ Then the markdown body:
- AC2: PASS / FAIL — [one line] - AC2: PASS / FAIL — [one line]
- ... - ...
Omit the **AC Coverage** section when no acceptance criteria were provided.
One line summary. One line summary.
--- ---

15
skills/message-schema/SKILL.md
View file

@ -52,7 +52,7 @@ The `signal` field is the orchestrator's primary routing key. It determines the
### worker_submission ### worker_submission
Emitted by: worker, debugger, documenter Emitted by: grunt, worker, senior, debugger, documenter
```yaml ```yaml
--- ---
@ -103,11 +103,12 @@ ac_coverage:
--- ---
``` ```
Required: `type`, `signal`, `critical_count`, `moderate_count`, `minor_count`, `ac_coverage` Required: `type`, `signal`, `critical_count`, `moderate_count`, `minor_count`
Optional: `ac_coverage` (omit when no acceptance criteria were provided in the assignment)
**Hard rule:** `critical_count > 0` requires `signal: fail`. **Hard rule:** `critical_count > 0` requires `signal: fail`.
Body: Findings by severity (CRITICAL / MODERATE / MINOR), then AC Coverage details, then one-line summary. Body: Findings by severity (CRITICAL / MODERATE / MINOR), then AC Coverage details when applicable, then one-line summary.
### audit_verdict ### audit_verdict
@ -131,7 +132,7 @@ typecheck_status: pass | fail | skipped
Required: `type`, `signal`, `security_findings`, `build_status`, `test_status` Required: `type`, `signal`, `security_findings`, `build_status`, `test_status`
Optional: `typecheck_status` Optional: `typecheck_status`
**Hard rule:** `security_findings.critical > 0` or `build_status: fail` or `test_status: fail` requires `signal: fail`. High-severity findings (`security_findings.high > 0`) do not require `fail` — use `pass_with_notes`. **Hard rule:** `security_findings.critical > 0` or `security_findings.high > 0` or `build_status: fail` or `test_status: fail` requires `signal: fail`.
Body: Security findings by severity (or CLEAN), then Runtime section with tested/passed/failed. Body: Security findings by severity (or CLEAN), then Runtime section with tested/passed/failed.
@ -208,7 +209,7 @@ Body: Answer, Verified Facts with sources, Version Constraints, Gotchas, Unverif
### task_assignment ### task_assignment
Sent to: worker, debugger, documenter Sent to: grunt, worker, senior, debugger, documenter
```yaml ```yaml
--- ---
@ -228,7 +229,7 @@ Body: Task spec, Acceptance Criteria, Context (interface contracts, constraints,
### revision_request ### revision_request
Sent to: worker, debugger, documenter Sent to: grunt, worker, senior, debugger, documenter
```yaml ```yaml
--- ---
@ -249,7 +250,7 @@ Body: Issues to fix (from reviewer and/or auditor), grouped by source, with guid
### approval ### approval
Sent to: worker, debugger, documenter Sent to: grunt, worker, senior, debugger, documenter
```yaml ```yaml
--- ---

4
skills/worker-protocol/SKILL.md
View file

@ -1,7 +1,7 @@
--- ---
name: worker-protocol name: worker-protocol
description: Standard output format, feedback handling, and operational procedures for all worker agents. description: Standard output format, feedback handling, and operational procedures for all worker agents.
when_to_use: Loaded by worker, debugger, and documenter agents. Defines the worker_submission envelope format and commit workflow. when_to_use: Loaded by grunt, worker, senior, debugger, and documenter agents. Defines the worker_submission envelope format and commit workflow.
--- ---
## Output format ## Output format
@ -29,7 +29,7 @@ Then the markdown body:
[Your deliverable here] [Your deliverable here]
## Self-Assessment ## Self-Assessment
- Acceptance criteria met: [yes/no per criterion, one line each] - Acceptance criteria met: [yes/no per criterion, one line each, or "No acceptance criteria were provided"]
- Known limitations: [any, or "none"] - Known limitations: [any, or "none"]
``` ```