Creating Pds Issues

Parent Issue Identification:

The parent can be specified as:

• Issue URL: https://github.com/NASA-PDS/repo/issues/123
• Short reference: #123 (current repo) or NASA-PDS/repo#123 (cross-repo)
• Search terms: "the registry theme" or "authentication epic"

If the parent is ambiguous, search for it:

# Search for potential parent issues by title
gh issue list --repo NASA-PDS/<repo> --search "theme OR epic" --label "theme,Epic" --limit 10

Then confirm with the user which parent issue to use.

1. Gather Information

Detect Current Repository (if applicable):

If the user is running this skill from within a cloned git repository, automatically detect the repository name:

# Check if in a git repo - try origin first, then upstream
git remote get-url origin 2>/dev/null || git remote get-url upstream 2>/dev/null

If the remote URL matches NASA-PDS/<repo-name>, use that as the default repository.

Edge Cases:

• Multiple remotes: Prefer origin first, then fall back to upstream or other NASA-PDS remotes
• Forks: If the detected repository is a fork (personal namespace), check for an upstream remote pointing to NASA-PDS
• Non-NASA-PDS repos: If no NASA-PDS remote is found, ask the user which repository to use
• Ambiguous remotes: If multiple NASA-PDS remotes exist, ask the user to clarify

Determine Issue Type:

Ask the user what type of issue to create using the AskUserQuestion tool with these options:

• Bug Report - Report defects or unexpected behavior
• I&T Bug Report - Internal Integration & Test bug report (requires test case references)
• Feature Request - Propose new features or enhancements
• Task - Internal development task (often sub-tasks of larger stories)
• Vulnerability - Security vulnerabilities or threats
• Release Theme - High-level epic for release planning

Gather Template-Specific Information:

Then gather the required information based on the template type:

For Bug Reports:

• Repository name (auto-detect from git remote, or ask if not in a repo or unclear)
• Brief title following format: <system feature> <is not/does not> <expected behaviour>
• Bug description (what happened)
• Expected behavior (what should have happened)
• Steps to reproduce (numbered list)
• Environment info (version, OS, etc.)

For I&T Bug Reports:

• Repository name (auto-detect from git remote, or ask if not in a repo or unclear)
• Brief title following format: <system feature> <is not/does not> <expected behaviour>
• Bug description (what happened)
• Expected behavior (what should have happened)
• Related test cases (TestRail or other test case references - REQUIRED)
• Steps to reproduce (numbered list)
• Environment info (version, OS, etc.)

For Feature Requests:

• Repository name (auto-detect from git remote, or ask if not in a repo or unclear)
• User story title: As a <role>, I want to <accomplish>
• User persona (e.g., "Data Engineer", "Node Operator")
• Motivation (why is this needed?)
• Additional context

For Tasks:

• Repository name (auto-detect from git remote, or ask if not in a repo or unclear)
• Task type (sub-task or theme)
• Description (clear but not excessive)

For Vulnerabilities:

• Repository name (auto-detect from git remote, or ask if not in a repo or unclear)
• Title: <system feature> <is not/does not> <expected behaviour>
• Vulnerability description
• Expected secure behavior
• Reproduction steps
• Environment info

For Release Themes:

• Repository name (auto-detect from git remote, or ask if not in a repo or unclear)
• Description of the release theme

2. Fill the Template

Use the cached templates in resources/templates/ directory. If templates are not cached, run the caching script first:

cd creating-pds-issues
node scripts/cache-templates.mjs

Fill templates with these guidelines:

Content Style:

• Be clear and specific, but concise
• Avoid unnecessary elaboration or "novel-length" descriptions
• Use bullet points and numbered lists for clarity
• Include only essential technical details
• Skip optional fields unless user provides information

Security and Privacy - CRITICAL:

• Remove or sanitize all sensitive information before creating the issue
• Replace actual file paths with generic examples (e.g., /Users/john/secrets/api-keys.txt → /path/to/file.txt)
• Remove usernames, email addresses, and personal identifiers
• Replace IP addresses with dummy values (e.g., 192.168.1.100 → 10.0.0.1)
• Strip API keys, tokens, passwords, and credentials
• Sanitize database connection strings and internal URLs
• Use placeholder hostnames (e.g., prod-server-01.internal.nasa.gov → server.example.com)
• Remove proprietary or confidential information
• If uncertain whether information is sensitive, ASK THE USER before including it

Required Field Examples:

Bug description (good):

When validating a PDS4 label with nested tables, the validator throws a NullPointerException
on line 342 of TableValidator.java. This occurs with labels containing 3+ nested table
definitions.

Bug description (too verbose):

I was working on my project late last night and I noticed that when I tried to validate
my carefully crafted PDS4 label that I had been working on for several days, the system
unexpectedly threw an error. I had been following all the documentation...
[continues for several paragraphs]

Expected behavior (good):

Validator should successfully validate labels with nested tables or provide a clear
error message about nesting limitations.

Reproduction steps (good):

1. Create PDS4 label with 3 nested <Table_Delimited> elements
2. Run: validate my-label.xml
3. Observe NullPointerException in output

Feature motivation (good):

...so that I can validate labels in CI/CD pipelines without manual intervention,
reducing deployment time from hours to minutes.

Sanitization Examples:

Before (UNSAFE - contains sensitive info):

When I run the validator on /Users/alice.johnson/Documents/NASA/mission-data/secret-project/labels/experiment-123.xml
using the API key sk-1234567890abcdef, it fails to connect to the database at