jumpstart-mode 1.1.13 → 1.1.14

package/.github/skills/agent-customization/references/hooks.md

@@ -0,0 +1,96 @@
+# [Hooks (.json)](https://code.visualstudio.com/docs/copilot/customization/hooks)
+
+Deterministic lifecycle automation for agent sessions. Use hooks to enforce policy, automate validation, and inject runtime context.
+
+## Locations
+
+| Path | Scope |
+|------|-------|
+| `.github/hooks/*.json` | Workspace (team-shared) |
+| `.claude/settings.local.json` | Workspace local (not committed) |
+| `.claude/settings.json` | Workspace |
+| `~/.claude/settings.json` | User profile |
+
+Hooks from all configured locations are collected and executed; workspace and user hooks do not override each other.
+
+## Hook Events
+
+| Event | Trigger |
+|------|-------|
+| `SessionStart` | First prompt of a new agent session |
+| `UserPromptSubmit` | User submits a prompt |
+| `PreToolUse` | Before tool invocation |
+| `PostToolUse` | After successful tool invocation |
+| `PreCompact` | Before context compaction |
+| `SubagentStart` | Subagent starts |
+| `SubagentStop` | Subagent ends |
+| `Stop` | Agent session ends |
+
+## Configuration Format
+
+```json
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "type": "command",
+        "command": "./scripts/validate-tool.sh",
+        "timeout": 15
+      }
+    ]
+  }
+}
+```
+
+Each hook command supports:
+- `type` (must be `command`)
+- `command` (default)
+- `windows`, `linux`, `osx` (platform overrides)
+- `cwd`, `env`, `timeout`
+
+## Input / Output Contract
+
+Hooks receive JSON on stdin and can return JSON on stdout.
+
+- Common output: `continue`, `stopReason`, `systemMessage`
+- `PreToolUse` permissions are read from `hookSpecificOutput.permissionDecision` (`allow` | `ask` | `deny`)
+- `PostToolUse` output can block further processing with `decision: block`
+
+`PreToolUse` example output:
+
+```json
+{
+  "hookSpecificOutput": {
+    "hookEventName": "PreToolUse",
+    "permissionDecision": "ask",
+    "permissionDecisionReason": "Needs user confirmation"
+  }
+}
+```
+
+Exit codes:
+- `0` success
+- `2` blocking error
+- Other values produce non-blocking warnings
+
+## Hooks vs Other Customizations
+
+| Primitive | Behavior |
+|------|-------|
+| Instructions / Prompts / Skills / Agents | Guidance (non-deterministic) |
+| Hooks | Runtime enforcement and deterministic automation |
+
+Use hooks when behavior must be guaranteed (for example: block dangerous commands, force validation, auto-inject context).
+
+## Core Principles
+
+1. Keep hooks small and auditable
+2. Validate and sanitize hook inputs
+3. Avoid hardcoded secrets in scripts
+4. Prefer workspace hooks for team policy, user hooks for personal automation
+
+## Anti-patterns
+
+- Running long hooks that block normal flow
+- Using hooks where plain instructions are sufficient
+- Letting agents edit hook scripts without approval controls

package/.github/skills/agent-customization/references/instructions.md

