Skills
skills/skill.new.ndhy.com/pms-issue-viewer

pms-issue-viewer

SKILL.md

PMS Issue Viewer

Fetch/create PMS issues with the signed-header scheme:

PMS OpenAPI response note (important):

  • Swagger may show endpoint-level response directly, but actual runtime response is wrapped:
{
  "success": true,
  "message": null,
  "data": <swagger-defined-response>
}

  • Always read business payload from data.

  • accessKey

  • signature = AES-CBC-PKCS7(Base64(accessKey|uuid|timestamp), key=secretKey, iv=accessKey)

Workflow

A) View existing issue

  1. Get the target issueId from the user.
  2. Use scripts/fetch_pms_issue.py.
  3. Prefer environment variables for credentials instead of hardcoding secrets.
  4. When the user wants local files, run with --archive and save under buglist/<issueId>/.
  5. Return a short summary first:
    • title
    • status
    • issue number / id
    • key description points
    • latest useful comments / assignments
    • extracted links from the description and comments, especially log / attachment links
  6. Important attachment rule:
    • issue attachments may not appear in description/comment links alone
    • when archiving, also call POST /attachment/metadata/list with belongType=issue and belongId=<issueId>
    • this endpoint also uses the AK/SK signed-header scheme
    • then download attachment content from the returned filePath values separately
  7. Use --raw only when the user wants full JSON.

B) Create new issue

  1. Collect title and description from the user.
  2. Use scripts/create_pms_issue.py.
  3. Pass projectId, processor, and creator explicitly via environment variables or command-line flags; do not rely on hardcoded internal defaults.
  4. Pass optional fields only when the user provides them (or when local environment variables already define them).
  5. Return the created issueId clearly in the first line of the response.

C) Comment existing issue

  1. Use scripts/comment_pms_issue.py to append follow-up notes to an existing issue.
  2. Use the AK/SK signed-header scheme for this endpoint as well.
  3. Prefer the user's personal PMS credentials from environment variables; do not fall back to shared/demo credentials.
  4. Use payload field issuesId (not issueId) when posting comments.
  5. Validate returned data.issueId equals requested issueId; if mismatch/null, treat as failed binding.
  6. Mandatory rule: if a bug is tracked by creating a GitHub issue, append the GitHub issue URL back to the PMS issue as a comment.
  7. Mandatory rule: when sharing issue progress or a final conclusion, include the PMS issue link in the user reply and mirror the conclusion back into PMS unless the user says not to.
  8. Return issueId + comment status in the first line.

D) Assign existing issue

  1. Collect issueId and target assignee (member id).
  2. Use scripts/assign_pms_issue.py.
  3. Endpoint and payload contract:
    • POST /issues/tools/assign
    • pass projectId explicitly
    • provide assign field IDs via environment variables or command-line flags
  4. Use the AK/SK signed-header scheme for this endpoint as well.
  5. Return issueId + assign status in the first line.

E) Resolve existing issue

  1. Collect issueId and resolution reason/comment from the user.
  2. Use scripts/resolve_pms_issue.py.
  3. Pass projectId, processor, and resolve field IDs explicitly via environment variables or command-line flags; do not rely on hardcoded internal defaults.
  4. Before resolving, prefer checking the field template once with scripts/get_issue_field_template.py when the solution enum is unclear.
  5. Default solution rule:
    • use fixed for normal “已解决” bug-fix completion
    • use invalid only when the user explicitly means “无效BUG”
  6. Use the AK/SK signed-header scheme for this endpoint as well.
  7. Return issueId + resolved status in the first line.

F) Get field template / enum values

  1. Use scripts/get_issue_field_template.py to fetch project field template data.
  2. Use the AK/SK signed-header scheme for this endpoint as well.
  3. Pass projectId explicitly via environment variables or command-line flags.
  4. Use this data before create/resolve flows when enum values are unclear.

Security notes

  • Never hardcode real PMS_ACCESS_KEY / PMS_SECRET_KEY into the skill files.
  • Prefer environment variables over command-line flags for secrets, to avoid leaking them into shell history, logs, screenshots, or copied commands.
  • Before publishing or sharing the skill, remove local cache files such as __pycache__/ and *.pyc.

Run the script

From the skill directory:

python3 scripts/fetch_pms_issue.py <issueId>

Or pass parameters explicitly:

python3 scripts/fetch_pms_issue.py <issueId> \
  --access-key '...' \
  --secret-key '...' \
  --project-id '...' \
  --workspace-id '...'

Archive the bug locally:

python3 scripts/fetch_pms_issue.py <issueId> \
  --access-key '...' \
  --secret-key '...' \
  --project-id '...' \
  --workspace-id '...' \
  --archive

Create a new issue:

PMS_BASE_URL='https://your-pms-host' \
PMS_CREATE_PROJECT_ID='your-project-id' \
PMS_CREATE_PROCESSOR='your-processor-id' \
PMS_CREATE_CREATOR='your-creator-id' \
python3 scripts/create_pms_issue.py \
  --title '标题' \
  --description '描述'

Create with optional fields:

python3 scripts/create_pms_issue.py \
  --title '标题' \
  --description '描述' \
  --platform 1 \
  --stage 2 \
  --severity 'S2' \
  --type '功能缺陷' \
  --source 2 \
  --priority 2 \
  --difficulty 1 \
  --department 4 \
  --discovery-probe 1 \
  --cc-json '["120905","xxx"]' \
  --affected-versions-json '[]'

