work-ally 0.2.0-alpha.1

package/skills/issue-to-spec-triage/references/triage-rules.md

@@ -0,0 +1,66 @@
+# Triage Rules
+
+## Decision order
+
+Ask these questions in order:
+
+1. Does this change product meaning, default behavior, or user path?
+2. Does it cross module, role, or system boundaries?
+3. Does it introduce a new object, state, flow, command, or long-term maintenance contract?
+4. Would it be expensive to get wrong and likely to cause rework?
+
+If any answer is yes, default to `spec-needed`.
+
+## Classification guide
+
+### `small-bugfix`
+
+Use when all of the following are true:
+
+- low-risk
+- local
+- does not change product semantics
+- does not need a new user path or mechanism contract
+
+Typical examples:
+
+- typo or wording correction
+- obvious local regression
+- tiny implementation hole already covered by an existing spec
+
+### `boundary-fix`
+
+Use when the underlying issue is that current behavior drifted from the already chosen product boundary.
+
+Typical examples:
+
+- bridge exposed too much internal state
+- docs drifted away from current shipped model
+- implementation violated an existing constraint such as KISS or faithful bridge
+
+### `spec-needed`
+
+Use when the request introduces or changes product behavior in a way another engineer could not safely infer without a written contract.
+
+Typical examples:
+
+- new command or workflow
+- new approval or routing behavior
+- new desk asset contract
+- non-trivial capability packaging decision
+
+### `hold`
+
+Use when the idea has value but should not become active implementation input yet.
+
+Typical examples:
+
+- promising direction but unclear target user or trigger path
+- good enhancement but below current priority line
+- interesting thought that belongs in planning, not execution
+
+## Output template
+
+- 结论：`<classification>`
+- 原因：`<1-3 short bullets>`
+- 下一步：`<draft spec / fix locally / park in dashboard / align with existing spec>`

package/skills/memory-digest/SKILL.md

@@ -0,0 +1,9 @@
+# memory-digest
+
+Use this skill when consolidating raw archive material into durable workspace memory.
+
+## Output contract
+
+1. Produce a daily summary suitable for `memory/daily/YYYY-MM-DD.md`.
+2. Produce an updated long-term memory version suitable for `memory/long-term/MEMORY.md`.
+3. Keep facts inspectable, concise, and grep-friendly.

package/skills/post-implementation-closure/SKILL.md

@@ -0,0 +1,39 @@
+---
+name: post-implementation-closure
+description: Use this skill when implementation is largely done and you need to close the loop properly: self-review, run the right regression checks, verify doc drift, sync spec and dashboard state, and decide whether the change is truly ready to commit or report as done.
+---
+
+# Post Implementation Closure
+
+Use this skill after implementation, not before it.
+
+Do not use this skill when:
+
+- the task is still in active design or coding mode
+- you are still trying to find the root cause of a bug
+- no meaningful code, behavior, or documentation change has happened yet
+
+## Quick start
+
+1. Read `references/closure-checklist.md` first.
+2. Load the relevant spec and the affected user or maintainer docs.
+3. Review the diff before you report status.
+4. Run only the validations that actually match the changed surface.
+5. Use `references/doc-drift-map.md` to check whether README, quickstart, troubleshooting, dashboard, or spec state needs updating.
+
+## Output contract
+
+When you use this skill, the closure result should cover:
+
+1. review findings or an explicit `no findings`
+2. validation run and remaining gaps
+3. documentation updates made or explicitly not needed
+4. final readiness judgment
+
+## Working rules
+
+- Default to closing the loop yourself instead of returning a half-finished progress report.
+- Findings come before summaries.
+- Prefer clean-environment regression when shell or runtime environment pollution could hide the truth.
+- Do not mark a task done while spec, dashboard, or user-facing docs still reflect stale status.
+- If you could not verify something important, state the gap plainly instead of pretending closure is complete.

package/skills/post-implementation-closure/references/closure-checklist.md

@@ -0,0 +1,45 @@
+# Closure Checklist
+
+## 1. Review the change itself
+
+- Read the relevant diff.
+- Look for regressions, scope leaks, edge cases, missing cleanup, and documentation drift.
+- If the user asked for a review, present findings first.
+
+## 2. Run the right validation
+
+Choose the minimum set that matches the changed area.
+
+Examples:
+
+- shell or lifecycle change: `bash -n ally.sh`, related shell checks, `tests/shell/assistant.sh`
+- bridge channel or Feishu change: unit and integration channel tests
+- broad product change: `npm test` or the relevant narrowed suite
+- runtime or shell environment sensitivity: rerun with clean env
+
+## 3. Check documentation drift
+
+At minimum, reconsider whether any of these changed:
+
+- `README.md`
+- `docs/user-quickstart.md`
+- `docs/user-quickstart-desktop.md`
+- `docs/manual-acceptance.md`
+- `docs/troubleshooting.md`
+- `DASHBOARD.md`
+- current spec status or location
+
+## 4. Sync project state
+
+- If the work is done, move planning status to completed or implemented state.
+- If a topic is no longer active, remove it from the wrong dashboard lane.
+- If a spec is superseded or completed, make that relationship explicit.
+
+## 5. Final readiness judgment
+
+Only call the work closed when:
+
+- review is done
+- validation is done or gaps are explicitly called out
+- docs are aligned
+- status surfaces are aligned

