- Home
- Skills
- Mkalhitti Cloud
- Universal Or Strategy
- Project Lifecycle
project-lifecycle_skill
- C#
0
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill mkalhitti-cloud/universal-or-strategy --skill project-lifecycle- SKILL.md7.5 KB
Overview
This skill provides a standardized project lifecycle for NinjaTrader strategy development, covering versioning, branching, backups, and documentation sync. It enforces a repeatable workflow to start new features, manage transitions between development/staging/production, and keep changelogs and READMEs current. The goal is safer deployments, faster rollbacks, and consistent project hygiene.
How this skill works
The skill inspects repository state, enforces pre-flight checks, and prescribes concrete steps: create timestamped backups, update CHANGELOG.md, copy version files without breaking UI class names, and update strategy metadata. It specifies branch naming, git flow, and staged testing (development → staging → production) with monitoring and rollback actions. It also defines regular maintenance tasks and scaling preparation for multi-account deployment.
When to use it
- When starting a new feature, minor/major version, or patch
- Before creating a feature, hotfix, or version branch
- After significant code changes that affect behavior or parameters
- When preparing a version for staging or live deployment
- When syncing documentation, order management spreadsheets, or skills
Best practices
- Always run the pre-flight checklist: stable tests, commits, changelog and README updated
- Create timestamped backups of strategy files before editing
- Keep public class names stable for NinjaTrader UI compatibility when copying files
- Commit frequently with descriptive messages and use clear branch names
- Test progressively: local compile → sim account → funded sim → live
Example use cases
- Start V7.0 → V7.1 feature: backup, update changelog, copy file, update metadata, test on sim
- Create hotfix branch for a live trading bug, deploy fix to sim then to production after validation
- Add a new strategy parameter: update Order_Management.xlsx, README, and CHANGELOG
- Roll back a failing live release by disabling new strategy and re-enabling previous version
- Scale from 1 to 20 accounts with phased rollout and monitoring for race conditions
FAQ
Use feature/[name], hotfix/[name], or version/[version-number] for branches and tag releases with semantic tags like v7.1.0.
What files must be updated after code changes?
Update CHANGELOG.md, README.md if usage changed, Order_Management.xlsx for parameter changes, and skills or docs for new lessons.