Build smarter. Build safely.

Using the Software Development Skill

IT publishes a TD Software Development Skill (a set of instructions that can be loaded into Claude Code or GitHub Copilot). It encodes the project structure, code patterns, and guardrails that have already been approved for TDIndustries.

What the Skill does for you

• Creates a proper application with the approved frontend and backend layout
• Steers the AI away from anti-patterns the AI App Review group rejects
• Encodes our visual style guide (TD Blue, Roboto, MUI components)
• Sets up local-first development so you can run the app without cloud access

How to invoke it

1. Open Claude Code in your project directory.
2. Run /build-fullstack-app to create a new application, or load td-industries-style-guide when reviewing UI work.
3. Let the Skill drive the structure — resist the urge to override it. The Skill is what makes review fast.

Tip: if a Skill instruction conflicts with what the AI wants to do, the Skill wins. That alignment is the whole point.

Read the full Developer Guide →

Testing what you built

Before anything goes to review, you have to prove the app actually works — not just that it runs. AI will happily generate code that looks right and behaves wrong. Testing is how you catch that gap before reviewers (or users) do.

The three layers

• Manual testing — click through every screen and flow yourself. Try the happy path, then try to break it: empty inputs, wrong inputs, the back button, a slow connection.
• Unit tests — ask the AI to write tests for the business logic it just wrote (calculations, validation, data transforms). These are cheap and catch regressions when you make changes later.
• Automated end-to-end tests — for the one or two flows that absolutely cannot break, have the AI implement an automated test that exercises the whole stack.

Get a second set of eyes

Before you submit for review, have another person run the app locally and try it out. You have been staring at this thing for hours — you will skip past the broken parts without seeing them. Someone who has never touched it will click the wrong button, type the wrong thing, and ask the questions a real user would ask. That is exactly what you want to catch before deployment, not after.

What “done” looks like

• You have personally walked through every user-facing flow at least once
• Unit tests exist for the logic that would be expensive to get wrong
• The app runs locally end-to-end without errors in the console
• At least one other person has run the app locally and tried the main flows

Tip: if you can’t describe how you tested it, you haven’t tested it. Write a short test summary in your PR description — reviewers use it to scope their review.

Getting approval from Product Team

Before you deploy, Product Team must confirm your application fits the company’s product direction and is not duplicating something that already exists.

The two paths

What to bring to the conversation

• A short summary of the problem the app solves
• Confirmation that no existing approved app already does this (check with the Product Team or your manager if unsure)
• Manager approval confirming business need and priority

Intellectual property

Any application, tool, or solution you build as part of your work here — including all underlying code, data, and documentation — is the intellectual property of TD Industries. This applies regardless of whether it was built during work hours, using company resources, or in support of a business need.

Getting code reviewed

The AI App Review group reviews both the initial submission and every submission of updated code after deployment. They focus on safety — not aesthetics.

What they check

• Security — common vulnerabilities and unsafe practices
• Secret exposure — no API keys, passwords, tokens, or credentials embedded in source code
• Data storage — data is written only to approved, auditable locations (never browser local storage)
• Authentication & SSO — the app integrates with TDIndustries’ identity provider and access is properly scoped

What they do not check

Code style and visual conventions. That is on you and the Skill.

The PR rule

Once your app is live, every change must go through a Pull Request. A Pull Request (PR) is a formal way to propose code changes — it creates a record of what changed, why, and who approved it before the update goes live. Direct pushes to main are not permitted. Make small, frequent PRs — they review faster and catch issues earlier.

Deploying the application

Your first deployment is self-service through Runway, TD’s deployment portal. When your app runs locally and is ready to share, you upload it — no IT ticket to create the repo, and no terminal required.

How the first deploy works

• Go to runway.tdindustries.com and choose Ship a new app
• Drag your whole my-app/ folder in, add a name and description, and check the database box if you need one
• Submit for approval — an admin approves, and Runway creates the GitHub repo under TDICitizenDev, wires up hosting and sign-in, and deploys it

After it’s live

Every later change ships through a Pull Request into that repo — AI App Review and Change Management approve it, then merging to main redeploys automatically.

The Change Management gate

Before any deployment to the cloud environment — the first Runway approval or any ongoing change — the IT Change Management committee must approve the release.

Required: your app must run locally without a hosted environment. That is how you validate changes before they ever ship.

Maintaining the application

After deployment, you keep ownership, assuming that Product does not require the application to be transfered to the Application Development group. The program is built around the idea that the person closest to the problem is the best person to keep evolving the solution.

Your responsibilities

• Bug fixes and enhancements (with AI assistance)
• Submitting all changes via Pull Request
• Notifying IT of any data integration issues
• Notifying IT and your users before retiring the app

IT responsibilities

• PR review for security and best practices
• Infrastructure and hosting
• Security incident response — do not try to patch one yourself
• Decommissioning and archiving when the app is retired

If you outgrow the AI: when an app has clear business value and you have hit the limits of what AI assistance can do, Application Development may take it into the formal development backlog. Submit through the Product Team intake process with manager approval.