@@ -0,0 +1,71 @@
+# [File-Specific Instructions (.instructions.md)](https://code.visualstudio.com/docs/copilot/customization/custom-instructions)
+
+Guidelines loaded on-demand when relevant to the current task, or explicitly when files match a pattern.
+
+## Locations
+
+| Path | Scope |
+|------|-------|
+| `.github/instructions/*.instructions.md` | Workspace |
+| `<profile>/instructions/*.instructions.md` | User profile |
+
+## Frontmatter
+
+```yaml
+---
+description: "<required>"    # For on-demand discovery—keyword-rich
+name: "Instruction Name"     # Optional, defaults to filename
+applyTo: "**/*.ts"           # Optional, auto-attach for matching files
+---
+```
+
+## Discovery Modes
+
+| Mode | Trigger | Use Case |
+|------|---------|----------|
+| **On-demand** (`description`) | Agent detects task relevance | Task-based: migrations, refactoring, API work |
+| **Explicit** (`applyTo`) | Files matching glob in context | File-based: language standards, framework rules |
+| **Manual** | `Add Context` → `Instructions` | Ad-hoc attachment |
+
+## Template
+
+```markdown
+---
+description: "Use when writing database migrations, schema changes, or data transformations. Covers safety checks and rollback patterns."
+---
+# Migration Guidelines
+
+- Always create reversible migrations
+- Test rollback before merging
+- Never drop columns in the same release as code removal
+```
+
+Note the "Use when..." pattern in the description—this helps on-demand discovery.
+
+## Explicit File Matching (optional)
+
+Use `applyTo` when the instruction applies to specific file types or folders:
+
+```yaml
+applyTo: "**"                           # ALWAYS included, no matter the file or description (use with caution)
+applyTo: "**/*.py"                      # All Python files
+applyTo: ["src/**", "lib/**"]           # Multiple patterns (OR)
+applyTo: src/**, lib/**                 # Multiple patterns without array syntax (OR)
+applyTo: "src/api/**/*.ts"              # Specific folder + extension
+```
+
+Applied when creating or modifying matching files, not for read-only operations.
+
+## Core Principles
+
+1. **Keyword-rich descriptions**: Include trigger words for on-demand discovery
+2. **One concern per file**: Separate files for testing, styling, documentation
+3. **Concise and actionable**: Share context window—keep focused
+4. **Show, don't tell**: Brief code examples over lengthy explanations
+
+## Anti-patterns
+
+- **Vague descriptions**: "Helpful coding tips" doesn't enable discovery
+- **Overly broad applyTo**: `"**"` with content only relevant to specific files
+- **Duplicating docs**: Copy README instead of linking
+- **Mixing concerns**: Testing + API design + styling in one file

package/.github/skills/agent-customization/references/prompts.md

@@ -0,0 +1,80 @@
+# [Prompts (.prompt.md)](https://code.visualstudio.com/docs/copilot/customization/prompt-files)
+
+Reusable task templates triggered on-demand in chat. Single focused task with parameterized inputs.
+
+## Locations
+
+| Path | Scope |
+|------|-------|
+| `.github/prompts/*.prompt.md` | Workspace |
+| `<profile>/prompts/*.prompt.md` | User profile |
+
+## Frontmatter
+
+```yaml
+---
+description: "<recommended>" # Optional, but improves discoverability
+name: "Prompt Name"          # Optional, defaults to filename
+argument-hint: "Task..."     # Optional: hint shown in chat input
+agent: "agent"               # Optional: ask, agent, plan, or custom agent
+model: "GPT-5.4"             # Optional: selected model, or fallback array
+tools: ["search", "web"]    # Optional: built-in, tool sets, MCP (<server>/*), extension
+---
+```
+
+Model fallback is supported:
+
+```yaml
+model: ['GPT-5.4', 'Claude Sonnet 4.6']
+```
+
+## Template
+
+```markdown
+---
+description: "Generate test cases for selected code"
+agent: "agent"
+---
+Generate comprehensive test cases for the provided code:
+- Include edge cases and error scenarios
+- Follow existing test patterns in the codebase
+- Use descriptive test names
+```
+
+**Context references**: Use Markdown links for files (`[config](./config.json)`) and `#tool:<name>` for tools.
+
+## Invocation
+
+- **Chat**: Type `/` → select from prompts and skills
+- **Command**: `Chat: Run Prompt...`
+- **Editor**: Open prompt file → play button
+
+> Both prompts and skills appear as slash commands in chat. Skills provide multi-step workflows with bundled assets; prompts are single focused tasks.
+
+**Tip**: Use `chat.promptFilesRecommendations` to show prompts as actions when starting a new chat.
+
+## Tool Priority
+
+When both prompt and custom agent define tools:
+1. Tools from prompt file
+2. Tools from referenced custom agent
+3. Default tools for selected agent
+
+## When to Use
+
+- Generate test cases for specific code
+- Create READMEs from specs
+- Summarize metrics with custom parameters
+- One-off generation tasks
+
+## Core Principles
+
+1. **Single task focus**: One prompt = one well-defined task
+2. **Output examples**: Show expected format when quality depends on structure
+3. **Reuse over duplication**: Reference instruction files instead of copying
+
+## Anti-patterns
+
+- **Multi-task prompts**: "create and test and deploy" in one prompt
+- **Vague descriptions**: Descriptions that don't help users understand when to use
+- **Over-tooling**: Many tools when the task only needs search or file access

package/.github/skills/agent-customization/references/skills.md

