docs(agents): add AI-assisted development guidance

.github/copilot-instructions.md

@@ -0,0 +1,3 @@
+# Copilot Instructions
+
+Read and follow the repository guidance in [../AGENTS.md](../AGENTS.md).

.github/instructions/ci-cd.instructions.md

@@ -0,0 +1,39 @@
+---
+applyTo: '.github/workflows/**,release.config.js,package.json,rollup.config.js,typedoc.json'
+name: ts-sdp CI/CD
+description: Use when reviewing checks, builds, documentation generation, package entry points, or semantic-release behavior.
+---
+
+# CI/CD Instructions
+
+## Pull-request checks
+
+- Read `.github/workflows/pull-request-checks.yml` before changing or describing CI.
+- Pull requests install with Yarn, then run `yarn test:lint` and `yarn test:coverage`.
+- Prettier, spelling, build, TypeScript validation, docs generation, and the aggregate `yarn test` command are not current pull-request gates.
+- Do not claim a check is CI-enforced unless the workflow invokes it.
+
+## Build and package outputs
+
+- Rollup builds ESM and CommonJS JavaScript plus bundled TypeScript declarations from `src/index.ts`.
+- Keep `package.json` `main`, `module`, `types`, and `exports` aligned with Rollup outputs.
+- The npm package includes only `dist/**/*`.
+- The package has no runtime `dependencies`; review any proposed runtime package as a compatibility and supply-chain change.
+- Generated API files belong under `docs/api/`.
+- Cleanup must not delete maintained files under `docs/contributing/` or `docs/knowledge-base/`.
+
+## Release
+
+- Pushes to `main` install with Yarn, run `yarn build`, and invoke semantic-release.
+- Conventional Commits on `main` determine whether semantic-release publishes and which version increment applies.
+- The release configuration publishes to the public npm registry and commits configured release assets.
+- The current release workflow builds but does not run tests or generate TypeDoc output. Document that gap accurately.
+- Treat changes to parser behavior, serialization, `src/index.ts`, exported signatures, entry points, declarations, or runtime dependencies as compatibility-sensitive.
+
+## Failure triage and safety
+
+- Fix deterministic lint, test, type, documentation, or build failures. Do not rerun them hoping for a different result.
+- Retry only failures supported by evidence of transient runner, registry, or network problems.
+- Treat a release failure on `main` as a coordinated delivery issue.
+- Never expose workflow tokens, npm credentials, or secret values.
+- Do not run semantic-release or npm publishing locally unless the user explicitly requests a coordinated release.

.github/instructions/code-review.instructions.md

@@ -0,0 +1,31 @@
+---
+applyTo: 'src/**/*.ts,README.md,AGENTS.md,docs/knowledge-base/**/*.md'
+name: ts-sdp Code Review
+description: Use when reviewing SDP parsing, models, munging, public exports, tests, or architecture guidance.
+---
+
+# Code Review Instructions
+
+## Priorities
+
+1. Supported and unsupported SDP lines continue to parse and serialize without accidental data loss.
+2. Parser registration order and custom `Grammar` extensions remain deterministic.
+3. Lines route to the correct session, media, ICE, codec, or fallback collection.
+4. Munging helpers keep payload references, secondary codecs, wildcard feedback, and media scope consistent.
+5. Changes to `src/index.ts`, exported signatures, accepted syntax, output ordering, errors, package entry points, or declarations include compatibility and semantic-version analysis.
+6. Protocol edge cases have focused line tests, model tests, or corpus-based round-trip coverage.
+
+## Checks
+
+- Each `Line` parser returns `undefined` for non-matches and emits a complete line from `toSdpLine()`.
+- New line parsers are registered under the correct line type and in an intentional order.
+- Unknown lines and custom line types remain available through `otherLines` and survive serialization.
+- Session-level and media-level fields serialize in the order defined by their model's `toLines()`.
+- Audio/video and application media behavior remains separated where their models differ.
+- Codec lines validate numeric or wildcard payload references through `CodecStore`.
+- Codec removal handles associated secondary payload types, and feedback changes cover per-codec and wildcard storage.
+- Public export changes are intentional and documented.
+- JSDoc remains complete where ESLint requires it. Comments explain protocol constraints or surprising behavior rather than restating code.
+- Documentation claims are verified against source, tests, package metadata, build configuration, and release configuration.
+- Test SDP contains no real ICE credentials, network identifiers, fingerprints, or other sensitive session data.
+- No secrets, credentials, private URLs, certificates, `.env` values, or local absolute paths appear in the diff.

.github/instructions/testing.instructions.md

