managing-practitest

name	managing-practitest
description	Use when working with Practitest — practiTest test management platform monitoring and analysis. Covers project organization, test library management, test set and run execution, requirement traceability, issue tracking, custom field analysis, and dashboard metrics. Use when managing test cases in PractiTest, reviewing execution results, or tracking QA coverage and traceability.
connection_type	practitest
preload	false

PractiTest Test Management Skill

Manage and analyze PractiTest projects, test libraries, runs, and traceability.

Core Helper Functions

#!/bin/bash

# PractiTest API helper
practitest_api() {
    local method="${1:-GET}"
    local endpoint="$2"
    local data="${3:-}"

    if [ -n "$data" ]; then
        curl -s -X "$method" \
            -H "Authorization: custom ${PRACTITEST_API_TOKEN}" \
            -H "Content-Type: application/json" \
            "https://api.practitest.com/api/v2/${endpoint}" \
            -d "$data"
    else
        curl -s -X "$method" \
            -H "Authorization: custom ${PRACTITEST_API_TOKEN}" \
            "https://api.practitest.com/api/v2/${endpoint}"
    fi
}

MANDATORY: Discovery-First Pattern

Always discover projects and test libraries before querying specifics.

Phase 1: Discovery

#!/bin/bash

echo "=== PractiTest Projects ==="
practitest_api GET "projects.json" | jq -r '
    .data[] | "\(.id)\t\(.attributes.name)\tstatus=\(.attributes.status)"
' | column -t | head -15

echo ""
echo "=== Test Libraries ==="
PROJECT_ID="${1:?Project ID required}"
practitest_api GET "projects/${PROJECT_ID}/tests.json?page[number]=1&page[size]=20" | jq -r '
    .data[] | "\(.id)\t\(.attributes.name)\tstatus=\(.attributes.status)\tpriority=\(.attributes.priority // "none")"
' | column -t

echo ""
echo "=== Test Sets ==="
practitest_api GET "projects/${PROJECT_ID}/sets.json?page[number]=1&page[size]=15" | jq -r '
    .data[] | "\(.id)\t\(.attributes.name)\tstatus=\(.attributes.status)"
' | column -t

echo ""
echo "=== Requirements ==="
practitest_api GET "projects/${PROJECT_ID}/requirements.json?page[number]=1&page[size]=10" | jq -r '
    .data[] | "\(.id)\t\(.attributes.name)\tstatus=\(.attributes.status)"
' | column -t

Phase 2: Analysis

#!/bin/bash

PROJECT_ID="${1:?Project ID required}"

echo "=== Run Instances ==="
SET_ID="${2:-}"
if [ -n "$SET_ID" ]; then
    practitest_api GET "projects/${PROJECT_ID}/instances.json?set-ids=${SET_ID}&page[size]=20" | jq -r '
        .data[] | "\(.id)\ttest=\(.attributes.test-id)\tstatus=\(.attributes.run-status)\tlast_run=\(.attributes.last-run-date // "never")"
    ' | column -t | head -15
fi

echo ""
echo "=== Recent Runs ==="
practitest_api GET "projects/${PROJECT_ID}/runs.json?page[number]=1&page[size]=10" | jq -r '
    .data[] | "\(.id)\tinstance=\(.attributes.instance-id)\tstatus=\(.attributes.status)\tdate=\(.attributes.created-at | split("T")[0])"
' | column -t

echo ""
echo "=== Issues ==="
practitest_api GET "projects/${PROJECT_ID}/issues.json?page[number]=1&page[size]=10" | jq -r '
    .data[] | "\(.id)\t\(.attributes.name)\tseverity=\(.attributes.severity // "none")\tstatus=\(.attributes.status)"
' | column -t

echo ""
echo "=== Traceability ==="
echo "Requirements linked to tests:"
practitest_api GET "projects/${PROJECT_ID}/requirements.json?page[size]=10" | jq -r '
    .data[] | "\(.id)\t\(.attributes.name)\tlinked_tests=\(.attributes["linked-tests-count"] // 0)"
' | column -t | head -10

Output Rules

• TOKEN EFFICIENCY: Target 50 lines per output
• Use JSON:API pagination (page[number], page[size])
• Summarize traceability links, not full test step details

Anti-Hallucination Rules

• NEVER guess project or test IDs — always discover via API
• NEVER fabricate run results — query actual PractiTest data
• NEVER assume custom field names — check project configuration

Safety Rules

• NEVER create or delete test sets without explicit user confirmation
• NEVER modify test status without user approval
• NEVER delete issues without user consent

Output Format

Present results as a structured report:

Managing Practitest Report
══════════════════════════
Resources discovered: [count]

Resource       Status    Key Metric    Issues
──────────────────────────────────────────────
[name]         [ok/warn] [value]       [findings]

Summary: [total] resources | [ok] healthy | [warn] warnings | [crit] critical
Action Items: [list of prioritized findings]

Target ≤50 lines of output. Use tables for multi-resource comparisons.

Counter-Rationalizations

Shortcut	Counter	Why
"I'll skip discovery and check known resources"	Always run Phase 1 discovery first	Resource names change, new resources appear — assumed names cause errors
"The user only asked for a quick check"	Follow the full discovery → analysis flow	Quick checks miss critical issues; structured analysis catches silent failures
"Default configuration is probably fine"	Audit configuration explicitly	Defaults often leave logging, security, and optimization features disabled
"Metrics aren't needed for this"	Always check relevant metrics when available	API/CLI responses show current state; metrics reveal trends and intermittent issues
"I don't have access to that"	Try the command and report the actual error	Assumed permission failures prevent useful investigation; actual errors are informative