The instruction says the skills library has "35 skills", but .github/skills/ currently contains 34 skill files plus a README (35 files total). To avoid this drifting (and ambiguity about whether README counts), consider removing the numeric count or updating it to match the repo.

This states there are "11 gh-aw markdown workflows" for news generation, but .github/workflows/ currently has 10 news-*.md workflows (breaking, weekly-review, monthly-review, week-ahead, month-ahead, committee-reports, motions, propositions, article-generator, translate). Please correct the count or add the missing workflow to the list so it’s consistent with the repo.

npm run lint is described as "ESLint + HTMLHint validation", but in package.json the lint script runs only eslint src/ (HTMLHint is a separate npm run htmlhint). Update the command description or include the separate HTMLHint command to avoid misleading contributors/agents.

npm run docs:generate is described as generating "JSDoc API docs", but package.json shows it runs typedoc (docs:api). Please update the wording to TypeDoc to match the actual tooling.

The agent selection table recommends a security-architect agent, but there is no security-architect agent file under .github/agents/ in this repo (only references in docs). Either add the missing agent definition or update the table to list only agents that actually exist here.

The EU Parliament Monitor relevance bullets mention data.europa.eu/op.europa.eu, but the repo’s workflows actually allow and use data.europarl.europa.eu (and www.europarl.europa.eu) in network.allowed/safe-outputs.allowed-domains. Please update the domains so this guidance matches the real endpoints configured in .github/workflows/news-*.md.

The CI-cleaner instructions say to call a noop tool when CI is passing, but this repo’s gh-aw workflows use safeoutputs___noop as the safe-output tool call (see .github/workflows/news-*.md). Using noop will likely fail at runtime. Please rename to the correct tool call and include the expected message parameter if required by the safe-outputs schema.

The linting section implies HTMLHint errors will show up under npm run lint, but npm run lint runs only ESLint in this repo; HTMLHint is npm run htmlhint. Consider updating the steps to run both commands (or remove the HTMLHint guidance) so the agent’s workflow is actionable.

This file describes npm run lint as "ESLint + HTMLHint validation" and npm run docs:generate as "JSDoc API docs", but package.json defines lint as eslint src/ and docs:generate as TypeDoc-based (typedoc). Please update these command descriptions to reflect the actual scripts.

The workflow frontmatter example here uses on.schedule: daily, tools:, and safe-output constraints like title-prefix, but the repo’s actual workflows use cron schedules, network.allowed, mcp-servers, and safe-outputs.allowed-domains (see .github/workflows/news-breaking.md). Consider updating this example to match the repo’s workflow format, or explicitly mark it as an upstream gh-aw example.

The workflow examples use engine: copilot|claude|codex as a scalar, but this repo’s gh-aw workflows use an engine object with id (and typically model) (e.g. .github/workflows/news-breaking.md:76-78). Using the scalar form here is likely to produce invalid frontmatter or confuse workflow authors—please update the examples/table to match the repo’s actual frontmatter shape.

The example includes tools: european-parliament: {} but in this repo the European Parliament MCP server is configured under mcp-servers: and not listed under tools: (see .github/workflows/news-breaking.md:39-52). Keeping this example as-is may lead authors to add unsupported/unused tool entries; consider aligning it to the repo pattern (mcp-servers + tools.github + bash).

The overview says the sandbox provides “read-only filesystem access” and that the repository checkout is read-only, but gh-aw agents in this repo do write to the workspace to generate patches/artifacts (see compiled workflows invoking copilot with --add-dir "${GITHUB_WORKSPACE}" and safe-outputs producing PR patches). Consider rephrasing to clarify that the GitHub token is read-only, while the workspace filesystem is writable for patch generation.

The “EU Parliament Monitor Relevance” bullets are too restrictive compared to actual workflow allowlists. For example, .github/workflows/news-breaking.md allows github.com and api.github.com (and some workflows also allow *.com, *.org, api.worldbank.org, etc.), so it’s not accurate to say agents can only access the two EP domains.

The “Safe Output Types” table lists constraint keys like title-prefix, labels, and max-changed-files, but the compiled lock workflows for this repo currently configure safe outputs using fields like max_patch_size, protected_files, and protected_path_prefixes (see news-breaking.lock.yml safe outputs config). To avoid misleading workflow authors, please either align this table to the constraints actually enforced here, or clearly label it as an upstream gh-aw example rather than this repo’s current configuration.

