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:

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 — 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.