modify template
This commit is contained in:
김경종
@@ -0,0 +1,20 @@
|
||||
{
|
||||
"name": "local-harness-engineering",
|
||||
"interface": {
|
||||
"displayName": "Local Report Harness"
|
||||
},
|
||||
"plugins": [
|
||||
{
|
||||
"name": "harness-engineering",
|
||||
"source": {
|
||||
"source": "local",
|
||||
"path": "./plugins/harness-engineering"
|
||||
},
|
||||
"policy": {
|
||||
"installation": "AVAILABLE",
|
||||
"authentication": "ON_INSTALL"
|
||||
},
|
||||
"category": "Productivity"
|
||||
}
|
||||
]
|
||||
}
|
||||
@@ -0,0 +1,65 @@
|
||||
---
|
||||
name: harness-review
|
||||
description: Review a Report Harness repository against its persistent rules and report docs. Use when Codex is asked to review local changes, generated phase files, research logs, report drafts, feedback handling, source quality, or output against `AGENTS.md`, `docs/ARCHITECTURE.md`, `docs/ADR.md`, `docs/UI_GUIDE.md`, and Harness step acceptance criteria.
|
||||
---
|
||||
|
||||
# Report Harness Review
|
||||
|
||||
Use this skill when the user wants a repository-grounded report review instead of generic commentary.
|
||||
|
||||
## Review input set
|
||||
|
||||
Read these first:
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/docs/PRD.md`
|
||||
- `/docs/ARCHITECTURE.md`
|
||||
- `/docs/ADR.md`
|
||||
- `/docs/UI_GUIDE.md`
|
||||
- `/docs/RESEARCH_LOG.md`
|
||||
- `/docs/REPORT_DRAFT.md`
|
||||
- `/docs/FEEDBACK.md`
|
||||
- the changed files or generated `phases/` files under review
|
||||
|
||||
If the user explicitly asks for delegated review, prefer the repo custom agent `harness_reviewer` or built-in read-only explorers.
|
||||
|
||||
## Checklist
|
||||
|
||||
Evaluate the patch against these questions:
|
||||
|
||||
1. Does it follow the report workflow described in `docs/ARCHITECTURE.md`?
|
||||
2. Does it stay within the research and writing decisions documented in `docs/ADR.md`?
|
||||
3. Does it satisfy the topic, purpose, keywords, direction, audience, and output format in `docs/PRD.md`?
|
||||
4. Are new factual claims backed by sources in `docs/RESEARCH_LOG.md` or clearly marked as `검증 필요`?
|
||||
5. Are source quality, publication/access dates, conflicts, and uncertainty handled explicitly?
|
||||
6. Does it violate any CRITICAL rule in `AGENTS.md`?
|
||||
7. Do generated `phases/` files remain self-contained, executable, and internally consistent?
|
||||
8. If the user expects verification, does `python scripts/validate_workspace.py` succeed or is the failure explained?
|
||||
|
||||
## Output rules
|
||||
|
||||
- Lead with findings, ordered by severity.
|
||||
- Include file references for each finding.
|
||||
- Explain the concrete report-quality risk, not just the rule name.
|
||||
- If there are no findings, say so explicitly and mention residual risks or missing evidence.
|
||||
- Keep summaries brief after the findings.
|
||||
|
||||
## Preferred review table
|
||||
|
||||
When the user asks for a checklist-style review, use this table:
|
||||
|
||||
| Item | Result | Notes |
|
||||
|------|------|------|
|
||||
| Brief alignment | PASS/FAIL | {details} |
|
||||
| Research coverage | PASS/FAIL | {details} |
|
||||
| Source quality | PASS/FAIL | {details} |
|
||||
| Claim support | PASS/FAIL | {details} |
|
||||
| Feedback handling | PASS/FAIL | {details} |
|
||||
| CRITICAL rules | PASS/FAIL | {details} |
|
||||
| Validation | PASS/FAIL | {details} |
|
||||
|
||||
## What not to do
|
||||
|
||||
- Do not approve a draft just because it is well written.
|
||||
- Do not ignore unsupported claims, stale sources, or missing counterarguments.
|
||||
- Do not assume a passing hook means the report is acceptable; review the actual documents and phase files.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Report Harness Review"
|
||||
short_description: "Review report artifacts against Report Harness rules"
|
||||
default_prompt: "Use Report Harness review to check source quality, claim support, feedback handling, and rules."
|
||||
@@ -0,0 +1,173 @@
|
||||
---
|
||||
name: harness-workflow
|
||||
description: Plan and run the Report Harness workflow for this repository. Use when Codex needs to read `AGENTS.md` and `docs/*.md`, discuss report scope, draft research/drafting/revision phase plans, or create/update `phases/index.json`, `phases/{phase}/index.json`, and `phases/{phase}/stepN.md` files for staged execution.
|
||||
---
|
||||
|
||||
# Report Harness Workflow
|
||||
|
||||
Use this skill when the user is working in the report-generation Harness template and wants structured planning or phase-file generation.
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Explore first
|
||||
|
||||
Read these files before proposing steps:
|
||||
|
||||
- `/AGENTS.md`
|
||||
- `/docs/PRD.md`
|
||||
- `/docs/ARCHITECTURE.md`
|
||||
- `/docs/ADR.md`
|
||||
- `/docs/UI_GUIDE.md`
|
||||
- `/docs/RESEARCH_LOG.md`
|
||||
- `/docs/REPORT_DRAFT.md`
|
||||
- `/docs/FEEDBACK.md`
|
||||
|
||||
If the user explicitly asks for parallel exploration, use built-in Codex subagents such as `explorer`, or the repo-scoped custom agent `phase_planner`.
|
||||
|
||||
### 2. Confirm report inputs before locking the plan
|
||||
|
||||
Check that `docs/PRD.md` has enough information for:
|
||||
|
||||
1. Report topic.
|
||||
2. Purpose and target reader.
|
||||
3. Required keywords.
|
||||
4. Direction or stance.
|
||||
5. Output format and success criteria.
|
||||
|
||||
If any of these are missing and cannot be reasonably inferred, create a short `blocked` step or ask the user for the missing input instead of fabricating intent.
|
||||
|
||||
### 3. Design steps with strict boundaries
|
||||
|
||||
When drafting a report phase plan:
|
||||
|
||||
1. Keep each step focused on one research question, source-review pass, outline pass, draft pass, or feedback pass.
|
||||
2. Make each `stepN.md` self-contained so it can run in an isolated Codex session.
|
||||
3. List prerequisite files explicitly. Never rely on "as discussed above".
|
||||
4. Specify report artifacts and invariants, not line-by-line prose.
|
||||
5. Use executable acceptance commands, not vague success criteria.
|
||||
6. Write concrete warnings in "do not do X because Y" form.
|
||||
7. Use kebab-case step names.
|
||||
8. Require web search for facts, current information, market data, policy/law, statistics, or recommendations.
|
||||
9. Require source notes in `docs/RESEARCH_LOG.md` before adding claims to `docs/REPORT_DRAFT.md`.
|
||||
|
||||
Recommended step sequence:
|
||||
|
||||
1. `brief-audit`: validate the report brief and derive research questions.
|
||||
2. `source-discovery`: perform broad web search and record candidate sources.
|
||||
3. `deep-research-{topic}`: research one specific keyword, stakeholder, region, or issue.
|
||||
4. `source-review`: check source quality, conflicts, freshness, and missing evidence.
|
||||
5. `outline`: design the report structure from the evidence.
|
||||
6. `draft-report`: write or revise `docs/REPORT_DRAFT.md`.
|
||||
7. `feedback-questions`: add targeted questions for the user and update `docs/FEEDBACK.md`.
|
||||
|
||||
## Files to generate
|
||||
|
||||
### `phases/index.json`
|
||||
|
||||
Top-level phase registry. Append to `phases[]` when the file already exists.
|
||||
|
||||
```json
|
||||
{
|
||||
"phases": [
|
||||
{
|
||||
"dir": "0-research",
|
||||
"status": "pending"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- `dir`: phase directory name.
|
||||
- `status`: `pending`, `completed`, `error`, or `blocked`.
|
||||
- Timestamp fields are written by `scripts/execute.py`; do not seed them during planning.
|
||||
|
||||
### `phases/{phase}/index.json`
|
||||
|
||||
```json
|
||||
{
|
||||
"project": "<report-project-name>",
|
||||
"phase": "<phase-name>",
|
||||
"steps": [
|
||||
{ "step": 0, "name": "brief-audit", "status": "pending" },
|
||||
{ "step": 1, "name": "source-discovery", "status": "pending" },
|
||||
{ "step": 2, "name": "draft-outline", "status": "pending" }
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- `project`: from `AGENTS.md` or `docs/PRD.md`.
|
||||
- `phase`: directory name.
|
||||
- `steps[].step`: zero-based integer.
|
||||
- `steps[].name`: kebab-case slug.
|
||||
- `steps[].status`: initialize to `pending`.
|
||||
|
||||
### `phases/{phase}/stepN.md`
|
||||
|
||||
Each step file should contain:
|
||||
|
||||
1. A title.
|
||||
2. A "read these files first" section.
|
||||
3. A concrete task section.
|
||||
4. Executable acceptance criteria.
|
||||
5. Verification instructions.
|
||||
6. Explicit prohibitions.
|
||||
|
||||
Recommended structure:
|
||||
|
||||
````markdown
|
||||
# Step {N}: {name}
|
||||
|
||||
## Read First
|
||||
- /AGENTS.md
|
||||
- /docs/PRD.md
|
||||
- /docs/ARCHITECTURE.md
|
||||
- /docs/ADR.md
|
||||
- /docs/UI_GUIDE.md
|
||||
- /docs/RESEARCH_LOG.md
|
||||
- /docs/REPORT_DRAFT.md
|
||||
- /docs/FEEDBACK.md
|
||||
- {files from previous steps}
|
||||
|
||||
## Task
|
||||
{specific report research, source review, drafting, or feedback instructions}
|
||||
|
||||
## Acceptance Criteria
|
||||
```bash
|
||||
python scripts/validate_workspace.py
|
||||
```
|
||||
|
||||
## Verification
|
||||
1. Run the acceptance commands.
|
||||
2. Check `AGENTS.md` and `docs/*.md` for report-rule drift.
|
||||
3. Confirm every new factual claim has a source or is listed under `검증 필요`.
|
||||
4. Update the matching step in `phases/{phase}/index.json`:
|
||||
- completed + summary
|
||||
- error + error_message
|
||||
- blocked + blocked_reason
|
||||
|
||||
## Do Not
|
||||
- {concrete prohibition}
|
||||
````
|
||||
|
||||
## Execution
|
||||
|
||||
Run the generated phase with:
|
||||
|
||||
```bash
|
||||
python scripts/execute.py <phase-name>
|
||||
python scripts/execute.py <phase-name> --push
|
||||
```
|
||||
|
||||
`scripts/execute.py` handles:
|
||||
|
||||
- `report-{phase}` branch checkout/creation when the directory is a git repository
|
||||
- guardrail injection from `AGENTS.md` and `docs/*.md`
|
||||
- accumulation of completed-step summaries into later prompts
|
||||
- up to 3 retries with prior error feedback
|
||||
- two-phase commit of report artifact changes and metadata updates
|
||||
- timestamps such as `created_at`, `started_at`, `completed_at`, `failed_at`, and `blocked_at`
|
||||
|
||||
## Recovery rules
|
||||
|
||||
- If a step is `error`, reset its status to `pending`, remove `error_message`, then rerun.
|
||||
- If a step is `blocked`, resolve the blocker, reset to `pending`, remove `blocked_reason`, then rerun.
|
||||
@@ -0,0 +1,4 @@
|
||||
interface:
|
||||
display_name: "Report Harness Workflow"
|
||||
short_description: "Guide Codex through report phase planning"
|
||||
default_prompt: "Use the Report Harness workflow to plan research, drafting, and revision steps."
|
||||
Reference in New Issue
Block a user