@modeloslab/modelcode 0.1.0

package/skills/skill-create/SKILL.md

@@ -0,0 +1,37 @@
+---
+name: skill-create
+description: Distill a reusable skill from what was just done — turn a successful multi-step task into a repeatable, parameterized SKILL.md.
+---
+
+# Skill Create: Capture a Reusable Workflow
+
+## Goal
+Turn a successful task (or the user's spec) into a tight, parameterized SKILL.md that works for the
+GENERAL case, not the one instance that prompted it.
+
+## Steps
+
+### 1. Decide the skill
+Follow the user's direction for the name, purpose, and any specifics (in "User input"). If unspecified,
+generalize from the steps that just solved the task — what was the repeatable procedure?
+**Success criteria**: a one-line statement of what the skill does and when to use it.
+
+### 2. Name + scope
+`name`: lowercase, hyphen-separated, matching the directory. Write to `.modelcode/skills/<name>/SKILL.md`
+(project) or `~/.modelcode/skills/<name>/SKILL.md` (global, if the user says "global").
+
+### 3. Write it (match this repo's skill style)
+- **Frontmatter**: `name` + a `description` precise enough that the agent knows WHEN to invoke it
+  (include trigger phrases).
+- **Body**: `# Title` → `## Goal` → `## Steps` (numbered, each with a **Success criteria** where useful).
+  Make steps PARAMETERIZED — refer to "the target file / the user's input", never hard-code the specific
+  values from the example task. Add a short discipline/"don't" note where it prevents misuse.
+- Keep it tight and high-signal; delegate to subagents for review-type work where it fits.
+**Success criteria**: someone could run this skill on a different input and it still applies.
+
+### 4. Confirm
+State the new skill name so it's available as `/<name>` next session.
+
+## Don't
+Don't bake in one-off paths/values, don't pad with obvious filler, don't duplicate an existing skill —
+extend that one instead.

package/skills/test/SKILL.md

@@ -0,0 +1,34 @@
+---
+name: test
+description: Detect the project's test runner, run the suite (or a named subset), summarize failures, and offer to fix them.
+---
+
+# Test: Run and Triage
+
+## Goal
+Run the right tests for this project and give a clear, actionable failure summary.
+
+## Steps
+
+### 1. Detect the runner
+Infer from the project, in priority order: `package.json` scripts (`test`/`test:unit`…), then framework
+markers — `bun test`, `vitest`/`jest` config, `pytest`/`pyproject.toml`/`tox.ini`, `go test ./...`,
+`cargo test`, `rspec`, `mvn/gradle test`. Prefer the project's own script if one exists.
+**Success criteria**: you know the exact command this repo uses.
+
+### 2. Run
+Run the full suite via `bash`, or a focused subset if the user named a file/pattern (use the runner's
+filter flag, e.g. `-k`, `-t`, `--test-name-pattern`, a path). Don't swallow output.
+
+### 3. Summarize
+Report pass/fail/skip counts. For each failure: the test name + the single key line of the error/assert
+(not the whole dump). Group related failures (often one root cause).
+**Success criteria**: the user can see what broke and where without re-running.
+
+### 4. Offer to fix
+If there are failures, offer to delegate root-causing to the **debugger** subagent (one per distinct
+root cause). Don't auto-fix unless asked.
+
+## Notes
+If there's no test setup at all, say so and offer to scaffold one matching the stack rather than
+inventing a runner. Flaky/order-dependent failures: re-run the failing test in isolation to confirm.

package/skills/vercel-deploy/SKILL.md

@@ -0,0 +1,16 @@
+---
+name: vercel-deploy
+description: Deploy a Next.js (or any) app to Vercel — vercel CLI, preview vs production, env vars, build settings, domains, and common deploy failures. Use to ship, set up CI previews, or fix a broken deploy.
+---
+
+Deploy with the **Vercel CLI** (or Git integration for auto previews on every push):
+- `vercel` → preview deploy; `vercel --prod` → production. `vercel link` to connect the project.
+- **Env vars**: `vercel env add <NAME> <production|preview|development>`; pull locally with
+  `vercel env pull .env.local`. Remember `NEXT_PUBLIC_` vars are build-time — redeploy after changes.
+- Next.js needs no special config (zero-config). Override build/output only if non-standard.
+- Git integration: each PR gets a unique **preview URL**; merging to the production branch deploys prod.
+- `vercel.json` for rewrites/redirects/headers/cron functions when needed.
+
+Debug failed deploys: read the build log (the error is almost always a failing `next build` — missing
+env var, type error, or a server-only import in client code). Reproduce locally with `next build` first,
+fix, then redeploy. Verify the live URL + that env-dependent features work in production.