@@ -0,0 +1,100 @@
+# [Agent Skills (SKILL.md)](https://code.visualstudio.com/docs/copilot/customization/agent-skills)
+
+Folders of instructions, scripts, and resources that agents load on-demand for specialized tasks.
+
+## Structure
+
+```
+.github/skills/<skill-name>/
+├── SKILL.md           # Required (name must match folder)
+├── scripts/           # Executable code
+├── references/        # Docs loaded as needed
+└── assets/            # Templates, boilerplate
+```
+
+## Locations
+
+| Path | Scope |
+|------|-------|
+| `.github/skills/<name>/` | Project |
+| `.agents/skills/<name>/` | Project |
+| `.claude/skills/<name>/` | Project |
+| `~/.copilot/skills/<name>/` | Personal |
+| `~/.agents/skills/<name>/` | Personal |
+| `~/.claude/skills/<name>/` | Personal |
+
+## SKILL.md Format
+
+```yaml
+---
+name: skill-name              # Required: 1-64 chars, lowercase alphanumeric + hyphens, must match folder
+description: 'What and when to use. Max 1024 chars.'
+argument-hint: 'Optional hint shown for slash invocation'
+user-invocable: true          # Optional: show as slash command (default: true)
+disable-model-invocation: false # Optional: disable automatic model-triggered loading
+---
+```
+
+### Body
+
+- What the skill accomplishes
+- When to use (triggers and use cases)
+- Step-by-step procedures
+- References to resources: `[script](./scripts/test.js)`
+
+## Template
+
+```markdown
+---
+name: webapp-testing
+description: 'Test web applications using Playwright. Use for verifying frontend, debugging UI, capturing screenshots.'
+---
+
+# Web Application Testing
+
+## When to Use
+- Verify frontend functionality
+- Debug UI behavior
+
+## Procedure
+1. Start the web server
+2. Run [test script](./scripts/test.js)
+3. Review screenshots in `./screenshots/`
+```
+
+## Progressive Loading
+
+1. **Discovery** (~100 tokens): Agent reads `name` and `description`
+2. **Instructions** (<5000 tokens): Loads `SKILL.md` body when relevant
+3. **Resources**: Additional files load only when referenced
+
+Keep file references one level deep from `SKILL.md`.
+
+## Slash Command Behavior
+
+Skills and prompt files both appear after typing `/` in chat.
+
+| Configuration | Slash command | Auto-loaded |
+|---|---|---|
+| Default (both omitted) | Yes | Yes |
+| `user-invocable: false` | No | Yes |
+| `disable-model-invocation: true` | Yes | No |
+| Both set | No | No |
+
+## When to Use
+
+Repeatable, on-demand workflows with bundled assets (scripts, templates, reference docs).
+
+## Core Principles
+
+1. **Keyword-rich descriptions**: Include trigger words for discovery
+2. **Progressive loading**: Keep SKILL.md under 500 lines; use reference files
+3. **Relative paths**: Always use `./` for skill resources
+4. **Self-contained**: Include all procedural knowledge to complete the task
+
+## Anti-patterns
+
+- **Vague descriptions**: "A helpful skill" doesn't enable discovery
+- **Monolithic SKILL.md**: Everything in one file instead of references
+- **Name mismatch**: Folder name doesn't match `name` field
+- **Missing procedures**: Descriptions without step-by-step guidance

package/.github/skills/agent-customization/references/workspace-instructions.md

@@ -0,0 +1,66 @@
+# [Workspace Instructions](https://code.visualstudio.com/docs/copilot/customization/custom-instructions)
+
+Guidelines that automatically apply to all chat requests across your entire workspace.
+
+## File Types (Choose One)
+
+| File | Location | Purpose |
+|------|----------|---------|
+| `copilot-instructions.md` | `.github/` | Project-wide standards (recommended, cross-editor) |
+| `AGENTS.md` | Root or subfolders | Open standard, monorepo hierarchy support |
+
+Use **only one**—not both.
+
+## AGENTS.md Hierarchy
+
+For monorepos, the closest file in the directory tree takes precedence:
+
+```
+/AGENTS.md              # Root defaults
+/frontend/AGENTS.md     # Frontend-specific (overrides root)
+/backend/AGENTS.md      # Backend-specific (overrides root)
+```
+
+Use nested `AGENTS.md` files for monorepos when different areas need different defaults.
+
+## Template
+
+Only include sections the workspace benefits from:
+
+```markdown
+# Project Guidelines
+
+## Code Style
+{Language and formatting preferences—reference key files that exemplify patterns}
+
+## Architecture
+{Major components, service boundaries, the "why" behind structural decisions}
+
+## Build and Test
+{Commands to install, build, test—agents will attempt to run these}
+
+## Conventions
+{Patterns that differ from common practices—include specific examples}
+```
+
+For large repos, link to detailed docs instead of embedding: `See docs/TESTING.md for test conventions.`
+
+## When to Use
+
+- General coding standards that apply everywhere
+- Team preferences shared through version control
+- Project-wide requirements (testing, documentation)
+
+## Core Principles
+
+1. **Minimal by default**: Only what's relevant to *every* task
+2. **Concise and actionable**: Every line should guide behavior
+3. **Link, don't embed**: Reference docs instead of copying
+4. **Keep current**: Update when practices change
+
+## Anti-patterns
+
+- **Using both file types**: Having both `copilot-instructions.md` and `AGENTS.md`
+- **Kitchen sink**: Everything instead of what matters most
+- **Duplicating docs**: Copying README instead of linking
+- **Obvious instructions**: Conventions already enforced by linters