Layer 4 describes “required prefixes” and “label constraints” as part of safe outputs. In this repo’s compiled workflows the safe outputs handler config currently enforces limits like max_patch_size / protected file lists rather than title-prefix/label constraints. Consider adjusting this description (or explicitly noting these are possible constraints) to match what the workflows actually enforce today.

“Deployment: GitHub Pages + S3 CDN” is ambiguous/misleading given the repo has a first-class S3/CloudFront deployment workflow (.github/workflows/deploy-s3.yml) and no equivalent GitHub Pages deploy workflow (Pages appears to be a failover/runbook scenario). Consider rewording to reflect the primary deployment path vs. fallback.

“Never merge Dependabot PRs on gh-aw manifest files directly” is unclear in this repo: there are no generated gh-aw manifest files like .github/workflows/package.json / requirements.txt / go.mod here. Consider either naming the actual generated artifacts that shouldn’t be merged directly (e.g., .lock.yml files) or removing this rule to avoid confusion.

The “Safe Output Rules” imply this repo enforces title prefixes and label allowlists via safe-outputs constraints. However, the current news workflows’ safe-outputs sections are {} (and the compiled .lock.yml handler config enforces things like max_patch_size / protected file lists instead). Suggest rephrasing this to describe the constraints that are actually enforced here, or clearly mark prefixes/labels as optional gh-aw capabilities not currently used by this repo.

The examples here use safe-outputs.create-pull-request.title-prefix / labels / max-changed-files, but this repo’s actual news workflows currently configure create-pull-request: {} (and enforcement happens via the compiled .lock.yml safe outputs handler config). To keep this agent repo-specific and avoid confusion, consider either updating the examples to match current workflow usage, or explicitly labeling these fields as optional upstream gh-aw features not currently used in this repository.

The tool configuration example lists european-parliament under tools:. In this repo’s actual gh-aw workflows (e.g. .github/workflows/news-breaking.md), the server is configured under mcp-servers: and not listed under tools:. Either update the example to match this repo’s frontmatter, or clarify that mcp-servers defines the server while tools controls built-ins like github/bash in this repository’s usage.

This section says built-in tools are “Always Available” (including bash), but this repo’s gh-aw workflows explicitly enable bash via tools: { bash: true } (see .github/workflows/news-breaking.md:48-53). Consider rewording to avoid implying bash is always enabled by default, or note that it must be turned on in frontmatter in this repo.

The “AI Engine Selection” table implies engine: { id: claude } is a valid/used option, but this repo’s workflows (e.g. news-breaking.md) run Claude via engine.id: copilot with a model: claude-opus-4.6 override. Consider adjusting the table (or adding a note) so readers don’t configure an unsupported id: claude in this repo’s workflows.

min-integrity is listed here as a top-level frontmatter field, but elsewhere in this PR (see gh-aw-firewall.md) integrity filtering is configured under tools.github.min-integrity. The repo’s existing workflows also don’t use a top-level min-integrity. Align the docs to a single location/key so workflow authors don’t end up with a frontmatter field that gh-aw ignores.

In “Common Issues”, the fix says “Add domain to the tools allowlist in frontmatter”, but domain allowlisting in this repo is configured via network.allowed (as shown earlier in this doc). Suggest updating the wording to point to network.allowed to avoid readers editing the wrong section.

timeout-minutes only controls the job’s wall-clock timeout; it doesn’t set CPU or memory limits. To avoid misleading readers, suggest rephrasing this bullet to separate “time limited via timeout-minutes” from “CPU/memory limited by the GitHub Actions runner/sandbox defaults” (or cite the specific gh-aw mechanism if it actually enforces CPU/memory).

The engine row lists claude as an engine id, but the repo’s compiled news workflows run Claude via engine.id: copilot with a model: claude-opus-4.6 override (see news-breaking.md). Consider clarifying here (e.g., “in this repo, Claude is selected via engine: { id: copilot, model: ... }”) to prevent authors from trying engine.id: claude and getting a compile/runtime error.