Skip to content

feat: add docs-triage-guard skill to prevent auto-coding design docs - #153

Open
maruiz93 wants to merge 1 commit into
mainfrom
triage-docs-design-guard
Open

feat: add docs-triage-guard skill to prevent auto-coding design docs#153
maruiz93 wants to merge 1 commit into
mainfrom
triage-docs-design-guard

Conversation

@maruiz93

@maruiz93 maruiz93 commented Aug 3, 2026

Copy link
Copy Markdown

Summary

  • Adds a docs-triage-guard skill that teaches the triage agent to detect ADR and design-doc issues and route them to human review instead of auto-coding
  • Uses category: "other" (which falls through to triaged in the post-script's * catch-all) combined with label_actions to apply design-doc and documentation labels
  • Registers a custom triage harness via base composition (ADR 0045) — the only override is adding the skill; no schema fork or post-script fork

How it works

  1. The skill teaches the triage agent to recognize ADR/design-doc issues (by title keywords like "ADR", "RFC", "design doc", "proposal" and by body structure)
  2. When detected, the agent sets category: "other" instead of "documentation", which routes to triaged via the existing *) default case in post-triage.sh
  3. The agent includes label_actions to add design-doc and documentation labels for tracking
  4. Regular documentation issues (typo fixes, README updates) continue to use category: "documentation" and auto-promote to ready-to-code as before

Why this approach

This replaces the approach from #149 (closed per review feedback — forking the post-script was too invasive). By working within the existing category routing, we avoid overriding the schema or post-script entirely.

A more general solution for user-defined categories is tracked in fullsend-ai/agents#618.

Files changed

File Purpose
config.yaml Register custom triage harness (local path replaces upstream URL)
harness/triage-custom.yaml Base composition — extends upstream triage with the skill
skills/docs-triage-guard/SKILL.md Context-injection skill for ADR/design-doc detection

Test plan

  • Verify base composition resolves correctly (skill concatenates with upstream issue-labels)
  • Test with an ADR issue (title: "ADR: ...") — should get triaged + design-doc + documentation
  • Test with a regular doc issue (title: "Fix typo in README") — should get ready-to-code + documentation
  • Test with a design-doc issue (title: "RFC: ...") — should get triaged + design-doc + documentation

Relates to fullsend-ai/agents#260, fullsend-ai/agents#618

🤖 Generated with Claude Code

ADR and design-doc issues were being auto-promoted to ready-to-code
via the documentation category, triggering the code agent on work
that requires human discussion. This adds a skill that teaches the
triage agent to classify these as category "other" with design-doc
and documentation labels via label_actions, routing them to triaged
instead.

Uses base composition (ADR 0045) to extend the upstream triage
harness with just the skill — no schema fork or post-script override.

Replaces the approach from #149 (closed per review feedback).
Relates to fullsend-ai/agents#260, fullsend-ai/agents#618.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Signed-off-by: Marta Anon <manon@redhat.com>
@maruiz93
maruiz93 requested a review from ggallen as a code owner August 3, 2026 11:49
@qodo-code-review

Copy link
Copy Markdown

PR Summary by Qodo

Add docs-triage-guard skill to route design docs to human review

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

Grey Divider

AI Description

• Add a triage skill to detect ADR/RFC/design-doc issues during intake.
• Route detected design docs to human review via category: "other" and labels.
• Register a custom triage harness via base composition (no upstream script/schema fork).
Diagram

graph TD
  cfg["config.yaml"] --> harness["harness/triage-custom.yaml"] --> upstream["Upstream triage.yaml"] --> agent(["Triage agent"])
  harness --> skill["docs-triage-guard skill"] --> agent --> route{{"Design doc?"}} --> state["triaged vs ready-to-code"]
  agent --> labels["Apply labels"]

  subgraph Legend
    direction LR
    _file["File/Config"] ~~~ _agent(["Agent"]) ~~~ _decision{{"Decision"}}
  end
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Fork post-triage routing script for design-doc handling
  • ➕ Hard-enforces routing regardless of model output
  • ➕ Centralizes routing logic in deterministic shell code
  • ➖ Invasive and harder to maintain across upstream updates
  • ➖ Requires ongoing divergence management vs upstream harness/scripts