package/.github/skills/agent-prd-writer/SKILL.md

@@ -0,0 +1,85 @@
+---
+name: agent-prd-writer
+description: 'Write implementation-ready PRD language for a Jump Start or AI Innovation Pod follow-on build, including users, workflow, capabilities, boundaries, tools, controls, and acceptance criteria. Use this whenever the user needs a build-ready handoff artifact that a Pod or delivery team can implement without reopening the core scope.'
+argument-hint: 'Describe the problem, users, workflow, and what the agent or system should do.'
+---
+
+# Agent PRD Writer
+
+## Positioning
+
+Use this skill to convert Jump Start discovery, architecture thinking, or scoped Pod concepts into a build-ready requirements document. The output should help a delivery team move from concept to implementation without turning a discovery artifact into an accidental commitment to full platform ownership.
+
+## When To Use This
+
+- A solution needs implementation-ready requirements.
+- The user wants a PRD for an agent or workflow.
+- Delivery teams need clearer capabilities, boundaries, tools, and acceptance criteria.
+- A workshop or roadmap outcome now needs a concrete handoff artifact.
+
+## Typical Need Shapes
+
+- "Turn this Jump Start recommendation into a build-ready PRD without implying production scope."
+- "Write the pilot requirements for this Ignition-tier assistant workflow."
+- "Convert these approved capabilities into acceptance criteria, controls, and out-of-scope boundaries."
+
+## When Not To Use This
+
+- Do not use it when the main need is a client-facing summary instead of a build document.
+- Do not use it before the business logic and operating constraints are understood. Route to `business-logic-extractor` or `solution-architecture-patterns` first when needed.
+
+## Required Inputs
+
+- Problem statement
+- Users and workflow
+- Any tools, integrations, data, or policy constraints
+- Delivery stage if known: Jump Start follow-on, Ignition, Turbo, or Overdrive
+
+## Evidence And Boundary Discipline
+
+Separate requirements from assumptions, design options, and future-state aspirations. A PRD can be implementation-ready without pretending every dependency is resolved. Make non-goals, client-owned responsibilities, human-review boundaries, and acceptance evidence visible so the delivery team does not have to reopen scope.
+
+## Workflow
+
+1. Define the problem, users, and desired outcomes.
+2. Translate workflow needs into capabilities, boundaries, and non-goals.
+3. Capture data, tools, integrations, controls, and human approvals.
+4. Separate required behavior from implementation assumptions.
+5. Draft acceptance criteria, dependencies, and explicit out-of-scope limits.
+
+## Output Structure
+
+1. Problem and goals
+2. Users and workflows
+3. Functional capabilities
+4. Data, tools, and integration boundaries
+5. Controls, approvals, and operating constraints
+6. Acceptance criteria
+7. Dependencies, assumptions, and out of scope
+
+## Reference Files
+
+- Use [prd-pattern.md](./references/prd-pattern.md) for the default PRD structure, Jump Start-to-PRD guidance, and Pod ownership reminders.
+- Use [../../../05-reference/prototype-to-Production.md](../../../05-reference/prototype-to-Production.md) when the PRD needs to show how a concept moves into delivery.
+- Use [../../../05-reference/understanding-the-ai-innovation-pod.md](../../../05-reference/understanding-the-ai-innovation-pod.md) when ownership boundaries between Pod and adjacent teams must be explicit.
+
+## Common Pitfalls
+
+### Pitfall 1: Writing A Vision Doc Instead Of A PRD
+
+Bad: emphasizing business value without concrete capabilities, boundaries, inputs, outputs, and acceptance criteria.
+
+Better: translate the vision into implementable behavior and verification signals.
+
+### Pitfall 2: Hiding Ownership Boundaries
+
+Bad: assuming the Pod owns data remediation, platform operations, or production support.
+
+Better: make ownership, dependencies, and out-of-scope responsibilities explicit.
+
+## Quality Bar
+
+- Be specific enough to support implementation discussion.
+- Separate required behavior from nice-to-have ideas.
+- Distinguish discovery conclusions from build commitments.
+- Keep ownership, approvals, and out-of-scope boundaries explicit.

