I kept explaining the same things to my coding agents. Use the existing components. Follow the design tokens. Keep business logic out of the UI. Check permissions on the server. Test the failure cases.

Then I would move to another project or another assistant and explain them again.

My first solution was copying and pasting. I saved instructions that worked and carried them into the next repository. That helped, until every improvement became another update to make across several copies. Some guidance belonged to a specific project. Some should have been reusable. Different assistants expected different configuration files. Maintaining all of it manually wasn't scaling.

That's why I built aayushus-skills: a CLI that scaffolds agent configurations, product templates, design assets, and engineering guidelines into a repository. I wanted a repeatable way to give agents a useful starting point before asking them to build anything.

A task carries more decisions than its description

Consider a hypothetical request: “Add a supplier approval screen.”

An agent can start writing that screen immediately. But what should it already know?

For the UI, it needs to know what happens while data loads, when there are no requests, when approval fails, and when the user opens the page on a phone. Those states affect whether someone can actually complete the task.

For design, it needs the existing typography, spacing, colors, and components. Otherwise, a new page can introduce another button implementation, a slightly different heading style, and its own interpretation of the layout. Each choice may look reasonable on its own. Together, they make the application inconsistent.

Architecture adds decisions that a screenshot won't reveal. Where does approval logic belong? Which service owns the request? Should notifications run through a queue? Is there already an API or workflow the implementation should extend?

Then there is security. Which tenant owns the request? Who can approve it? Does the server enforce that permission? What happens if someone changes the request ID and calls the endpoint directly?

And before any of that, there is a product question: what does “approved” mean? Does it change a status, trigger another process, or commit the business to something? What should happen if two people act at once?

These are decisions I want made explicitly. If the repository doesn't provide an answer, the agent either asks, makes an assumption, or builds something I have to correct later.

What I wanted to stop copying

A prompt for that task could grow into several paragraphs of reminders: reuse the shared components, put authorization in the API, follow the existing error contract, cover tenant isolation, and handle the mobile states.

The task-specific details belong in the request. The recurring rules need a maintained home.

That distinction shaped the package. Product-management templates live under docs/pm/. Engineering guidance lives under docs/guidelines/, divided into architecture, security, API contracts, testing, quality and performance, and operations. Prism supplies design tokens, component assets, and pattern specifications under src/design/ or design/.

Agent configuration files provide entry points for tools including Claude Code, Cursor, Codex, and Copilot. The interactive wizard asks about the project stack and generates tailored configurations. The source and README describe the available packs and destinations.

For the supplier screen, I would still specify its behavior and acceptance criteria. But I want the agent to find the project's reusable guidance instead of relying on me to remember every relevant instruction in that session.

Try it on one problem first

For an existing repository, I would start with a small selection. This example previews Codex configuration, product-management templates, and security guidance using the version this article describes:

npx --yes [email protected] codex pm security --dry-run

The relevant destinations are:

AGENTS.md
docs/pm/SKILL.md
docs/guidelines/security/

Remove --dry-run to write the selected files, then review the diff. Existing files are skipped by default; --force permits overwriting them. If the repository already has an AGENTS.md, merge the useful guidance deliberately rather than replacing its project knowledge.

For a new project, the interactive wizard is another starting point:

npx --yes [email protected]

Installing a pack is the beginning of the work. Adapt the defaults to the application. In a project with an established design system, keep that system as the reference. Prism can provide a starting point for a new application or material for specific gaps; introducing a competing component library would make reuse harder.

The optional Graphify integration helps explore codebase relationships and involves a separate CLI installation. I would add it when that navigation is useful, rather than make it a prerequisite for every task.

The files have to earn their place

I don't expect an instruction file to enforce architecture or prove security. A rule about tenant isolation needs tests that attempt access across tenants. An API contract needs validation. Acceptance criteria need checks that can fail when the behavior is wrong.

Different assistants may also interpret the same guidance differently. Having a shared starting point makes the decisions available; it doesn't guarantee the agent will follow every one of them. Review and executable checks still matter.

There is a maintenance cost here, too. Guidance that nobody updates becomes stale context. I would keep the parts that answer recurring questions, remove the parts that don't fit, and update the instructions when the project changes.

On the next feature, look at what the agent did with that context. Did it reuse the existing component? Did it put the logic in the right place? Did the tests catch the missing permission check? If you are still pasting the same reminders into every session, that is the next piece of project knowledge to make reusable.