Comment issue (append progress / GitHub links):

python3 scripts/comment_pms_issue.py \
  --issue-id '2c5396b4-6e24-462b-a0bc-57359c0e7a66' \
  --comment 'GitHub issue: https://github.com/ndhy-component-h5/virtual-anchor-control-js/issues/38' \
  --access-key '...' \
  --secret-key '...'

Assign issue (set assignee and optional cc):

PMS_BASE_URL='https://your-pms-host' \
PMS_CREATE_PROJECT_ID='your-project-id' \
PMS_ASSIGN_ASSIGNEE_FIELD_ID='your-assignee-field-id' \
PMS_ASSIGN_CC_FIELD_ID='your-cc-field-id' \
python3 scripts/assign_pms_issue.py \
  --issue-id '36842405-5fce-4d27-990b-728a46ed4b18' \
  --assignee '619973' \
  --cc-json '[]' \
  --comment '请协助确认接口返回'

Resolve issue (set to resolved):

PMS_BASE_URL='https://your-pms-host' \
PMS_CREATE_PROJECT_ID='your-project-id' \
PMS_CREATE_PROCESSOR='your-processor-id' \
PMS_RESOLVE_FIELD_SOLUTION='your-solution-field-id' \
PMS_RESOLVE_FIELD_DUPLICATE_ID='your-duplicate-id-field-id' \
PMS_RESOLVE_FIELD_RESOLVED_VERSION='your-resolved-version-field-id' \
PMS_RESOLVE_FIELD_ASSIGNEE='your-assignee-field-id' \
PMS_RESOLVE_FIELD_MISS_OWNER='your-miss-owner-field-id' \
PMS_RESOLVE_FIELD_MISS_SOURCE='your-miss-source-field-id' \
PMS_RESOLVE_FIELD_BUG_OWNER='your-bug-owner-field-id' \
PMS_RESOLVE_FIELD_DEV_OWNER='your-dev-owner-field-id' \
PMS_RESOLVE_FIELD_STATUS='your-status-field-id' \
python3 scripts/resolve_pms_issue.py \
  --issue-id '1719e9fb-ca88-4db0-937a-8f26d6549f6c' \
  --comment '已解决：补充修复说明' \
  --solution fixed

Get issue field template/enums:

python3 scripts/get_issue_field_template.py \
  --project-id 'your-project-id' \
  --with-empty-option false

This creates:

  • buglist/<issueId>/issue-detail.json
  • buglist/<issueId>/issue-comments.json
  • buglist/<issueId>/summary.json
  • buglist/<issueId>/issue-description.md
  • buglist/<issueId>/issue-comments.md
  • buglist/<issueId>/attachments/
  • buglist/<issueId>/attachments.json

Archive flow note:

  • fetch_pms_issue.py --archive now combines two attachment sources:
    • links extracted from description/comments
    • attachment metadata returned by POST /attachment/metadata/list
  • prefer the metadata API when QA says they re-uploaded logs but the text comments do not contain direct download links.

If an attachment filename ends with .zip, the script auto-extracts it into:

  • buglist/<issueId>/attachments/<zip-file-name-without-extension>/

References

  • OpenAPI definition snapshot: references/openapi.json

Configuration

Read references/config-example.md for the supported environment variables and a shell example.

Output guidance

When summarizing results for the user:

  • Lead with whether the request succeeded.
  • For create/assign/resolve/comment flows, put issueId and action status on the first line.
  • Include the PMS issue link in user-facing replies whenever an issueId is known.
  • For create flow, then echo title and key fields used.
  • If a corresponding GitHub bug issue is created, append that GitHub URL back to PMS via comment_pms_issue.py and report comment status.
  • Surface the issue title, current status, and processor if available.
  • Pull out the most relevant comments rather than dumping everything.
  • Extract links from the description and comments and list important ones under key information.
  • Prioritize log, download, attachment, and evidence links when present.
  • When --archive is used, mention the local directory path and what was saved there.
  • If a .zip attachment was downloaded, mention the auto-extracted directory path too.
  • The extractor skips re-extracting when the target directory already has files, and records extracted file counts plus sample paths.
  • For known top-level log folders, include local repo mappings in the extracted summary:
    • VirtualAnchorControl -> workspace repo virtual-anchor-control
    • Electron -> workspace repo virtual-anchor-control-js
  • Add repoInvestigationHints to the archive result so the user can see which local repo to inspect first.
  • Default priority rule: prefer Electron first; only prefer VirtualAnchorControl when the issue text clearly points to event-editor-related investigation.
  • When Electron logs include filenames like main-1.0.<pack-date>.<git-hash>-<log-time>.log, extract the git hash and suggest checking out that hash first in virtual-anchor-control-js.
  • Assume the Electron log git hash usually corresponds to the master branch history unless the user says otherwise.
  • Include ready-to-run git commands in the Electron investigation hint, such as checking master history first and then git checkout <hash>.
  • Check whether the hash is already visible in local master history; if not, suggest git fetch --all --tags before retrying.
  • For large attachments, prefer the archive flow with long timeouts; the downloader now resumes partial .part files and retries interrupted downloads.
  • Mention if the API returned HTTP errors or authentication failures.
  • Avoid repeating secrets back to the user unless explicitly requested.
Installs
2
Source
skill.new.ndhy.…e-viewer
First Seen
Mar 27, 2026