package/.github/skills/agent-prd-writer/evals/evals.json

@@ -0,0 +1,17 @@
+{
+  "skill_name": "agent-prd-writer",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "Create an implementation-ready PRD for this agent-assisted intake and triage workflow.",
+      "expected_output": "A build-oriented PRD with capabilities, controls, and acceptance criteria.",
+      "files": []
+    },
+    {
+      "id": 2,
+      "prompt": "Turn this rough solution concept into an agent PRD with boundaries, tools, and approval points.",
+      "expected_output": "A structured specification usable by a delivery team.",
+      "files": []
+    }
+  ]
+}

package/.github/skills/agent-prd-writer/references/prd-pattern.md

@@ -0,0 +1,21 @@
+# PRD Pattern
+
+Use this structure by default when converting Jump Start outputs or Pod scope into a build-ready handoff.
+
+1. Problem statement and goals
+2. Users and workflow context
+3. Required capabilities
+4. Data, tools, and integration boundaries
+5. Controls and human approval points
+6. Acceptance criteria
+7. Out of scope
+
+## Jump Start To PRD Reminder
+
+- Preserve directional workshop conclusions, but do not upgrade them into assumed production commitments.
+- Carry forward only the workflow, controls, and dependencies the room actually confirmed.
+
+## Pod Delivery Reminder
+
+- State what the Pod owns, what the client owns, and what must be approved before build or release.
+- Map each major capability to at least one acceptance criterion when the input supports it.

package/.github/skills/agent-tool-catalog-designer/SKILL.md

