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 skills add techygarg/lattice --skill code-forgegit clone --depth 1 https://github.com/techygarg/latticeWrote 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/techygarg/lattice/code-forge)<a href="https://agentmods.dev/skills/techygarg/lattice/code-forge"><img src="https://agentmods.dev/badge/skills/techygarg/lattice/code-forge/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/techygarg/lattice/code-forge"><img src="https://agentmods.dev/badge/skills/techygarg/lattice/code-forge.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
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.00081 | $0.02645 |
| Opus 5.5 | $0.00032 | $0.01058 |
| Sonnet 5.5 | $0.00016 | $0.00529 |
| Haiku 4.5 | $0.00008 | $0.00265 |
Grade A, and why
code-forge 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 11d 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 — 147 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Code Forge
Required Skills
Read and apply:
framework:knowledge-priming-- Load project context (stack, architecture, conventions) so implementation matches the real project. (always)framework:context-anchoring-- Find and load the feature's context anchor doc; enrich it as implementation decisions are made (Create / Load / Enrich behaviors). (always)framework:learning-harvest-- Load prior operational learnings to inform implementation at session start; harvest new ones at session end. (always)framework:collaborative-judgment-- Surface genuine judgment calls as structured options instead of silently assuming. (always)framework:architecture-- Layer placement, dependency direction, structural validation. (always)framework:clean-code-- Craft guardrails: SRP, naming, complexity, error handling. (always)framework:domain-driven-design-- Aggregates, entities, value objects, domain services. (conditional: domain-layer components only)framework:secure-coding-- Trust bounds, injection prevention, secrets handling. (conditional: trust-boundary code only)framework:test-quality-- AAA structure, isolation, assertion quality, naming. (always when writing tests)
Additional Instructions
STOP: Before Step 1, read additional_instructions.code_forge (one line or a list) from .lattice/config.yaml. No file or no key → skip silently.
When lines are found:
- Show them verbatim under "Additional instructions (from config):".
- Highest priority — apply them for the whole session, including on resume. On any conflict with anything else in this skill — steps, gates, STOP rules — or with its Required Skills, standards documents, or operational learnings, the config line wins.
Workflow
Step 1: Establish Implementation Context
- Run
framework:learning-harvestLoad behavior. Focus hint: "implementation session — focus: implementation craft, quality signals, reliability". - Run
framework:context-anchoringDocument Discovery: scan the context base directory (per the atom's Config Resolution) for an existing anchor doc covering this feature's implementation.- Found → Load behavior. Present the structured acknowledgment: feature name, status, decision count, open questions, constraints. STOP: Honor every logged decision and constraint as an active commitment.
- Not found → ask the user: "Is there a design doc or blueprint for this feature, or do we work from what we've discussed?" Accept either answer gracefully:
- Doc provided → load it and follow it.
- Proceed without → all atom rails still apply; there is simply no approved design doc to reference. Work from the verbal requirements in conversation.
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.
- 11d ago Changed · +9 lines 3d73461bd5c5
- 1mo ago First seen · 138 lines · 81 tokens per session scan A 519566d6f37e
code-forge is a skill published in the GitHub repository techygarg/lattice (207 stars, last pushed 11d ago), licensed MIT. It adds 81 tokens to every session and 2,645 once invoked, about $0.0003 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-08-30.
Other skills, from other repositories
api-design
Designs interfaces that survive their consumers — resource modeling, errors, versioning, pagination, and compatibility. Use this to design a new API, review one before it ships, decide how to version or deprecate, fix an interface consumers keep misusing, or work out whether a change is breaking.
ash-framework
Ash Framework — resources, actions, policies, aggregates, calculations, AshPhoenix.Form, LiveView, migrations. Use when generating resources via mix ash.codegen, editing changes, checks, types, validations, or domain code interfaces.
liveview-patterns
Build LiveView: async data (assignasync), PubSub (check connected?), phx-change events, form components/modals/uploads, streams for lists, livepatch. Use when handling interactions, debugging events, or tracking Presence.
tidewave-integration
Tidewave MCP runtime tools — debugging, smoke testing, live state inspection, SQL queries, hex docs. Use when evaluating code in a running Phoenix app.
oban
Use when writing, scheduling, testing or debugging Oban jobs, even for a how-to question: workers, cron, retries, unique jobs, queues, Pro Workflow/Batch. Load it before touching job code; it holds the job rules.
perf
Use when anything in a Phoenix app is slow, times out, or uses too much memory, even if the cause looks obvious. Load it before analyzing or fixing: it runs measured Ecto, LiveView and OTP checks and ranks fixes.