[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CS6S630MWEQCSJCXRVHPJ4":3,"skill-same:01M6CS6S630MWEQCSJCXRVHPJ4":58},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":40,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":6,"updatedAt":43,"install":44,"resources":57},"01M6CS6S630MWEQCSJCXRVHPJ4","feature-request",null,"Operate FeatureRequest projects and evidence-backed request lifecycles through its authenticated MCP tools.","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\u002Fskills\u002Ffeature-request\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29],"feature request","MCP","mcp tools","Tools","projects","evidence","2026-11-10 10:12:30",false,"---\nname: feature-request\ndescription: Operate FeatureRequest projects and evidence-backed request lifecycles through its authenticated MCP tools.\n---\n\n# FeatureRequest Operator\n\nUse this skill when the user wants to collect, inspect, triage, update, implement,\nor follow up on requests stored in FeatureRequest.\n\n## Agent Contract Handoff\n\n- This skill is a downstream operational adapter. `agent\u002Fcontract.yaml` is the sole semantic\n  source for tool schemas, scopes, capabilities, ownership, approvals, errors, side effects,\n  idempotency, and retry behavior.\n- Agent Contract 1.1.0 defines `get_account_capabilities` as the implemented bootstrap tool.\n- The repository implements the full 30-tool Contract projection, including public Product Spec\n  reads, owner-controlled spec updates, scope reassessment, and private proposal resolution.\n  MCP production conformance is `pending` until the immutable MCP release and real-client\n  acceptance gates pass; do not present the public service as released before then.\n- The flows below describe the downstream repository adapter and must not reinterpret the Contract.\n\n## Decision Boundary\n\n- FeatureRequest supplies stored facts, deterministic queue signals, similarity evidence,\n  activity events, and controlled mutations.\n- You, the calling agent, decide priority, duplicate equivalence, implementation readiness,\n  and whether delivery evidence proves the requested outcome.\n- Never classify a duplicate solely from a similarity score.\n- Never describe a delivery artifact as verified until you inspect it with the appropriate\n  repository, GitHub, CI, deployment, or release capability.\n- Duplicate and delivery links do not change priority or status automatically.\n\n## Authentication and Scope\n\n- Connect through MCP OAuth discovery. Authorization Code + PKCE S256 is required, CIMD is\n  preferred, and public-client DCR is the controlled fallback.\n- Initial linking requests `read`; mutation tools trigger a `write` step-up challenge.\n- Existing `fr_` FeatureRequest API tokens are for `\u002Fapi` only and are rejected by `\u002Fmcp`.\n- Call `get_account_capabilities` first for capability and project-limit discovery; use\n  `list_projects` when owner or project context is unknown. `get_connection_context` is not exposed.\n- Never expose OAuth access\u002Frefresh tokens, authorization codes, PKCE values, or API tokens.\n\n## Triage Flow\n\n1. Call `get_queue_snapshot` for active requests and deterministic counts\u002Fsignals.\n2. Read relevant requests, comments, activity, and delivery artifacts.\n3. Make and explain your own priority decisions using the user's urgency and impact context.\n4. Use `find_duplicate_candidates` as evidence; inspect plausible requests before linking.\n5. Apply only the explicitly intended mutation and summarize its effect.\n\n## Intake Flow\n\n1. Normalize input into project, issue type, title, description, and current priority.\n2. Search duplicate candidates before creating when enough text is available.\n3. Reuse a canonical request only after semantic comparison; otherwise call `create_request`.\n4. Add useful source or clarification context as a comment when needed.\n\n## Implementation and Delivery Flow\n\n1. Read one ready request and its activity before code changes.\n2. Implement in the coding agent's current repository; FeatureRequest does not edit code.\n3. Run proportionate tests and inspect resulting pull request, commit, deployment, or release.\n4. Call `link_delivery_artifact` to store relevant evidence URLs.\n5. Add a concise result comment when write access is available.\n6. Transition to `done` or `closed` only with explicit user direction and inspected evidence.\n\n## Project Operations\n\n- Use focused `create_project`, `get_project`, and `update_project` tools.\n- `delete_project` is destructive. Call `get_project` first, require explicit user direction,\n  and pass the same id as `confirm_project_id`.\n- Use `get_project_spec` to read the public one-page Product Spec. Use `update_project_spec`\n  only with explicit owner intent and the current independent spec revision.\n- Scope verdicts are evidence, not a replacement for owner judgment. Automatic decline is valid\n  only for an exact `Out of scope` quote with no in-scope contradiction or ambiguity.\n- Failed assessments stay owner-only and fail open. Owners can call `reassess_request_scope`.\n- For a current-revision `spec_gap`, owners may generate a private full-replacement proposal,\n  inspect its deterministic diff, and explicitly accept or reject it. Never expose pending drafts.\n- Only project owners may transition into or out of `declined`; request authors may still comment.\n\n## Follow-up\n\n- Use `list_request_changes` with the last returned cursor for incremental follow-up.\n- Activity begins with the P1 event migration; do not claim it reconstructs pre-P1 history.\n- Surface stale or blocked requests with evidence and a clear next action.\n\n## Intentionally Unsupported MCP Actions\n\n- Token creation or revocation.\n- Billing or checkout.\n- Bulk close or bulk mutation.\n","# FeatureRequest Operator\n\nUse this skill when the user wants to collect, inspect, triage, update, implement,\nor follow up on requests stored in FeatureRequest.\n\n## Agent Contract Handoff\n\n- This skill is a downstream operational adapter. `agent\u002Fcontract.yaml` is the sole semantic\n  source for tool schemas, scopes, capabilities, ownership, approvals, errors, side effects,\n  idempotency, and retry behavior.\n- Agent Contract 1.1.0 defines `get_account_capabilities` as the implemented bootstrap tool.\n- The repository implements the full 30-tool Contract projection, including public Product Spec\n  reads, owner-controlled spec updates, scope reassessment, and private proposal resolution.\n  MCP production conformance is `pending` until the immutable MCP release and real-client\n  acceptance gates pass; do not present the public service as released before then.\n- The flows below describe the downstream repository adapter and must not reinterpret the Contract.\n\n## Decision Boundary\n\n- FeatureRequest supplies stored facts, deterministic queue signals, similarity evidence,\n  activity events, and controlled mutations.\n- You, the calling agent, decide priority, duplicate equivalence, implementation readiness,\n  and whether delivery evidence proves the requested outcome.\n- Never classify a duplicate solely from a similarity score.\n- Never describe a delivery artifact as verified until you inspect it with the appropriate\n  repository, GitHub, CI, deployment, or release capability.\n- Duplicate and delivery links do not change priority or status automatically.\n\n## Authentication and Scope\n\n- Connect through MCP OAuth discovery. Authorization Code + PKCE S256 is required, CIMD is\n  preferred, and public-client DCR is the controlled fallback.\n- Initial linking requests `read`; mutation tools trigger a `write` step-up challenge.\n- Existing `fr_` FeatureRequest API tokens are for `\u002Fapi` only and are rejected by `\u002Fmcp`.\n- Call `get_account_capabilities` first for capability and project-limit discovery; use\n  `list_projects` when owner or project context is unknown. `get_connection_context` is not exposed.\n- Never expose OAuth access\u002Frefresh tokens, authorization codes, PKCE values, or API tokens.\n\n## Triage Flow\n\n1. Call `get_queue_snapshot` for active requests and deterministic counts\u002Fsignals.\n2. Read relevant requests, comments, activity, and delivery artifacts.\n3. Make and explain your own priority decisions using the user's urgency and impact context.\n4. Use `find_duplicate_candidates` as evidence; inspect plausible requests before linking.\n5. Apply only the explicitly intended mutation and summarize its effect.\n\n## Intake Flow\n\n1. Normalize input into project, issue type, title, description, and current priority.\n2. Search duplicate candidates before creating when enough text is available.\n3. Reuse a canonical request only after semantic comparison; otherwise call `create_request`.\n4. Add useful source or clarification context as a comment when needed.\n\n## Implementation and Delivery Flow\n\n1. Read one ready request and its activity before code changes.\n2. Implement in the coding agent's current repository; FeatureRequest does not edit code.\n3. Run proportionate tests and inspect resulting pull request, commit, deployment, or release.\n4. Call `link_delivery_artifact` to store relevant evidence URLs.\n5. Add a concise result comment when write access is available.\n6. Transition to `done` or `closed` only with explicit user direction and inspected evidence.\n\n## Project Operations\n\n- Use focused `create_project`, `get_project`, and `update_project` tools.\n- `delete_project` is destructive. Call `get_project` first, require explicit user direction,\n  and pass the same id as `confirm_project_id`.\n- Use `get_project_spec` to read the public one-page Product Spec. Use `update_project_spec`\n  only with explicit owner intent and the current independent spec revision.\n- Scope verdicts are evidence, not a replacement for owner judgment. Automatic decline is valid\n  only for an exact `Out of scope` quote with no in-scope contradiction or ambiguity.\n- Failed assessments stay owner-only and fail open. Owners can call `reassess_request_scope`.\n- For a current-revision `spec_gap`, owners may generate a private full-replacement proposal,\n  inspect its deterministic diff, and explicitly accept or reject it. Never expose pending drafts.\n- Only project owners may transition into or out of `declined`; request authors may still comment.\n\n## Follow-up\n\n- Use `list_request_changes` with the last returned cursor for incremental follow-up.\n- Activity begins with the P1 event migration; do not claim it reconstructs pre-P1 history.\n- Surface stale or blocked requests with evidence and a clear next action.\n\n## Intentionally Unsupported MCP Actions\n\n- Token creation or revocation.\n- Billing or checkout.\n- Bulk close or bulk mutation.\n",{"name":5,"description":7},"main","259333d4024b6b981659ebab9e6dfcb9a0e45e19","skills\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":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add onurmatik\u002Ffeature-request --skill feature-request",{"tool":50,"command":51},"bunx","bunx skills add onurmatik\u002Ffeature-request --skill feature-request",{"tool":53,"command":54},"pnpm","pnpm dlx skills add onurmatik\u002Ffeature-request --skill feature-request","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fonurmatik\u002Ffeature-request\u002Fblob\u002Fmain\u002Fskills\u002Ffeature-request\u002FSKILL.md",true,[],[59,64],{"skillNo":60,"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":61,"categories":62,"keywords":63,"publishedAt":30},"01M6CS6EMBC9DWENV3MT9Y723M","https:\u002F\u002Fgithub.com\u002Fonurmatik\u002Ffeature-request\u002Fblob\u002Fmain\u002FSKILL.md",[],[24],{"skillNo":65,"name":5,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":70,"publishedAt":30},"01M6CS6BZ9K96YQJKQX696XSSH","Manage feature request intake, normalization, triage, queue operations, and API-only lifecycle workflows.","https:\u002F\u002Fgithub.com\u002Fonurmatik\u002Ffeature-request\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ffeature-request\u002FSKILL.md",[69],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[24,71,72,73,74,75,76,77,78,79,80,81],"triage","workflows","intake","lifecycle","api","normalization","request intake","operations","only","queue","manage"]