@@ -0,0 +1,107 @@
+---
+name: agent-tool-catalog-designer
+description: 'Define the typed tool surface — inputs, outputs, side effects, auth, rate limits, and error contracts — for an AI agent before any code is written, so the Pod can implement, test, and govern the agent with confidence. Use this whenever the user is shaping an agent that will call APIs, query databases, send messages, modify records, or invoke other systems, even when phrased as "what tools should the agent have", "design the function calling surface", "wire the agent to our APIs", or "build the agent toolkit".'
+argument-hint: 'Provide the agent purpose, the user, the systems it must touch, and any auth, rate limit, or governance constraints.'
+---
+
+# Agent Tool Catalog Designer
+
+## Positioning
+
+A tool catalog is the contract between an agent and the rest of the world. If it is vague, the agent will hallucinate calls, leak data across boundaries, hit rate limits in production, and quietly corrupt records. Use this skill to design the tool surface before any code: a typed schema per tool, a side-effect classification, an auth and identity model, a rate-limit posture, and an error contract.
+
+The output should let three audiences act:
+
+- A developer can implement each tool from the catalog without re-deriving intent.
+- A reviewer can tell at a glance which tools are read-only, which mutate, and which require human approval.
+- A governance owner can map each tool to identity, scope, audit, and rate-limit policy.
+
+## When To Use This
+
+- A Jump Start or Pod build includes an agent that calls APIs, services, or tools and the surface has not been specified.
+- An existing agent is brittle, unsafe, or making the wrong calls and the tool surface needs to be tightened.
+- A scope or SOW must commit to which systems the agent will touch and how.
+- A governance review needs a defensible "what can this agent actually do" artifact.
+
+## When Not To Use This
+
+- Do not use this for simple chat-only assistants with no external side effects.
+- Do not use this in place of [`agent-permissioning-designer`](../agent-permissioning-designer/SKILL.md) for the identity, scope, and RBAC mapping. Pair the two.
+- Do not use this in place of [`mcp-server-designer`](../mcp-server-designer/SKILL.md) when the deliverable is a domain MCP server.
+
+## Required Inputs
+
+- Agent purpose in one sentence.
+- User identity and execution context (who calls the agent; whose authority does it act under).
+- Systems and data sources the agent must reach.
+- Action class expected: read, write, send, schedule, escalate.
+- Constraints: auth model, residency, rate limits, audit, approval requirements.
+
+## Tool Specification (per tool)
+
+Every tool entry includes:
+
+1. **Name and one-line purpose** — verb-led, scoped to one job.
+2. **Input schema** — typed (JSON schema or Pydantic), with required vs. optional, examples, and validation rules.
+3. **Output schema** — typed, including success and structured error shapes.
+4. **Side effect class** — `read` | `write` | `send` | `schedule` | `escalate`. Drives approval, audit, and rollback design.
+5. **Auth and identity** — system identity, on-behalf-of user, scoped tokens, consent surface.
+6. **Rate limits and quotas** — per-call, per-user, per-tenant, per-day.
+7. **Idempotency and rollback** — idempotency key strategy; how to undo or compensate.
+8. **Failure modes and error contract** — typed errors the agent must handle (retryable, fatal, user-fixable).
+9. **Approval gate** — none | implicit | explicit human | dual-control. Tied to risk class.
+10. **Observability** — what is traced, what is logged at what level, what is redacted.
+11. **Examples** — at least one happy path and one error path.
+
+Use [templates/tool-spec.md](./templates/tool-spec.md) for each tool, and [templates/tool-catalog.md](./templates/tool-catalog.md) to roll up the catalog.
+
+## Workflow
+
+1. Anchor on the agent's job and the smallest set of actions that completes it. Resist toolkit sprawl.
+2. List candidate tools by user intent, not by API. Multiple intents may map to one underlying API; one intent may need a composed tool.
+3. Classify side effects. Read-only tools need light governance; write/send/schedule/escalate tools need explicit approval and audit design.
+4. Design auth: prefer on-behalf-of user identity; only fall back to system identity with explicit rationale.
+5. Define rate limits early; production agents fail on rate limits before they fail on logic.
+6. Draft the schemas. Strict types beat free-text fields; enums beat strings.
+7. Write the error contract. The agent must know which errors to retry, which to surface, and which to escalate.
+8. Add approval gates per side-effect class — see [`human-in-the-loop-designer`](../human-in-the-loop-designer/SKILL.md).
+9. Capture observability hooks per tool.
+10. Review for least privilege, separation of duties, and the "what could a compromised prompt do" lens.
+
+## Output Structure
+
+1. Agent purpose and user.
+2. Action inventory (intent → candidate tool).
+3. Tool catalog table (name, side effect, auth, approval, rate limit).
+4. Per-tool specs (one per tool, full schema).
+5. Cross-cutting: auth model, rate-limit posture, error taxonomy, observability.
+6. Out-of-scope tools (named and justified).
+7. Risks, assumptions, next validation step.
+
+A worked output is in [examples/example-it-helpdesk-agent.md](./examples/example-it-helpdesk-agent.md).
+
+## Common Pitfalls
+
+- **Mirroring the API instead of the intent.** A tool should match a unit of agent reasoning, not a REST endpoint. Compose where useful.
+- **Stringly-typed inputs.** Free-text inputs collapse to prompt-injection vectors. Use enums, IDs, and structured types.
+- **One giant tool.** "Run anything" tools are unscopeable. Split by side effect and risk class.
+- **Hidden side effects.** A "search" tool that also writes audit logs into a privileged store is not read-only. Classify by *all* effects.
+- **System identity by default.** Acting as a service account erases user accountability and bypasses RBAC. Require an explicit reason to use it.
+- **No error contract.** Without typed errors, the agent will retry destructive calls or silently swallow failures.
+- **Tool sprawl.** Every extra tool widens the attack and hallucination surface. Justify each.
+
+## Quality Bar
+
+- Every tool has typed input/output, a side-effect class, and an auth note.
+- Write/send/schedule/escalate tools name an approval gate and an audit field.
+- Rate limits are specified, not assumed.
+- The catalog includes an out-of-scope list with rationale.
+
+## Related Skills
+
+- `agent-permissioning-designer` — RBAC/ABAC and scoped token mapping.
+- `human-in-the-loop-designer` — approval gates per risk class.
+- `mcp-server-designer` — when the catalog is exposed as MCP tools/resources.
+- `agent-governance` — wraps the catalog in policy, audit, and trust controls.
+- `failure-mode-and-effects-ai` — surface tool-misuse failure modes.
+- `observability-design-for-ai` — wire tracing for each tool call.