Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/gtrabanco/agentic-workflow/planning-preflightnpx skills add gtrabanco/agentic-workflow --skill planning-preflightgit clone --depth 1 https://github.com/gtrabanco/agentic-workflowWrote 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/gtrabanco/agentic-workflow/planning-preflight)<a href="https://agentmods.dev/skills/gtrabanco/agentic-workflow/planning-preflight"><img src="https://agentmods.dev/badge/skills/gtrabanco/agentic-workflow/planning-preflight.svg" alt="Measured on agentmods" height="20"></a>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 | $0.00072 | $0.01222 |
| Opus 5 | $0.00036 | $0.00611 |
| Sonnet 5 | $0.00014 | $0.00244 |
| Haiku 4.5 | $0.00007 | $0.00122 |
Grade A, and why
planning-preflight 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 5d 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 — 131 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Planning Preflight (internal)
The single owner of the planning-side repository gates. plan-feature and
plan-fix consume this one contract instead of each internal repeating its own
normalized-state read and architectural classification.
This skill uses a two-stage contract to resolve the tension between: (1) the need for planners to read the NRS early (architecture discovery is read-only and required to inform the plan), and (2) the requirement that the final architectural classification only happens after the complete engineering plan exists.
When to use
Any planner route that can write planning artifacts:
plan-feature— every route that will scaffold (scoped, issue,--next).plan-fix— every fix-SPEC draft.
Composed internals (plan-feature-from-issue, plan-feature-scaffold)
consume the same result via the in-turn planning context the router creates;
they never re-run discovery or classification.
Two-Stage Contract
Stage 1 — NRS read during planning (lightweight)
While the plan is still being built, routers may perform a read-only consumption of the normalized repository state (NRS) for architectural context. At this stage only the NRS port is classified; the architectural classification is deferred.
Record the Stage 1 result using the following format:
Preflight: Stage 1 — NRS <consumed|n/a> · arch: deferred
This result informs the plan but does not block emission.
Stage 2 — Full classification after plan cut (final)
Once the complete engineering plan exists (the SPEC is filled and the phases are cut), run the FULL architectural classification exactly once per plan — never per-composed-internal.
Discover the optional project invariant document declared in the documentation
map (normally docs/architecture/ARCHITECTURAL_INVARIANTS.md). If absent,
record n/a: no project invariants declared and pass. For every applicable
rule, cite its ID and repository evidence and classify the planned change as
preserves, violates, introduces, or changes. Only preserves may
reach emission. A violation, new rule, or changed rule stops for an explicit
architectural decision through the project's declared authority; never convert
it into an engineering task or infer approval from the SPEC. Use frozen NRS
facts when available, but repository inspection remains authoritative.
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.
- 5d ago First seen · 131 lines · 72 tokens per session scan A 8940c690a62e
planning-preflight is a skill published in the GitHub repository gtrabanco/agentic-workflow (20 stars, last pushed today), licensed MIT. It adds 72 tokens to every session and 1,222 once invoked, about $0.0004 per session on Opus 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-08-30.
Other skills, from other repositories
think-like-me
Personal engineering rules and reasoning patterns the user has curated over time. Consult BEFORE writing, modifying, debugging, or designing any technical feature — rules often cover domain-specific gotchas (e.g., mobile audio timers need background mode) that generic answers miss. Also triggers on /learn-this, "learn…
offensive-mitigations
Security mitigation reference and bypass catalog: ASLR, DEP/NX, RELRO, stack canaries, CFI, sandboxing, seccomp. Covers both detection of enabled mitigations and known bypass techniques. Use when assessing target hardening or planning exploit mitigation bypasses.
offensive-exploit-development
Exploit development operational guide: environment setup, debugging workflow, PoC development lifecycle, writing reliable exploits, using pwntools/pwndbg, heap exploitation techniques, and weaponization considerations. Use when actively developing exploits or setting up an exploit dev environment.
offensive-advanced-redteam
Comprehensive red team operations methodology covering full engagement lifecycle from planning through reporting. Addresses engagement scoping and rules of engagement negotiation, multi-tier C2 infrastructure design with redirectors and domain fronting, malleable traffic profiles and beacon tradecraft, OPSEC…
offensive-crypto-attacks
Systematic methodology for identifying and exploiting cryptographic implementation weaknesses in real-world applications. Covers padding oracle attacks against CBC-mode ciphers with PKCS7 padding (Vaudenay's original attack through modern padbuster automation), ECB mode exploitation including block cut-and-paste and…
offensive-c2-frameworks
Command and Control framework deployment, configuration, and operational tradecraft for red team engagements. Covers Cobalt Strike (malleable C2 profiles, Beacon types HTTP/HTTPS/DNS/SMB, Beacon Object Files for in-memory execution, sleep and jitter tuning, named pipe pivoting), Sliver (implant generation across…