2. Introduce a first-class `design-doc` category in schema + router
  • ➕ More explicit and self-documenting than overloading other
  • ➕ Enables richer reporting/automation keyed on category
  • ➖ Requires coordinated changes across schema, prompts, and routing scripts
  • ➖ Broader blast radius than a skill-only change
3. Label-only workflow gate (never auto-promote if label matches)
  • ➕ Keeps categories stable; routing based on observable labels
  • ➕ Can be implemented as a simpler policy layer
  • ➖ Depends on reliable label emission; still model-dependent
  • ➖ May require additional routing logic changes anyway

Recommendation: The PR’s approach (base-composed harness + skill that routes via existing other catch-all while adding tracking labels) is the least invasive option and aligns with the stated goal of avoiding script/schema forks. Consider the first-class category approach only if design-doc routing needs to become a supported extensibility feature across repos.

Files changed (3) +76 / -1

Enhancement (2) +74 / -0
triage-custom.yamlAdd base-composed triage harness that injects docs-triage-guard +6/-0

Add base-composed triage harness that injects docs-triage-guard

• Introduces a custom triage harness that base-references the upstream triage.yaml and adds the 'skills/docs-triage-guard' skill. Keeps the rest of the upstream triage behavior intact by only composing configuration.

harness/triage-custom.yaml

SKILL.mdDefine skill to detect ADR/design-doc issues and avoid auto-coding routing +68/-0

Define skill to detect ADR/design-doc issues and avoid auto-coding routing

• Adds a new skill that instructs the triage agent how to identify ADRs and design docs by title/body cues. When detected, it directs the agent to emit 'category: "other"' and add 'design-doc' + 'documentation' labels via 'label_actions' so the issue routes to human review.

skills/docs-triage-guard/SKILL.md

Other (1) +2 / -1
config.yamlPoint triage agent to a local custom harness +2/-1

Point triage agent to a local custom harness

• Replaces the remote triage harness source with a named 'triage' agent that loads 'harness/triage-custom.yaml'. This enables local base composition while keeping other agents pinned to upstream URLs.

config.yaml

@qodo-code-review

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

Context used
✅ Compliance rules (platform): 4 rules

Grey Divider


Remediation recommended