package/skills/post-implementation-closure/references/doc-drift-map.md

@@ -0,0 +1,49 @@
+# Doc Drift Map
+
+## Change type -> Docs to recheck
+
+### User-visible CLI behavior
+
+Recheck:
+
+- `README.md`
+- `docs/user-quickstart.md`
+- `docs/manual-acceptance.md`
+- `docs/troubleshooting.md`
+
+### Desktop-only internal beta behavior
+
+Recheck:
+
+- `README.md`
+- `docs/user-quickstart-desktop.md`
+- relevant desktop implementation docs
+
+### Bridge semantics, approval, routing, or recovery behavior
+
+Recheck:
+
+- `README.md`
+- `docs/manual-acceptance.md`
+- `docs/troubleshooting.md`
+- relevant planning or completed spec
+- `DASHBOARD.md`
+
+### Product boundary or long-term direction
+
+Recheck:
+
+- `PRODUCT.md`
+- `AGENTS.md`
+- `README.md`
+- `DASHBOARD.md`
+- relevant spec state
+
+### Engineering-only workflow improvements
+
+Recheck:
+
+- `AGENTS.md`
+- `README.md`
+- `docs/developer-workflow.md`
+- `DASHBOARD.md`

package/skills/product-spec/SKILL.md

@@ -0,0 +1,244 @@
+---
+name: product-spec
+description: Use this skill when drafting, refining, reviewing, or self-scoring a product spec for work-ally. It applies the team spec standard, determines whether a request is non-trivial and needs a spec, identifies missing product inputs, guides clarification with the requester, and outputs either a spec draft or a readiness review against docs/product-spec-standard.md.
+---
+
+# Product Spec
+
+Use this skill only for product-spec work. Do not load it for normal coding, architecture debugging, or implementation tasks.
+
+## What this skill is for
+
+This skill exists to help product managers and collaborators produce a spec that is:
+
+- clear
+- understandable by others
+- ready for engineering handoff
+
+It is not a general writing style guide.
+
+The source of truth for the standard is:
+
+- [docs/product-spec-standard.md](../../docs/product-spec-standard.md)
+
+Read that file first when using this skill.
+
+## Trigger conditions
+
+Use this skill when the task is any of the following:
+
+- write a new product spec
+- turn a rough product idea into a spec
+- assess whether a request is non-trivial and needs a spec
+- review an existing spec against the team standard
+- self-score a spec before implementation
+- tighten a spec so another engineer can implement it without guesswork
+
+Do not use this skill when the task is only:
+
+- writing code
+- reviewing implementation details unrelated to product behavior
+- editing README / quickstart copy without product behavior changes
+
+## Non-trivial request rule
+
+A request is non-trivial and should become a spec if any of these are true:
+
+- it changes product meaning, default behavior, or user path
+- it introduces a new object, state, flow, or command
+- it crosses module, role, or system boundaries
+- it affects long-term product or maintenance semantics
+- it is expensive to get wrong and likely to cause rework
+
+If none of these are true, a full spec may not be necessary.
+
+## Modes
+
+This skill has four modes. Pick one explicitly based on the task.
+
+### 1. Draft
+
+Use when the requester has a rough idea and needs a new spec.
+
+Your job:
+
+- determine whether the request needs a spec
+- extract the real problem, not just the proposed solution
+- identify missing product inputs
+- ask only the minimum clarifying questions needed
+- produce a first spec draft using the team standard
+
+### 2. Refine
+
+Use when a draft spec exists but is not yet handoff-ready.
+
+Your job:
+
+- find unclear sections
+- strengthen `what / why / how`
+- tighten terminology
+- fill gaps in user path, mechanism, boundaries, and acceptance
+
+### 3. Review
+
+Use when evaluating an existing spec.
+
+Your job:
+
+- review against [docs/product-spec-standard.md](../../docs/product-spec-standard.md)
+- focus on missing clarity, ambiguity, mechanism gaps, scope confusion, and weak acceptance
+- state whether it is `Not ready`, `Ready for review`, or `Ready for implementation`
+
+### 4. Score
+
+Use when the requester wants a structured self-check.
+
+Your job:
+
+- run the quick yes/no gate first
+- then score against the 10-item rubric in the standard doc
+- explain deductions briefly
+- give a final readiness recommendation
+
+## Working method
+
+### Step 1: Load only the standard first
+
+Always start by reading:
+
+- [docs/product-spec-standard.md](../../docs/product-spec-standard.md)
+
+Do not load unrelated large docs unless the current spec references them or the task requires them.
+
+### Step 2: Classify the task
+
+Determine:
+
+- Does this request need a spec?
+- Is the user asking to draft, refine, review, or score?
+- Is the current input enough to proceed, or are key product inputs missing?
+
+### Step 3: Check the six essentials
+
+Before calling a spec handoff-ready, verify that it clearly answers:
+
+1. what it is
+2. why it matters
+3. scope
+4. user path
+5. mechanism
+6. completion criteria
+
+If any of these are materially unclear, do not mark it ready for implementation.
+
+### Step 4: Be strict on mechanism when needed
+
+If the feature includes any of the following, require explicit mechanism design:
+
+- new object
+- new ID / key
+- new state or state transition
+- new command / entry point
+- new default behavior
+- current vs history behavior
+- persistent storage changes
+- migration or fallback logic
+
+In those cases, do not accept a spec that only explains direction.
+
+### Step 5: Keep the spec lightweight
+
+Do not force the full long template on every request.
+
+Default expectation:
+
+- use the minimal structure for ordinary features
+- use expanded structure only when complexity truly requires it
+
+The goal is not “complete paperwork”. The goal is “clear enough that another engineer can implement correctly”.
+
+If the spec includes `Scope / Phase`, require that each phase be a user-value delivery slice, not an engineering task list. Treat `build UI / wire API / storage refactor / integration` style phases as a spec-quality problem, not as acceptable structure.
+
+## Clarification policy
+
+This skill should not pretend unclear requests are implementation-ready.
+
+When core inputs are missing, ask for only the minimum needed to unblock product clarity. Typical missing inputs are:
+
+- target user or role
+- main user path
+- default behavior
+- non-goals
+- success condition
+- boundary with existing behavior
+
+Do not ask broad brainstorming questions if the gap can be reasonably inferred.
+
+## Output contracts
+
+### If drafting a spec
+
+Output should include:
+
+- a concise readiness statement
+- missing assumptions called out explicitly
+- a spec draft aligned to the standard
+
+### If reviewing a spec
+
+Output should include, in this order:
+
+- findings
+- readiness verdict
+- concrete next fixes
+
+Prioritize:
+
+- unclear problem definition
+- weak mechanism design
+- object / ID / state ambiguity
+- acceptance that cannot be tested
+- scope leaks and missing non-goals
+- `Scope / Phase` written as engineering task sequencing instead of user-value delivery
+
+### If scoring a spec
+
+Output should include:
+
+- quick gate result
+- 10-item score table or list
+- total score
+- final verdict
+
+## Readiness labels
+
+Use exactly these labels:
+
+- `Not ready`
+- `Ready for review`
+- `Ready for implementation`
+
+Use them consistently with the team standard.
+
+## Review posture
+
+Be direct and pragmatic.
+
+Do not praise a spec for being long.
+Do not reject a spec just because it is short.
+Reject specs that still require the author to explain the important parts verbally.
+
+## Suggested structure defaults
+
+For most specs, prefer the minimal structure:
+
+1. Summary
+2. 背景
+3. 问题定义
+4. 目标 / 非目标
+5. 产品定义与用户路径
+6. 机制设计
+7. 验收标准
+8. 风险 / 假设 / 待决问题
+
+Only expand beyond this when the feature complexity warrants it.

