Create a new Lattice skill — atom, molecule, or refiner — following all framework conventions. Writing skill files manually almost always produces convention violations: wrong section order, missing confirmation gates, defaults.md without the right structure. This skill knows all of that and guides you through it. Use whenever adding any new atom, molecule, or refiner to Lattice, or when the user says 'create a new skill', 'add an atom', 'add a molecule', 'add a refiner', 'build X for Lattice', 'new lattice skill', or 'skill forge'. Does not validate, align docs, or deploy — those are separate skills you run after.
npx skills add https://github.com/techygarg/lattice --skill skill-forge
Core responsibility: Create the right files with the right structure for a new Lattice skill.
Input: A description of what the skill should do and when it should trigger.
Output: One or more skill files written to the correct path:
skills/atoms/{name}/SKILL.md + skills/atoms/{name}/references/defaults.mdskills/molecules/{name}/SKILL.mdskills/refiners/{name}/SKILL.md + skills/refiners/{name}/assets/template.mdHow to verify this skill did its job:
name: frontmatter exactlyAsk the user: *"What should this skill do, and when should it trigger? Describe it briefly."*
From the description, determine the tier:
| The skill... | Tier |
|---|---|
| Enforces ONE principle with a checklist and anti-pattern scan | Atom |
| Orchestrates multiple atoms into a multi-step workflow | Molecule |
| Runs a guided interview to produce a .lattice/standards/*.md file | Refiner |
State your read and confirm with the user. Get explicit tier agreement before proceeding.
Before writing a single line of SKILL.md, agree on the design.
Check knowledge-base/ for an existing requirements doc:
ls knowledge-base/ | grep -i {name}
If found → read it, summarise key design decisions, confirm they still reflect intent.
If not found → resolve these questions through conversation before writing:
For a molecule:
skills/atoms/ to see what exists.).lattice/? Which subfolder? (Must be a named subfolder, never the root.)For a refiner:
paths.{snake_case_key} config key does it add to .lattice/config.yaml?Write a one-paragraph design summary and confirm with the user.
Do NOT write SKILL.md until design is confirmed.
Read PROJECT.md — the Skill Conventions section. Always read it fresh; never rely on memory.
Note the current skill counts (atoms/molecules/refiners) — they will need updating in PROJECT.md after creation, but that is skill-align's job.
skills/atoms/{name}/SKILL.md — sections in this exact order:
name (lowercase-hyphenated), description (include trigger phrases).lattice/config.yaml for paths.{config_key}mode: overlay (merge with defaults) or mode: override (replace)./references/defaults.md- [ ] Name: what it looks like → fix), minimum 5 itemsskills/atoms/{name}/references/defaults.md — the embedded defaults:
skills/molecules/{name}/SKILL.md:
framework:{name} with always/conditional qualifierGenerative molecule conventions (code-forge, bug-fix, refactor-safely pattern):
framework:collaborative-judgmentPlanning/interactive molecule conventions (design-blueprint, requirement-forge pattern):
.lattice/{subfolder}/ — never to .lattice/ rootskills/refiners/{name}/SKILL.md — cover all of these:
./assets/template.md and its Interview Guidance comments)paths.{key} to .lattice/config.yaml)skills/refiners/{name}/assets/template.md:
<!-- INTERVIEW GUIDANCE: --> comments per sectionBefore finishing, verify:
name: frontmatter field (exactly, character by character)description: contains trigger phrases — what a user would actually type to invoke thisdefaults.md exists and has §-numbered sections with real contenttemplate.md exists with Interview Guidance comments in every sectionReport what was created and where. Do not run validation, sync, or deploy — those are separate steps.
Use when creating new skills, editing existing skills, or verifying skills work before deployment
Curated collection of high-quality prompts for various use cases. Includes role-based prompts, task-specific templates, and prompt refinement techniques. Use when user needs prompt templates, role-play prompts, or ready-to-use prompt examples for coding, writing, analysis, or creative tasks.
Convert abstract edge concepts into strategy draft variants and optional exportable ticket YAMLs for edge-candidate-agent export/validation.
INVOKE THIS SKILL when writing ANY LangGraph code. Covers StateGraph, state schemas, nodes, edges, Command, Send, invoke, streaming, and error handling.
Analyze the protocol layer between agent harness and LLM model. Use when (1) understanding message wire formats and API contracts, (2) examining tool call encoding/decoding mechanisms, (3) evaluating streaming protocols and partial response handling, (4) identifying agentic chat primitives (system prompts, scratchpads, interrupts), (5) comparing multi-provider abstraction strategies, or (6) understanding how frameworks translate between native LLM APIs and internal representations.
Translate SKILL.md and README.md files into multiple languages for sharing skills internationally
| Shared workflow for editing Langfuse's repo-owned agent setup under `.agents/`. Use when changing AGENTS files, shared skills, `.agents/config.json`, generated shim behavior, provider discovery paths, or install-time agent sync.
>- Summarizes Google Cloud Data Lineage graphs to help users debug data quality issues and understand data provenance for BQ/GCS. Use when summarizing upstream and downstream data flows, and presenting complex lineage data as an intuitive Markdown report. Don't use for generic BigQuery queries, editing lineage relationships, or downstream deprecation. Don't use for downstream blast-radius impact analysis (use datalineage-bigquery-asset-impact-analysis skill instead).
Take techygarg/skill-forge from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.