by garagon
Minimal AI coding agent team skills for the full engineering workflow.
# Add to your Claude Code skills
git clone https://github.com/garagon/nanostackYou have access to a set of composable engineering workflow skills. Each skill is a folder with supporting files — read them as needed for context.
| Skill | When to use | Modes | Key files |
|-------|-------------|-------|-----------|
| /think | Before planning — strategic product thinking, premise validation, scope decisions. | — | think/references/forcing-questions.md, think/references/cognitive-patterns.md |
| /nano | Before starting any non-trivial work. Produces a scoped, actionable plan. | — | plan/templates/plan-template.md |
| /review | After code is written. Two-pass review + scope drift detection + conflict resolution. | --quick --standard --thorough | review/checklist.md, reference/conflict-precedents.md |
| /qa | To verify code works. Browser-based testing with Playwright, plus root-cause debugging. | --quick --standard --thorough | qa/bin/screenshot.sh |
| /security | Before shipping. OWASP Top 10 + STRIDE + variant analysis + conflict detection. | --quick --standard --thorough | security/references/owasp-checklist.md, security/templates/security-report.md |
| /ship | To create PRs, merge, deploy, and verify. Generates sprint journal on success. | — | ship/templates/pr-template.md |
| /guard | When working near production, destructive operations, or sensitive systems. | — | guard/bin/check-dangerous.sh |
| /conductor | Orchestrate parallel agent sessions through a sprint. Coordinate task claiming and artifact handoff. | start claim complete status | conductor/bin/sprint.sh |
Inspired by gstack from Garry Tan. 9 skills. Zero dependencies. Zero build step.
Works with Claude Code, Cursor, OpenAI Codex, OpenCode, Gemini CLI, Antigravity, Amp and Cline.
git clone https://github.com/garagon/nanostack.git ~/.claude/skills/nanostack
cd ~/.claude/skills/nanostack && ./setup
That's it. Now try this:
You: I need to add notifications to my app. Users keep missing
replies on their posts.
You: /think
Agent: Before we build anything, how are users coping today?
You: They open the app 3-4 times a day just to check. Sometimes
they miss replies for hours. People are frustrated.
Agent: I'm going to push back on "notifications." You said users open
the app 3-4 times a day. That's high engagement. They already
come back. The problem isn't that they can't be reached. The
problem is that when they arrive, they can't tell what changed.
That's a freshness problem, not a messaging problem.
A notification system (email, push, in-app, preferences,
digest, unsubscribe) is a 3-week project. A red dot on the
nav icon that says "something new" ships this afternoon.
One solves the symptom (they're not being told). The other
solves the cause (they can't see what's new when they look).
RECOMMENDATION: Reduce. Ship the dot. See if complaints drop.
If they do, you just saved 3 weeks. If they don't, then build
push notifications, but now you have data, not a guess.
You: Makes sense. Let's do the dot.
You: /nano
[3 steps, 2 files, product standards: shadcn/ui + Tailwind]
You: [builds it]
You: /review
Review: 2 findings (1 auto-fixed, 1 nit). 2 things done well.
You: /ship
Ship: PR created. Tests pass. Done.
You said "notifications." The agent said "your users have a freshness problem" and found a solution that ships in an afternoon instead of three weeks. Four commands. That is not a copilot. That is a thinking partner.
No comments yet. Be the first to share your thoughts!
The default workflow is: /think → /nano → build → /review → /qa → /security → /ship
With /conductor, review + qa + security run in parallel — they all depend on build, not on each other:
think → plan → build ─┬─ review ─┐
├─ qa ├─ ship
└─ security ─┘
Activate /guard at any point when operating near production or sensitive systems.
Read ZEN.md for the full set of principles. When in doubt about a decision during any skill, consult it. The short version:
Skills /review, /security, and /qa support intensity modes:
| Mode | Flag | When | Confidence |
|------|------|------|-----------|
| Quick | --quick | Trivial changes (typos, config, docs) | 9/10 — only the obvious |
| Standard | (default) | Normal changes | 7/10 — anything reasonable |
| Thorough | --thorough | Critical changes (auth, payments, infra) | 3/10 — flag everything suspicious |
Skills auto-suggest a mode based on the diff, but the user always decides.
Skills automatically save their output to .nanostack/ after every run:
.nanostack/<phase>/<timestamp>.json
This enables:
/review compares planned vs actual files/review and /security cross-reference each other's findings/ship generates a journal entry from all phase artifactsAuto-saving is on by default. The user can disable it by setting auto_save: false in .nanostack/config.json.
Artifacts are validated before saving: save-artifact.sh rejects invalid JSON, missing required fields (phase, summary), and phase mismatches.
To discard artifacts from a bad session: bin/discard-sprint.sh (removes artifacts and journal entry for the current project and date).
When skills produce contradictory guidance (e.g., /review says "more error detail" but /security says "minimize error exposure"), the conflict resolution framework applies:
Read reference/conflict-precedents.md for known conflict patterns and pre-defined resolutions.
On first use in a project, run bin/init-config.sh --interactive to create .nanostack/config.json. This stores:
If config exists, read it at the start of any skill to adapt behavior:
bin/init-config.sh # outputs current config or {} if none
Skills use config for:
/review, /qa, /security: read preferences.default_intensity instead of always defaulting to standard/security: read preferences.conflict_precedence to determine who wins in cross-skill conflicts/security: read detected to skip irrelevant checks (don't scan for Python vulns in a Go project)Per-skill configs (security/config.json, guard/config.json) store skill-specific settings and are read by that skill only.
Suggest skills when context matches — don't wait for the user to remember:
| Trigger | Suggest |
|---------|---------|
| User says "what should I build" / unclear on direction | /think |
| Task touches 3+ files or user says "how should I approach this" | /nano |
| User says "done", "finished", "ready for review" | /review |
| User says "does this work", "test this", bug report | /qa |
| Pre-ship, user says "ready to deploy", or diff touches auth/env/infra | /security |
| User says "create PR", "merge", "ship it" | /ship |
| Destructive commands, production access, or sensitive operations detected | /guard |
/think for new products or when the "what" is unclear/nano before building anything that touches more than 3 files/review on your own code — the adversarial pass catches what you missed/security is not optional before shipping to production/guard is on-demand — activate it, don't leave it always on/qa can invoke /security checks, /ship can invoke /reviewNanostack is a process, not a collection of tools. The skills run in the order a sprint runs:
/think → /nano → build → /review → /qa → /security → /ship
Each skill feeds into the next. /nano writes an artifact that /review reads for scope drift detection. /review catches conflicts with /security findings. /ship verifies everything is clean before creating the PR. Nothing falls through the cracks because every step knows what came before it.
| Skill | Your specialist | What they do |
|-------|----------------|--------------|
| /think | CEO / Founder | Three intensity modes: Founder (full pushback), Startup (challenges scope, respects pain) and Builder (minimal pushback). Six forcing questions including manual delivery test and community validation. --autopilot runs the full sprint after approval. |
| /nano | Eng Manager | Auto-generates product specs (Medium scope) or product + technical specs (Large scope) before implementation steps. Product standards for web (shadcn/ui), CLI/TUI (Bubble Tea, Rich, Ink, Ratatui). Stack defaults with CLI preference for beginners. |
| /review | Staff Engineer | Two-pass code review: structural then adversarial. Auto-fixes mechanical issues, asks about judgment calls. Detects scope drift against the plan. Cross-references /security with 10 conflict precedents. |
| /qa | QA Lead | Functional testing + Visual QA. Takes screenshots and analyzes UI against product standards. Browser, API, CLI and debug modes. WTF heuristic stops before fixes cause regressions. |
| /security | Security Engineer | Auto-detects your stack, scans secrets, injection, auth, CI/CD, AI/LLM vulnerabilities. Graded report (A-F). Cross-references /review for conflict detection. Every finding includes the fix. |
| /ship | Release Engineer | Pre-flight + repo quality checks (broken links, stale refs, writing quality). PR creation, CI monitoring, post-deploy verification. Auto-generates sprint journal. Rollback plan included. |
| Skill | What it does |
|-------|-------------|
| /compound | Knowledge | Documents solved problems after each sprint. Three types: bug (what broke + fix), pattern (reusable approach), decision (architecture choice). /nano and /review search past solutions automatically in future sprints. |
| /guard | Safety | Three-tier safety: allowlist, in-project bypass, pattern matching with 28 block rules. Blocked commands get a safer alternative. /freeze locks edits to one directory. Rules in guard/rules.json. |
| /conductor | Orchestrator | Orchestrate parallel agent sessions through a sprint. Agents claim phases, resolve dependencies, hand off artifacts. No daemon, just atomic file ops. |
Not every change needs a full audit. /review, /qa and /security support three modes:
| Mode | Flag | When to use |
|------|------|-------------|
| Quick | --quick | Typos, config, docs. Only report the obvious. |
| Standard | (default) | Normal features and bug fixes. |
| Thorough | --thorough | Auth, payments, infra. Flag everything suspicious. |
/nano generates specs automatically based on project complexity:
| Scope | What you get | |-------|-------------| | Small (1-3 files) | Implementation steps only | | Medium (4-10 files) | Product spec + implementation steps | | Large (10+ files) | Product spec + technical spec + implementation steps |
The product spec covers: problem, solution, user stories, acceptance criteria, user flow, edge cases, out of scope. The technical spec adds: architecture, data model, API contracts, integrations, technical decisions, security considerations, migration/rollback.
Specs are presented for approval before implementation. If the spec is wrong, everything downstream is wrong.
You: I want to build a security scanner for cloud misconfigurations.
We keep finding S3 buckets left public and IAM roles that are
way too broad. Last month a public bucket caused an incident.
You: /think
Agent: I'm going to push back on "security scanner." A scanner finds
problems after they exist. But you said last month a public
bucket caused an incident. You don't want to find misconfigs,
you want to stop them from reaching production.
That's a prevention gate, not a scanner. Different product.
The scanner is 10% better than what you have (manual audits).
A pre-deploy gate is 10x. The misconfiguration never ships.
Who would use a broken v1 tomorrow? Your platform team. They
got paged for that incident. They'd use anything that blocks
public S3 buckets before deploy, even if it only checks one rule.
RECOMMENDATION: Reduce scope. One rule. S3 public access check,
pre-deploy. Ship tomorrow. The full scanner is a 3-month project.
You: That makes sense. Let's start with S3.
You: /nano
[5 steps, 4 files, risks listed, out-of-scope explicit]
You: [builds the feature]
You: /review
Review: 3 findings (2 auto-fixed, 1 ask). Scope drift: CLEAN.
You: /security
Security: CRITICAL (0) HIGH (0) MEDIUM (1) LOW (1). Score: A.
You: /ship
Ship: PR created. CI passed. Post-deploy: smoke test clean.
You said "security scanner." The agent said "you're building a prevention gate" because it listened to your pain, not your feature request. Six commands, start to shipped.
Discuss the idea, approve the brief, walk away. The agent runs the full sprint:
/think --autopilot
/think is interactive: the agent asks questions, you answer, you align on the brief. After you approve, everything else runs automatically:
/nano → build → /review → /security → /qa → /ship
Autopilot only stops if:
/review finds blocking issues that need your decision/security finds critical or high vulnerabilities/qa tests failBetween steps the agent shows status:
Autopilot: build complete. Running /review...
Autopilot: review clean (5 findings, 0 blocking). Running /security...
Autopilot: security grade A. Running /qa...
Autopilot: qa passed (12 tests, 0 failed). Running /ship...
Nanostack works well with one agent. It gets interesting with three running at once.
/conductor coordinates multiple sessions. Each agent claims a phase, executes it and the next agent picks up the artifact. Review, QA and security run in parallel because they all depend on build, not on each other.
/think → /nano → build ─┬─ /review (Agent A) ─┐
├─ /qa (Agent B) ├─ /ship
└─ /security (Agent C) ─┘