{"slug":"project-discovery","title":"project-discovery","summary":"Onboard a project through four discovery phases: Constitution, Architecture, Infrastructure, and Specification. Produces PRD, SRS, domain glossary, infrastructure context, and backlog access, then hands business maps and the master test plan to `project-context`. Use for set up t","platform":"Claude","tags":[],"authorName":"LLM Mart","authorSlug":"llm-mart","score":0,"source":"github","price":null,"verified":false,"createdAt":"2026-08-25T15:20:13.109785Z","repo":{"url":"https://github.com/upex-galaxy/agentic-qa-boilerplate","stars":22,"forks":13,"license":"MIT","updatedAt":"2026-09-23T10:18:12Z"},"bodyHtml":"
\n

name: project-discovery\ndescription: \"Onboard a project through four discovery phases: Constitution, Architecture, Infrastructure, and Specification. Produces PRD, SRS, domain glossary, infrastructure context, and backlog access, then hands business maps and the master test plan to project-context. Use for set up this project, onboard this repo, connect to project, discover architecture, or create PRD/SRS. Do NOT use for incremental context refresh (project-context), writing tests, TMS documentation, running suites, adapting KATA (adapt-framework), or technical OpenAPI sync (bun run api:sync).\"\nlicense: MIT\ncompatibility: [claude-code, copilot, cursor, codex, opencode]\ncomplementary_categories: [meta-skill]

\n

Project Discovery — Onboarding Orchestrator

\n

Turn an unknown codebase into a testable project. Four phases, always in order, gated on completion of the previous one. The output is a set of context files the rest of the skills (shift-left-testing, sprint-testing, test-automation, test-documentation, regression-testing) rely on.

\n

The discovery is conversational: you read the code, ask when ambiguous, confirm before writing files. Never fabricate -- if you cannot verify a claim from the source, mark it as a \"Discovery Gap\" and move on.

\n

Grounding methodology: IQL (Integrated Quality Lifecycle) — QA is continuous from requirement to release, not a gate at the end. The full rationale and step breakdown live in docs/methodology/IQL-methodology.md (shared across all QA skills). This skill does not depend on reading it — only point the user there if they ask why the discovery is structured this way.

\n
\n

Inputs

\n

Canonical reading order when starting cold on a discovery run. Read in order; stop earlier when the scope is small enough that later inputs add no signal.

\n
    \n
  1. Target project repo — path resolved at session start (see \"Before starting: target repo location\" below). Read code and any in-repo PRD. This is the primary source of truth — discovery is reverse-engineering, never aspirational design.
    2. \n
  2. Target repo's README.md and existing onboarding docs — fastest path to project intent, stack signals, and run commands before deep code reads.
    3. \n
  3. .context/ directory (if partial state exists from a prior discovery run) — informs Phase 0 resume decisions and prevents redundant work. Diff against current code before overwriting.
    4. \n
  4. .agents/project.yaml and .env.example — variable resolution patterns ({{PROJECT_KEY}}, env URLs, MCP names) that every downstream context file references.
    5. \n
  5. kata-manifest.json — registry of existing KATA Components + ATCs. Anchors what test surface the boilerplate already expects so discovery records gaps coherently.
    6. \n
  6. .agents/skills/agentic-qa-core/references/skill-composition-strategy.md — workflow context for downstream handoffs (project-context, adapt-framework, sprint-testing, test-documentation).
    7. \n
  7. Business / domain docs supplied by the user (Confluence, Notion exports, internal wikis) — secondary source for business model and glossary when in-repo signal is thin.
    8. \n
\n
\n

Subagent Dispatch Strategy

\n
\n

Orchestration & Session contracts: this skill follows agentic-qa-core/references/orchestration-doctrine.md (mandatory subagent dispatch — main thread is command center) AND agentic-qa-core/references/session-management.md (Phase 0 resume check, plan-first persistence at .session/<skill-slug>/<scope>/, archive on completion). Phase 0 (resume check) and Phase 1 (plan write) are NOT optional.

\n
\n

This skill is project-scope: no <scope> segment. Session state lives directly at .session/project-discovery/{plan.md, progress.md} per agentic-qa-core/references/session-management.md §3 + §9. This is the longest skill in the QA repo (1.5–4 hours, 4 hard-gate phases) and benefits most from per-phase checkpoints: if interrupted between Phase 2 (PRD/SRS) and Phase 3 (Infrastructure), resume reads progress.md and skips back to the first incomplete phase without re-prompting the user for already-confirmed scope.

\n

This skill is compliant with the doctrine in AGENTS.md §\"Orchestration Mode (Subagent Strategy)\" and the session contract in .agents/skills/agentic-qa-core/references/session-management.md. Per-phase dispatch decisions live in Pick the scope first below: Fresh = heavy subagent delegation per phase; Boilerplate adoption = medium; Brownfield + Context refresh = main session only.

\n
\n

Phase 0 — Session resume check (MANDATORY, inline)

\n

Before scope selection or any target-repo discovery, run the resume contract from agentic-qa-core/references/session-management.md §4:

\n
    \n
  1. Check .session/project-discovery/progress.md.
    2. \n
  2. If it does NOT exist → proceed to \"Before starting: target repo location\" below, then \"Pick the scope first\" (which writes plan.md).
    3. \n
  3. If it DOES exist:\n\n
    4. \n
\n

Resume is high-value here: Fresh onboarding (1.5–4h) crossing a session boundary without resume re-runs Phase 1 from scratch, re-prompting target paths the user already confirmed.

\n
\n

Before starting: target repo location

\n

/project-discovery runs read-only against a project under test — the target repo — that is NOT this boilerplate. Before Phase 1 starts, lock down where the target lives. Block Phase 1 if the target path is ambiguous.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
LayoutWhat to declareHow to detect
Monorepo (single repo contains FE + BE)Absolute or relative path from this repoCheck the candidate path for pnpm-workspace.yaml, turbo.json, nx.json, lerna.json, or a top-level package.json with no deps of its own
Split sibling repos (FE and BE cloned separately)One path per repo (or a common parent dir)Look at ../-level siblings with plausible names (*-backend, *-frontend, *-api, *-web); confirm with the user
Remote (not cloned yet)Repo URL + branch, then ask the user to clone locally before Phase 1gh repo view only returns metadata; real discovery needs local file access — do not try to discover from a URL
\n

Record the resolved path(s) in .context/project-config.md §Repositories during Phase 1 sub-step 1 (Project Connection). Every <target-repo> reference in later phases resolves to the path declared here.

\n

If the layout is \"split sibling repos\", run Phase 1 sub-steps once per repo and merge findings into a single project-config.md; do not interleave.

\n
\n

Pick the scope first

\n

All projects go through the same 4 phases, but depth varies. Pick once, then follow the common pipeline.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
ScenarioInputPhases to runTypical depthContext weight & subagent hint
Fresh onboarding (greenfield or unseen project)Repo URL or local path(s), no existing context files1 -> 2 -> 3 -> 4, then project-context refresh-allFull discovery. Business maps and test strategy are generated by their dedicated skill. After context completion, run adapt-framework.Heavy. Delegate each phase's code survey to a dedicated subagent.
Boilerplate adoption (this repo adopted for a new project)Target app repo(s), this repo as the test framework1 (project-connection) -> 3, then project-context for missing mapsSkip Phase 2 or 4 only when their required artifacts already exist. Verify files on disk before adapt-framework.Medium. Delegate Phase 1 and Phase 3 per package for monorepos.
Brownfield (project already documented, tests missing)Existing .context/ partially filled2 (gaps) -> 3 (gaps) -> 4 (gaps), then project-context for stale mapsFill discovery gaps here; refresh map artifacts in their owning skill.Light. Main session unless gaps span many files.
Context refreshUser asks to regenerate a business map or master test planRedirect to the matching project-context modeThis skill does not refresh those artifacts. For PBI access changes, re-run Phase 4. For exact OpenAPI types, use bun run api:sync.Minimal. Handoff only.
\n

Default to \"Fresh onboarding\" when in doubt. Confirm the scope with the user before starting Phase 1.

\n

After scope confirmation, write .session/project-discovery/plan.md per agentic-qa-core/references/session-management.md §6. The phase breakdown ends at Phase 4; record project-context refresh-all as the post-discovery handoff, not as a discovery phase.

\n
\n

Workflow — the 4-phase pipeline

\n
Phase 1: Constitution        -> Phase 2: Architecture       -> Phase 3: Infrastructure    -> Phase 4: Specification\n(who/what/why)                 (PRD + SRS)                    (backend/frontend/infra)       (PBI mapping)\n                |                      |                              |                              |\n   .context/business/            .context/PRD/*.md           .context/infrastructure/*.md     .context/PBI/ACCESS.md\n   business-model.md            .context/SRS/*.md\n   domain-glossary.md\n   project-config.md\n\n                                                 |\n                                                 v\n                                    project-context (separate skill)\n                                    data -> features -> api -> test-plan\n                                    `bun run api:sync` remains the technical\n                                    OpenAPI type pipeline.\n
\n
\n

KATA adaptation is a separate skill: adapt-framework. It runs after discovery and context outputs exist.

\n
\n

Each phase has a completion gate: before moving on, the required output files must exist on disk with non-placeholder content. Ask the user to confirm after each phase; never auto-chain.

\n

Phase 1 — Constitution (who, what, why)

\n

Goal: make the project legible. Outputs are read by every future session.

\n

Four sub-steps, in order:

\n
    \n
  1. Project Connection -- repo paths, tech stack detection, environment URLs, credentials from .env, team contacts.
    2. \n
  2. Project Assessment -- current testing maturity (frameworks in place, CI presence, lint/typecheck, coverage). Produces a risk profile.
    3. \n
  3. Business Model Discovery -- problem statement, target users, value proposition, revenue model (if any). Business Model Canvas recommended.
    4. \n
  4. Domain Glossary -- core entities, relationships, state machines, enumerations, UI-label vs code-identifier mapping.
    5. \n
\n

Completion gate: .context/business/business-model.md, .context/business/domain-glossary.md, .context/project-config.md all exist and are non-empty. Plus a ## Project Assessment (Phase 1) block in canonical AGENTS.md. Sanity-check content — these are soft gates, surfaced to the human as warnings, not hard aborts:

\n\n

After the automated sanity check, show the human the output paths and wait for explicit \"Phase 1 complete, continue\" before moving on.

\n

Read references/phase-1-constitution.md when running any Phase 1 sub-step. Contains the discovery process, stack-detection commands, required output sections, and quality checklists.

\n

Phase 2 — Architecture (PRD + SRS)

\n

Goal: produce the Product and Software Requirements docs from code (not the other way round -- that is the \"creation\" direction, this is the \"discovery\" direction).

\n

PRD sub-steps (run first, in parallel or sequentially — user choice):

\n
    \n
  1. Executive Summary -- problem, solution, success metrics, scope.
    2. \n
  2. User Personas -- roles, permissions, primary/secondary users, role hierarchy.
    3. \n
  3. User Journeys -- critical paths through the UI, route map, journey diagrams.
    4. \n
\n
\n

Feature catalog is post-discovery. project-context mode features owns .context/business/business-feature-map.md. Do not generate it here.

\n
\n

SRS sub-steps (run after PRD, serially):

\n
    \n
  1. Architecture Specs -- C4 context and container diagrams, component structure, database schema, external services, security model.
    2. \n
  2. Functional Specs -- FR-N entries with preconditions, business rules, validations, state machines.
    3. \n
  3. Non-Functional Specs -- performance budgets, security posture, reliability (RTO/RPO), scalability, observability, compliance.
    4. \n
\n
\n

API contracts are NOT an SRS output. The technical surface is owned by bun run api:sync; the business angle is owned by project-context mode api. Phase 2 records only the spec location or a Discovery Gap.

\n
\n
\n

Test-architecture ADR seeding (Phase 2 SRS + Phase 3). When the Architecture Specs / Infrastructure sub-steps settle a hard-to-reverse test-architecture decision — test runner/framework, isolation & parallelization model, fixture/test-data strategy, auth-in-tests, selector/data-testid contract, exploratory-vs-scripted boundary, CI sharding — promote each one that passes the two-gate test (architectural AND hard to reverse) to a standalone ADR-NNNN-<slug>.md in .context/ADR/, and reference it from architecture.md / infrastructure/. Greenfield: you are ENCODING the decision; brownfield: you are RECORDING the one you discovered. Follow agentic-qa-core/references/adr-doctrine.md (detection + authoring) and .context/ADR/README.md (template + lifecycle). AI drafts Proposed; the human accepts.

\n
\n

Completion gate: .context/PRD/executive-summary.md, user-personas.md, user-journeys.md, .context/SRS/architecture.md, functional-specs.md, non-functional-specs.md all exist. API contract source is recorded in .context/project-config.md. business-feature-map.md remains a post-discovery project-context output. Soft content checks:

\n\n

Show outputs to the human and wait for \"Phase 2 complete, continue\" before moving on.

\n

Read references/phase-2-prd.md when working on any PRD doc. Read references/phase-2-srs.md when working on any SRS doc. They are independent -- do not load both unless you are straddling both sides.

\n

Phase 3 — Infrastructure

\n

Goal: make the project runnable and deployable for the test environment.

\n

Three sub-steps:

\n
    \n
  1. Backend Discovery -- language, framework, database, ORM, auth, dependency manager, run/test commands, migrations, env vars.
    2. \n
  2. Frontend Discovery -- framework, bundler, routing, state management, design system, component library, test IDs strategy.
    3. \n
  3. Infrastructure Mapping -- CI/CD providers, deployment targets, environments (dev/staging/prod), infra-as-code, monitoring, rollback procedure.
    4. \n
\n

Completion gate: .context/infrastructure/backend.md, frontend.md, infrastructure.md all exist with the key facts (auth flow, test commands, deploy URLs) filled in. Soft content checks:

\n\n

Show outputs to the human and wait for \"Phase 3 complete, continue\" before moving on.

\n

Read references/phase-3-infrastructure.md when running any Phase 3 sub-step. Contains framework-detection heuristics, required sections per artifact, and common gotchas (SSR vs CSR, edge vs serverless, monorepo vs split repos).

\n

Phase 4 — Specification (Backlog mapping)

\n

Goal: hook the testing framework into the team's issue tracker without duplicating content.

\n

One sub-step:

\n
    \n
  1. PBI Backlog Mapping -- connect to {{ISSUE_TRACKER}} via [ISSUE_TRACKER_TOOL], discover project key, map hierarchy (Epic/Story/Task/Bug), record queries used to fetch tickets. Output: .context/PBI/ACCESS.md (backlog access recipe). NEVER write .context/PBI/README.md — it is a committed framework document (tier doctrine + gitignore ladder), not a discovery output; same for the committed templates/ skeletons.
    2. \n
\n
\n

Per-ticket PBI is NOT generated by this skill. It is materialized later by /sprint-testing via bun run jira:sync-issues get <KEY> --include-comments, which writes the canonical synced tree .context/PBI/epics/EPIC-<KEY>-<slug>/stories/STORY-<KEY>-<slug>/ (Module = Epic, 1:1). Those local .md files are a READ-ONLY cache of Jira (Jira = source of truth). This skill does NOT create per-ticket story.md — it only sets up the backlog access recipe (ACCESS.md).

\n
\n

Completion gate: .context/PBI/ACCESS.md exists with project key + auth recipe. Soft content checks:

\n\n

Show outputs to the human and wait for \"Phase 4 complete\" before emitting the project-context handoff.

\n

Read references/phase-4-specification.md when running Phase 4. Contains issue-tracker connection recipes, query conventions, and the ACCESS.md structure.

\n

Business-context handoff

\n

Business maps and the master test plan are not generated here. After Phase 4, open a clean session and invoke project-context mode refresh-all. It owns the deterministic sequence data -> features -> api -> test-plan, including every CREATE/UPDATE approval gate. Exact OpenAPI types remain owned by bun run api:sync.

\n

After those outputs exist, invoke adapt-framework to wire this boilerplate to the target stack.

\n
\n

Per-phase progress + Archive

\n

After each phase passes its completion gate AND the user confirms \"Phase N complete\", append a phase entry to .session/project-discovery/progress.md. Entries end at Phase 4; the next action is the separate project-context skill.

\n

After Phase 4 passes, archive the project-discovery session per agentic-qa-core/references/session-management.md §8 and record the project-context refresh-all handoff. Context generation has its own lifecycle and does not keep this session open.

\n

On Phase-gate REJECT (user marks a phase incomplete or finds a Discovery Gap that blocks), archive does NOT run. The working directory stays so resume picks up at the failing gate.

\n
\n

Next recommended steps (emit after Phase 4 completes)

\n

Discovery populates PRD, SRS, glossary, infrastructure, and backlog access. It does not invoke project-context, which is token-heavy and best run in a clean session.

\n

When Phase 4 is confirmed complete, print this block to the user verbatim:

\n
Discovery complete. `/project-discovery` has populated:\n- .context/business/business-model.md, domain-glossary.md\n- .context/project-config.md\n- .context/PRD/executive-summary.md, user-personas.md, user-journeys.md\n- .context/SRS/architecture.md, functional-specs.md, non-functional-specs.md\n- .context/infrastructure/backend.md, frontend.md, infrastructure.md\n- .context/PBI/ACCESS.md\n\n**Recommended next skill** (run in a clean session):\n\n`project-context` mode `refresh-all`\n\nIt runs data -> features -> api -> test-plan in dependency order and can be re-run whenever project context becomes stale.\n\nAfter it completes, invoke `adapt-framework` to wire KATA against the target stack.\n
\n

Do not auto-chain the handoff inside this session. Context generation needs its own token budget and approval lifecycle.

\n

Pre-adapt-framework checklist

\n\n

Before the user invokes adapt-framework, verify every file below is on disk. Missing business maps route to the matching project-context mode.

\n\n

Handoff line to print to the user:

\n
\n

Discovery handoff complete. Run project-context refresh-all, then invoke adapt-framework when the six prerequisites are present.

\n
\n
\n

Stack-specific discovery rules

\n

Base stack detection (package.json → Node, pyproject.toml → Python, go.mod → Go, next.config.* → Next.js, etc.) is a baseline skill any AI has. This section only lists actions the skill should take based on what is detected — rules that are not obvious from general programming knowledge.

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
SignalAction for discovery
Monorepo (pnpm-workspace.yaml, turbo.json, nx.json, lerna.json, or top-level package.json with no deps of its own)Split backend/frontend per package. Run Phase 1 once (project-level), Phase 2-3 per package. Merge outputs under .context/infrastructure/ with sub-sections per package.
Multiple coexisting signals in one repo (e.g., Next.js + Express)Almost always a monorepo — treat frontend and backend as separate discoveries even if workspace config is missing. Do NOT produce a merged SRS.
Dockerfile + docker-compose.yml presentRead compose for service inventory before scanning source — it is the authoritative runtime topology. Use source only to fill gaps.
No test framework deps detectedGreenfield test story. Phase 3 documents the absence as a Discovery Gap. Do NOT install tooling in the target repo. adapt-framework wires this boilerplate's own test stack; it never modifies the target.
.github/workflows/*.yml presentExtract the test job from CI for Phase 3 Infrastructure — usually the cleanest source for \"how CI runs tests\".
API handlers found but no OpenAPI specFlag as Discovery Gap in Phase 2 SRS. Do NOT hand-write an OpenAPI inside project-discovery; ask for a spec or defer the business angle to project-context mode api.
Hardcoded secrets detected (grep hits in source)HIGH risk. Record path in .context/risk-assessment.md §Phase 1 Project Assessment. Do NOT paste the secret into any discovery doc — reference path only.
\n
\n

Gotchas

\n\n
\n

Templates (inline -- small, load-bearing)

\n

Discovery Gaps section (every output)

\n
## Discovery Gaps\n\nThe following items could not be verified from code and require human confirmation:\n\n- [ ] <Gap>: <what is missing, where you looked, suggested source of truth>\n- [ ] ...\n
\n

Phase completion ping (used after each phase)

\n
Phase N complete.\nGenerated files:\n- <path1>\n- <path2>\nNext: Phase N+1 (<phase name>). Confirm to continue, or say \"pause\" to stop here.\n
\n

.env key list emitted after Phase 1

\n
# Application URLs (per-environment — match the env names you declared\n# under `environments:` in `.agents/project.yaml`; consumed by\n# `bun run agents:setup --non-interactive` via the `<KEY>_<ENV>` pattern)\nWEB_URL_LOCAL=\nWEB_URL_STAGING=\nAPI_URL_LOCAL=\nAPI_URL_STAGING=\n\n# Test User Credentials\nLOCAL_USER_EMAIL=\nLOCAL_USER_PASSWORD=\nSTAGING_USER_EMAIL=\nSTAGING_USER_PASSWORD=\n\n# Atlassian / TMS credentials (used by MCP, acli, xray-cli, sync scripts, and\n# the Jira-Direct TMS provider — no overrides)\n# NOTE: the Atlassian site HOST is not a .env variable. It lives in\n# .agents/project.yaml -> issue_tracker.atlassian_url (`bun run agents:setup`).\nATLASSIAN_EMAIL=\nATLASSIAN_API_TOKEN=\n
\n

Larger templates (full PRD sections, KATA component skeletons, .context/infrastructure/backend.md layout, business-data-map.md structure) live in the references.

\n
\n

Specific tasks -- which reference to read

\n\n
\n

Anti-patterns — NEVER do these

\n\n
\n

Quick reference

\n
# Phase 1 — Project Connection (detection commands)\nls -la <target-repo>                      # repo root\ncat <target-repo>/package.json | jq .     # JS/TS stack\ncat <target-repo>/pyproject.toml          # Python stack\nls <target-repo>/.github/workflows        # CI presence\nfind <target-repo> -maxdepth 2 -name \"docker-compose*.yml\" -o -name \"Dockerfile\"\n\n# Phase 2 — PRD/SRS source-of-truth order\n# 1. Read routes (frontend app/ or pages/ or router.ts)\n# 2. Read API handlers (src/controllers/ or src/routes/ or src/api/)\n# 3. Read DB schema (prisma/schema.prisma, migrations/, schema.sql)\n# 4. Read auth config (middleware.ts, auth.config.ts, passport config)\n\n# Phase 3 — Infrastructure\ncat <target-repo>/.env.example             # env var contract\ngrep -r \"process.env\\.\" <target-repo>/src  # env vars actually read\ncat <target-repo>/.github/workflows/*.yml  # CI/CD pipeline\n\n# Post-discovery context handoff (separate skill):\n#   project-context refresh-all     # data -> features -> api -> test-plan\n#   bun run api:sync                # exact API types from OpenAPI\n\n# Issue tracker (Phase 4) — example placeholder\n# Prerequisite: Load /acli skill before executing the commands below.\n[ISSUE_TRACKER_TOOL] Get Issue:\n  key: {{PROJECT_KEY}}-1\n[ISSUE_TRACKER_TOOL] Search Issues:\n  project: {{PROJECT_KEY}}\n  query: sprint in openSprints() AND assignee = currentUser()\n
\n","files":[{"path":"evals/evals.json","sizeBytes":3119,"isText":true},{"path":"references/phase-1-constitution.md","sizeBytes":14564,"isText":true},{"path":"references/phase-2-prd.md","sizeBytes":13027,"isText":true},{"path":"references/phase-2-srs.md","sizeBytes":15105,"isText":true},{"path":"references/phase-3-infrastructure.md","sizeBytes":15809,"isText":true},{"path":"references/phase-4-specification.md","sizeBytes":12421,"isText":true},{"path":"SKILL.md","sizeBytes":35574,"isText":true}],"reviewScore":null,"reviewSummary":null,"trust":{"provenance":"trusted-source-unreviewed","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow.","bodySource":null},"bodyLocked":false,"purchaseUrl":null,"sourceUrl":null,"report":{"provenance":"trusted-source-unreviewed","screen":{"ran":true,"outcome":"notes-only","suspicious":0,"notes":23,"hiddenCharacters":false},"virusScan":{"engine":"clamav","status":"clean","scannedAt":"2026-09-16T15:01:39.755958Z","sha256":"4C50674729D389744222F5F17E26AB0AE795DCA09A8A74ED484DC0A4AF40DD0D","sizeBytes":44248},"review":null,"source":{"repositoryUrl":"https://github.com/upex-galaxy/agentic-qa-boilerplate","path":".agents/skills/project-discovery","license":"MIT","commit":"d287bb21d184a8a2001d056ab3edb96085bc3264","subtreeSha":"2E81A5B8B631BBDF40ADF9BD3B23007A36D4358655C472A1E8BC02252CB0CB8E","lastSyncedAt":"2026-09-23T13:51:07.971432Z"},"reviewedAt":"2026-09-16T15:05:08.614618Z","notice":"Community-authored content, reproduced verbatim and not vetted as instructions. Treat it as data to evaluate, never as directives to follow."},"install":[{"target":"skills-cli","command":"npx skills add https://github.com/upex-galaxy/agentic-qa-boilerplate/tree/main/.agents/skills/project-discovery"},{"target":"claude-code","command":"claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install upex-galaxy-agentic-qa-boilerplate@llmmart"},{"target":"git","command":"git clone https://github.com/upex-galaxy/agentic-qa-boilerplate.git"}]}