Agentic AI in Software Development: Project-Specific Skills and Context

Agentic AI in software development gives an AI system a bounded engineering task, relevant project information and approved tools to carry it out. Useful adoption depends on making that task clear enough to execute and its result clear enough to review.

For industrial OEM teams, the information is rarely contained in the latest request. An application may depend on a device interface. Firmware may need to preserve a deliberate workaround. A test may be valid only for a particular build or target revision.

Project-specific context and skills help carry these details into everyday development work.

AMD's September introduction of Ross illustrates this direction: its assistant combines tool connections, a knowledge base, expert-authored skills and examples. AMD's offering also spans hardware design; the transferable lesson for software and firmware teams is how engineering knowledge and repeatable procedures support the work. AMD, 30 September 2026

Give each part a clear job

Four elements need different responsibilities.

Context supplies the project facts. These include approved requirements, current interfaces, supported versions, architecture decisions and known limitations.

A skill describes a repeatable procedure. It explains when it applies, what inputs it needs, which checks to perform and what evidence to return.

Tools provide access or execution. A repository search, issue-tracker connection or test runner gives the agent a specific capability. Model Context Protocol, or MCP, is one way to connect compatible tools and information sources.

Enforced controls constrain actions. Access permissions, protected branches, sandboxing and required CI checks operate outside the wording of a skill.

These distinctions matter. GitHub's late-July code-review release supports repository skills and external MCP context, while explicitly limiting that review product's MCP calls to read-only. The permission boundary belongs to the implementation, rather than being an automatic property of every skill or MCP connection. GitHub, July 2026

Start with one recurring task

Choose work engineers already understand well enough to judge.

A useful starting point might be preparing a device-interface change, investigating a recurring build failure or drafting regression tests for an established software module.

Describe the task in operational terms:

• What starts the work?
• Which information must be available?
• What may the agent inspect or change?
• What should the engineer receive?
• Which conditions require the agent to stop and ask?

Avoid combining every development activity into one large skill. A narrow procedure is easier to test, maintain and assign to an owner.

Prepare the context the task actually needs

Begin with the approved requirement and relevant parts of the codebase. Add the decisions needed to interpret them.

For application software, this may include business rules, permissions, interface contracts and failure behavior. For firmware, it may also include target revision, toolchain, timing and resource constraints, supported peripherals and known device limitations.

Record where each fact came from. A document title alone is insufficient when several revisions exist. Include the applicable version or date and a reference the reviewer can follow.

Make uncertainty visible. A missing timing limit should remain an open question until an authorized engineer supplies or approves it. The agent should not fill the gap with a plausible value.

Select context for the task rather than treating every available document as equally relevant. Conflicting or stale material can make a large context package harder to use.

Write a skill your team can inspect

A maintainable engineering skill should include:

1. Purpose and trigger: the task it supports and when to use it
2. Required inputs: documents, repository state and project assumptions
3. Procedure: an ordered set of checks and permitted work
4. Boundaries: excluded changes and specialist-review conditions
5. Expected output: findings, evidence links, proposed changes and unresolved questions
6. Ownership: maintainer, version and review history

Store the skill with controlled project material and review changes to it. A procedure that influences code deserves deliberate maintenance.

A July research note on agent skills argues for treating them as software artifacts, including evaluation of selection and behavior. It is a useful design perspective, not evidence that any skill format guarantees reliable execution. Destefanis, 27 July 2026

Walk through a bounded example

Consider a software application that reads measurements from an industrial device. Engineers repeatedly investigate reports of missing readings after a connection interruption.

A project-specific investigation skill could require the agent to:

• Identify the application and supported firmware versions
• Read the approved reconnect behavior and relevant interface code
• Gather available logs and separate observations from hypotheses
• Propose a narrowly scoped change or additional test
• Report which checks ran and what still needs verification

If the logs refer to an unsupported device revision, the agent should flag the mismatch. If the required environment is unavailable, it should report the blocked check.

This example is illustrative. Its value is a consistent, reviewable investigation path. The engineer still judges the diagnosis and accepts any resulting change.

Evaluate the skill before wider use

Test the workflow against representative cases, including situations where it should decline to proceed.

Include a normal task, missing requirement, stale document, conflicting source, unavailable test environment and request outside the allowed scope. Check whether the skill was selected appropriately and whether it returned the required evidence.

Review the outputs for unsupported claims, especially claims that a test passed when no matching run exists.

Measure the human effort too: preparation, review, correction and follow-up. A procedure that produces a polished report but adds substantial checking work may need redesign.

For deeper review and verification questions, use NeoBram's industrial AI validation approach.

Maintain context as the project changes

Assign someone to update relevant context when requirements, interfaces, device revisions or toolchains change. Re-evaluate affected skills after changes to their procedure, model or tool access.

A discovered defect may justify a new regression case or clearer instruction. It should not automatically become a universal rule for every project.

Distributed teams need access to the same approved material. Agree where source code, prompts and test logs may be stored, customer permissions, target-lab access and who reviews each handoff. Information boundaries and governance belong in that conversation.

Questions teams ask

Can we keep our existing IDE?

The selected IDE, model access, build environment and required connections should be checked during scoping. A portable instruction format does not guarantee identical behavior in every tool.

Does agentic development require multiple agents?

Agent count is an architecture decision. First define the work, evidence and permission boundaries; then choose an arrangement that supports them.

Who approves the result?

The designated engineering or acceptance owner. Skills help prepare and check work, while the project's existing approval controls remain in force.

Build around one real project

NeoBram's AI SDLC offering connects business definition and planning in its accelerator, using the customer's LLM, with project-specific skills in the agreed developer IDE. A connected project dashboard makes delivery evidence visible.

Bring one recurring software or firmware task, examples of accepted work and the context engineers repeatedly explain. That is enough to begin defining a useful skill, its boundaries and a practical evaluation.