Harness prompt
Self-improving, tool-first Harness Engineering Agent Skills for Claude Code, Codex, Cursor and TRAE. Build, audit, update and verify AGENTS.md-based repositories.
npx -y skills add atlax-tech/harness-armor --skill harness-promptAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
3 things to look at
- 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Generate source-grounded execute, test, and review engineering prompts for every step in an existing implementation plan, with independent roles and explicit file/verification boundaries. Use when a repository already has product facts, Harness constraints, and a real roadmap or plan. Do not use to improve generic chat prompts, invent a plan, implement code, or let executors self-approve.
The file declares its own license as CC-BY-NC-4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.4 KB, as published. Nobody here has run it
Generate independent engineering prompts
Create three role-specific contracts per real plan step: execute, test, and review. The prompt files coordinate agents; they do not perform the work.
Inputs
- Repository root with product definition and applicable Harness constraints.
- A named implementation plan, roadmap slice, or ordered set of steps.
- Optional output plan name; otherwise derive a safe kebab-case name from the source plan title.
Load the contract
- Treat this file's directory as
SKILL_ROOT. - Read references/prompt-contract.md.
- Resolve shared resources from
SKILL_ROOT/../../sharedorSKILL_ROOT/../.harness-armor. - Read
spec/harness-engineering-v1.md. Read the local templates assets/execute.md, assets/test.md, assets/review.md, and assets/prompt-index.md.
Applicability gate
- Read applicable
AGENTS.mdand authoritative product/architecture/testing documents. - Locate a concrete ordered plan. Confirm steps have a real source, intended outcome, and enough project context to define boundaries.
- If the plan is absent or only aspirational themes exist, stop with
UNRESOLVED; do not invent implementation steps. Recommend the appropriate planning workflow. - If product or Harness constraints are missing/conflicted, route to
harness-build,harness-promotion, orharness-checkbefore prompt generation.
Source pass
- For each plan step, collect the exact plan source, related product requirements, architecture/design constraints, allowed code area, forbidden changes, tests, acceptance behavior, and dependencies on other steps.
- Mark unsupported assumptions
UNRESOLVEDinside the prompt. Never turn them into instructions to implement a guessed feature. - Fingerprint key sources with
python scripts/fingerprint_sources.py <root> <paths...>and record the source digest or locator inPROMPT_INDEX.md.
Output plan and authorization
-
Propose this exact tree:
docs/prompts/<plan-name>/ ├── PROMPT_INDEX.md ├── step-001/ │ ├── execute.md │ ├── test.md │ └── review.md └── ... -
An explicit generation request authorizes creation of a new prompt tree. Existing prompt files are user-owned: do not overwrite them. Offer a new versioned plan name or request exact-file approval.
Generation workflow
- Create one directory per source plan step in original order. Keep each step a single task; split a source step only when its own acceptance evidence requires independent work, and record the mapping.
- Render
execute.mdwith required reading, current facts, allowed and forbidden files, functional and technical constraints, non-degradation rules, verification, completion evidence, small Conventional Commits, and final report format. - Render
test.mdas an independent verification task: requirement sources, expected behavior, normal/error/edge cases, unit/integration/end-to-end scope, manual acceptance, failure evidence, and verdict. Do not trust executor prose. - Render
review.mdwith original task, constraints, expected diff scope, actual test evidence, regression/architecture/data/security risks, severity, and exactly one verdict:PASS,CHANGES_REQUIRED, orBLOCKED. - Make roles independent. Execute may not declare review success; test may not repair implementation; review may not substitute self-authored evidence for an inspected diff and test results.
- Create
PROMPT_INDEX.mdmapping every step and prompt to source locators, prerequisites, outputs, and current unresolved items. - Run local reference checks and inspect every generated prompt for unresolved placeholders, cross-step leakage, and invented facts.
Allowed and forbidden changes
Allowed: a new approved docs/prompts/<plan-name>/ tree.
Forbidden: business code, source plan edits, existing prompt overwrite, generated commits, execution/testing/review actions, collapsed roles, invented requirements, or unsupported client-specific control syntax.
Idempotency and failures
If the identical prompt tree already exists and sources are unchanged, write nothing. If sources drift, report regeneration as a proposal; preserve user edits. On incomplete plan, conflict, permission failure, or broken references, report the exact step and source evidence and do not claim a complete set.
Result format
Report plan source, step count, created/preserved files, source mapping, unresolved items, role-separation checks, reference validation, and manual acceptance steps. State explicitly that no implementation, tests, or review were performed by generating the prompts.
Gives 0 of the 12 instructions most prompt engineering skills give
Counted across 563 of the 626 authors here whose files we hold, read 2026-08-06
- ask at most three clarifying questionsin 22 of 563, across 15 files
- respond in the user input languagein 14 of 563, across 9 files
- preserve the original intentin 13 of 563, across 11 files
- Establish baseline metrics and collect representative examplesin 12 of 563, across 2 files
- Identify failure modes and prioritize high-impact fixesin 12 of 563, across 2 files
- Apply prompt and workflow improvements with measurable goalsin 12 of 563, across 2 files
- Roll back quickly if quality or safety metrics regressin 12 of 563, across 2 files
- validate changes with tests and roll out in controlled stagesin 12 of 563, across 2 files
- generate quantitative baseline performance reportsin 12 of 563, across 2 files
- create representative test scenariosin 12 of 563, across 2 files
- treat prompts as codein 12 of 563, across 5 files
- test prompts on diverse inputsin 12 of 563, across 8 files
Said here and by no other author read
- create execute test and review prompts per step
- load contract references before generating prompts
- stop unresolved if plan is missing or aspirational
- route to appropriate workflow if constraints are missing
- collect exact source and constraints for each step
- mark unsupported assumptions unresolved
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.