Borrowing it
Nothing to install: this file belongs to Hackbyrd/orbital-express. Take a copy, put it at the same path in your own repository, and replace the rules that are about this project with yours.
curl -O https://raw.githubusercontent.com/Hackbyrd/orbital-express/main/.claude/skills/modify-feature/SKILL.mdgit clone --depth 1 https://github.com/Hackbyrd/orbital-expressWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/hackbyrd/orbital-express/modify-feature)<a href="https://agentmods.dev/skills/hackbyrd/orbital-express/modify-feature"><img src="https://agentmods.dev/badge/skills/hackbyrd/orbital-express/modify-feature/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/hackbyrd/orbital-express/modify-feature"><img src="https://agentmods.dev/badge/skills/hackbyrd/orbital-express/modify-feature.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00070 | $0.00931 |
| Opus 5.5 | $0.00028 | $0.00372 |
| Sonnet 5.5 | $0.00014 | $0.00186 |
| Haiku 4.5 | $0.00007 | $0.00093 |
Grade A, and why
modify-feature scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 26 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Modify an existing feature (Path B — no new folder)
For adding columns and/or methods to a feature that already exists. This is the SAME process as create-feature — the same steps in the same order. It differs in exactly two places: (1) scaffold — you skip the one-time whole-folder yarn gen <Feature> (the folder exists), but you still scaffold every new action/task/mailer (yarn gen <Feature> -a/-t/-m) — modifying is NOT "no scaffolding"; (2) migration — use yarn migration to ALTER (add columns), not yarn model to create a table. Everything else is identical. Composes with create-feature — one product feature can create new table(s) AND modify existing one(s); plan all schema changes together, then run create-feature per new table and this skill per existing table touched. Full order: schema → scaffold (new pieces) → model → migration → routes → controller → actions/tasks → helpers/services → test → run. Full lifecycle: docs/workflow.md.
0. Plan first
- Decide the new columns (types, defaults, FKs, indexes), actions/tasks, and wiring. Add columns to
database/schema.sql, present the plan, and get sign-off before scaffolding or edits. This applies to every modification. - Confirm the existing folder has complete standard structure. Preview
yarn repair <Feature> --dry-run, review it, then runyarn repair <Feature>before feature edits. Repair never overwrites existing files.
Steps (do only the parts your change needs) — order: schema → model+migration → routes/controller → actions/tasks → run
- Model + migration first (if adding columns):
- Model: add the new field definitions to
app/<Feature>/model.js(andindexes/associateif the change adds FKs/indexes). Mirror exactly what you put inschema.sql. - Migration — ALTER, not create: make an add-columns migration (see
add-migration):yarn migration→ rename to<ts>-add-cols-<colA>-and-<colB>-to-<TablePlural>-tbl.js.addColumn/addIndex/addConstraint, transaction-wrapped, named indexes matching the model. Never drop or rename in place (rollback safety) — add new, backfill (you can run SQL right in the migration), remove the old one much later.
- Model: add the new field definitions to
- Routes + controller — for any new endpoints (feature
routes.js+ controller method). - New actions and/or tasks →
yarn gen <Feature> -a V1<Action>/-t V1<Action>Task. Never hand-create when scaffolding exists. Then write the body (seeadd-action/add-query-action/add-task), register task processors inworker.js, add supporting constants/errors/i18n/mailers/helpers/services, and complete every generated test. Root routes, models, workers, and errors auto-discover features. - Run checks/tests:
yarn conventions:check, focused tests, thenyarn test. Finish with the mandatoryreview-conventionsself-audit.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2mo ago First seen · 26 lines · 70 tokens per session scan A 81f8847fe3f5
modify-feature is a skill published in the GitHub repository Hackbyrd/orbital-express (15 stars, last pushed 2mo ago), licensed MIT. It adds 70 tokens to every session and 931 once invoked, about $0.0003 per session on Opus 5.5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
event-store-design
Design and implement event stores for event-sourced systems. Use when building event sourcing infrastructure, choosing event store technologies, or implementing event persistence patterns.
platform-custom-field-generate
Use when users create, generate, or validate Salesforce Custom Field metadata. Trigger on custom fields, field types, Roll-Up Summary, Master-Detail/Lookup relationships, formula fields, picklists, dependent (controlling) picklists, referencing a value set from a field, or scoping picklist values per record type; also…
field-service-sobject-create-configure
Headless 360 REST API deployment step for creating sObject records. Handles describe-based field discovery, required-field derivation, entity-relationship ordering, and composite graph transactions. Use this skill when a designer skill (or a user directly) needs to create sObject records after design confirmation…
durable-objects
Build, debug, or review Cloudflare Durable Objects code for persistent state and coordination.
nornicdb-grpc
Drive NornicDB over gRPC — the Qdrant-compatible surface (Collections, Points, Snapshots) plus the additive NornicSearch service. Use when ingesting via Qdrant SDKs, migrating from Qdrant, or running hybrid text+vector search from a non-Bolt client. Covers connection, RPC catalog, collection→database mapping…
output-dev-credentials
Store and reference encrypted secrets in Output SDK workflows using @outputai/core/credentials. Use when integrating API keys, database passwords, or third-party tokens.