[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CS6BZ9K96YQJKQX696XSSH":3,"skill-same:01M6CS6BZ9K96YQJKQX696XSSH":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":36,"linkOnly":37,"markdownContent":38,"markdownBody":39,"frontMatter":40,"refName":41,"commitSha":42,"skillDirectory":43,"forksCount":44,"repositoryHtmlUrl":45,"repositoryHomepageUrl":46,"ownerHtmlUrl":47,"ownerBlogUrl":48,"ownerDescription":6,"updatedAt":49,"install":50,"resources":63},"01M6CS6BZ9K96YQJKQX696XSSH","feature-request",null,"Manage feature request intake, normalization, triage, queue operations, and API-only lifecycle workflows.","onurmatik\u002Ffeature-request","onurmatik","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F127720?v=4","01M6CS699DRA2MWA7HBZP3RVW0","Onur Mat","01M6CS69DSNNY7PWYS81ATV07S",1,"MIT","https:\u002F\u002Fgithub.com\u002Fonurmatik\u002Ffeature-request\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ffeature-request\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35],"feature request","triage","workflows","intake","lifecycle","api","normalization","request intake","operations","only","queue","manage","2026-11-10 10:12:30",false,"---\nname: feature-request\ndescription: Manage feature request intake, normalization, triage, queue operations, and API-only lifecycle workflows.\n---\n\n# Skills (Agent Task Catalog)\n\nThis file is the repository's downstream skill registry. Each section is an actionable skill\nwith a deterministic flow, but normative agent semantics live only in `agent\u002Fcontract.yaml`.\nTool schemas, scopes, capabilities, ownership, approvals, errors, side effects, and retry rules\nmust be referenced or mechanically projected from that Contract rather than redefined here.\n\nAgent Contract 1.1.0 names `get_account_capabilities` as the bootstrap tool. The repository now\nimplements its exact 30-tool projection, while MCP production conformance is `pending`\nuntil the immutable MCP release, PostgreSQL concurrency, deployment, observation, and real-client\nacceptance gates pass. The MCP and API sections below document that release-preparation handoff.\n\n## Skill: `agent-onboard`\n### Trigger\nUser asks for agent-facing setup or onboarding changes.\n\n### Required Inputs\n- Target feature area (`backend`, `frontend`, `tooling`, or `manifest`).\n- Scope of changes and acceptance criteria.\n\n### Command Flow\n1. Read `.\u002FAGENTS.md`.\n2. Read `.\u002Fagents.json` if present.\n3. Update only the requested sections.\n4. Run relevant validation commands after edit.\n\n### Expected Output\n- Summary of updated sections.\n- List of files changed.\n- Validation command results.\n\n### Failure Handling\n- If required references are missing, stop and request the missing inputs before writing.\n- If validation fails, include failing command output and propose next corrective step.\n\n## Skill: `feature-request-operator` \n### Trigger\nUser asks an agent to read or mutate feature requests for a public board.\n\n### Purpose\nOperate on board data via API:\n- read, create, update, and explicitly delete projects\n- read requests\u002Fissues\n- read owner-scoped queue signals and cursor-based request changes\n- find explainable duplicate candidates and manage reversible canonical links\n- record delivery artifact links for agent-side verification\n- update requests\u002Fissues\n- transition request status\n- read comments\n- create requests\n- add comments\n- edit comments\n- toggle upvotes\n\n### Prompt Presets\n- `portfolio-triage`: read-only queue snapshot across all projects owned by the authenticated user.\n- `project-triage`: read-only queue snapshot for one `owner_handle\u002Fproject_slug`.\n- `project-implementation`: use one project's FeatureRequest issues as the source of truth for local repo implementation work.\n\n### Agent\u002FMCP Decision Boundary\n- FeatureRequest stores facts and controlled state; the calling agent performs semantic judgment.\n- Treat current priority, votes, comments, status, and activity timestamps as queue evidence.\n- Treat duplicate similarity scores, matched terms, and score components as candidates only.\n- Use the returned algorithm identifier when comparing scores across runs or versions.\n- Never create a duplicate link solely because a similarity score is high; inspect both requests first.\n- A delivery artifact is only a stored URL. Inspect it with the agent's repository, GitHub, CI,\n  deployment, or release tools before describing delivery as verified.\n- Linking a duplicate or delivery artifact never changes request priority or status automatically.\n- Activity\u002Fchange events begin when P1 is deployed; do not infer a complete pre-P1 audit history.\n\n### Required Inputs\n- Base URL:\n  - https:\u002F\u002Ffeaturerequest.io\n- Auth mode:\n  - MCP: OAuth 2.1 Authorization Code + PKCE S256; CIMD preferred, DCR fallback.\n  - API-only workflows: existing `fr_` bearer tokens remain valid on `\u002Fapi`.\n  - Never send an `fr_` API token to `\u002Fmcp`; initial MCP scope is `read`, with `write` step-up.\n- `owner_handle` (required for read\u002Fwrite paths under that board).\n- Optional: `project_slug`.\n- Input payloads:\n  - request: `issue_type`, `title`, `description`, `priority`.\n  - comment: `body`.\n  - optional filters: `issue_type`, `status`, `priority`, `limit`.\n  - `status=active` is a list-only filter that excludes `done`, `closed`, and `declined`.\n\n### MCP\u002FOAuth 1.1 Repository Runtime (Production Conformance Pending)\n- Transport: Streamable HTTP at `\u002Fmcp`.\n- Authentication: MCP OAuth discovery, public clients, PKCE S256, exact resource binding.\n- Permission model:\n  - act as the consenting FeatureRequest user;\n  - use Contract-projected `read` and `write` scopes;\n  - enforce project\u002Frequest\u002Fcomment ownership in the domain service;\n  - reject API tokens, query tokens, cookie tokens, foreign-resource tokens, and expired tokens.\n- The server intentionally does not expose `get_connection_context`; call `list_projects`\n  when the authenticated user's owner\u002Fproject context is unknown.\n- `get_account_capabilities` is implemented as the capability\u002Flimit bootstrap. Its public\n  production availability remains pending the immutable release gates.\n- This tool list is a downstream projection only. The canonical public catalog and all\n  behavioral metadata are owned by `agent\u002Fcontract.yaml`.\n- Bootstrap tool:\n  - `get_account_capabilities`\n- P1 project tools:\n  - `list_projects`\n  - `get_project`\n  - `create_project`\n  - `update_project`\n  - `delete_project`\n- Product Spec and scope tools:\n  - `get_project_spec`\n  - `update_project_spec`\n  - `get_request_scope_assessment`\n  - `reassess_request_scope`\n  - `propose_project_spec_update`\n  - `list_project_spec_proposals`\n  - `resolve_project_spec_proposal`\n- P1 request and evidence tools:\n  - `list_requests`\n  - `get_request`\n  - `list_request_comments`\n  - `get_queue_snapshot`\n  - `find_duplicate_candidates`\n  - `list_request_activity`\n  - `list_request_changes`\n  - `list_delivery_artifacts`\n  - `create_request`\n  - `update_request`\n  - `transition_request`\n  - `add_request_comment`\n  - `update_request_comment`\n  - `link_duplicate_request`\n  - `unlink_duplicate_request`\n  - `link_delivery_artifact`\n  - `unlink_delivery_artifact`\n- `delete_project` is destructive: call `get_project` first, require explicit user direction,\n  and pass the same project id as `confirm_project_id`.\n- Keep status transitions separate from content\u002Fpriority updates.\n- Treat scope assessments as evidence. Automatic `declined` is allowed only when the guarded\n  Contract rule matches an exact `Out of scope` quote without contradiction or ambiguity.\n- Assessment failures fail open and remain owner-only. Pending spec proposals are owner-private;\n  acceptance requires the unchanged base spec revision and rejection creates no public event.\n- Only the project owner may transition into or out of `declined`; authors may still comment.\n- Do not transition a request to `done` or `closed` without explicit user direction\n  and delivery evidence that the calling agent has inspected.\n- Intentionally not exposed through MCP: token create\u002Frevoke, billing\u002Fcheckout, bulk close,\n  and bulk mutation.\n\n### Plugin Package Compatibility\n- Portable package contract: Agent Plugins 1.0.0 root `plugin.json`, root `mcp.json`,\n  and immediate-child skills under `skills\u002F`.\n- The portable MCP declaration uses `streamable-http`; authentication is configured by\n  the consuming client because Agent Plugins 1.0.0 does not define credential references.\n- Codex-native metadata remains in `.codex-plugin\u002Fplugin.json` and `.mcp.json`; keep its\n  name, version, MCP URL, and shared `skills\u002F` content aligned with the portable package.\n\n### Required API Routes\n- Web-session agent onboarding only:\n  - `POST \u002Fapi\u002Fauth\u002Fagent-token\u002Fconnect`\n  - `POST \u002Fapi\u002Fauth\u002Fagent-token\u002Frefresh`\n- Read projects:\n  - `GET \u002Fapi\u002Fprojects`\n  - `GET \u002Fapi\u002Fowners\u002F{owner_handle}\u002Fprojects`\n- Manage owned projects:\n  - `POST \u002Fapi\u002Fprojects`\n  - `GET \u002Fapi\u002Fprojects\u002F{project_id}`\n  - `PATCH \u002Fapi\u002Fprojects\u002F{project_id}`\n  - `DELETE \u002Fapi\u002Fprojects\u002F{project_id}`\n- Product Spec and owner proposal workflow:\n  - `GET \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fspec`\n  - `PUT \u002Fapi\u002Fprojects\u002F{project_id}\u002Fspec`\n  - `DELETE \u002Fapi\u002Fprojects\u002F{project_id}\u002Fspec`\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}\u002Fscope-assessment`\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fscope-assessment\u002Fretry`\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fspec-change-proposals`\n  - `GET \u002Fapi\u002Fprojects\u002F{project_id}\u002Fspec-change-proposals?status=pending`\n  - `PATCH \u002Fapi\u002Fspec-change-proposals\u002F{proposal_id}`\n- Read issues:\n  - `GET \u002Fapi\u002Fowners\u002F{owner_handle}\u002Fissues`\n  - `GET \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fissues`\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}`\n- Read queue and activity evidence:\n  - `GET \u002Fapi\u002Fme\u002Frequest-queue`\n  - `GET \u002Fapi\u002Fme\u002Fissue-changes`\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}\u002Factivity`\n- Find and manage duplicates:\n  - `GET \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fduplicate-candidates`\n  - `PATCH \u002Fapi\u002Fissues\u002F{issue_id}\u002Fduplicate`\n  - `DELETE \u002Fapi\u002Fissues\u002F{issue_id}\u002Fduplicate`\n- Manage delivery evidence:\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}\u002Fdelivery-artifacts`\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fdelivery-artifacts`\n  - `DELETE \u002Fapi\u002Fissues\u002F{issue_id}\u002Fdelivery-artifacts\u002F{artifact_id}`\n- Update issue:\n  - `PATCH \u002Fapi\u002Fissues\u002F{issue_id}`\n- Create issue:\n  - `POST \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fissues`\n  - Agents must continue to use this authenticated endpoint. The public\n    `\u002Fapi\u002Fembed\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fsubmissions` route is browser-only,\n    requires Turnstile and anonymous browser-submission safeguards, and must not be used for\n    agent writes.\n- Add comment:\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fcomments`\n- Read comments:\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}\u002Fcomments`\n- Edit comment:\n  - `PATCH \u002Fapi\u002Fissues\u002F{issue_id}\u002Fcomments\u002F{comment_id}`\n- Toggle upvote:\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fupvote\u002Ftoggle`\n\n### Command Flow\n1. Select MCP or API mode explicitly; never reuse credentials across the two resources.\n2. For MCP, complete OAuth discovery and call `get_account_capabilities`; accept `write` step-up\n   only when the user-requested action requires mutation.\n3. For API-only mode, use a supplied raw API token only on `\u002Fapi`; agent-token connect\u002Frefresh\n   remains limited to browser\u002Fsession onboarding.\n4. If read requested:\n   - for portfolio triage, call `GET \u002Fapi\u002Fme\u002Frequest-queue`; use the returned current fields and signals as evidence for the agent's own prioritization.\n   - for project-scoped triage or implementation, call `GET \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fissues` directly with optional filters.\n   - if one issue is target, call issue detail.\n5. If managing a project:\n   - use the focused create\u002Fget\u002Fupdate project route.\n   - before delete, read the project by id and proceed only when the user explicitly requested deletion.\n6. If creating request:\n   - optionally call duplicate candidates with the proposed title\u002Fdescription.\n   - inspect plausible candidates; do not treat the score as a decision.\n   - call create issue endpoint with required body when a new canonical request is still appropriate.\n7. If classifying a duplicate:\n   - read both issues, ensure they represent the same underlying request, then link the duplicate to the root canonical issue.\n   - unlink the relationship when evidence changes; never transition or reprioritize as a side effect.\n8. If updating request content or priority:\n   - call update issue with only the requested fields.\n9. If transitioning request status:\n   - call update issue with only `status`.\n   - do not use `done` or `closed` without explicit user direction and delivery evidence.\n10. If adding comment:\n   - call create comment endpoint with `{\"body\": \"\u003Ctext>\"}`.\n11. If editing comment:\n   - call update comment endpoint with `{\"body\": \"\u003Ctext>\"}`.\n12. If upvote requested:\n   - call upvote toggle endpoint and read returned `upvoted` + `upvotes_count`.\n13. If recording delivery:\n   - link the artifact URL with its kind and label.\n   - inspect the external artifact independently; the stored link is not verification.\n   - only then comment or transition when explicitly requested.\n14. For polling or follow-up, call the cursor-based change feed with the last `next_cursor`.\n15. Return a normalized result object (see output format).\n16. On failures, return error object with action and actionable recovery step.\n\n### Project-Scoped Implementation Guidance\n- Treat FeatureRequest as the ticket source of truth.\n- Perform code changes only in the local repository\u002Fworkspace where the coding agent is already running.\n- Only read issues for the instructed `owner_handle\u002Fproject_slug`; do not read or modify other projects.\n- Pick at most one ready issue per run unless the user explicitly asks for more.\n- Before code changes, produce a short implementation plan.\n- Run relevant tests after edits.\n- After implementation, add a concise comment back to the issue when write access is available.\n- Link relevant pull request, commit, deployment, or release URLs as delivery artifacts.\n- Verify those artifacts with the coding agent's external tools; FeatureRequest does not verify them.\n- Do not mark an issue `done` automatically; reserve `done`\u002F`closed` for merge or release confirmation.\n\n### Expected Output Format\nReturn compact JSON:\n```json\n{\n  \"ok\": true,\n  \"action\": \"\u003Cfocused MCP or API action name>\",\n  \"request\": {\n    \"method\": \"POST\",\n    \"path\": \"\u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fissues\",\n    \"status\": 201\n  },\n  \"resource\": {\n    \"owner_handle\": \"owner\",\n    \"project_slug\": \"project\",\n    \"issue_id\": 123\n  },\n  \"data\": {},\n  \"meta\": {\n    \"items_returned\": 0,\n    \"created_at\": \"2026-02-27T12:00:00Z\"\n  }\n}\n```\n\nFor failures:\n```json\n{\n  \"ok\": false,\n  \"action\": \"add_comment\",\n  \"request\": {...},\n  \"error\": {\n    \"status_code\": 400,\n    \"message\": \"Message rejected by moderation\"\n  },\n  \"next_step\": \"Retry with cleaner content or ask user for a revised message.\"\n}\n```\n\n### Failure Handling\n- `401`: refresh or request new credentials and retry.\n- `403`:\n  - for read-only token on write action, instruct token replacement with `can_write=true` before retry.\n- `400`: log payload validation\u002Fmoderation failure and stop; do not retry silently.\n- `404`: validate `owner_handle`, `project_slug`, or `issue_id` input.\n- `503`: retry with backoff for transient moderation\u002Fprovider failures.\n- Never auto-delete or mutate any resource unless `action` explicitly asked.\n\n### Prompt Examples\n- Read-only daily triage: read authenticated user's projects, summarize active requests, and return `Queue Snapshot`, `Priority Decisions`, `Active Follow-ups`, `Risks and Blockers`, and `Next Checkpoint`.\n- Project-specific planning: read only `owner_handle\u002Fproject_slug`, identify the next ready issue, and produce an implementation plan without editing code.\n- Project-specific implementation with tests: read only `owner_handle\u002Fproject_slug`, pick at most one ready issue, implement in the current local repo, run relevant tests, and comment back with results when write access is available.\n- Release follow-up: after merge or release confirmation, add a closure comment and update the issue status only when explicitly asked.\n\n## Skill: `user-request-manager`\n### Trigger\nUser asks an agent to manage incoming requests as a queue (visibility, prioritization, ownership, follow-up, closure).\n\n### Required Inputs\n- API access token and scope.\n- Request source input (list, ticket export, or pasted requests).\n- Optional SLA or deadline policy.\n\n### Command Flow\n1. Ingest requests from provided source.\n2. Normalize each item into an API-backed record:\n   - `issue_id`, `owner_handle`, `project_slug`, `issue_type`, `title`, `description`, `priority`, `status`.\n3. Deduplicate overlapping requests and keep one canonical item.\n4. Triage by urgency\u002Fimpact and assign `P0`-`P3`.\n5. Maintain one prioritized queue sorted by priority and due date.\n6. For each active request, include explicit next action in report output (do not persist non-model fields as API attributes).\n7. Produce concise checkpoint updates (new\u002Fchanged\u002Fblocked\u002Fdue soon\u002Fnext actions).\n8. Close request only after expected outcome is met, with closure note.\n\n### Expected Output\n- `Queue Snapshot` table:\n  - `issue_id | summary | priority | status | owner_handle\u002Fproject_slug | next action`\n- `Priority Decisions`\n- `Active Follow-ups`\n- `Risks and Blockers`\n- `Next Checkpoint`\n\n### Failure Handling\n- Missing permissions\u002Fscope: return blocking auth note and exact missing scope.\n- Missing required request fields: mark item `waiting`, request only missing fields.\n- API rate-limit\u002Ftransient failure: retry with bounded backoff and report partial progress.\n- Never perform code or config edits from this skill; operate only through exposed request APIs.\n","# Skills (Agent Task Catalog)\n\nThis file is the repository's downstream skill registry. Each section is an actionable skill\nwith a deterministic flow, but normative agent semantics live only in `agent\u002Fcontract.yaml`.\nTool schemas, scopes, capabilities, ownership, approvals, errors, side effects, and retry rules\nmust be referenced or mechanically projected from that Contract rather than redefined here.\n\nAgent Contract 1.1.0 names `get_account_capabilities` as the bootstrap tool. The repository now\nimplements its exact 30-tool projection, while MCP production conformance is `pending`\nuntil the immutable MCP release, PostgreSQL concurrency, deployment, observation, and real-client\nacceptance gates pass. The MCP and API sections below document that release-preparation handoff.\n\n## Skill: `agent-onboard`\n### Trigger\nUser asks for agent-facing setup or onboarding changes.\n\n### Required Inputs\n- Target feature area (`backend`, `frontend`, `tooling`, or `manifest`).\n- Scope of changes and acceptance criteria.\n\n### Command Flow\n1. Read `.\u002FAGENTS.md`.\n2. Read `.\u002Fagents.json` if present.\n3. Update only the requested sections.\n4. Run relevant validation commands after edit.\n\n### Expected Output\n- Summary of updated sections.\n- List of files changed.\n- Validation command results.\n\n### Failure Handling\n- If required references are missing, stop and request the missing inputs before writing.\n- If validation fails, include failing command output and propose next corrective step.\n\n## Skill: `feature-request-operator` \n### Trigger\nUser asks an agent to read or mutate feature requests for a public board.\n\n### Purpose\nOperate on board data via API:\n- read, create, update, and explicitly delete projects\n- read requests\u002Fissues\n- read owner-scoped queue signals and cursor-based request changes\n- find explainable duplicate candidates and manage reversible canonical links\n- record delivery artifact links for agent-side verification\n- update requests\u002Fissues\n- transition request status\n- read comments\n- create requests\n- add comments\n- edit comments\n- toggle upvotes\n\n### Prompt Presets\n- `portfolio-triage`: read-only queue snapshot across all projects owned by the authenticated user.\n- `project-triage`: read-only queue snapshot for one `owner_handle\u002Fproject_slug`.\n- `project-implementation`: use one project's FeatureRequest issues as the source of truth for local repo implementation work.\n\n### Agent\u002FMCP Decision Boundary\n- FeatureRequest stores facts and controlled state; the calling agent performs semantic judgment.\n- Treat current priority, votes, comments, status, and activity timestamps as queue evidence.\n- Treat duplicate similarity scores, matched terms, and score components as candidates only.\n- Use the returned algorithm identifier when comparing scores across runs or versions.\n- Never create a duplicate link solely because a similarity score is high; inspect both requests first.\n- A delivery artifact is only a stored URL. Inspect it with the agent's repository, GitHub, CI,\n  deployment, or release tools before describing delivery as verified.\n- Linking a duplicate or delivery artifact never changes request priority or status automatically.\n- Activity\u002Fchange events begin when P1 is deployed; do not infer a complete pre-P1 audit history.\n\n### Required Inputs\n- Base URL:\n  - https:\u002F\u002Ffeaturerequest.io\n- Auth mode:\n  - MCP: OAuth 2.1 Authorization Code + PKCE S256; CIMD preferred, DCR fallback.\n  - API-only workflows: existing `fr_` bearer tokens remain valid on `\u002Fapi`.\n  - Never send an `fr_` API token to `\u002Fmcp`; initial MCP scope is `read`, with `write` step-up.\n- `owner_handle` (required for read\u002Fwrite paths under that board).\n- Optional: `project_slug`.\n- Input payloads:\n  - request: `issue_type`, `title`, `description`, `priority`.\n  - comment: `body`.\n  - optional filters: `issue_type`, `status`, `priority`, `limit`.\n  - `status=active` is a list-only filter that excludes `done`, `closed`, and `declined`.\n\n### MCP\u002FOAuth 1.1 Repository Runtime (Production Conformance Pending)\n- Transport: Streamable HTTP at `\u002Fmcp`.\n- Authentication: MCP OAuth discovery, public clients, PKCE S256, exact resource binding.\n- Permission model:\n  - act as the consenting FeatureRequest user;\n  - use Contract-projected `read` and `write` scopes;\n  - enforce project\u002Frequest\u002Fcomment ownership in the domain service;\n  - reject API tokens, query tokens, cookie tokens, foreign-resource tokens, and expired tokens.\n- The server intentionally does not expose `get_connection_context`; call `list_projects`\n  when the authenticated user's owner\u002Fproject context is unknown.\n- `get_account_capabilities` is implemented as the capability\u002Flimit bootstrap. Its public\n  production availability remains pending the immutable release gates.\n- This tool list is a downstream projection only. The canonical public catalog and all\n  behavioral metadata are owned by `agent\u002Fcontract.yaml`.\n- Bootstrap tool:\n  - `get_account_capabilities`\n- P1 project tools:\n  - `list_projects`\n  - `get_project`\n  - `create_project`\n  - `update_project`\n  - `delete_project`\n- Product Spec and scope tools:\n  - `get_project_spec`\n  - `update_project_spec`\n  - `get_request_scope_assessment`\n  - `reassess_request_scope`\n  - `propose_project_spec_update`\n  - `list_project_spec_proposals`\n  - `resolve_project_spec_proposal`\n- P1 request and evidence tools:\n  - `list_requests`\n  - `get_request`\n  - `list_request_comments`\n  - `get_queue_snapshot`\n  - `find_duplicate_candidates`\n  - `list_request_activity`\n  - `list_request_changes`\n  - `list_delivery_artifacts`\n  - `create_request`\n  - `update_request`\n  - `transition_request`\n  - `add_request_comment`\n  - `update_request_comment`\n  - `link_duplicate_request`\n  - `unlink_duplicate_request`\n  - `link_delivery_artifact`\n  - `unlink_delivery_artifact`\n- `delete_project` is destructive: call `get_project` first, require explicit user direction,\n  and pass the same project id as `confirm_project_id`.\n- Keep status transitions separate from content\u002Fpriority updates.\n- Treat scope assessments as evidence. Automatic `declined` is allowed only when the guarded\n  Contract rule matches an exact `Out of scope` quote without contradiction or ambiguity.\n- Assessment failures fail open and remain owner-only. Pending spec proposals are owner-private;\n  acceptance requires the unchanged base spec revision and rejection creates no public event.\n- Only the project owner may transition into or out of `declined`; authors may still comment.\n- Do not transition a request to `done` or `closed` without explicit user direction\n  and delivery evidence that the calling agent has inspected.\n- Intentionally not exposed through MCP: token create\u002Frevoke, billing\u002Fcheckout, bulk close,\n  and bulk mutation.\n\n### Plugin Package Compatibility\n- Portable package contract: Agent Plugins 1.0.0 root `plugin.json`, root `mcp.json`,\n  and immediate-child skills under `skills\u002F`.\n- The portable MCP declaration uses `streamable-http`; authentication is configured by\n  the consuming client because Agent Plugins 1.0.0 does not define credential references.\n- Codex-native metadata remains in `.codex-plugin\u002Fplugin.json` and `.mcp.json`; keep its\n  name, version, MCP URL, and shared `skills\u002F` content aligned with the portable package.\n\n### Required API Routes\n- Web-session agent onboarding only:\n  - `POST \u002Fapi\u002Fauth\u002Fagent-token\u002Fconnect`\n  - `POST \u002Fapi\u002Fauth\u002Fagent-token\u002Frefresh`\n- Read projects:\n  - `GET \u002Fapi\u002Fprojects`\n  - `GET \u002Fapi\u002Fowners\u002F{owner_handle}\u002Fprojects`\n- Manage owned projects:\n  - `POST \u002Fapi\u002Fprojects`\n  - `GET \u002Fapi\u002Fprojects\u002F{project_id}`\n  - `PATCH \u002Fapi\u002Fprojects\u002F{project_id}`\n  - `DELETE \u002Fapi\u002Fprojects\u002F{project_id}`\n- Product Spec and owner proposal workflow:\n  - `GET \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fspec`\n  - `PUT \u002Fapi\u002Fprojects\u002F{project_id}\u002Fspec`\n  - `DELETE \u002Fapi\u002Fprojects\u002F{project_id}\u002Fspec`\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}\u002Fscope-assessment`\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fscope-assessment\u002Fretry`\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fspec-change-proposals`\n  - `GET \u002Fapi\u002Fprojects\u002F{project_id}\u002Fspec-change-proposals?status=pending`\n  - `PATCH \u002Fapi\u002Fspec-change-proposals\u002F{proposal_id}`\n- Read issues:\n  - `GET \u002Fapi\u002Fowners\u002F{owner_handle}\u002Fissues`\n  - `GET \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fissues`\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}`\n- Read queue and activity evidence:\n  - `GET \u002Fapi\u002Fme\u002Frequest-queue`\n  - `GET \u002Fapi\u002Fme\u002Fissue-changes`\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}\u002Factivity`\n- Find and manage duplicates:\n  - `GET \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fduplicate-candidates`\n  - `PATCH \u002Fapi\u002Fissues\u002F{issue_id}\u002Fduplicate`\n  - `DELETE \u002Fapi\u002Fissues\u002F{issue_id}\u002Fduplicate`\n- Manage delivery evidence:\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}\u002Fdelivery-artifacts`\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fdelivery-artifacts`\n  - `DELETE \u002Fapi\u002Fissues\u002F{issue_id}\u002Fdelivery-artifacts\u002F{artifact_id}`\n- Update issue:\n  - `PATCH \u002Fapi\u002Fissues\u002F{issue_id}`\n- Create issue:\n  - `POST \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fissues`\n  - Agents must continue to use this authenticated endpoint. The public\n    `\u002Fapi\u002Fembed\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fsubmissions` route is browser-only,\n    requires Turnstile and anonymous browser-submission safeguards, and must not be used for\n    agent writes.\n- Add comment:\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fcomments`\n- Read comments:\n  - `GET \u002Fapi\u002Fissues\u002F{issue_id}\u002Fcomments`\n- Edit comment:\n  - `PATCH \u002Fapi\u002Fissues\u002F{issue_id}\u002Fcomments\u002F{comment_id}`\n- Toggle upvote:\n  - `POST \u002Fapi\u002Fissues\u002F{issue_id}\u002Fupvote\u002Ftoggle`\n\n### Command Flow\n1. Select MCP or API mode explicitly; never reuse credentials across the two resources.\n2. For MCP, complete OAuth discovery and call `get_account_capabilities`; accept `write` step-up\n   only when the user-requested action requires mutation.\n3. For API-only mode, use a supplied raw API token only on `\u002Fapi`; agent-token connect\u002Frefresh\n   remains limited to browser\u002Fsession onboarding.\n4. If read requested:\n   - for portfolio triage, call `GET \u002Fapi\u002Fme\u002Frequest-queue`; use the returned current fields and signals as evidence for the agent's own prioritization.\n   - for project-scoped triage or implementation, call `GET \u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fissues` directly with optional filters.\n   - if one issue is target, call issue detail.\n5. If managing a project:\n   - use the focused create\u002Fget\u002Fupdate project route.\n   - before delete, read the project by id and proceed only when the user explicitly requested deletion.\n6. If creating request:\n   - optionally call duplicate candidates with the proposed title\u002Fdescription.\n   - inspect plausible candidates; do not treat the score as a decision.\n   - call create issue endpoint with required body when a new canonical request is still appropriate.\n7. If classifying a duplicate:\n   - read both issues, ensure they represent the same underlying request, then link the duplicate to the root canonical issue.\n   - unlink the relationship when evidence changes; never transition or reprioritize as a side effect.\n8. If updating request content or priority:\n   - call update issue with only the requested fields.\n9. If transitioning request status:\n   - call update issue with only `status`.\n   - do not use `done` or `closed` without explicit user direction and delivery evidence.\n10. If adding comment:\n   - call create comment endpoint with `{\"body\": \"\u003Ctext>\"}`.\n11. If editing comment:\n   - call update comment endpoint with `{\"body\": \"\u003Ctext>\"}`.\n12. If upvote requested:\n   - call upvote toggle endpoint and read returned `upvoted` + `upvotes_count`.\n13. If recording delivery:\n   - link the artifact URL with its kind and label.\n   - inspect the external artifact independently; the stored link is not verification.\n   - only then comment or transition when explicitly requested.\n14. For polling or follow-up, call the cursor-based change feed with the last `next_cursor`.\n15. Return a normalized result object (see output format).\n16. On failures, return error object with action and actionable recovery step.\n\n### Project-Scoped Implementation Guidance\n- Treat FeatureRequest as the ticket source of truth.\n- Perform code changes only in the local repository\u002Fworkspace where the coding agent is already running.\n- Only read issues for the instructed `owner_handle\u002Fproject_slug`; do not read or modify other projects.\n- Pick at most one ready issue per run unless the user explicitly asks for more.\n- Before code changes, produce a short implementation plan.\n- Run relevant tests after edits.\n- After implementation, add a concise comment back to the issue when write access is available.\n- Link relevant pull request, commit, deployment, or release URLs as delivery artifacts.\n- Verify those artifacts with the coding agent's external tools; FeatureRequest does not verify them.\n- Do not mark an issue `done` automatically; reserve `done`\u002F`closed` for merge or release confirmation.\n\n### Expected Output Format\nReturn compact JSON:\n```json\n{\n  \"ok\": true,\n  \"action\": \"\u003Cfocused MCP or API action name>\",\n  \"request\": {\n    \"method\": \"POST\",\n    \"path\": \"\u002Fapi\u002Fprojects\u002F{owner_handle}\u002F{project_slug}\u002Fissues\",\n    \"status\": 201\n  },\n  \"resource\": {\n    \"owner_handle\": \"owner\",\n    \"project_slug\": \"project\",\n    \"issue_id\": 123\n  },\n  \"data\": {},\n  \"meta\": {\n    \"items_returned\": 0,\n    \"created_at\": \"2026-02-27T12:00:00Z\"\n  }\n}\n```\n\nFor failures:\n```json\n{\n  \"ok\": false,\n  \"action\": \"add_comment\",\n  \"request\": {...},\n  \"error\": {\n    \"status_code\": 400,\n    \"message\": \"Message rejected by moderation\"\n  },\n  \"next_step\": \"Retry with cleaner content or ask user for a revised message.\"\n}\n```\n\n### Failure Handling\n- `401`: refresh or request new credentials and retry.\n- `403`:\n  - for read-only token on write action, instruct token replacement with `can_write=true` before retry.\n- `400`: log payload validation\u002Fmoderation failure and stop; do not retry silently.\n- `404`: validate `owner_handle`, `project_slug`, or `issue_id` input.\n- `503`: retry with backoff for transient moderation\u002Fprovider failures.\n- Never auto-delete or mutate any resource unless `action` explicitly asked.\n\n### Prompt Examples\n- Read-only daily triage: read authenticated user's projects, summarize active requests, and return `Queue Snapshot`, `Priority Decisions`, `Active Follow-ups`, `Risks and Blockers`, and `Next Checkpoint`.\n- Project-specific planning: read only `owner_handle\u002Fproject_slug`, identify the next ready issue, and produce an implementation plan without editing code.\n- Project-specific implementation with tests: read only `owner_handle\u002Fproject_slug`, pick at most one ready issue, implement in the current local repo, run relevant tests, and comment back with results when write access is available.\n- Release follow-up: after merge or release confirmation, add a closure comment and update the issue status only when explicitly asked.\n\n## Skill: `user-request-manager`\n### Trigger\nUser asks an agent to manage incoming requests as a queue (visibility, prioritization, ownership, follow-up, closure).\n\n### Required Inputs\n- API access token and scope.\n- Request source input (list, ticket export, or pasted requests).\n- Optional SLA or deadline policy.\n\n### Command Flow\n1. Ingest requests from provided source.\n2. Normalize each item into an API-backed record:\n   - `issue_id`, `owner_handle`, `project_slug`, `issue_type`, `title`, `description`, `priority`, `status`.\n3. Deduplicate overlapping requests and keep one canonical item.\n4. Triage by urgency\u002Fimpact and assign `P0`-`P3`.\n5. Maintain one prioritized queue sorted by priority and due date.\n6. For each active request, include explicit next action in report output (do not persist non-model fields as API attributes).\n7. Produce concise checkpoint updates (new\u002Fchanged\u002Fblocked\u002Fdue soon\u002Fnext actions).\n8. Close request only after expected outcome is met, with closure note.\n\n### Expected Output\n- `Queue Snapshot` table:\n  - `issue_id | summary | priority | status | owner_handle\u002Fproject_slug | next action`\n- `Priority Decisions`\n- `Active Follow-ups`\n- `Risks and Blockers`\n- `Next Checkpoint`\n\n### Failure Handling\n- Missing permissions\u002Fscope: return blocking auth note and exact missing scope.\n- Missing required request fields: mark item `waiting`, request only missing fields.\n- API rate-limit\u002Ftransient failure: retry with bounded backoff and report partial progress.\n- Never perform code or config edits from this skill; operate only through exposed request APIs.\n",{"name":5,"description":7},"main","259333d4024b6b981659ebab9e6dfcb9a0e45e19",".agents\u002Fskills\u002Ffeature-request",0,"https:\u002F\u002Fgithub.com\u002Fonurmatik\u002Ffeature-request","https:\u002F\u002FFeatureRequest.io","https:\u002F\u002Fgithub.com\u002Fonurmatik","rekognize.io","2026-09-18 03:34:39",{"source":8,"skillName":5,"commands":51,"prompt":61,"zipAvailable":62},[52,55,58],{"tool":53,"command":54},"npx","npx skills add onurmatik\u002Ffeature-request --skill feature-request",{"tool":56,"command":57},"bunx","bunx skills add onurmatik\u002Ffeature-request --skill feature-request",{"tool":59,"command":60},"pnpm","pnpm dlx skills add onurmatik\u002Ffeature-request --skill feature-request","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fonurmatik\u002Ffeature-request\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ffeature-request\u002FSKILL.md",true,[64,70],{"path":65,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":68,"sourceHtmlUrl":69},"SOURCE.md","REFERENCE","参考文档",178,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fmevx-trading-agent\u002FSOURCE.md",{"path":71,"resourceType":66,"resourceTypeDesc":67,"sizeBytes":72,"sourceHtmlUrl":73},"TRUST.auto.yaml",2217,"https:\u002F\u002Fgithub.com\u002Fjiayaoqijia\u002Fcryptoskill\u002Fblob\u002Fmain\u002Fskills\u002Ftrading\u002Fmevx-trading-agent\u002FTRUST.auto.yaml",[75,87],{"skillNo":76,"name":5,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":81,"publishedAt":36},"01M6CS6S630MWEQCSJCXRVHPJ4","Operate FeatureRequest projects and evidence-backed request lifecycles through its authenticated MCP tools.","https:\u002F\u002Fgithub.com\u002Fonurmatik\u002Ffeature-request\u002Fblob\u002Fmain\u002Fskills\u002Ffeature-request\u002FSKILL.md",[80],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[24,82,83,84,85,86],"MCP","mcp tools","Tools","projects","evidence",{"skillNo":88,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":89,"categories":90,"keywords":91,"publishedAt":36},"01M6CS6EMBC9DWENV3MT9Y723M","https:\u002F\u002Fgithub.com\u002Fonurmatik\u002Ffeature-request\u002Fblob\u002Fmain\u002FSKILL.md",[],[24]]