Feature To Assets

Feature to assets

A shipped feature that only exists in code is not adopted. This expands one feature into the artifacts each consumer surface needs, derived from the implementation rather than from a description of it.

Unlike the other skills in this plugin, this one writes files. Everything is a draft, written to a staging directory, and nothing existing is overwritten.

Applies to

Most useful on features that introduce a new capability rather than adjust an existing one. A bug fix needs a changelog line, not twelve artifacts, and the skill will say so.

How to use

/agentrel:feature-to-assets                      use the current branch's diff
/agentrel:feature-to-assets "invoice scheduling" name the feature explicitly
/agentrel:feature-to-assets #482                 use a pull request

Writes drafts to ./feature-assets/<feature-slug>/, one file per asset, and prints what it wrote and what it deliberately skipped.

This is the one skill that writes files. It never writes into docs/ or any existing tree, and never overwrites — a human moves the drafts after review.

1. Understand what actually shipped

Do not work from the user's summary alone. Read the code.

Establish before writing anything:

• What can a user now do that they could not before?
• What is the smallest complete example that demonstrates it?
• What are the limits — rate, size, permission, plan?
• What breaks or changes for existing users?
• What does it deliberately not do?

That last question prevents the most common documentation failure: copy that implies capability the code does not have.

2. Decide which assets the feature needs

Not every feature earns twelve artifacts. A bug fix needs a changelog line. A new resource type needs most of the set. Decide first, then write — and report the ones you skipped.

State the skipped ones and why. "No concept explainer — introduces no new noun" is a useful line in the report, because it shows the decision was made rather than forgotten.

3. Write each asset

Draft into ./feature-assets/<feature-slug>/, one file per asset. Never write into docs/ or any existing tree — a human moves them after review.

Standards, applied to all of them:

• Derived from code, not from the ticket. Every parameter, default, and limit is read from the implementation. If it is not in the code, it does not go in the docs.
• Complete examples. Runnable start to finish. No ..., no unexplained placeholder.
• Real values. cus_8f21c4, not <CUSTOMER_ID>. Where a placeholder is unavoidable, say on the same line where the value comes from.
• State the limits. Rate limits, size caps, and required permissions belong in the reference entry, not discovered in production.
• No marketing verbs. Not "powerful", "seamless", or "revolutionary". Say what it does.

Per-asset shape

Reference entry — signature, every parameter with type and default, return shape, every error with cause, limits, one minimal example.

How-to guide — starts from the user's job, not the API. Title reads "Send an invoice to a customer", not "Using the invoices endpoint".

Runnable example — a complete file that executes. Include the install line and any env vars. End with output the reader can compare against.

MCP tool definition — a full tool schema: verb-noun name, description stating what it does and its boundary, constrained input schema with patterns and enums, declared output, honest destructive and idempotent annotations. If it is destructive, say so in the description as well as the annotation.

Changelog entry — one line, user-facing verb, links to the reference. Written for someone scanning fifty entries.

Announcement — three sentences: what you can now do, why it matters, how to start. No preamble about the team's excitement.

Troubleshooting entry — the symptom as the user experiences it, the cause, the fix. Title with the error the user will paste into search.

4. Report

Write ./feature-assets/<feature-slug>/README.md as the index, then print:

FEATURE → ASSETS · invoice-scheduling

  Written
    reference/invoices-schedule.md
    how-to/schedule-a-recurring-invoice.md
    examples/schedule-invoice.ts
    mcp/schedule_invoice.json
    changelog.md
    troubleshooting/invoice-not-sent.md
    announcement.md

  Skipped
    concept explainer     introduces no new noun
    migration note        no existing behaviour changed
    quickstart update     not on the recommended first path

  Review   ./feature-assets/invoice-scheduling/
  Note     3 limits found in code and now documented: 100/hr,
           max 90 days ahead, requires invoices:write

Surface anything the code revealed that was not in the original description — undocumented limits, silent failure modes, defaults that will surprise users. That is often the most valuable output of the run, and it belongs in the printed summary rather than buried in a file.

Notes

• Never overwrite. Everything lands in ./feature-assets/. If the directory exists, add a numbered suffix.
• Flag uncertainty inline. Where behaviour could not be determined from the code, write <!-- UNVERIFIED: ... --> in the draft rather than guessing. A human resolves it.
• If the feature turns out to be internal-only with no user-facing surface, say so and write only the changelog entry.