1. Hash updater breaks 🐞 Bug ⚙ Maintainability
Description
hack/update-agent-hashes.sh greps any harness/*.yaml substring from config.yaml and then tries
to fetch it from the fullsend-ai/agents repo; the new local source: harness/triage-custom.yaml
matches this and will cause the script to curl a non-existent URL and exit non-zero. This breaks the
repo’s standard workflow for bumping the pinned fullsend-ai/agents SHA.
Code

config.yaml[R43-44]

+  - name: triage
+    source: harness/triage-custom.yaml
Relevance

●●● Strong

Team invested in updater script correctness/atomicity; breaking it likely unacceptable (PRs
#106,#107).

PR-#106
PR-#107

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
config.yaml now references a local harness file. The updater script extracts all harness/*.yaml
tokens from config.yaml and unconditionally constructs a
raw.githubusercontent.com/fullsend-ai/agents/<sha>/<path> URL for each one, which will fail for a
repo-local harness path like harness/triage-custom.yaml.

config.yaml[42-45]
hack/update-agent-hashes.sh[14-24]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`hack/update-agent-hashes.sh` currently assumes every `harness/*.yaml` occurrence in `config.yaml` is a remote path inside the `fullsend-ai/agents` repo, but `config.yaml` now includes a repo-local harness (`harness/triage-custom.yaml`). The script should only hash/update remote agents harness URLs (or at least skip local `source:` entries), otherwise `curl -sfL` fails and the script exits.

## Issue Context
The config change is intentional (local wrapper harness). The maintenance script should adapt so future SHA bumps remain smooth.

## Fix Focus Areas
- hack/update-agent-hashes.sh[14-24]
- config.yaml[43-44]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Triage base SHA drifts 🐞 Bug ☼ Reliability
Description
harness/triage-custom.yaml pins its own base: URL to a specific fullsend-ai/agents
commit+sha256, but hack/update-agent-hashes.sh only rewrites agent SHAs/hashes inside
config.yaml. After this PR, bumping the agents SHA via the script will leave triage inheriting an
older upstream triage harness (and/or require manual base+sha256 updates), causing version skew.
Code

harness/triage-custom.yaml[R1-2]

+base: https://raw.githubusercontent.com/fullsend-ai/agents/a0fec953cd3c8b877af9821551b503df88d394d8/harness/triage.yaml#sha256=f56cbb0a3c1cb71563aa1b2fb80ca9ecb922e4c832f886e8154e2e9beb6b56c6
+role: triage
Relevance

●● Moderate

Repo pins base URLs for determinism (PR #85) but no evidence they auto-sync base pins with update
script.

PR-#85
PR-#106

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The wrapper harness hard-codes the agents SHA+sha256 in its base: field, while the bump script’s
SHA rewrite is scoped to a temporary copy of config.yaml only—so it cannot keep this new pin in
sync.

harness/triage-custom.yaml[1-6]
hack/update-agent-hashes.sh[12-24]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new wrapper harness (`harness/triage-custom.yaml`) embeds a pinned `base:` URL to `fullsend-ai/agents/<sha>/...#sha256=...`. The existing bump script only updates pins found in `config.yaml`, so triage’s base stays on the old SHA when the rest of the repo is updated.

## Issue Context
This doesn’t necessarily break current runtime behavior, but it will cause drift on the next agents SHA bump.

## Fix Focus Areas
- harness/triage-custom.yaml[1-1]
- hack/update-agent-hashes.sh[12-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

To customize comments, go to the Qodo configuration screen, or learn more in the docs.

Qodo Logo

Comment thread config.yaml
Comment on lines +43 to +44
- name: triage
source: harness/triage-custom.yaml

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

1. Hash updater breaks 🐞 Bug ⚙ Maintainability

hack/update-agent-hashes.sh greps any harness/*.yaml substring from config.yaml and then tries
to fetch it from the fullsend-ai/agents repo; the new local source: harness/triage-custom.yaml
matches this and will cause the script to curl a non-existent URL and exit non-zero. This breaks the
repo’s standard workflow for bumping the pinned fullsend-ai/agents SHA.
Agent Prompt
## Issue description
`hack/update-agent-hashes.sh` currently assumes every `harness/*.yaml` occurrence in `config.yaml` is a remote path inside the `fullsend-ai/agents` repo, but `config.yaml` now includes a repo-local harness (`harness/triage-custom.yaml`). The script should only hash/update remote agents harness URLs (or at least skip local `source:` entries), otherwise `curl -sfL` fails and the script exits.

## Issue Context
The config change is intentional (local wrapper harness). The maintenance script should adapt so future SHA bumps remain smooth.

## Fix Focus Areas
- hack/update-agent-hashes.sh[14-24]
- config.yaml[43-44]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment on lines +1 to +2
base: https://raw.githubusercontent.com/fullsend-ai/agents/a0fec953cd3c8b877af9821551b503df88d394d8/harness/triage.yaml#sha256=f56cbb0a3c1cb71563aa1b2fb80ca9ecb922e4c832f886e8154e2e9beb6b56c6
role: triage

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

2. Triage base sha drifts 🐞 Bug ☼ Reliability

harness/triage-custom.yaml pins its own base: URL to a specific fullsend-ai/agents
commit+sha256, but hack/update-agent-hashes.sh only rewrites agent SHAs/hashes inside
config.yaml. After this PR, bumping the agents SHA via the script will leave triage inheriting an
older upstream triage harness (and/or require manual base+sha256 updates), causing version skew.
Agent Prompt
## Issue description
The new wrapper harness (`harness/triage-custom.yaml`) embeds a pinned `base:` URL to `fullsend-ai/agents/<sha>/...#sha256=...`. The existing bump script only updates pins found in `config.yaml`, so triage’s base stays on the old SHA when the rest of the repo is updated.

## Issue Context
This doesn’t necessarily break current runtime behavior, but it will cause drift on the next agents SHA bump.

## Fix Focus Areas
- harness/triage-custom.yaml[1-1]
- hack/update-agent-hashes.sh[12-26]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant