Skills reference

Table of contents

• feature (author a feature end-to-end)
• product (set up & run a product)
• doctor (diagnose & fix)
• conventions (always-on framework knowledge)
• Tips

Each skill is invocable explicitly (/splent:<name>) or automatically when your request matches its purpose. You can always just describe what you want.

feature (author a feature end-to-end)

/splent:feature <description>

Turns a plain-language request into a working, tested, wired-up feature. It does the following.

1. Infers the name, archetype (full / light / service / config), domain model and target SPL/product, asking only what it can’t infer.
2. Scaffolds with feature:create, then reads the generated stubs.
3. Writes idiomatic code, including models, repositories (BaseRepository), services (BaseService), routes (resolved via service_proxy), forms, namespaced templates, layout hooks, seeders.
4. Writes tests at the unit / integration / functional levels using the framework fixtures.
5. Adds the feature to the SPL (spl:add-feature, run with no product selected, which auto-detects => dependency constraints and edits the working copy splent_spl_<name>/ when there is one, otherwise the cached model), installs it into the product (feature:add), infers the contract (feature:contract) once the product is selected, runs migrations (db:migrate + db:upgrade), and verifies (feature:test, feature:xray --validate, product:validate).

Example. “add a notes feature with title and body owned by the user” produces splent_feature_notes (a full feature) with a Notes model (user_id FK to the auth user table), a CRUD service scoped to the current user, a login-protected /notes route, a sidebar hook, a seeder, and passing unit/integration/functional tests, added to the SPL with a notes => auth constraint and migrated into the product.

product (set up & run a product)

/splent:product <what you want>

Drives a product from nothing to running, or onboards an existing one. It reads the current state first (product:list, check:docker, product:containers) and picks the path.

• New product. spl:list → product:create <name> --spl <spl> (fetches the model once and pins its DOI) → product:select → product:configure → product:resolve → product:derive --dev → db:seed -y → URL.
• Onboard / fresh clone. Select → resolve → derive → seed.
• Run / restart. product:up --dev / product:restart.

It then verifies with product:validate, product:routes and product:containers, and routes failures to the right diagnostic.

doctor (diagnose & fix)

/splent:doctor [symptom]

Works like a doctor. Reproduce → run the right diagnostic → apply the smallest fix → re-verify. It starts with doctor (all check:*) and narrows to the failing area.

• Docker / infra → check:docker, check:infra
• feature:clone git failures → the .gitconfig-is-a-directory trap, then the forge itself: features live on git.splent.io (SSH on port 2223), and the credentials are SPLENT_FORGE_USER / SPLENT_FORGE_TOKEN (check:forge, tokens:setup)
• SPL model not found → spl:info, spl:fetch --force or spl:pin
• missing features → product:missing → product:auto-require
• UVL unsatisfiable → product:validate, spl:deps <feature> <spl>, spl:configurations <spl> (the spl:* commands run with no product selected)
• migrations → db:status, db:migrate, db:rollback, db:reset
• env / config → env:list, product:env --generate --merge
• SESSION_TYPE: null → add a session feature (splent_feature_session_filesystem / _redis)

conventions (always-on framework knowledge)

(automatic, no slash command)

Background knowledge Claude consults whenever you read, write or review SPLENT code. It carries the workspace model, the feature anatomy, the base classes, the service locator and template-hook systems, the test conventions, the feature contract, and the golden-path command sequences, so generated code is idiomatic SPLENT, not generic Flask.

Tips

• Prefer describing intent over typing commands. The right skill triggers automatically.
• The skills never hand-edit pyproject feature lists, the .uvl model, or Alembic version tables; they use the CLI. Follow the same rule in your edits.
• Destructive commands (product:clean, db:reset, cache:clear) are always confirmed before running.