Add follow-up issue guidance
This commit is contained in:
@@ -20,6 +20,8 @@ PROJECT_NAME: PROJECT_DESCRIPTION
|
||||
- Replace all applicable placeholders. Remove non-applicable placeholder sections instead of leaving fake values.
|
||||
- Derive `REPOSITORY_OWNER` and `REPOSITORY_NAME` from the target repository remote or `GITHUB_REPOSITORY`. Never reuse the owner from this template repository.
|
||||
- If `GITEA_TOKEN` is available locally, use it only for read-only Gitea API checks such as private repository metadata, package-read visibility, and Actions run status. Never print, commit, or store the token.
|
||||
- When you find a real, actionable follow-up that is outside the current scope or can be worked on independently, create a tracker issue so humans or other agents can pick it up later or in parallel. Do not create issues for work you can safely finish in the current task. If no issue tracker is available, update `docs/agent-handoff.md` instead.
|
||||
- Keep issues scoped and actionable: include the observed problem, impact, affected files or commands, suggested next steps, and any verification already performed. Never include secrets, tokens, private data, or sensitive logs in public issues.
|
||||
- After pushing commits that trigger a Gitea workflow, poll the workflow run until it succeeds. If it fails or is cancelled, inspect the failing job/logs, fix the issue when in scope, push again, and repeat the workflow check loop. Fixing and pushing a workflow failure is not a stopping point.
|
||||
- When the project uses `blueprint.md` and `blueprint.json` for README generation, keep the rainbow `{{ template:section-line }}` divider between major README sections. Do not replace it with plain `---` unless the target renderer cannot display inline images.
|
||||
- If README blueprint files are changed, regenerate or update `README.md` in the same change and verify the generated output renders reasonably.
|
||||
@@ -81,5 +83,6 @@ ARTIFACT_NAME
|
||||
- The cheapest reliable verification command has been run, or the reason it could not be run is documented.
|
||||
- README, changelog, security review, and release checklist are updated when the change touches release behavior.
|
||||
- `docs/agent-handoff.md` is updated when work is interrupted, risky, or spans multiple sessions.
|
||||
- Independent follow-up work has tracker issues, or `docs/agent-handoff.md` explains why issues could not be created.
|
||||
- Any pushed Gitea workflow has been polled to success or a concrete blocker has been reported.
|
||||
|
||||
|
||||
@@ -7,6 +7,7 @@
|
||||
- Do not commit secrets, generated credentials, local `.env` files, or private keys.
|
||||
- Do not create releases unless explicitly requested.
|
||||
- Preserve unrelated user changes.
|
||||
- Create focused issues for real follow-up work that is outside the current change or can be worked on independently. Do not put secrets, tokens, private data, or sensitive logs in public issues.
|
||||
|
||||
## Before Committing
|
||||
|
||||
@@ -45,4 +46,3 @@ docs/release-checklist.md
|
||||
docs/security-review.md
|
||||
README.md
|
||||
```
|
||||
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
|
||||
Use this file when a task spans multiple sessions, has unresolved follow-up work, or changes release behavior.
|
||||
|
||||
Prefer focused tracker issues for independent follow-up work when an issue tracker is available. Use this handoff file when issues cannot be created, when the context is too sensitive for a public issue, or when a task needs a compact session summary.
|
||||
|
||||
## Current State
|
||||
|
||||
```text
|
||||
@@ -29,7 +31,12 @@ PENDING
|
||||
|
||||
- PENDING
|
||||
|
||||
## Follow-up Issues
|
||||
|
||||
| Issue | Status |
|
||||
| --- | --- |
|
||||
| PENDING | PENDING |
|
||||
|
||||
## Risks
|
||||
|
||||
- PENDING
|
||||
|
||||
|
||||
Reference in New Issue
Block a user