Borrowing it
Nothing to install: this file belongs to SocialGouv/egapro. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/SocialGouv/egapro/alpha/.claude/skills/implement/SKILL.mdgit clone --depth 1 https://github.com/SocialGouv/egaproWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/socialgouv/egapro/implement)<a href="https://agentmods.dev/skills/socialgouv/egapro/implement"><img src="https://agentmods.dev/badge/skills/socialgouv/egapro/implement/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/socialgouv/egapro/implement"><img src="https://agentmods.dev/badge/skills/socialgouv/egapro/implement.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector warn
SkillSpector: 6 findings, up to high
These are SkillSpector’s own severities. On a checked sample its high-severity flags on skills were ~96% false positives — a documented command, a public API, a “never do X” rule — so we show them as a caution to read, not a verdict. Why →
- high Tool Misuse · line 137 Tool parameters are crafted to achieve unintended or unsafe behavior. Parameter abuse can bypass intended safety checks (e.g. shell=True, --force, dangerous glob patterns).Fix: Validate all tool parameters against an allowlist. Reject dangerous parameter values (shell=True, --force, -rf /) and use safe defaults.
- medium Rogue Agent · line 12 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Rogue Agent · line 103 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Rogue Agent · line 144 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Rogue Agent · line 284 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
- medium Rogue Agent · line 105 Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.Fix: Remove any persistence mechanisms (cron jobs, startup scripts, state files). Skills should not maintain state across sessions without explicit user consent.
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00055 | $0.06561 |
| Opus 5.5 | $0.00022 | $0.02624 |
| Sonnet 5.5 | $0.00011 | $0.01312 |
| Haiku 4.5 | $0.00006 | $0.00656 |
Grade A, and why
implement scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 303 lines — stays where its author put it; the contents beside it link to each section on GitHub.
/implement
Phase exécution de la pipeline. Détecte le mode depuis le type d'issue et branche :
| Type d'issue | Mode | Mécanisme |
|---|---|---|
Feature (epic) |
epic | nohup bash scripts/orchestration/epic_loop.sh <N> > /tmp/epic_loop_<KEY>.log 2>&1 & (background, parallèle, plusieurs sub-tickets ; e2e-dev lancé en fin de loop sur epic/<N>) |
Task |
task | Lance code-dev en CLI foreground (claude --agent code-dev, bloquant), puis e2e-dev une fois validated |
Bug |
bug | Lance code-dev en CLI foreground (claude --agent code-dev, bloquant) avec rules/bug-fix-workflow.md, puis e2e-dev une fois validated |
| sub-issue d'un epic (non-feature) | task-debug | Comme task — utile pour re-rouler un sous-ticket d'un epic plus large (ex: après refacto ou debug) |
/implement n'orchestre rien lui-même : pour epic c'est epic_loop.sh qui parallèlise (et exécute la gate E2E bloquante run_e2e_dev.sh → run_architect_rework.sh en fin de loop), pour task/bug c'est un process CLI claude --agent code-dev foreground suivi d'un claude --agent e2e-dev. code-dev tourne comme main agent (process CLI) — obligatoire pour qu'il puisse lancer ses propres sous-agents (les 4 validateurs, functional-validator, design-validator) : un sous-agent ne peut pas en spawner d'autres. e2e-dev tourne en fin de pipeline (après dev terminé + sous-tickets mergés pour une Feature, ou après code-dev validated pour une Task/Bug) et possède toute la couverture E2E — code-dev n'écrit plus aucun test E2E.
Step 0 — Valider l'argument
$ARGUMENTS doit contenir un numéro d'issue. Si vide → demander à l'utilisateur lequel exécuter.
ARG_HEAD="$(echo "$ARGUMENTS" | awk '{print $1}')"
ISSUE_N="${ARG_HEAD#\#}"
# Récupérer le type + parent eventuel
gh issue view "$ISSUE_N" --json number,title,issueType,labels,state \
--jq '{number, title, issueType: .issueType.name, labels: [.labels[].name], state}'
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago Changed 4d6609a72021
- 16d ago Changed 18d1a6efaf48
- 1mo ago Changed 890bcc95803a
- 1mo ago First seen · 303 lines · 55 tokens per session scan A 9df6e449dbc3
implement is a skill published in the GitHub repository SocialGouv/egapro (12 stars, last pushed yesterday), licensed Apache-2.0. It adds 55 tokens to every session and 6,561 once invoked, about $0.0002 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-04.
Other skills, from other repositories
jira-validate-production
Check that the fix a Jira issue carries is live on the PRODUCTION site and behaves as the issue asked, then close the card, or open a follow-up issue for what failed. Insert into the prompt of a run started on a batch of merged issues, or of a Jira post-deploy column rule.
acceptance-criteria-gwt
Use when writing acceptance criteria for a task - express each as an observable Given/When/Then that QA can execute, including negative cases.
pm-uat-review
Use when a task is in pmuat - verify every acceptance criterion and the human's comments yourself in the browser, on a device, or over a loopback HTTP request, record a verdict per criterion, then move to humanuat or needrevision.
testrail
Sincronizar testes com TestRail. Use quando o usuário mencionar "testrail", "gestão de testes", "casos de teste", "execução de testes", "sincronizar casos de teste", "enviar resultados para testrail" ou "importar do testrail".
retest-after-revision
Use when the task came back to QA after needrevision - what to re-run, what may carry over, and how to keep old passes from approving new code.
aem-qa-handoff
Post the QA handoff comment to ADO — QA page URLs, prerequisites, wiki link. Use after /aem-doc-gen and /dx-doc-gen, or for 'handoff to QA'.