package/templates/env.example

@@ -0,0 +1,5 @@
+WORK_ALLY_ALLOWED_USER_IDS=
+FEISHU_APP_ID=
+FEISHU_APP_SECRET=
+WORK_ALLY_ASSISTANT_NAME=
+WORK_ALLY_ASSISTANT_GIT_REMOTE=

package/templates/routines/nightly-memory-digest.yaml

@@ -0,0 +1,10 @@
+id: nightly-memory-digest
+description: Summarize today's archive into daily and long-term memory
+schedule: '0 23 * * *'
+enabled: true
+type: memory_digest
+thread_mode: new
+push:
+  kind: none
+writeback:
+  kind: none

package/templates/workspace/AGENTS.md

@@ -0,0 +1,26 @@
+# AGENTS.md
+
+## Role
+
+You are the dedicated AI partner for this workspace.
+
+## Core rules
+
+- Read the relevant files before acting.
+- Respect the existing code, docs, and operating context.
+- Keep durable conclusions in workspace files when appropriate.
+- Prefer inspectable file changes over hidden state.
+- Treat `memory/`, `knowledge/`, and `docs/` as workspace assets, not disposable scratch space.
+
+## Remote docs
+
+- You may read a provided remote document link as reference context.
+- Do not modify an existing remote document unless the user explicitly asks you to update that exact document.
+- If the user shares a document link without edit intent, treat it as read-only context by default.
+- If a result should be written back remotely, confirm the target and the write intent before editing.
+
+## Collaboration
+
+- When a task changes real files or process behavior, explain what changed in plain language.
+- When work produces durable output, prefer writing it back into the workspace.
+- Keep the workspace coherent for the next human and the next session.