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. Infers the contract (feature:contract) and tests at the unit / integration / functional levels using the framework fixtures.
5. Adds the feature to the SPL (spl:add-feature, which auto-detects => dependency constraints), installs it into the product (feature:add), 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. product:create → 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
• missing features → product:missing → product:auto-require
• UVL unsatisfiable → product:validate, spl:deps
• 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.