skills/project-profile/SKILL.md
# Skill: project-profile Detect and describe the project's profile from codebase signals. ## Purpose Classify the project into one of 8 profile types and extract key tech-stack facts that all downstream stages (CLARIFY → SPEC → PLAN) rely on. ## Profile Types | Type | Signals | |------|---------| | `application` | main entry point, GUI, user-facing pages | | `backend-service` | HTTP server, REST/gRPC endpoints, Dockerfile | | `frontend` | framework components (React/Vue/Svelte), build pipel
npx skillsauth add LUAgam/stage-harness skills/project-profileInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Detect and describe the project's profile from codebase signals.
Classify the project into one of 8 profile types and extract key tech-stack facts that all downstream stages (CLARIFY → SPEC → PLAN) rely on.
| Type | Signals |
|------|---------|
| application | main entry point, GUI, user-facing pages |
| backend-service | HTTP server, REST/gRPC endpoints, Dockerfile |
| frontend | framework components (React/Vue/Svelte), build pipeline |
| library | no binary entry, exports API, package.json main/exports |
| data-pipeline | ETL scripts, DAGs, notebook, batch jobs |
| infra | Terraform/Pulumi/Helm, IaC files dominant |
| plugin | .claude-plugin/ or extension manifest |
| docs | majority Markdown/RST, no runnable code |
1. Read root file listing (non-recursive, first 50 entries)
2. Read package.json / pyproject.toml / go.mod / Cargo.toml if present
3. Check for Dockerfile, docker-compose.yml, *.tf, *.yaml (k8s)
4. Check for test directory structure (tests/, spec/, __tests__/)
5. Check for .claude-plugin/ directory
6. Score each profile type based on signals
7. Select highest-scoring type; if tie → prefer more specific
# .harness/project-profile.yaml
profile_type: backend-service # one of 8 types
primary_language: typescript # dominant language
secondary_languages: [sql, bash]
framework: express # main framework if any
build_tool: npm # npm / cargo / go / poetry / gradle
test_framework: jest # test runner
has_database: true
has_auth: false
has_docker: true
has_ci: true
estimated_size: medium # small / medium / large / xlarge
risk_default: medium # low / medium / high (default for new epics)
intensity:
agent_parallelism: 3 # how many parallel workers
council_size: 3 # reviewers per council
harness_strength: standard # minimal / standard / strict
notes: "Express API, PostgreSQL, Jest, Docker Compose"
# --- Scan routing (optional; aligns with templates/project-profile.yaml) ---
workspace_mode: single-repo # single-repo | monorepo | multi-repo | docs-heavy | infra-heavy
scan:
max_repos_deep_scan: 5
max_files_deep_read_per_scout: 20
max_subagents_wave: 4
| Value | Meaning |
|-------|---------|
| single-repo | One app root; directory-level scoping |
| monorepo | packages/apps/libs; scope to affected packages first |
| multi-repo | Sibling repos; use .harness/repo-catalog.yaml (see templates/repo-catalog.yaml) |
| docs-heavy | Mostly docs; prefer README, ADR, indexes — minimal code scan |
| infra-heavy | IaC/CI dominant; prefer modules, env, pipelines |
When workspace_mode: multi-repo, maintain .harness/repo-catalog.yaml so impact-analyst can narrow repos before deep scan.
| Risk Level | Parallelism | Council Size | Harness | |-----------|-------------|--------------|---------| | low | 2 | 2 | minimal | | medium | 3 | 3 | standard | | high | 4 | 5 | strict |
Invoke at the start of /stage-harness:start or when profile is stale:
Invoke skill: project-profile
Purpose: Detect project type and set intensity controls for this session.
Output file: .harness/project-profile.yaml
After detection, surface findings to user for confirmation before proceeding.
development
在 generate-test-cases 阶段之后执行,逐个验证测试用例并在失败时修复项目代码、重新编译部署、再次验证, 直到通过或达到最大修复次数。覆盖 UI / API / API+UI / 性能测试四个维度,UI 测试通过浏览器真实模拟用户操作并截图, API 测试根据项目代码生成可执行的接口脚本,性能测试调用现有性能/质量技能全量执行。 涉及真实用户登录信息(如手机号+验证码、账号密码、JWT)时必须中断要求用户提供,禁止编造无效凭证。 所有 case 状态变更必须通过 e2e-case-tracker.sh 脚本持久化,确保中途崩溃可恢复、无 case 遗漏。
development
# SKILL: e2e > **核心原则**: > 1. 测试范围跟着本次变动走。后端接口改了,对应的前端流程必须做联调验证;与本次需求无关的功能不测。对于涉及算法、转换准确率等质量敏感型需求,需额外生成专项质量测试。 > 2. **覆盖完整性优先于执行便利性**。不得以"链路复杂"、"需要外部依赖"为由跳过本次变动相关的用例;凡是受变动影响的接口和 UI 流程,都必须生成真实调用/操作用例。 > 3. **UI 测试必须模拟真实用户操作**(定位元素、点击、键入、等待渲染、断言可见文本/状态)。**禁止**将 UI 套件退化为浏览器上下文里的 `page.evaluate(fetch(...))` API 验证——那只是把 API 测试换了执行环境,没有额外价值,不算 UI 测试。 > 4. **通用性**:本 skill 不假设具体业务域,所有规则均以抽象变动面(文件、接口、页面、用户动作)为单位组织,不针对任何特定项目的数据库/领域词汇。 > 5. **E2E 套件必须验证运行时行为**。严禁把"读取源码/配置文件并做字符串/结构匹配"的检查封装成独立 E2E 套件——这类检
tools
# SKILL: deploy ## CLI Bootstrap 在执行任何 `harnessctl` 命令前,先解析本地 CLI 路径: ```bash if [ -z "${HARNESSCTL:-}" ]; then candidates=( "./stage-harness/scripts/harnessctl" "../stage-harness/scripts/harnessctl" "$(git rev-parse --show-toplevel 2>/dev/null)/stage-harness/scripts/harnessctl" ) for candidate in "${candidates[@]}"; do if [ -n "$candidate" ] && [ -x "$candidate" ]; then HARNESSCTL="$candidate" break fi done fi test -n "${HARNESSCTL:-}" && test -x "$H
tools
# SKILL: build ## CLI Bootstrap 在执行任何 `harnessctl` 命令前,先解析本地 CLI 路径: ```bash if [ -z "${HARNESSCTL:-}" ]; then candidates=( "./stage-harness/scripts/harnessctl" "../stage-harness/scripts/harnessctl" "$(git rev-parse --show-toplevel 2>/dev/null)/stage-harness/scripts/harnessctl" ) for candidate in "${candidates[@]}"; do if [ -n "$candidate" ] && [ -x "$candidate" ]; then HARNESSCTL="$candidate" break fi done fi test -n "${HARNESSCTL:-}" && test -x "$HA