baram2584/Agentic-AI-Template
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

modify coding template

Browse Source
This commit is contained in:
NINI
2026-05-09 02:20:01 +09:00
parent 38291723f0
commit a1aea6a449
55 changed files with 437 additions and 2862 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Coding/Codex/.agents/skills/harness-workflow/SKILL.md
+71 -92
View File
@@ -1,47 +1,36 @@
---
name: harness-workflow
description: Plan and run the Harness Engineering workflow for this repository. Use when Codex needs to read `AGENTS.md` and `docs/*.md`, discuss implementation scope, draft phase plans, or create/update `phases/index.json`, `phases/{phase}/index.json`, and `phases/{phase}/stepN.md` files for staged execution.
description: Use when planning or running this Harness framework: reading AGENTS.md and docs/*.md, discussing implementation scope, creating or updating phases/index.json, phases/{task}/index.json, phases/{task}/stepN.md, or invoking scripts/execute.py for staged Codex execution.
---
# Harness Workflow
Use this skill when the user is working in the Harness template and wants structured planning or phase-file generation.
## Overview
Use this skill to turn a user-approved task into small, self-contained Harness steps that another Codex session can execute reliably. Keep the workflow grounded in repository docs and executable acceptance criteria.
## Workflow
### 1. Explore first
1. Read `AGENTS.md` and relevant files under `docs/`, especially `docs/PRD.md`, `docs/ARCHITECTURE.md`, and `docs/ADR.md`.
2. Discuss unresolved product or technical decisions with the user before writing phase files.
3. When the user asks for an implementation plan, draft steps and get approval before creating files.
4. Create or update `phases/index.json`, `phases/{task-name}/index.json`, and one `phases/{task-name}/stepN.md` per step.
5. Run the phase with `python scripts/execute.py {task-name}` when asked to execute it. Use `--push` only when the user asks to push.
Read these files before proposing steps:
## Step Design Rules
- `/AGENTS.md`
- `/docs/PRD.md`
- `/docs/ARCHITECTURE.md`
- `/docs/ADR.md`
- `/docs/UI_GUIDE.md`
- Scope each step to one layer or module. Split steps when multiple modules would otherwise change together.
- Make every step self-contained. Do not rely on prior conversation; include all required context and file paths.
- Force context gathering. Each step must tell Codex which docs and previous outputs to read before editing.
- Specify interfaces and signatures, not full implementations, unless exact code is required for a constraint.
- Put core invariants directly in the step: idempotency, security, data integrity, API contracts, or other non-negotiables.
- Use executable acceptance criteria such as `npm run build && npm test`, not abstract statements.
- Write cautions concretely: "Do not do X. Reason: Y."
- Name steps with kebab-case slugs such as `project-setup`, `api-layer`, or `auth-flow`.
If the user explicitly asks for parallel exploration, use built-in Codex subagents such as `explorer`, or the repo-scoped custom agent `phase_planner`.
## Phase Files
### 2. Discuss before locking the plan
If scope, sequencing, or architecture choices are still ambiguous, surface the decision points before creating `phases/` files.
### 3. Design steps with strict boundaries
When drafting a phase plan:
1. Keep scope minimal. One step should usually touch one layer or one module.
2. Make each step self-contained. Every `stepN.md` must work in an isolated Codex session.
3. List prerequisite files explicitly. Never rely on "as discussed above".
4. Specify interfaces or invariants, not line-by-line implementations.
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.
## Files to generate
### `phases/index.json`
Top-level phase registry. Append to `phases[]` when the file already exists.
Create or update `phases/index.json`:
```json
{
@@ -54,16 +43,12 @@ Top-level phase registry. Append to `phases[]` when the file already exists.
}
```
- `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`
Create `phases/{task-name}/index.json`:
```json
{
"project": "<project-name>",
"phase": "<phase-name>",
"phase": "<task-name>",
"steps": [
{ "step": 0, "name": "project-setup", "status": "pending" },
{ "step": 1, "name": "core-types", "status": "pending" },
@@ -72,74 +57,68 @@ Top-level phase registry. Append to `phases[]` when the file already exists.
}
```
- `project`: from `AGENTS.md`.
- `phase`: directory name.
- `steps[].step`: zero-based integer.
- `steps[].name`: kebab-case slug.
- `steps[].status`: initialize to `pending`.
Rules:
### `phases/{phase}/stepN.md`
- `project` comes from `AGENTS.md`.
- `phase` matches the task directory name.
- `steps[].step` starts at `0`.
- Initial status is always `pending`.
- Do not add timestamps when creating files. `scripts/execute.py` records `created_at`, `started_at`, `completed_at`, `failed_at`, and `blocked_at`.
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:
## Step Template
```markdown
# Step {N}: {name}
## Read First
- /AGENTS.md
- /docs/ARCHITECTURE.md
- /docs/ADR.md
- {files from previous steps}
## 읽어야 할 파일
## Task
{specific instructions}
먼저 아래 파일들을 읽고 프로젝트의 아키텍처와 설계 의도를 파악하라:
- `/AGENTS.md`
- `/docs/ARCHITECTURE.md`
- `/docs/ADR.md`
- {previously created or modified files}
이전 step에서 만들어진 코드를 꼼꼼히 읽고, 설계 의도를 이해한 뒤 작업하라.
## 작업
{Concrete instructions with file paths, interfaces, signatures, and rules.}
## Acceptance Criteria
```bash
python scripts/validate_workspace.py
```
## Verification
1. Run the acceptance commands.
2. Check AGENTS and docs for rule drift.
3. 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
npm run build
npm test
```
`scripts/execute.py` handles:
## 검증 절차
- `feat-{phase}` branch checkout/creation
- 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 code changes and metadata updates
- timestamps such as `created_at`, `started_at`, `completed_at`, `failed_at`, and `blocked_at`
1. 위 AC 커맨드를 실행한다.
2. 아키텍처 체크리스트를 확인한다:
- ARCHITECTURE.md 디렉토리 구조를 따르는가?
- ADR 기술 스택을 벗어나지 않았는가?
- AGENTS.md CRITICAL 규칙을 위반하지 않았는가?
3. 결과에 따라 `phases/{task-name}/index.json`의 해당 step을 업데이트한다:
- 성공: `"status": "completed"`, `"summary": "산출물 한 줄 요약"`
- 3회 수정 시도 후 실패: `"status": "error"`, `"error_message": "구체적 에러 내용"`
- 사용자 개입 필요: `"status": "blocked"`, `"blocked_reason": "구체적 사유"` 후 중단
## 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.
- {Do not do X. Reason: Y.}
- 기존 테스트를 깨뜨리지 마라.
```
## Execution And Recovery
Run:
```bash
python scripts/execute.py {task-name}
python scripts/execute.py {task-name} --push
```
`scripts/execute.py` creates or checks out `feat-{task-name}`, injects `AGENTS.md` and `docs/*.md` into each prompt, carries completed step summaries forward, retries failed steps up to three times, separates code and metadata commits, and records timestamps.
If a step is `error`, set it back to `pending` and remove `error_message` after fixing the cause. If a step is `blocked`, resolve `blocked_reason`, set it back to `pending`, remove `blocked_reason`, and rerun.