@@ -0,0 +1,35 @@
+---
+applyTo: 'src/**/*.spec.ts,src/sdp-corpus/**'
+name: ts-sdp Tests
+description: Use when writing or reviewing co-located Jest tests and SDP corpus fixtures.
+---
+
+# Testing Instructions
+
+## Framework and location
+
+- Jest runs through `ts-jest` in the environment configured by `jest.config.js`. Check `package.json` and `jest.config.js` instead of pinning tool versions in guidance.
+- Keep tests next to source as `src/**/*.spec.ts`.
+- Keep reusable SDP fixtures under `src/sdp-corpus/`.
+- Use `yarn test:unit` for focused runtime feedback and `yarn test:coverage` for the pull-request test command.
+- Run `yarn transpile:validate` when changing exports, parser types, line classes, model contracts, or munging signatures.
+
+## Test patterns
+
+- Name the top-level `describe` after the line, model, parser flow, or munging behavior under test.
+- Use behavior-focused `it('should ...')` descriptions.
+- Test both successful parsing and a representative non-match for line parsers.
+- Assert `toSdpLine()` output for new or changed line models.
+- Use corpus round trips when ordering and preservation across a complete SDP matter.
+- Keep tests independent. Avoid mutating `DefaultSdpGrammar` unless the test is specifically verifying global parser registration.
+- Use synthetic, non-sensitive SDP values. Never copy real ICE credentials, fingerprints, addresses, or user session captures.
+
+## Required coverage by change type
+
+- Grammar changes: parser order, custom parser behavior, fallback handling, and non-match behavior.
+- Line changes: accepted forms, rejected forms, field extraction, and serialization.
+- Session or media model changes: `addLine()` routing and `toLines()` ordering.
+- Codec changes: numeric and wildcard payload references, codec aggregation, secondary codec relationships, and serialization.
+- Munging changes: both `Sdp` and media-description entry points where supported, matching and non-matching cases, and return flags.
+- Public type changes: TypeScript validation plus runtime tests where behavior also changes.
+- Regression fixes: the smallest fixture or inline SDP that fails before the fix and passes after it.

.github/skills/pr-description/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: pr-description
+description: Draft accurate ts-sdp pull-request descriptions from the repository template, committed changes, and observed test evidence.
+---
+
+# PR Description
+
+Create a concise, reader-friendly pull-request description that helps reviewers understand why the change matters, what behavior changes, and how it was verified.
+
+## Sources
+
+Read these before drafting:
+
+1. `.github/pull_request_template.md`
+2. The complete committed diff against the pull-request base branch
+3. All branch commits
+4. Test output supplied by the author or produced in the current session
+5. Public issues or documentation linked by the author
+
+Repository files and observed results are authoritative. Do not invent motivation, test evidence, issue links, screenshots, SDP compatibility, or release claims.
+
+## Workflow
+
+1. Confirm the base branch. Use `main` when no other base is specified.
+2. Review the complete branch diff, not only the latest commit.
+3. Check `git status`. If uncommitted changes exist, warn the author and exclude them from the pull-request description until committed.
+4. Identify effects on grammar registration, line parsing, serialization order, session and media models, codec or ICE handling, munging helpers, public exports, declarations, package formats, runtime dependencies, and release behavior.
+5. Ask what manual testing was performed. Request the SDP scenario and result when relevant. If no manual testing was needed, ask the author to confirm why.
+6. Ask only for facts that cannot be derived, such as a public issue link, screenshots, or the Generative AI disclosure category.
+7. Produce the completed repository template without removing headings or policy checkboxes. Do not reproduce private-only links in newly drafted text.
+
+## Description rules
+
+- Under `Description`, start with two to four short bullets that explain the developer or user outcome.
+- Lead with why the change is useful, then explain what changed to achieve it.
+- Use plain language, active voice, and short sentences. Explain an unavoidable technical term the first time it appears.
+- Prefer outcomes such as “documentation commands cannot remove contributor guides” over implementation phrases such as “isolate generated output.”
+- Describe behavior and developer outcomes instead of listing changed files or repeating the diff.
+- Include implementation details only when they help a reviewer evaluate correctness or compatibility.
+- State important non-effects directly, such as “This does not change runtime behavior or the public API.”
+- Add a short `Testing` subsection under `Description` with only commands and manual checks that actually ran.
+- Summarize warnings or partial results in plain language and identify whether they existed before the change.
+- When manual testing was not needed, explain why in one sentence.
+- Call out accepted SDP forms, round-trip behavior, public API impact, declaration changes, package compatibility, dependency changes, migration steps, or semantic-version impact only when supported by the diff.
+- Preserve the `This change implements...`, breaking-change, certification, and Generative AI sections.
+- Keep checkboxes unchecked when evidence or author input is missing.
+- Never mark the test certification checkbox without evidence.
+- Never select a Generative AI disclosure category for the author.
+- Do not add a dedicated risk section.
+- Use only public links in this public repository.
+
+## Wording example
+
+Avoid:
+
+> Preserve maintained documentation by isolating generated TypeDoc output and extend formatting and spelling checks to the new documentation.
+
+Prefer:
+
+> Keep generated API documentation separate from contributor guides so documentation commands cannot remove maintained content. Include the new guides in formatting and spell checks.
+
+## Output
+
+Return one Markdown block that can be pasted into GitHub.
+
+After the block, list unresolved author questions separately. Do not put `TBD` placeholders in an otherwise final description.

.prettierignore

@@ -1,2 +1,6 @@
 # package.json is formatted by package managers, so we ignore it here
-package.json
+package.json
+
+# Generated API documentation and the repository policy template are maintained separately
+docs/api/
+.github/pull_request_template.md