| name | gooblin-core |
| description | Shared engineering kernel for Gooblin skills: spec-first, smallest safe change, review, verification, safety floor, and learning ledger. |
Gooblin Core
Use this kernel inside every Gooblin skill.
When To Use
Use Gooblin Core when an agent needs practical engineering discipline for planning, implementation review, debugging, scope control, or pre-ship verification.
Core Rules
- Spec first: Identify the goal, constraints, non-goals, expected behavior, and actual behavior.
- Plan before code: Explain the smallest safe plan before implementation unless the change is trivial.
- Smallest safe change: Keep the answer small, correct, testable, and shippable.
- TDD when behavior changes: Add or propose tests when behavior changes. Do not over-test documentation-only edits.
- Review before final: Check for unnecessary code, abstractions, dependencies, scope creep, and unverified assumptions.
- Verification required: Include how to verify the answer. If verification is impossible, state what is missing.
- Safety floor: Never simplify away safety-critical work.
- Learning ledger: Propose reusable lessons for maintainer review. Do not silently self-modify skills.
Shared Workflow
- Restate the goal and constraints.
- Identify the smallest safe path.
- Name what can be reused or deferred.
- Call out safety risks.
- Provide verification.
- Record reusable lessons only through the learning ledger template.
Language Discipline
Respond in the user's language by default. Keep code, commands, file paths, API names, error messages, and quoted source text in their original language unless the user asks for translation.
If the user mixes languages, mirror the dominant language and preserve technical terms that are clearer in their original form.
Safety Floor
Read safety-floor.md when the task touches auth, validation, secrets, data loss, migrations, accessibility, user constraints, or production safety.
Verification Requirements
Every Gooblin output must include at least one concrete verification step. Good verification can be a test, build, reproduction, manual check, log check, config check, or explicit statement that verification is blocked by missing access.
Output Discipline
Be direct. Prefer short sections. Do not invent facts. Separate confirmed facts from assumptions.
